openstack multi-region管理

openstack多集群管理1 背景介绍

由于有些物理集群处于不同的地点，或者某一些物理集群规模太大，就需要创建多个openstack集群对其进行管理。而每个openstack集群是单独管理的，这就导致管理入口太多，不方便统一管理。那么就需要一种统一管理的机制。

2 方案对比

2.1 nova AZ

针对多个集群处于不同地点的情况，这时每个集群可以作为一个（或者多个）AZ，但是由于AZ之间还是会共享很多服务，比如neutron，glance，mariadb，rabbitMQ等，需要跨机房访问这些服务，时延比较大，也会消耗较多的机房间带宽，会影响用户体验。 当单个物理集群太大时，即使划分了多个AZ，从逻辑上分割开了，但是rabbitMQ，glance，neutron，mariadb等服务的压力还是会比较大，同样会影响用户体验，划分多个AZ是无法解决这类问题的，AZ只是一个逻辑范围的划分。

2.2 multi-region

一个region可以对应一个物理集群，region与region可以是不同地点的物理集群，也可以是单个大规模物理机集群分割后的多个物理集群。region之间只共享dashboard service（horizon）和identity service（keystone），也就是说使用统一的管理界面和认证，其他服务（例如，nova，neutron，glance，cinder，mariadb，rabbitMQ等）都是各个region独立拥有的，这样可以有效避免region间的交互开销。 该方案如下图所示

在上图中，左边的集群是RegionOne，右边的集群是RegionTwo，可以使用任何一个region的horizon和keystone service来行使dashboard和identity功能。为了便于后面进行说明，需要选定一个region提供dashboard和identity service，这里就选定RegionOne了。

下面对上图中的几个关键点做下说明，

1）keystone数据库设置主从

RegionOne中keystone连接的数据库作为master，RegionTwo中keystone连接的数据库作为slave，他们之间做主从，以实现keystone数据库之间的同步。 这么做的目的是当RegionOne的keystone service无法给RegionTwo的各个service提供访问认证服务时（比如，当RegionOne和RegionTwo之间的网络中断时），RegionTwo上的keystone service可以使用slave keystone数据库中的信息给RegionTwo上的各个service提供访问认证服务。

2）keystone token driver配置为memcache

keystone除了token对象存放在memcache中，其他对象（例如，user，role，credential，endpoint，service，region等）全都存放在mariadb中。 之所以把token存在memcache中，是因为token是有使用期限的（例如，24h），如果把token存在mariadb中，当RegionOne上的keystone service无法给RegionTwo上的各个service提供访问认证服务时，这时就要使用RegionTwo上的keystone，那么当slave keystone数据库中存放的token过期了，就无法把新的token存储到slave keystone数据库中，因为slave数据库不允许写。那么如果把token存放在memcache中，当RegionOne上的keystone service无法给RegionTwo上的各个service提供访问认证服务时，RegionTwo上的keystone service只需要把把新生成的token存放到memcache中即可，后面就可以使用memcache中的token进行访问。

3）RegionOne上的keystone service无法给RegionTwo上的各个service提供访问认证服务时，RegionTwo仍可以管理

RegionTwo的dashboard和identity service平常不再起作用，其实这时RegionTwo上各个service的访问认证已经不通过RegionTwo上的keystone了，而是通过RegionOne上的keystone进行认证，上图的RegionTwo中的两条虚线就代表这个意思。当RegionOne上的keystone service无法给RegionTwo上的各个service提供访问认证服务时，就需要使用RegionTwo上的horizon和keystone重新提供dashboard和identity服务。通过修改RegionTwo上各个service的配置使其重新使用RegionTwo上的keystone进行访问认证。

4）dashboard支持multi-region

openstack dashboard是支持multi-region的，它通过keystone service可以发现所有的Region，然后再界面上提供Region切换功能，如下图所示

5）openstack其他组件

region之间只共享horizon和keystone service，其余service（例如nova，neutron，glance，cinder，ceilometer，mariadb，rabbitMQ等），各个region都是用自己的，这些service如果要做HA，那么各个region自己做自己的。

3 方案实施

通过上面的方案介绍可以知道，该方案总共有四个关键点，一是提供dashboard和identity service的Region和其他Region之间，keystone数据库要做主从；二是各个Region的keystone token driver要使用memcache；三是创建多Region；四是当RegionOne上的dashboard和identity service无法给其他Region提供服务时，要保证其他Region仍可管理。下面就围绕这四点进行实施。

3.1 多集群环境准备

总共搭建了两个openstack集群，每个集群有两个节点，controller和compute节点，controller同时也作为compute节点，如下表所示

我是使用packstack部署的openstack，默认都是只有一个RegionOne。下面计划把cluster-1作为RegionOne，cluster-2作为RegionTwo，然后使用RegionOne上的horizon和keystone service给这两个Region提供dashboard和identity服务。

3.2 keystone token driver配置为memcache

所有region的token driver都要配置为memcache，默认情况下token driver使用的是sql数据库。

3.2.1 修改token driver

3.3.2 启动memcached服务

3.3.3 修改keystone [memcache] section配置

然后修改/etc/keystone/keystone.conf的[memcache] sectionservers = localhost:11211

3.3.4 restart keystone service

systemctl restart httpd.service

3.3.5 确认是否修改成功

在确认是否修改成功前，先重新登录下dashboard，这样会产生新的token。

有多种方式都可以确认是否修改成功，下面列举了四种

1）telnet 127.0.0.1 11211

2）lsof -i :11211

如果输出中有服务跟memcache建立了连接，如下图所示

然后再查询keystone service使用的port是否可以对上

3）netstat -antp | grep memcache如果已经有服务跟memcache建立连接，并且建立连接的keystone服务，那么就说明memcache生效了。

3.3 创建multi-region

3.3.1 备份keystone database

3.3.2 修改cluster-2的region name为RegionTwo

1）在region table中插入一个'RegionTwo'记录

insert into keystone.region(id,extra) values ('RegionTwo','{}');

2）修改endpoint table中的所有记录的region_id为'RegionTwo'

update keystone.endpoint set region_id='RegionTwo';

3）删除region table中的'RegionOne'记录

delete from keystone.region where id='RegionOne';

在验证是否修改成功之前，需要修改/root/keystonerc_admin，将OS_REGION_NAME修改为RegionTwo，然后重新source /root/keystonerc_admin，

验证region name是否修改成功，如下图所示

3.3.3 备份RegionTwo的endpoint、service table

其实，endpoint table可以不备份，因为在RegionOne上执行以下命令也会在RegionOne的keystone数据中的endpoint table中插入RegionTwo上的各个service的endpoint记录

openstack endpoint create --publicurl --internalurl --adminurl --region RegionTwo

并且以上命令，还会在RegionOne的keystone数据库的region table中插入'RegionTwo'记录。但是由于命令操作比较麻烦，每个service都要创建endpoint，还是直接导数据库简单。

另外，需要把导出的endpoint、service table文件中的‘判断是否存在endpoint(service) table，如果存在就删除，以及后面紧跟着的创建endpoint(service) table’ 的处理删除，如下截图所示（以endpoint table为例）

因为这两个table的导出文件是要导入到RegionOne的keystone的endpoint、service table中的，因为在RegionOne的keystone数据库中已经有endpoint、service table了，并且也有记录了，是不可以删除的，我们只是要合并两个region的keystone的endpoint、service table。

3.3.4 RegionOne的keystone的region table插入RegionTwo记录

insert into region(id,extra) values ('RegionTwo','{}');在3.3.3中也注明过，通过openstack endpoint create --region RegionTwo也可以在region table增加'RegionTwo'记录。

3.3.5 在RegionOne上导入RegionTwo上导出的endpoint、service table

1）将RegionTwo上导出的endpoint、service table拷贝到RegionTwo的controller node上

2）将拷贝的endpoint、service table导入到10.13.32.19的keystone的相应的endpoint service table中

mysql -uroot keystone < keystone.endpoint_RegionTwo.sqlmysql -uroot keystone < keystone.service_RegionTwo.sql

3）修改RegionTwo的identity的三个endpoint（publicurl，internalurl，admin url）

4）验证是否修改成功

①确认endpoint list中是否都已经添加进去

②确认RegionTwo的identity service的三个url是否已经修改成功

3.3.6 修改RegionTwo的所有节点的各个service的authencation endpoint

修改RegionTwo上所有service访问认证endpoint为RegionOne的keystone service。

默认情况下，keystone service提供服务的两个端口为5000和35357，可以通过以下命令搜到到修改点

service-auth-endpoint.png

其中，/etc/openstack-dashboard/local_settings是不需要修改的，因为RegionTwo上的dashboard服务是不需要跟RegionTwo上的keystone service交互的。然后逐个去修改，将10.13.131.137修改为10.13.32.19。另外，上图中搜索出来的内容之所以被注释掉了，是因为我已经做了修改。

需要额外注意的就是/etc/cinder/cinder.conf [keymgr] section,

3.3.9 修改RegionTwo的各个service的admin pass

需要修改RegionTwo上的各个service的admin pass，跟RegionOne上相应service的admin pass保持一致。 可以通过find /etc/ -type f | xargs grep admin_pass搜到相关的修改点，以nova为例进行说明，编辑/etc/nova/nova.conf

3.3.10 重启RegionTwo上的各个service

需要重启RegionTwo上的各个service，让上面的修改生效。

3.4 keystone数据库配置master-slave

请参考 Openstack Mysql 主备服务器搭建

3.5 keystone service无法给其他region上的各个service提供访问认证服务时，其他Region仍可管理

RegionOne上的keystone service无法给RegionTwo上的各个service提供访问认证服务的场景很多，最典型的就是RegionOne和RegionTwo之间的网络中断了，这时就要考虑如何单独的管理RegionTwo。这时需要revert3.3.6中做的修改，然后重启各个service，让RegionTwo上各个service重新使用RegionOne上的keystone service进行访问认证。这时就可以使用RegionTwo上的dashboard来管理RegionTwo，不过有一点需要注意，由于现在RegionTwo上的keystone数据库是read-only的，是不可以创建user，project，service等操作的。

4 遗留问题

4.1 memcache size

可以使用memcached-tool 127.0.0.1:11211 stats来查看memcache的空间是否紧张，如下图所示

如果touchmisses持续增加，可以适当调大memcache size，可以通过编辑/etc/sysconfig/memcached，改大CACHESIZE的值。当调大cache size后，如果发现totalitems, total_connections有所增加，就说明调大cache size是有效果的。