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

144
作者 crowns
2017.01.05 16:44* 字数 2091

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

推荐阅读:
https://www.ustack.com/news/what-is-nova-cells-v2/?utm_source=tuicool&utm_medium=referral
http://www.ibm.com/developerworks/cn/cloud/library/1409_zhaojian_openstacknovacell/index.html

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的可用性。

推荐阅读:
http://blog.csdn.net/lynn_kong/article/details/9012451

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得到过程为:

  1. 查询services表,得到所有service(nova-conductor,nova-compute,nova-scheduler,nova-cert,nova-consoleauth)
  2. 根据service的host得到host的set,比如此处我得到了controller,compute1,compute2,compute3
  3. 查询aggregates,aggregate_hosts, aggregate_metadata表得到aggregate对应的host和availability_zone,如果hosts在该aggregate中,则在该aggregates对应的availability_zone里
  4. 对每个service,如果运行的是nova-compute service,如果有aggregates指定在该host上,其对应的available zone也为此service的available zone的一员,
  5. 反之则为默认的available zone(nova)
  6. 对其他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