Synnefo » snf-ganeti » ganeti-local

================

Node State Cache

================

.. contents:: :depth: 4

This is a design doc about the optimization of machine info retrieval.

Current State

=============

Currently every RPC call is quite expensive as a TCP handshake has to be

made as well as SSL negotiation. This especially is visible when getting

node and instance info over and over again.

This data, however, is quite easy to cache but needs some changes to how

we retrieve data in the RPC as this is spread over several RPC calls

and are hard to unify.

Proposed changes

================

To overcome this situation with multiple information retrieval calls we

introduce one single RPC call to get all the info in a organized manner,

for easy store in the cache.

As of now we have 3 different information RPC calls:

- ``call_node_info``: To retrieve disk and hyper-visor information

- ``call_instance_info``: To retrieve hyper-visor information for one

  instance

- ``call_all_instance_info``: To retrieve hyper-visor information for

  all instances

Not to mention that ``call_all_instance_info`` and

``call_instance_info`` return different information in the dict.

To unify the data and organize them we introduce a new RPC call

``call_node_snapshot`` doing all of the above in one go. Which

data we want to know will be specified about a dict of request

types: CACHE_REQ_HV, CACHE_REQ_DISKINFO, CACHE_REQ_BOOTID

As this cache is representing the state of a given node we use the

name of a node as the key to retrieve the data from the cache. A

name-space separation of node and instance data is not possible at the

current point. This is due to the fact that some of the node hyper-visor

information like free memory is correlating with instances running.

An example of how the data for a node in the cache looks like::

  {

    constants.CACHE_REQ_HV: {

      constants.HT_XEN_PVM: {

        _NODE_DATA: {

          "memory_total": 32763,

          "memory_free": 9159,

          "memory_dom0": 1024,

          "cpu_total": 4,

          "cpu_sockets": 2

        },

        _INSTANCES_DATA: {

          "inst1": {

            "memory": 4096,

            "state": "-b----",

            "time": 102399.3,

            "vcpus": 1

          },

          "inst2": {

            "memory": 4096,

            "state": "-b----",

            "time": 12280.0,

            "vcpus": 3

          }

        }

      }

    },

    constants.CACHE_REQ_DISKINFO: {

      "xenvg": {

        "vg_size": 1048576,

        "vg_free": 491520

      },

    }

    constants.CACHE_REQ_BOOTID: "0dd0983c-913d-4ce6-ad94-0eceb77b69f9"

  }

This way we get easy to organize information which can simply be arranged in

the cache.

The 3 RPC calls mentioned above will remain for compatibility reason but

will be simple wrappers around this RPC call.

Cache invalidation

------------------

The cache is invalidated at every RPC call which is not proven to not

modify the state of a given node. This is to avoid inconsistency between

cache and actual node state.

There are some corner cases which invalidates the whole cache at once as

they usually affect other nodes states too:

 - migrate/failover

 - import/export

A request will be served from the cache if and only if it can be

fulfilled entirely from it (i.e. all the CACHE_REQ_* entries are already

present). Otherwise, we will invalidate the cache and actually do the

remote call.

In addition, every cache entry will have a TTL of about 10 minutes which

should be enough to accommodate most use cases.

We also allow an option to the calls to bypass the cache completely and

do a force remote call. However, this will invalidate the present

entries and populate the cache with the new retrieved values.

Additional cache population

---------------------------

Besides of the commands which calls above RPC calls, a full cache

population can also be done by a separate new op-code run by

``ganeti-watcher`` periodically. This op-code will be used instead of

the old ones.

Possible regressions

====================

As we change from getting "one hyper-visor information" to "get all we

know about this hyper-visor"-style we have a regression in time of

execution. The execution time is about 1.8x more in process execution

time. However, this does not include the latency and negotiation time

needed for each separate RPC call. Also if we hit the cache all 3 costs

will be 0. The only time taken is to look up the info in the cache and

the deserialization of the data. Which takes down the time from today

~300ms to ~100ms.

.. vim: set textwidth=72 :

.. Local Variables:

.. mode: rst

.. fill-column: 72

.. End: