Chapter 1. Introduction to autoscaling components
Chapter 1. Introduction to autoscaling components Use telemetry components to collect data about your Red Hat OpenStack Platform (RHOSP) environment, such as CPU, storage, and memory usage. You can launch and scale instances in response to workload demand and resource availability. You can define the upper and lower bounds of telemetry data that control the scaling of instances in your Orchestration service (heat) templates. Control automatic instance scaling with the following telemetry components: Data collection : Telemetry uses the data collection service (Ceilometer) to gather metric and event data. Storage : Telemetry stores metrics data in the time-series database service (gnocchi). Alarm : Telemetry uses the Alarming service (aodh) to trigger actions based on rules against metrics or event data collected by Ceilometer. 1.1. Data collection service (Ceilometer) for autoscaling You can use Ceilometer to collect data about metering and event information for Red Hat OpenStack Platform (RHOSP) components. The Ceilometer service uses three agents to collect data from RHOSP components: A compute agent (ceilometer-agent-compute) : Runs on each Compute node and polls for resource use statistics. A central agent (ceilometer-agent-central) : Runs on the Controller nodes to poll for resource use statistics for resources that are not provided by Compute nodes. A notification agent (ceilometer-agent-notification) : Runs on the Controller nodes and consumes messages from the message queues to build event and metering data. The Ceilometer agents use publishers to send data to the corresponding end points, for example the time-series database service (gnocchi). Additional resources Ceilometer in the Managing overcloud observability guide. 1.1.1. Publishers In Red Hat OpenStack Platform (RHOSP), you can use several transport methods to transfer the collected data into storage or external systems, such as Service Telemetry Framework (STF). When you enable the gnocchi publisher, the measurement and resource information is stored as time-series data. 1.2. Time-series database service (gnocchi) for autoscaling Gnocchi is a time-series database that you can use for storing metrics in SQL. The Alarming service (aodh) and Orchestration service (heat) use the data stored in gnocchi for autoscaling. Additional resources Storage with gnocchi . 1.3. Alarming service (aodh) You can configure the Alarming service (aodh) to trigger actions based on rules against metrics data collected by Ceilometer and stored in gnocchi. Alarms can be in one of the following states: Ok : The metric or event is in an acceptable state. Firing : The metric or event is outside of the defined Ok state. insufficient data : The alarm state is unknown, for example, if there is no data for the requested granularity, or the check has not been executed yet, and so on. 1.4. Orchestration service (heat) for autoscaling Director uses Orchestration service (heat) templates as the template format for the overcloud deployment. Heat templates are usually expressed in YAML format. The purpose of a template is to define and create a stack, which is a collection of resources that heat creates, and the configuration of the resources. Resources are objects in Red Hat OpenStack Platform (RHOSP) and can include compute resources, network configuration, security groups, scaling rules, and custom resources. Additional resources Understanding heat templates .