管理openstack多region介绍与实践

转：http://www.cnblogs.com/zhoumingang/p/5514853.html

概念介绍

所谓openstack多region，就是多套openstack共享一个keystone和horizon。每个区域一套openstack环境，可以分布在不同的地理位置，只要网络可达就行。个人认为目的就是为了提供环境隔离的功能，选择启虚拟机的时候可以根据自己所处的位置就近选择。

既然提到region了，那不如就此总结下openstack中其他的至上而下的不同的区域概念。

Region

每个region都有个完整的Openstack部署环境， 有自己的一套服务的endpoint（服务入口）。

不同的region共享一套keystone和horizon来提供访问控制与web操作，regions之间完全隔离，但是多个regions之间共享同一个keystone和dashboard。

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

AZ(Availability Zones)

region中的计算结点可以被逻辑上划分为不同的availability zones，具有独立的电力供应设备，如下图。用户可见，在启动虚拟机时，可以指定特定的AZ来启动该虚拟机实例,通常你看到的就是默认nova。

修改availability zone，直接修改 nova.conf中的 字段node_availability_zone即可。

机器之间是否有明确的物理隔离，或者是考虑冗余。 如果的确有，则可考虑AZ。

Host Aggregate

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

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

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

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

多region的实践

openstack多region，就是多套openstack共享一个keystone和horizon，那么很容易想到，在一套openstack的keystone的服务实例中创建另外一个区域的服务入口点，只不过认证的服务endpoint一样罢了，horizon自动识别region。

环境介绍

以我自己的例子，先搭建了两套openstack环境，因为是为了实践，所以我简单的搞了两套allinone的。

A主机是10.133.47.95 ，定义成我的region one；

B主机是10.133.47.20，定义成我的region two。

配置

1.在A主机上创建nova、glance、cinder服务入口endpoint，定义为region two。

[root@zmg ~(keystone_admin)]# keystone endpoint-create --service-id $(keystone service-list | awk '/ compute / {print $2}') --publicurl http://10.133.47.95:5000/v2.0 --internalurl http://10.133.47.95:5000/v2.0 --adminurl http://10.133.47.95:35357/v2.0 --region RegionTwo

[root@zmg ~(keystone_admin)]# keystone endpoint-list|grep RegionTwo

注意：1.这里的endpoint地址都是主机B上的openstack环境中的服务endpoint。

2.glance，cinder以及其他服务，一样操作。

2.在主机B上对相应的服务配置修改

①编辑nova配置文件，在/etc/nova/nova.conf

auth_uri=http://10.133.47.95:5000/v2.0

identity_uri=http://10.133.47.95:35357

admin_token = 3a64046c0c9a4ef4af3d13819a451461

admin_user=nova

admin_password=cd2b0a687cd14376

admin_tenant_name=services

注：1.原来uri这里是47.20，因为我们要和regionone共享keystone，所以认证url改为主机A上的keystone。

2.admin_token需要增加，也是主机Akeystone配置文件中的，必须要加不然认证没法通过，user和password要和A的文件中的一致。

[neutron]

url=http://10.133.47.20:9696

admin_username=neutron

admin_password=072bdefd676644ca

admin_tenant_name=services

admin_auth_url=http://10.133.47.95:5000/v2.0

2.修改cinder.conf文件

[keystone_authtoken]

auth_uri = http://10.133.47.95:5000/v2.0

region_name = RegionTwo

identity_uri = http://10.133.47.95:35357

admin_user = cinder

admin_password = e3cdaaf26e774509

admin_token = 3a64046c0c9a4ef4af3d13819a451461

admin_tenant_name = services

3.glance配置修改和nova cinder类似，只不过要改api.conf和register.conf。

[keystone_authtoken]

auth_uri=http://10.133.47.95:5000/v2.0

identity_uri=http://10.133.47.95:35357

admin_user=glance

admin_password=bdda12a1e36e4d70

admin_tenant_name=services

admin_token = 3a64046c0c9a4ef4af3d13819a451461

[keystone_authtoken]

auth_uri=http://10.133.47.95:5000/v2.0

identity_uri=http://10.133.47.95:35357

admin_user=glance

admin_password=bdda12a1e36e4d70

admin_token = 3a64046c0c9a4ef4af3d13819a451461

admin_tenant_name=services

总结：要将B机器上所有的验证url都改成A的验证url，另外注意将B中各种配置文件中的token改成A中的admin_token。还有注意两台机器的时间一定要接近，不然还是会出现未授权的错误。

验证：

修改好之后就可以登录到horizon上去看了，horizon不需要修改，它可以自己识别多region。

至此，我们就可以通过一个horizon界面去操作不同环境的openstack去创建虚拟机，资源是完全隔离的，是不是很方便了。

以上，是我在完成后再写的步骤，细节的地方可能会有纰漏，但是思路基本就是这样。

另外，cell的实验会在后续介绍。