理解openstack中region、cell、availability zone、host aggregate 概念

openstack中region、cell、availability zone、host aggregate 几个概念都是对节点进行划分，具体有什么区别呢？

Region、Availability Zone最开始是亚马逊 AWS（Amazon Web Service）的概念，整个 AWS 被按照地域划分成了若干 Region，而每个 Region 中可以有多个 Availability Zone。在 AWS 中，每个 Availability Zone 是网络独立的，但是同一个 Region 内部的 Availability Zone 一般会通过一些其他的网络设备相连接，可以查看亚马逊的官方文档了解更多有关 Region 和 Availability Zone 的概念。为了表达方便，本文之后将 Availability Zone 简称为 AZ。

Paste_Image.png

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 的环境一样处理该请求。

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。

/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。

因此创建一个aggregate后，同时把它作为一个zone，此时aggregate=zone。因为大家知道，aggregate是管理员可见，普通用户不可见的对象，那么这个改变，就可以使普通用户能够通过使用zone的方式来使用aggregate。

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

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

在horizon上创建instance时，要制定available zone，执行：

zones =api.nova.availability_zone_list(request)

然后调用nova client的rest call：

return self._list("/os-availability-zone", self.return_parameter_name)

在nova/api/openstack/compute/contrib/availability_zone.py中，调用AvailabilityZoneController的index方法，trace一下，

 def _describe_availability_zones：
     available_zones, not_available_zones = availability_zones.get_availability_zones(ctxt)

trace这个函数，同时进去数据库，跟着看数据库中services和aggregates两个表的内容，available zone list得到过程为：

查询services表，得到所有service（nova-conductor，nova-compute，nova-scheduler，nova-cert，nova-consoleauth）
根据service的host得到host的set，比如此处我得到了controller，compute1，compute2，compute3
查询aggregates，aggregate_hosts, aggregate_metadata表得到aggregate对应的host和availability_zone，如果hosts在该aggregate中，则在该aggregates对应的availability_zone里
对每个service，如果运行的是nova-compute service，如果有aggregates指定在该host上，其对应的available zone也为此service的available zone的一员，
反之则为默认的available zone（nova）
对其他service，available_zone为internal default available zone(internal)

即通过services找host，通过host找aggregate，再通过aggregate找availability_zone。

5. 总结

AZ是用户可见的，用户手动的来指定vm运行在哪些host上；Host Aggregate是调度器可见的，影响调度策略的一个表达式。

G版开始，通过Aggregate操作AZ，使得不用修改配置文件重启服务就能修改节点的AZ。但同时也带来一个问题，使得节点可以跨AZ，在使用时要注意，建议建立Aggreate与AZ一一对应的关系，然后再创建带属性的Aggreate。

不明白社区为什么不通过直接修改services表中availability_zone字段进行修改AZ，而要通过Aggreate来关联AZ，望明白的同学告诉我，谢谢。

6. 来源

http://www.cnblogs.com/xingyun/p/4703325.html
http://www.ibm.com/developerworks/cn/cloud/library/1607-openstack-neutron-availability-zone/
http://blog.csdn.net/dingdingwolf/article/details/45462321

理解openstack中region、cell、availability zone、host aggregate 概念