From 662a43a085d461df740b5d239ee307ae1e097162 Mon Sep 17 00:00:00 2001 From: Ildiko Date: Tue, 16 Sep 2014 14:26:20 +0200 Subject: [PATCH] Add description about central and compute agent HA Add description about the HA support for central and compute agent of Telemetry into the Admin Guide chapter. Also a typo is fixed. Change-Id: Iefc70f4d12ec126452103bc1c888751a95698310 --- .../section_telemetry-data-collection.xml | 86 ++++++++++++++++--- .../section_telemetry-system-architecture.xml | 10 +-- 2 files changed, 77 insertions(+), 19 deletions(-) diff --git a/doc/admin-guide-cloud/telemetry/section_telemetry-data-collection.xml b/doc/admin-guide-cloud/telemetry/section_telemetry-data-collection.xml index b238d57cf6..180cd406c8 100644 --- a/doc/admin-guide-cloud/telemetry/section_telemetry-data-collection.xml +++ b/doc/admin-guide-cloud/telemetry/section_telemetry-data-collection.xml @@ -225,10 +225,10 @@ "http://docs.openstack.org/trunk/install-guide/install/apt/content/ceilometer-install.html"> Install the Telemtery module section in the OpenStack Installation Guide. - The central agent can be run as a single instance currently. It does not need - any database connection directly. The samples collected by this agent are sent via - message queue to the collector service, which is responsible for persisting the - data into the configured database backend. + The central agent does not need direct database connection. The + samples collected by this agent are sent via message queue to the collector + service, which is responsible for persisting the data into the configured + database back end.
Compute agent @@ -250,7 +250,7 @@ . The compute agent uses the API of the hypervisor installed on the compute hosts. Therefore the supported meters can be different in case of each virtualization - backend, as these tools provide different set of metrics. + back end, as these tools provide different set of metrics. The list of collected meters can be found in the Compute section in the Telemetery Measurements Reference. @@ -260,6 +260,68 @@ Telemetry supports Libvirt, which hides the hypervisor under it.
+
+ Support for HA deployment of the central and compute agent services + Both the central and the compute agent can run in an HA deployment, which + means that multiple instances of these services can run in parallel + with workload partitioning among these running instances. + The Tooz + library provides the coordination within the groups of service instances. It + provides an API above several back ends that can be used for building + distributed applications. + Tooz supports the following back-end solutions: + + + Zookeeper. + Recommended solution by the Tooz project. + + + Memcached + + + You must configure these back ends to use either of them for the HA deployment + of the Telemetry services. + For information about the required configuration options that have to be set in the + ceilometer.conf configuration file for both the central and compute + agents, see the + + coordination section + in the OpenStack Configuration Reference. + + Without the option being set only one + instance of both the central and compute agent service is able to run + and function correctly. + + The availability check of the instances is provided by heartbeat + messages. When the connection with an instance is lost, the workload will be + reassigned within the remained instances in the next polling cycle. + + Memcached uses a value, which + should always be set to a value that is higher than the + value set for Telemetry. + + For backward compatibility and supporting existing deployments, the central agent + configuration also supports using different configuration files for groups of service + instances of this type that are running in parallel. For enabling this configuration + set a value for the option in the + + central section in the OpenStack Configuration + Reference. + + For each sub-group of the central agent pool with the same + a disjoint subset of meters must be polled, + otherwise samples may be missing or duplicated. The list of meters to poll can be set + in the /etc/ceilometer/pipeline.yaml configuration + file. For more information about pipelines see + . + + To enable the compute agent to run multiple instances simultaneously with + workload partitioning, the + option has to be set to True + under the + compute section in the ceilometer.conf configuration + file. +
Send samples to Telemetry @@ -637,12 +699,12 @@ sinks: Storing samples The Telemetry module has a separate service that is responsible for persisting the data that is coming from the pollsters or received as notifications. The data is stored in - a database backend, the list of supported databases can be found in + a database back end, the list of supported databases can be found in . The ceilometer-collector service receives the samples as metering messages from the message bus of the configured AMQP service. It stores - these samples without any modification in the configured backend. The service has to run on + these samples without any modification in the configured back end. The service has to run on a host machine from which it has access to the database. Multiple ceilometer-collector process can be run at a time. It is also supported to start multiple worker threads per collector process. @@ -652,7 +714,7 @@ sinks: collector section of the ceilometer.conf configuration file. Using multiple workers per collector process is not recommended to be used with - PostgreSQL as database backend. + PostgreSQL as database back end. By default the time to live value (ttl) for samples is set to -1, which means that they are kept in the database forever. This can be changed by modifying the time_to_live @@ -664,9 +726,9 @@ sinks: these useless entries, which is called ceilometer-expirer. This script should be run periodically, for instance in a cron job, to ensure that the database is cleaned up properly. - The level of support differs in case of the configured backend: + The level of support differs in case of the configured back end: - + @@ -689,8 +751,8 @@ sinks: - - +
Time-to-live support for database backendsTime-to-live support for database back ends
SQL-based backendsThe library (SQLAlchemy) that is used for accessing SQL-based backends does + SQL-based back endsThe library (SQLAlchemy) that is used for accessing SQL-based back ends does not support using the ttl value. ceilometer-expirer has to be used for deleting both the samples and the remaining entires in other diff --git a/doc/admin-guide-cloud/telemetry/section_telemetry-system-architecture.xml b/doc/admin-guide-cloud/telemetry/section_telemetry-system-architecture.xml index a67af78a51..14198363a1 100644 --- a/doc/admin-guide-cloud/telemetry/section_telemetry-system-architecture.xml +++ b/doc/admin-guide-cloud/telemetry/section_telemetry-system-architecture.xml @@ -67,10 +67,6 @@ Besides the ceilometer-agent-compute service, all the other services are placed on one or more controller nodes. - - The ceilometer-agent-central service does - not support multiple running instances at a time, it can have only one. - The Telemetry architecture highly depends on the AMQP service both for consuming notifications coming from OpenStack services and internal communication.
@@ -78,10 +74,10 @@ The other key external component of Telemetry is the database, where the samples, alarm definitions and alarms are stored. - Multiple database backends can be configured in order to store samples and alarms + Multiple database back ends can be configured in order to store samples and alarms separately. - The list of supported database backends: + The list of supported database back ends: @@ -165,7 +161,7 @@
- Suported networking services + Supported networking services Telemetry is able to retrieve information from OpenStack Networking and external networking services: