OpenStack G版之后的Availability Zone与Aggregate Hosts

 

 

    关于Availability Zone与Aggregate Hosts的概念解析，能够参考这篇文章：http://blog.chinaunix.net/uid-20940095-id-3875022.html

 

1. availability zone   

     az是在region范围内的再次切分，只是工程上的独立，例如能够把一个机架上的机器划分在一个az中，划分az是为了提升容灾性和提供廉价的隔离服务。选择不一样的region主要考虑哪一个region靠近你的用户群体，好比用户在美国，天然会选择离美国近的region；选择不一样的az是为了防止全部的instance一块儿挂掉，下图描述了两者之间的关系。

      catalog实际上是分级的  <catalog>.<region>.<service>.<endpoint>，第二级的region就是上文提到的region。在这里咱们能够设置不一样的region和不一样的service的endpoint。horizon只提取keystone中catalog的regionOne中的endpoint，因此，即便设置了多个region，horizon也体现不出来。

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

 

 

    

 

2. Aggregate Hosts   

　　Availability zones are a customer-facing capability, host aggregates are meant to be used by administrators to separate hardware by particular properties, and are not seen by customers.

　　az是一个面向终端客户的概念和能力，而host aggregate是管理员用来根据硬件资源的某一属性来对硬件进行划分的功能，只对管理员可见。

其主要功能就是实现根据某一属性来划分物理机，好比按照地理位置，使用固态硬盘的机器，内存超过32G的机器，根据这些指标来构成一个host group。

nova aggregate-create joesservers chicago

Host aggregate能够用来进一步细分availability zone。

     经过以上分析，问题就来了：availability zone和host aggregate都能对host machine进行划分，那么两者的区别是啥？

   　az是用户可见的，用户手动的来指定vm运行在哪些host上，即用户可见；Host aggregate是一种更智能的方式，是调度器可见的，影响调度策略的一个表达式

 

 

3.Openstack 中如何指定那些computer节点属于同一availability zone？   

　　　在G版之前，当咱们用nova-manage service list 查看nova服务启动的状态的时候，即看status是笑脸仍是XX，实际上是经过一个循环任务report_state，循环地向数据库service表中写入信息，好比一个计数report_count以及更新该记录的时间。而判断该服务状态时，就会读取Service表，看当前时刻与该服务上次更新的时间的差值是否在容许的范围内（配置项service_down_time），若是超出了service_down_time，就认为该服务状态异常。因此，总结一下，一个服务状态是XXX的缘由，要么是该服务出现了异常，要么是时间不一样步致使。

 

　　须要注意的是，在report_state中，除了report_count，还有一个更新的字段：availability_zone。该字段来源于配置项node_availability_zone。举个例子，一个nova-compute服务，它的Availability Zone就依赖于配置文件中的node_availability_zone配置项。同时，一个nova-compute仅属于一个AZ。还有一点要注意，咱们建立aggregate时也能够指定Availability Zone，而后向aggregate中添加主机时，要求主机的zone与aggregate的zone一致。

　　

　　所以，总结以下：每个computer node的属于哪个AZ，是经过nova.conf中的node_availability_zone配置项来指定，一个nova-compute仅属于一个AZ，而且建立Aggregate指定的AZ，在向其添加host的时候，应与host原属的AZ与其一致。

 

　　可是从G版开始之后的版本，好比我如今所用的H版里头，nova.conf里面就没有node_availability_zone的配置字段，虽然还留有一个default_availability_zone的配置项，但仅在nova-api节点起做用。所以在这个时候，若是想用户起虚拟机的时候能指定AZ，或将某一个compute node指定成一个AZ，该如何操做了？

 

　　G版中对服务的管理增长了不少方式，能够是老的更新数据的方式（若是节点很少，可使用这种，不会对数据库形成大的压力），但若是节点较多，使用数据库的方式就不太明智了，此时能够选择效率较高的memcached或者zookeeper。因而，Service表中也再也不保存availability_zone字段，配置项node_availability_zone也再也不使用。

 

　　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，这一点也与以前的版本不一样。

 

 

4.实际测试使用

　　　　1. 建立aggregate，指定zone 

　　　　　　#nova aggregate-create Aggregate1 az1

　　　　　　#nova aggregate-list 

　　　　2.添加主机

　　　　　　#nova aggregate-add-host Aggregate1 computer1

　　　　3. 查询主机与服务所属的zone

　　　　　　#nova host-list

　　　　　　#nova service-list

　　　　4. 再将主机加入另外一个aggregate，再次查询

　　　　　　#nova aggregate-create Aggregate2 az2

　　　　　　#nova aggregate-add-host Aggregate2 computer1

　　　　　　#nova host-list

　　　　　　#nova service-list

 

　　　　本文后部份内容参考来源：【OpenStack】F版和G版中的Availability Zone：http://blog.csdn.net/lynn_kong/article/details/9012451

　　　　　　　　　　　　　　　　　　更多精彩内容，敬请访问上一条连接！