Openstack关于Regions和Availability Zones

在AWS中有Region和Availability Zones的概念，并且在openstack中也实现了两者，只是不太容易看出来。

此文主要介绍他们的概念和关系，以及在openstack中的实现。

如果没有特别强调，下文中Availability Zones简称az。

 

概述

===

    一般情况下region表示地理上隔离的两个区域，例如一个region放在美国，另外一个放在中国。换句话说一个region之间是相对独立的，一个region的死活和另外一个region没有任何关系。az是在region范围内的再次切分，只是工程上的独立，例如可以把一个机架上的机器划分在一个az中。划分az是为了提高容灾性和提供廉价的隔离服务。
    选择不同的region主要考虑哪个region靠近你的用户群体，如果用户主要在美国，那么自然选择离美国近的region。选择不同的az，是为了防止在所有instance一起挂掉。

 下图是两者之间的关系图

Region 和Availability Zones

======

 Region是最高等级的隔离，因为region是地理位置的隔离。例如一个美国，一个中国，那么当你的虚拟机分别跑在这两个region上，那么当美国不存在的时候，你在中国的虚拟机还在快乐的运行着。

而且如果目标用户多数在中国，那么将虚拟机跑在中国也是很好的选择。

az是低一级的隔离。例如我们可以在中国的datacenter划分为几个az，然后用户可以选择将这些虚拟机跑在同一个az中，或者不同az中。前者可以提供更快的网络，后者提供更好的容灾性。

 

Openstack实现

在openstack中这两个概念都是存在的。一下将会介绍openstack是如何实现这两个概念的。

 

 

region

因为Region是地理位置的隔离，那么不同的region意味着不同的endpoint，也就是说（nova-api，glance……）这些服务的ip地址是不同的。这些东西就体现在keystone的catalog中。

以下是keystone的catalog配置文件：

catalog.RegionOne.identity.publicURL = http://keystone.cn:$(public_port)s/v2.0  
catalog.RegionOne.compute.publicURL = http://nova.cn:$(compute_port)s/v1.1/$(tenant_id)s  
catalog.RegionOne.volume.publicURL = http://cinder.cn:8776/v1/$(tenant_id)s  
catalog.RegionOne.ec2.publicURL = http://nova.cn:8773/services/Cloud  
catalog.RegionOne.image.publicURL = http://glance.cn:9292/v1  

注意到catalog其实是分级的  <catalog>.<region>.<service>.<endpoint>，第二级的region就是上文提到的region。在这里我们可以设置不同的region和不同的service的endpoint。

例如我们在美国加了一个datacenter，那么我们修改配置文件为

catalog.RegionOne.identity.publicURL = http://keystone.cn:$(public_port)s/v2.0  
catalog.RegionOne.compute.publicURL = http://nova.cn:$(compute_port)s/v1.1/$(tenant_id)s  
catalog.RegionOne.volume.publicURL = http://cinder.cn:8776/v1/$(tenant_id)s  
catalog.RegionOne.ec2.publicURL = http://nova.cn:8773/services/Cloud  
catalog.RegionOne.image.publicURL = http://glance.cn:9292/v1  
  
catalog.RegionUS.identity.publicURL = http://keystone.us:$(public_port)s/v2.0  
catalog.RegionUS.compute.publicURL = http://nova.us:$(compute_port)s/v1.1/$(tenant_id)s  
catalog.RegionUS.volume.publicURL = http://cinder.us:8776/v1/$(tenant_id)s  
catalog.RegionUS.ec2.publicURL = http://nova.us:8773/services/Cloud  
catalog.RegionUS.image.publicURL = http://glance.us:9292/v1 

这样以后我们就可以通过选择不同的region来访问不同的endpoint了。

ps：现在horizon默认只提取keystone中catalog的regionOne中的endpoint，所以即使在keystone配置了多个region，在horizon也是体现不出来的。

 

 

Availability Zones

az在openstack中其实是nova-scheduler来实现的，当新建虚拟机，调度器将会根据nova-compute设置的az来调度，例如在新建虚拟机的时候，用户设置了希望将虚拟机放在az-1中，那么调度器将会选择属于这个az的nova-compute来调度。如下图所示

其实Region和Az的概念主要是隔离的等级问题，我们完全可以将一个datacenter根据机房划分region，然后根据机架划分az。

这个就是仁者见仁的问题，完全可以根据各自的需要采取不同的部署方法。

 

在介绍几个隔离方式

Cells

cell英译细胞，主要解决openstack的扩展性和规模瓶颈（rabbitmq和database组件），通过每个cell引进自己独立的rabbitmq和db来解决。

cell被实现为树形的分级调度，在每个cell中引入cell的概念：

（1）Messages的路由，即父cell通过nova-cell将Messages路由到子cell的AMQP模块。

 

（2）分级调度功能，即调度某个instances的时候先要进行cell的选择，根据调度策略。
（3）资源统计，子cell定时的将自己的资源信息上报给父cell，用来给分级调度策略提供决策数据和基于cell的资源监控。
（4）cell之间的通信（通过rpc完成）
  最后，所有的子cell公用底层cell的nova-api，子cell包含除了nova-api之外的其他nova服务，当然所有的cell都共用keystone服务。
（注：nova-*是指除了nova-api之外的其他nova服务，子cell + 父cell才构成了完整的nova服务）

小结一下：我的理解就是在原来的nova-api访其他服务之前加了一层，先选择哪个子cell来提供计算服务。父cell才有nova api服务，子cell提供nova的其他服务，cell之间通过nova-cell把消息传递到子cell的rabbitmq(AMQP)。

 

 

Host Aggregate

除了AZ，计算结点也可以被逻辑上划分为主机集合，具有相同特性的集群，比如使用一个带有SSD磁盘的主机集合，或一个装有万兆网卡的主机集合。Host Aggregates是用户不可见的概念。

小结一下：AZ用于让用户指定从哪个特定的服务器组合里发起虚拟机，主机集合主要用来为具有特定性能的主机分组以此让调度器根据某种特性在特定的集合中发起虚拟机。

是否有基于硬件能力的隔离， 如果有很可能要使用HA。

 

 

 

以上是一些openstack的区域分级的概念，当然keystone里面还有分domain，project，Telnet，user，role等的概念后面另外再介绍。