openstack中region、az、host aggregate、cell 概念

1. region

　　更像是一个地理上的概念，每一个region有本身独立的endpoint，regions之间彻底隔离，可是多个regions之间共享同一个keystone和dashboard。（注：目前openstack的dashboard还不支持多region）

　　因此除了提供隔离的功能，region的设计更多侧重地理位置的概念，用户能够选择离本身更近的region来部署本身的服务。

2. cell

　　cell是openstack一个很是重要的概念，主要用来解决openstack的扩展性和规模瓶颈。众所周知，openstack是由不少的组件经过松耦合构成，那么当达到必定的规模后，某些模块必然成为整个系统的瓶颈。比较典型的组件就是database和AMQP了，因此，每一个cell有本身独立的DB和AMQP。

　　另外，因为cell被实现为树形结构，天然而然引入了分级调度的概念。经过在每级cell引入nova-cell服务，实现了如下功能：

• Messages的路由，即父cell经过nova-cell将Messages路由到子cell的AMQP模块
• 分级调度功能，即调度某个instances的时候先要进行cell的选择，目前只支持随机调度，后续会增长基于filter和weighing策略的调度
• 资源统计，子cell定时的将本身的资源信息上报给父cell，用来给分级调度策略提供决策数据和基于cell的资源监控
• cell之间的通讯(经过rpc完成)

　　最后，全部的子cell公用底层cell的nova-api，子cell包含除了nova-api以外的其余nova服务，固然全部的cell都共用keystone服务。

　　（注：nova-*是指除了nova-api以外的其余nova服务，子cell + 父cell才构成了完整的nova服务）

　　

　　每个 Cell 包含独立的 Message Broker 以及 Database，其中 API Cell 主要包含 nova-api 服务，用于接收用户请求，并将用户请求经过 message 的形式发送至指定的 Cell；Child Cell 包含除 nova-api 以外的全部 nova-*服务，实现具体的 Nova Compute 节点服务;API Cell 与 Child Cell 共享 Glance 服务，且各 Cells 之间的通讯均经过 nova cells 服务进行。Cell 调度独立于与 host 调度，在建立新的实例时，首先由 nova-cells 选择一个 Cell。当 Cell 肯定后，实例建立请求会被送达目标 Cell 的 nova-cells 服务，随后该请求会被交给本 Cell 的主机调度机制处理，此时主机调度机制会像未配置 Cell 的环境同样处理该请求。

　　 http://www.ibm.com/developerworks/cn/cloud/library/1409_zhaojian_openstacknovacell/index.html

3. Availability Zone

　　AZ能够简单理解为一组节点的集合，这组节点具备独立的电力供应设备，好比一个个独立供电的机房，一个个独立供电的机架均可以被划分红AZ。因此，AZ主要是经过冗余来解决可用性问题。　　

　　AZ是用户可见的一个概念，用户在建立instance的时候能够选择建立到哪些AZ中，以保证instance的可用性。

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

　　AZ是一个面向用户的概念和能力，而host aggregate是管理员用来根据硬件资源的某一属性来对硬件进行划分的功能，只对管理员可见，主要用来给nova-scheduler经过某一属性来进行instance的调度。其主要功能就是实现根据某一属性来划分物理机，好比按照地理位置，使用固态硬盘的机器，内存超过32G的机器，根据这些指标来构成一个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 1 node1
+----+---------+-------------------+-----------+-------------------+
| Id | Name    | Availability Zone | Hosts      | Metadata          |
+----+---------+-------------------+------------+-------------------+
| 1  | fast-io | nova              | [u'node1'] | {u'ssd': u'true'} |
+----+---------+-------------------+------------+-------------------+

$ nova aggregate-add-host 1 node2
+----+---------+-------------------+---------------------+-------------------+
| 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 80 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, when 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 are node1 and node2.

　　另外，G版中，默认状况下，对Nova服务分为两类，一类是controller节点的服务进程，如nova-api, nova-scheduler, nova-conductor等；另外一类是计算节点进程，nova-compute。对于第一类服务，默认的zone是配置项internal_service_availability_zone，而nova-compute所属的zone由配置项default_availability_zone决定。（这两个配置项仅在nova-api的节点起做用，horizon界面才会刷新）。

　　多是社区的开发人员意识到，让管理员经过配置的方式管理zone不太合适，不够灵活，因此在G版中将这一方式修改。就改用nova  aggregate-create 命令，在建立一个aggregate的同时，指定一个AZ。

root@controller:~# 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).  

　　所以建立一个aggregate后，同时把它做为一个zone，此时aggregate=zone。由于你们知道，aggregate是管理员可见，普通用户不可见的对象，那么这个改变，就可使普通用户可以经过使用zone的方式来使用aggregate。

　　建立完aggregate以后，向aggregate里加主机时，该主机就自动属于aggregate表示的zone。

　　在G版以后，能够认为aggregate在操做层面与AZ融合在一块儿了，但同时又不影响aggregate与flavor的配合使用，由于这是两个调度层面。同时又要注意，一个主机能够加入多个aggregate中，因此G版中一个主机能够同时属于多个Availability Zone，这一点也与以前的版本不一样。