Stuck Stack成过去时，OpenStack升级还可以这样玩？！

不可否认，OpenStack确实是目前最为成功的开源项目，并且牢牢占据了云计算基础设施领域事实上的标准的地位，然而，OpenStack在升级方面的表现，实际上可以用“灾难性”来形容，看看OpenStack官方论坛里对OpenStack升级的关注，您就一目了然了。

如果这样的证明还来得不够直接，不够有说服力的话，那从2017 OpenStack用户调查（https://www.openstack.org/assets/survey/April2017SurveyReport.pdf）中，我们也许能够得到更直接更有说服力的证据——只有27%的OpenStack用户在运行最新版本。

那么，究竟是什么阻碍这些用户使用新版本OpenStack呢？答案就是——所谓的“Stuck Stack”（字面意思是“卡住的OpenStack”）。

Stuck Stack是指无法将OpenStack升级到更新版本的问题，导致企业用户不得不继续使用比较旧的、不受支持的版本，而这些版本存在已知的安全漏洞和问题；被卡住的时间越长，就需要越专业的技能才能维护其运行。

OpenStack升级究竟难在哪儿？

实际上，“纯净的”OpenStack （即未经过定制化修改的原版OpenStack）并不难升级，因为每个OpenStack版本都是为无缝滚动更新（rollover）设计的，并经受大量的社区测试，确保升级过程尽可能顺畅无阻。但是，企业平常所部署的OpenStack版本并不是纯净的、没有经过修改和优化的OpenStack。

这是因为OpenStack具有一个最显著的特点或者说最大的优点之一就是其灵活的可定制性。OpenStack完全可以按照企业的需要来构建，以适应企业内部现有的流程和技术。正是这种灵活性，让许多企业的IT团队摩拳擦掌、跃跃欲试，因为基于这个特性，企业的IT团队能够通过对OpenStack的定制，自行构建满足自身要求的云，同时这也是OpenStack能够吸引如此众多的IT技术人员趋之若鹜的重要原因。

然而，凡事都有利有弊，也正是OpenStack的这个特点引发了数量惊人的Stuck Stack：因为企业竭力想要构建适合自己现有基础设施的私有云，所以他们不断对OpenStack进行定制化改造，不断添加功能和组件，几个月、甚至几年下来，由于大量的定制功能和规范，最终整个OpenStack系统变成了一个基于OpenStack但已经面目全非的庞然大物。

因此，当新版本出现时，企业想要获得平滑的升级，已经非常困难，需要事先做大量的准备工作，而OpenStack的更新、迭代、升级又是如此之快，每次更新、升级都近一步增加了企业IT团队升级OpenStack所需要的工作量。累积下来，平滑升级几乎变成了“Mission Impossible”。

传统的升级方案

虽然是“Mission Impossible”，但在IT界我们也有自己的“伊森·亨特”们，他们用自己超凡的技术和经验，找到了一条OpenStack的升级之路。

升级意味着升级到一个新的OpenStack稳定版本。一个OpenStack云由相互协作的若干分发式软件组件构成，以交付满足需求的云服务。初步来看，这些组件，包括操作系统依赖项，必须同时进行升级，这将使得升级任务变得更加复杂。好在OpenStack社区旨在保持组件APIs的兼容性，所以旧的API版本往往也会被保留和支持一段时间。然而，旧API总会被标记为不推荐的并会在之后的版本中移除。

原则上，执行OpenStack升级的首选方法是使用命令行界面（CLI），这种方法对于单个服务器是很好的，但对于大型节点集群则显得效率低下。对于大型集群执行更新来说，出现错误和升级失败的几率则会显著提高，因此采用工具升级是一个不错的选择。

在理想的OpenStack升级中，IT人员需要事先做大量的准备工作，应对所有节点进行检查，打补丁、准备一个升级失败的回滚计划、准备一个至少带有配置文件和数据库的备份的数据备份计划。然后才是重新启动整个配置——但这种方法会导致大量的停机时间。在实施具体更新之前仔细分析更新内容可以提供一种替代解决方案。寻找那些不对其他模块有依赖性且不会实质性改变存储数据结构的模块。

如果OpenStack升级影响了跨模块的交互，那么IT团队就需要一起更新这两个模块。但是，难题在于任何节点都可能与其他任何节点进行交互。最安全的打补丁方法就是关闭所有节点。但是，如果跨模块更新涉及了可以关闭的功能，那么就可以安全地重新启动系统。然后，当集群更新时，可再次打开功能。一般来说，最好是一次更新一个OpenStack模块，然后确定集群是否稳定和无错误。当错误修复出错时，区域化方法可实现更为简便的调试。

同时，企业IT技术团队务必需要始终从已知和安全的来源获取更新代码包。这一原则也同样适用于实例与容器镜像、实例与容器中的应用程序和数据，以及OpenStack代码等。当OpenStack集群扩展规模并链接至公共云时，识别和恢复可能是非常耗时的。

最后，升级后还要对系统进行详细的测试和检查，以确保升级正确无误。而实际上，前期准备和后期检查才是耗费时间和人力最多的部分，升级部分其实是很快的。

有没有更好的方法？

虽然有这样的升级方案，但纵观整个升级过程，对于企业IT技术团队的技术能力显然提出了很高的要求，因此，对很多IT技术团队能力不足的企业用户来说，其实是望梅止渴。那么，有没有一种更好的方法可以帮助用户更加容易和简单的平滑升级OpenStack呢？答案是肯定的。

Platform9可实现OpenStack升级的自动化， Stratoscale、NephoScale 和 Mirantis也是可以考虑的升级方案。但它们都还不够完美，因为跨模块的依赖性仍然会是这些解决方案无法跨越的障碍。

不过，在刚刚结束的OpenInfraDays China大会上，易捷行云EasyStack产品总监郑晨在主论坛演讲环节进行的5分钟新一代云平台的现场演示，则有望为用户提供一种“无感”的OpenStack平滑升级解决方案。

通过采用全平台微服务架构，EasyStack新一代云平台实现的不仅仅是单一服务、单一组件的可持续升级，而是整体平台级的平滑无感演进，产品基于的是可持续演进的开源内核和稳定的开源模块，客户将不用关心到底是哪个OpenStack版本，因为稳定、持续更新、开放兼容可以通过平滑升级保证。

这里的核心技术点——全平台微服务化，涵盖计算、网络、存储模块，应用中心、事件网格，从数据库到消息队列，从日志到监控等服务组件的微服务化。通过全新设计的易捷行云EasyStack自动化中心，新一代云平台可以完成微服务粒度的升级操作，在升级过程中，系统会通过分布式高可靠的架构设计保证了云平台服务的生产级高可用。在Demo 中，完全通过自动化中心用户控制台，用户就可以实现自助式上传升级包，完成云平台的升级操作，升级过程对于正在操作的界面和运行的云主机业务没有任何影响。

看到这，被OpenStack升级搞的焦头烂额的你，是不是躲在被窝里偷偷的笑呢？