openstack 的 Availability Zone

转载自：http://blog.csdn.net/lynn_kong/article/details/9012451 

首先，G版中对服务的管理增加了很多方式，可以是老的更新数据的方式（如果节点不多，可以使用这种，不会对数据库造成大的压力），但如果节点较多，使用数据库的方式就不太明智了，此时可以选择效率较高的memcached或者zookeeper。

同时，Service表中也不再保存availability_zone字段，配置项node_availability_zone也不再使用。那么这时，如何确定一个host属于哪个zone呢？

G版中，默认情况下，对Nova服务分为两类，一类是controller节点的服务进程，如nova-api, nova-scheduler, nova-conductor等；另一类是计算节点进程，nova-compute。对于第一类服务，默认的zone是配置项internal_service_availability_zone，而nova-compute所属的zone由配置项default_availability_zone决定。所以，一个新的环境，我们看到的服务如下：

root@controller23:~# nova-manage service list 2>/dev/null  Binary           Host                                 Zone             Status     State Updated_At  nova-cert        controller23                         internal         enabled    :-)   2013-06-03 05:01:42  nova-conductor   controller23                         internal         enabled    :-)   2013-06-03 05:01:39  nova-consoleauth controller23                         internal         enabled    :-)   2013-06-03 05:01:42  nova-scheduler   controller23                         internal         enabled    :-)   2013-06-03 05:01:42  nova-compute     controller23                         nova             enabled    :-)   2013-06-03 05:01:37  nova-compute     compute24                            nova             enabled    :-)   2013-06-03 05:01:43  

可以看到internal和nova两个默认的Availability Zone。

可能是社区的开发人员意识到，让管理员通过配置的方式管理zone不太合适，不够灵活，所以在G版中将这一方式修改。那么如何修改一个host所属的zone呢？这里需要提到G版的另一个改变。

G版中，创建一个aggregate可以指定一个参数availability_zone：

root@controller23:~# 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取代了zone，但同时又不影响aggregate与flavor的配合使用，因为这是两个调度层面。同时又要注意，一个主机可以加入多个aggregate中，所以G版中一个主机可以同时属于多个Availability Zone，这一点与F版也不同。

Folsom已是过去式，这里就在Grizzly环境中实践。我就直接使用我的团队中一个同事的总结截图。

1. 创建aggregate，指定zone

2. 添加主机

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

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