OpenStack in Region, AZ, host aggregate, cell concept

1. Region

　　More like a geographic concept, each region has its own separate endpoint,regions between the two, but multiple regions share the same Keystone and dashboard. (Note: Currently OpenStack dashboard does not support multiple region)

So in addition to providing isolation, the region's design is more geographically oriented, and users can choose to deploy their services in a region closer to themselves.

2. Cell

　　The cell is a very important concept for OpenStack, primarily to address the scalability and scale bottlenecks of OpenStack. As we all know, OpenStack is composed of many components through loose coupling, so when we reach a certain scale, some modules will inevitably become the bottleneck of the whole system. The more typical components are database and AMQP, so each cell has its own independent DB and AMQP.

In addition, because the cell is implemented as a tree structure, the concept of hierarchical scheduling is introduced naturally. By introducing Nova-cell services at each level of cells, the following functions are implemented:

• Messages route, the AMQP module that the parent cell routes messages to the child cell via Nova-cell
• Hierarchical scheduling function, that is, the scheduling of a instances first to the cell selection, currently only support random scheduling, followed by the increase of the filter and weighing policy-based scheduling
• Resource statistics, the sub-cell timed its own resource information to the parent cell, to provide decision-making data and cell-based resource monitoring for the hierarchical scheduling policy
• Communication between cells (completed via RPC

Finally, all of the sub-cells are common to the nova-api of the underlying cell, and the child cell contains the Nova service in addition to the NOVA-API, and of course all cells share the Keystone service.

(Note: nova-* refers to a Nova service other than Nova-api, where the child cell + parent cell constitutes the full Nova service)

　　cell is still under study http://www.ibm.com/developerworks/cn/cloud/library/1409_zhaojian_openstacknovacell/index.html

3. Availability Zone

AZ can be simply understood as a set of nodes that have independent power supply devices, such as individual power-supply rooms, each independently powered rack can be divided into AZ. As a result, AZ solves usability problems primarily through redundancy.

AZ is a user-visible concept that allows users to choose which AZ to create instance to ensure the availability of instance.

4. Host Aggregate (http://docs.openstack.org/havana/config-reference/content/host-aggregates.html)

　　AZ is a user-oriented concept and capability, and host aggregate is a feature that administrators use to partition hardware according to a property of hardware resources, only visible to the administrator, mainly used to give nova-scheduler through a property to instance scheduling. Its main function is to achieve a certain attribute to divide the physical machine, such as geographical location, the use of solid-state drive machines, more than 32G of memory machines, based on these indicators to form a host group.

Example:specify Compute hosts with SSDs

/etc/nova/nova.conf:scheduler_default_filters= aggregateinstanceextraspecsfilter, availabilityzonefilter,ramfilter,computefilter$ Nova Aggregate -create fast-io Nova+----+---------+-------------------+-------+----------+| Id | Name | Availability Zone | Hosts | Metadata |+----+---------+-------------------+-------+----------+| 1 | Fast-io |       Nova |          | |+----+---------+-------------------+-------+----------+$ nova Aggregate-set-metadata 1 ssd=true+----+---------+-------------------+-------+-------------------+| Id | Name | Availability Zone | Hosts | Metadata |+----+---------+-------------------+-------+-------------------+| 1 | Fast-io | Nova | []    | {u'SSD': U'true'} |+----+---------+-------------------+-------+-------------------+$ nova Aggregate-add-host 1Node1+----+---------+-------------------+-----------+-------------------+| Id | Name | Availability Zone | Hosts | Metadata |+----+---------+-------------------+------------+-------------------+| 1 | Fast-io | Nova | [u'Node1'] | {u'SSD'8 7'true'} |+----+---------+-------------------+------------+-------------------+$ nova Aggregate-add-host 1Node2+----+---------+-------------------+---------------------+-------------------+| Id | Name | Availability Zone | Hosts | Metadata |+----+---------+-------------------+----------------------+-------------------+| 1 | Fast-io | Nova | [u'Node1', u'Node2'] |{u'SSD': U'true'}|+----+---------+-------------------+----------------------+-------------------+$ Nova Flavor-create Ssd.large 6 8192 4+----+-----------+-----------+------+-----------+------+-------+-------------+-------- ---+-------------+| ID | Name | MEMORY_MB | Disk | Ephemeral | Swap | Vcpus | Rxtx_factor | Is_public | Extra_specs |+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------- -----+| 6 | Ssd.large | 8192 | 80 |      0 | | 4 | 1 | True | {}          |+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+#Nova Flavor-key set_key--name=ssd.large--KEY=SSD--value=true$ Nova flavor-Show Ssd.large+----------------------------+-------------------+| Property | Value |+----------------------------+-------------------+| os-flv-disabled:disabled | False | | os-flv-ext-data:ephemeral | 0 | | Disk | 80 | | Extra_specs |{u'SSD': U'true'}|| ID | 6 | | name | Ssd.large | | Os-flavor-access:is_public | True | | Ram | 8192 | | Rxtx_factor | 1.0 | |                   Swap | || Vcpus | 4 |+----------------------------+-------------------+Now , if a user requests an instance with the Ssd.large flavor, the scheduler only considers hosts with the SSD=true Key-value pair. In this example, these is Node1 andNode2.

In addition, in the G version, by default, the Nova service is divided into two categories, one is the Controller node service process, such as Nova-api, Nova-scheduler, Nova-conductor, etc., the other is the compute node process, Nova-compute. For the first type of service, the default zone is the configuration item internal_service_availability_zone, and the zone Nova-compute belongs to is determined by the configuration item Default_availability_zone. (These two configuration items only work on NOVA-API nodes, and the Horizon interface refreshes).

It may be that community developers realize that it is not appropriate and inflexible to have administrators manage zones in a configured way, so this is modified in version G. Instead, use the Nova aggregate-create command to specify an AZ while creating a aggregate.

[Email protected]:~#  Nova help aggregate-create  Usage:nova aggregate-create <name> [< Availability-zone>]    Create A new aggregate with the specified details.    Positional arguments:    <name>               name of aggregate.     <availability-zone> the  availability Zone of the aggregate (optional).  

So after creating a aggregate, take it as a zone at this time aggregate=zone. Because you know, aggregate is the administrator visible, ordinary users are not visible objects, then this change, you can enable ordinary users to use the zone to use the aggregate way.

After aggregate is created, when the host is added to aggregate, the host automatically belongs to the zone represented by aggregate.

After the G version, it can be considered that the aggregate is fused with AZ at the operational level, but at the same time does not affect the use of aggregate and flavor , as this is a two scheduling level. Also note that a host can join multiple aggregate, so the G version of a host can belong to multiple availability Zone at the same time, which is different from the previous version.

OpenStack in Region, AZ, host aggregate, cell concept