OpenStack 升级实践文章

刺骨的言语ヽ痛彻心扉 2022-07-10 12:58 296阅读 0赞

**【摘要】**

1.OpenStack的使用情况及背景介绍

2.升级的风险和收益评估

3.升级的前期准备

4.升级步骤和策略

5.升级中遇到问题

6.Q&A

##     ##

## **OpenStack的使用情况及背景介绍** ##

那么让我们开始吧，首先介绍一下背景，我们团队在维护一套OpenStack集群用于公司内部私有云，公司大部分业务都运行在这个私有云平台上。我们的私有云平台名字叫“HULK”(浩克),它提供了很多服务。

![image2017-2-9_10-40-27.png_version_1_modificationDate_1486636827000_api_v2][]

如图中所示，涵盖了非常多的服务，为公司业务做了良好的支撑，我们的OpenStack就是在HULK中提供“web”和“云服务器”服务。

我们的OpenStack提供http api接口，HULK通过api调用来对资源进行“创建”,“删除”等操作,为了和HULK无缝的集成我们没有使用OpenStack原生的dashboard，HULK开发同事帮我们开发了一套管理端，在管理端可以很方便的管理和控制OpenStack集群，创建，删除虚拟机，因为结合我们自己的使用场景，相比原生dashboard要方便很多。如图：

![image2017-2-9_10-40-46.png_version_1_modificationDate_1486636846000_api_v2][]

所以我们的OpenStack集成到了hulk云平台当中，重新开发了管理端，相互通信都使用http api方式。

下面介绍下OpenStack一些情况：

我们的OpenStack集群的虚拟化方式目前有两种模式“本地磁盘+vlan网络”和“共享存储+vxlan网络”，目前有9个机房，1000+物理节点，4000+虚拟机，我们之前使用的版本是kilo，下面简单说下我们的架构：

![image2017-2-9_10-41-8.png_version_1_modificationDate_1486636869000_api_v2][]

如上图所示：

为了统一认证和授权，整个OpenStack只有一个keystone节点(使用负载均衡做HA)

大体上以机房为单位划分region，当然region是个抽象概念如果机房规模很大，机房内可再划分region，一个region除了keystone以外其它组件都在本机房内部，性能上有很大保证，而且每个region组件都是独立的，不会互相干扰。

在region下以交换机为单位划分AZ，这样做是方便进行网络控制，因为我们既有传统vlan模式也有vxlan模式，通过AZ的划分我们就能做到同一个region下既能跑“vlan”也能跑“vxlan”。

AZ下以机柜为单位划分AG，这样做是想基于机柜单位对资源进行“超卖”等细节调整。

我们使用ansible来批量部署和更新配置，把每个组件的部署和管理配置操作抽象出role和playbook，部署和更新都可以做到一键操作。

以上就是一些背景和架构的介绍，下面正式聊聊OpenStack升级吧。

## **升级的风险和收益评估**    ##

大家知道OpenStack版本迭代很快，每半年更新一次，新版肯定会更加提升稳定性，也会引入新的特性，升级貌似是一个不可避免的问题，但是我还是建议大家先仔细评估一下“为什么要升级”，“升级的成本和收益”。

我们的升级起源于想使用DPDK网络技术，因为我们发现有些业务对网络非常敏感，因为虚拟化本身的网络路径太长，并且受制于qemu线程处理能力，达不到物理机的网络效果，但是DPDK在M版本才支持。

基于这个原因，我们想引入DPDK，要么在当前版本二次开发，要么升级到M版本，所以我们将升级OpenStack提上了日程。

但是我们对待升级还是持比较谨慎的态度，我们还是又回到最初的问题上开始讨论，“为什么要升级”。

做过运维的同学都知道“稳定压倒一切”，我们心理上是很抵触线上变化的，尤其是OpenStack组件众多，依赖复杂，你会对升级产生一种恐惧。

所以我们先是粗略的看release，看看社区的发展方向，有哪些吸引人的新特性，引入这些特性能对用户带来多少好处，新版本有哪些变动，目前结构是否兼容，需要做多大的调整。

但是有一条很重要的原因是，我们不想和官方差距太大，目前是K版本，官方是N版本，已经落下3个版本了，如果现在不升级，再过一年就是5个版本，那时候差异太大，升级就更加困难了，所以长痛不如短痛，现在升级还来得及。

所以我们决定对OpenStack进行升级。

既然我们已经决定开始升级，那么就进入到升级的准备工作了，我先上一张图，表明升级的时间分配。

![image2017-2-9_10-41-53.png_version_1_modificationDate_1486636913000_api_v2][]

从这张图可以看出，真正执行升级时间很短，我们将很多时间花费在了前期准备和后期检查上。

升级的前期准备工作很重要，准备的越充分，升级就会越顺畅，所以建议大家不要急于升级，先做好充足的准备。

##     ##

## **升级的前期准备**    ##

下面说下前期准备

首先我们要确定升级版本，当时最新版本是N版，但是我们决定升级到M版，第一是因为M版本到K版本有两个版本跨度，升级成本相对小，第二是一般官方稳定版的”前一个“版本更加健壮，因为已经发布一段时间，会陆续修复一些bug。

确定好升级版本以后，大家开始着手升级工作，我们的大致方式是这样的，由一名同事负责牵头升级事宜，他先去看一些相关资料和文档，评估出升级的大致步骤和整体的升级流程，然后具体组件再由其它同事评估升级细节。

就是由一个人“宏观”把控升级，做好“顶层设计”，再由其他人细化升级步骤。这个人会告诉大家要关心哪些点，要注意哪些问题。

比如说：

**阅读官方release node**

了解新的、升级的、废弃的feature，对比版本之间的差异；

确定API version是否有变化；

https://releases.openstack.org/

https://releases.openstack.org/mitaka/index.html

**配置文件是否适配**

http://docs.openstack.org/mitaka/config-reference/

与新版本配置文件对比，在现有配置文件的基础上，增、删、改；

升级组件的顺序，贴一张官方的建议顺序：

![image2017-2-9_10-42-30.png_version_1_modificationDate_1486636950000_api_v2][]

确定每个组件的大致升级步骤，如nova组件

\# 备份好配置文件

cp -a /etc/nova /etc/nova-kilo-backup

\# 升级软件包

yum upgrade \\\*nova\\\*

\#根据需要修改配置文件

vim /etc/nova/nova.conf

\#以下两步确保配置文件中数据库配置是正确的

\#升级DB schema

openstack-db --service nova --update

\#同步新的nova\_api数据库

nova-manage api\_db sync

\#启动服务

这里给大家发几篇关于升级的参考文章，写得都很不错。

http://docs.openstack.org/ops-guide/ops-upgrades.html

https://access.redhat.com/documentation/en/red-hat-openstack-platform/8/single/upgrading-red-hat-openstack-platform/

https://www.mirantis.com/blog/yes-can-upgrade-openstack-heres/

确定好这些大的步骤，每个组件负责人再细化升级流程。

比如负责neutron组件的同事会细化每个参数点，做大量的测试来验证新版带来的影响，如下图：

![image2017-2-9_10-42-54.png_version_1_modificationDate_1486636975000_api_v2][]

只有做这样细致的工作，才能将出问题概率降到最低。

## **升级步骤和策略** ##

做完前期准备还要确定升级的步骤，先升级哪些机房，升级的周期等，还有升级的策略，因为我们的机房比较多，都是线上业务在跑，稳定性是第一位的。

所以我们还要评估升级对线上业务的影响，这块分两方面：

一方面是已经运行的虚拟机，是否有影响，因为OpenStack是通过libvirt“操控”虚拟机，已经运行的虚拟机只要“libvirt”，“qemu”，“ovs”没有变动应该不会受到影响。

另一方面就是控制虚拟机，比如创建，删除等，因为我们是私有云，对于高可用性要求并不是很高，可以容忍短时间“无法操控”虚拟机，所以我们没有追求绝对平滑的升级步骤，因为那样成本很高。所以我们采取分region短暂停用的升级策略。

关于升级步骤，因为OpenStack组件众多，组件之间关系复杂，我们计划先在测试集群上演练升级，然后再升级线上。如图：

![image2017-2-9_10-43-41.png_version_1_modificationDate_1486637021000_api_v2][]

我们先升级测试环境，因为是第一次升级，主要目标是演练一下升级步骤，看看会遇到哪些坑，我们具体升级次序是先升级keystone，然后升级glance，neutron，然后升级nova和cinder，每个组件升级完知会下一个同事开始升级。升级完开始做一些列验证测试，比如镜像拉取，建网，创建虚拟机等等。

但是验证功能ok还没完，那只是说明OpenStack能正常跑起来了，但是能run起来和“优雅”的run还不太一样。你要去看一下各个组件的日志，比如keystone下面

Option "verbose" from group "DEFAULT" is deprecated for  removal.(Boolean) DEPRECATED: If set to false, the logging level will be set to WARNING instead of the default INFO level.

说明这个参数在DEFAULT中移除了，你要修改配置文件。

WARNING oslo\_log.versionutils \[-\] Deprecated: keystone.contrib.revoke.backends.sql.Revoke is deprecated as of Mitaka in favor of sql and may be removed in O.

官方将参数形式做了精简：

keystone.conf now references entrypoint names for drivers. For example, the drivers are now specified as "sql", "ldap", "uuid", rather than the full module path. See the sample configuration file for other examples.

We now expose entrypoints for the keystone-manage command instead of a file.

所以你也要跟着修改。

还有M版本推荐使用keystone-wsgi-admin和keystone-wsgi-public替代/var/www/cgi-bin/keystone/main，你也要修改。

虽然这些细节不修改也能run起来，但是你最好优化一下你的配置和参数，达到最佳效果。

每个组件都这样检查一遍，优化和调整去适配新版本OpenStack。

等到这些做完了，我们在测试环境上的升级就完成了。

然后下一步再准线上环境再升级一遍，因为我们在测试环境升级完，说明升级步骤是ok的，基本的坑也都填完了，那么在准线上环境升级主要目标是让流程自动化起来。

因为在测试环境很多步骤都是手动完成的，真正的线上升级必须批量的去跑，所以我们会把测试环境手动执行的步骤全部都变成ansible的playbook，用写好的ansible playbook去做升级。

而且playbook的执行要遵循“幂等性”，就是可以重复的执行，发现执行出错，修改playbook，再次从头执行，直到完全成功为止，同时在准线上环境再做一遍测试，看是否有问题。

还有因为我们是和hulk对接的，所以这时也会让相关开发同事，在准线上环境测试一下api接口是否有问题。

等到这些完成，经过多次演练，我们有了一套可行的升级流程，并且把它变成了自动化的步骤，也经过了内部和外部调用的验证，我们就可以着手线上升级了。

因为我们机房比较多，所以先选择规模比较小的机房，这样即使出问题影响也比较小，小机房升级完再升级大机房。

这块我想说下升级的时间安排，一般来讲，运维相关的升级维护都放到夜里或凌晨，因为那是流量低峰，用户敏感度低，出了问题影响小，我想这也是让人觉得运维很辛苦的原因之一吧。但是夜里干活很多弊端，一般半夜人的精力已经下降，顶着困意解决问题效率也很低，而且一般你都是单兵作战，很难获取其它同事帮助，并且大家要是不在一起，沟通效率也非常低，有时候出现问题反倒解决的时间会更长，所以个人觉得夜里的升级维护更适合“机械性”，“不复杂”的操作。因为OpenStack升级的复杂性，好多问题需要协同排查，所以我们把升级时间定在了白天的工作时间，选择白天业务相对低峰的时间段。

选择好时间，我们开始按照步骤先升级一个小机房，升级完成以后，还是例行的检测，确认全部ok以后，我们会留1星期的观察期，看看后续使用上是否还会暴漏一些问题。

经过一星期的观察，下个星期我们会选择升级2个机房，因为已经运行稳定，我们的节奏可以加快一些，这样逐步的边观察，边升级，最后将所有机房升级到了mitaka版本。

以上是我们的升级步骤和策略，下面我分享下遇到的一些问题。

##     ##

## **升级中遇到问题** ##

**组件依赖问题**

虽然OpenStack各个组件是松耦合的，大部分都基于http api调用，但是组件的底层依赖库都是相同的，比如你的controler节点上跑着nova，neutron，glance等，他们用的是同一套olso，novaclient，neutronclient，这样如果你升级了nova，就会升级novaclient，那么老版本neutron就会有问题，所以我们采用“集中时间一起升”的办法。

**nova的endpoint api版本更新到了v2.1**

之前我们没有注意这个问题，因为测试基本都是命令行调用，也是hulk开发同事测试才发现这个问题，需要keystone更新endpoint。

**RPC 版本Controller节点与Compute节点不匹配**

针对这个问题官方已经给出了解决方案。简单理解的话就是为了升级时高版本组件和低版本组件RPC正常通信，通过在controller和compute配置文件中指定版本号的方式来统一他们之间的通信。因为我们是跨版本升级，验证K和M版本无法匹配，所以我们采取“要升一起升”的策略，nova control和nova compute一起升级。

**neutron配置错误导致创建虚拟机失败**

经过分析发现是Mitaka版本中对于neutron配置部分配置改变导致。在 \[neutron\] 中添加如下几项： user\_domain\_name=Default project\_domain\_name=Default project\_name = service

**升级DB**

一般通过以下命令可正常升级openstack db

openstack-db --service yourservice --update

有时候升级db会报错，多半情况是db授权有问题，没有一些“删表”等权限，所以升级前要确认db的权限。

还有一种情况是因为我们改动了neutron的数据库表，增加了轮询配置dns策略，neutron是通过alembic来对数据库进行版本控制，它对version id要求很严格，如果你自行改了数据库结构，变更了version id，升级db会失败。

**ovs-agent和neutron server**

升级过程当中会重启ovs-agent，它会重新刷ovs流表，这个时候如果你的neutron server或者rabbitmq不可用，无法获取新的流表，有可能会断网！所以升级ovs-agent前先确保你的neutron sever和rabbitmq是可用的。

**rabbitmq 问题**

升级完以后发现rabbitmq内存开始疯长，rabbitmq 社区说是 erlang 版本不匹配的导致，我们换掉了默认安装的最新版，使用其它版本解决了问题。

**python-novaclient bug**

我们发现M版的novaclient不支持keystone V3版本验证，这是一个bug，虽然已经修复但是还没有并入到此次升级的包中，所以我们重新打入patch，build了一个novacilent包。

因为时间关系，我只是列举了一些问题，在升级过程当中还遇到了很多问题，好在我们都一一的解决了，升级的过程就是“痛并快乐着”，升级过程也提升了大家排查问题能力和技术水平，加深对OpenStack理解，也是收获颇多。

## **Q&A** ##

1、监控用的什么软件来做的，如果出现问题，自动恢复嘛？

答：监控是我们使用自研的wonder，基于openfalcon二次开发，是其它同事做的。

2、hulk的平台是通过dashboard的api来调用所有的服务嘛?

答：是直接调用OpenStack组件的http api

3、一个region，vlan和vxlan并存，对于neutron,你们做了二次开发嘛？

答：没有做二次开发，通过合理的AZ划分可以实现

4、rabbitmq，现在最新版本，容易脑裂，你们这个问题出现的多嘛？

答：记得我们好像出现过一回，貌似社区叫“网裂”，是刚开始上线出现过一次，前期我们的rabbitmq也不稳定，我们集中了一段时间做优化和测试，目前比较稳定了 。

5、关于playbook是因为是一健更新 怎么区分各个机房呢 不同的机房对应不同的playbook ，里面的变量通过主机名来区分吗？

答：我们是简单粗暴的用文件夹区分的，呵呵，比如IDC1,IDC2，公共变量我们都抽象到role中，每个IDC独有的变量各自维护一个config.yml

6、你好，感谢你的这次分享。但这样的升级非常痛苦，为什么不使用kolla部署呢（将OpenStack服务容器化）？

答：容器化是一个很好的方案，因为历史原因刚开始没有使用容器化方案，我个人理解容器化能够解决一台服务器复用多个服务相关依赖环境问题，但是OpenStack升级还有其它问题也不好解决，比如组件间版本一致性，组件间协调等问题。

7、升级过程中虚拟机业务是否受影响，各个组件的具体的先后顺序能给一下吗？，controller做了ha，有啥需要注意的吗？

答：我们的顺序是 keystone glance neutron nova cinder，controler直接挂负载均衡没啥要注意的。

8、以后如果要升级到更高版本，这个方案的可复用性高吗？是否有考虑过 使用 KOLLA容器化 ？

答：我个人觉得容器化会提高OpenStack升级的便利性，以后有时间我们也想变成容器化部署，但是容器化不是银弹，它解决不了所有问题，它只能让各个组件变更不互相干扰，比如不受公共库的干扰，版本更迭参数改变，新特性如何调优等都是不可避免的。

9、从评估到第一个机房升级完成总共花了多少时间？升级过程节点出错率有多少？

答：我们大约花了一个月的时间，出错率没有统计过，总体还是比较流畅的。

10、升级过程中会影响虚拟机的业务吗？重新刷ovs流表，网络会断吗？

答：我们测试，只在更新完ovs-agent后的那一次重启会重刷流表，后期再重启就不会了，网会断的。

[image2017-2-9_10-40-27.png_version_1_modificationDate_1486636827000_api_v2]: http://10.0.30.107/download/attachments/4817151/image2017-2-9_10-40-27.png?version=1&modificationDate=1486636827000&api=v2
[image2017-2-9_10-40-46.png_version_1_modificationDate_1486636846000_api_v2]: http://10.0.30.107/download/attachments/4817151/image2017-2-9_10-40-46.png?version=1&modificationDate=1486636846000&api=v2
[image2017-2-9_10-41-8.png_version_1_modificationDate_1486636869000_api_v2]: http://10.0.30.107/download/attachments/4817151/image2017-2-9_10-41-8.png?version=1&modificationDate=1486636869000&api=v2
[image2017-2-9_10-41-53.png_version_1_modificationDate_1486636913000_api_v2]: http://10.0.30.107/download/attachments/4817151/image2017-2-9_10-41-53.png?version=1&modificationDate=1486636913000&api=v2
[image2017-2-9_10-42-30.png_version_1_modificationDate_1486636950000_api_v2]: http://10.0.30.107/download/attachments/4817151/image2017-2-9_10-42-30.png?version=1&modificationDate=1486636950000&api=v2
[image2017-2-9_10-42-54.png_version_1_modificationDate_1486636975000_api_v2]: http://10.0.30.107/download/attachments/4817151/image2017-2-9_10-42-54.png?version=1&modificationDate=1486636975000&api=v2
[image2017-2-9_10-43-41.png_version_1_modificationDate_1486637021000_api_v2]: http://10.0.30.107/download/attachments/4817151/image2017-2-9_10-43-41.png?version=1&modificationDate=1486637021000&api=v2