OpenStack用户是否须要升级版本？

一、OpenStack升级问题

OpenStack正逐渐被接受为企业级框架，用于自动化数据中心基础设施，并使企业可以运营各类各样的应用程序和服务。

2010年，该平台做为托管服务提供商Rackspace和NASA的联合项目出如今市场上。目前，它已经发展成为迄今为止最大的开放源码项目之一，其版本发布由OpenStack社区一年两次的会议推进，每次会议通常会公布下一个版本的优先事项。

市场研究代表，愈来愈多的企业OpenStack部署正在从试点项目（测试和开发平台）转向全面的生产状态，但还有一些待解决的问题——其中最主要的是确保在升级到最新版本时能平滑更新构成OpenStack的无数组件。OpenStack早期版本的升级老是有问题的，部分缘由是那时候大部分开发工做侧重于保证其做为IaaS平台充分运行所需的功能。

早期采用者常常发现本身面临着难以置信的选择——要么在安装新代码的同时将OpenStack基础设施脱机，要么简单地将工做负载迁移到基于新代码的、彻底独立的部署。这样的升级使得整个原有的平台在升级过程当中须要花费大量时间中断业务，并升级相关软件包，并考虑软件包的相互依赖问题。在升级完成后，还须要通过大量的测试，确保不会影响其余原有的OpenStack组件，这样的升级常常使得用户“苦不堪言”。

二、OpenStack产品升级支持度

而随着OpenStack社区的努力和产品的进步，和运维人员素质的提升，升级变得愈来愈可控，对业务的影响也变得更小了。特别是OpenStack产品在推出Kolla容器化部署后，因为容器的特性，可使得每一个组件能够解耦，对每一个组件能够实现“原子化”的升级，令以前被一直诟病的升级问题变得易于处理。

较新的OpenStack版本，例现在年早些时候公布的Queen版本，更侧重于稳定性和可靠性，强调全部模块在升级时尽量接近零停机时间。OpenStack社区也在经过对产品的不断提升功能性和稳定性，吸引用户来升级Openstack产品，也使得用户有兴趣升级已经部署在机房而且运行着的OpenStack。

然而，最新用户调查结果显示，有一半以上的OpenStack用户仍然运行着比最新版本老两个以上版本的平台。这意味着按照OpenStack官方的生命周期，这些用户的版本“不受支持”。打包和分发OpenStack构建的公司一般会提供更长时间（一般是三到五年）的商业支持。更重要的是，这可能意味着他们正在使用自发布以来就被认为具备安全漏洞和问题的OpenStack软件模块。

三、OpenStack升级变得简易化

Openstack迭代很快，半年一次的更新每每会引入新的特性，及原有功能的完善。每一个新版本都包含了大量的新特性以及性能稳定性的提高。

版本升级成为了一个不可避免的问题。因为openstack升级的复杂性许多公司和团队采用直接迁移至新版本云的方案，这是不失为一种可行的方案。

在某些状况下，升级OpenStack也意味着更新操做系统层， OpenStack的价值主张在很大程度上围绕着它很容易定制和高度可插拔的。OpenStack的一个优势在于它有一套全面的应用程序编程接口（API）服务，能够将不一样的存储技术和不一样的网络技术插入其中，而且围绕OpenStack和发行版有一个很是健康的生态系统。

实际上，“纯净的”OpenStack （即未通过定制化修改的原版OpenStack）并不难升级，由于每一个OpenStack版本都是为无缝滚动更新（rollover）设计的，并经受大量的社区测试，确保升级过程尽量顺畅无阻。在升级过程当中，应该尽可能减小生产环境的中断时间，所以须要优化升级过程，平滑升级。

从软件的进化的原则来讲，在不断的bug修复过程当中，才能提升软件产品的高可用性和鲁棒性，从早期版本到最新版本过程当中，中间有多个大版本的进步，那么OpenStack不管是从功能性、易用性或者是从稳定性来讲都是有了质变的提高，在不断修复bug的同时，社区的开发人员也从用户反馈的问题进行思考，而不是脱离实际用户。另外，社区也建议，使用比最新一版（Rocky）更低一级的版本（Queens）版本，这样即增长了社区的功能和稳定性，也下降了最新版本可能存在的风险。

四、功能的多样性

OpenStack的产品每一个版本都有新的项目加入，特别是社区实行了big tent策略以后，新的项目更是层出不穷，特别是新的项目如cinder multi-attach解决了共享存储的问题、cyborg对GPU有了更好的支持、也引进了Plecement API，给用户更好的可见性、cellv2模块支撑了更大的部署规模、octavia模块提供了一种全新的解决LB的思路、 keystone增长了多因素身份验证规则提升了云平台的安全性、界面上也把各个版本增长的功能体如今Horizon组件上、容器化也新增了kuryr和zun等组件来融合容器平台、OpenStack-Helm用于在Kubernetes之上管理 OpenStack的生命周期……还有不少精彩的新增功能来契合用户的痛点。

五、一些伪报道

因为一些Vmware厂商和支持在裸机上直接部署容器的厂商的竞争，一些报道为了夸大OpenStack的缺点，所以可能用了一些修饰手法，从OpenStack社区开发人员“大量减小”或者是bug数“指数级增长”，都是比较片面的说法。从Mikata版本到Queens版本OpenStack社区的resolved bug数目来看，每一个组件都有一些不一样程度的增长和减小，而不是单纯的bug数量增长，更不是“指数性”增长。

六、OpenStack升级的优点

OpenStack 是软件，是软件就会有 bug。 OpenStack 包含了不少组件，结构很松散，每一个组件能够单独更新，只要保证各个组件都属于同一个大版本（好比 kilo, liberty）就不会有问题。在旧版本遇到了 bug，若是社区已经有 fix，只须要更新包含该 fix 的组件就能够了，其余组件保持不变。

6.1高效性。升级完成后，具有高效性。这一目标主要体如今：一是资源，时间资源、空间资源的高效利用，充分挖掘服务器的可利用价值，因为新的组件具有了资源占用更少、计算更加高效的特性，知足了升级的高效性；二是操做，OpenStack升级为用户提供便捷式操做，在原有功能基础上提供程序修改、软件组装、指令调整等新型功能。

6.2经济性。一项新软件产品成功研发需消耗大量的人力、物力、财力。从成本耗资角度考虑，新软件产品需符合持久应用的标准。而OpenStack借助了社区的力量，不须要在OpenStack软件开发上投入，使得产品的升级不须要耗费太多的成本，创造了良好的经济收益。并且社区一年发布2个版本，所以不会致使更新很是频繁。

6.3安全性。OpenStack产品升级配备了更高的安全防护功能，对常见的功能缺陷及时补充改进，加强云产品抗***的能力。如：用户认证开启了更强的安全防护功能，对网络的安全协议有了更好的支持，从而提升了软件工程系统的抗侵袭性能。

6.4稳定性。因为OpenStack社区具备庞大的开发者，而代码质量参差不齐，每一个版本都有不少明显或者不明显的Bug，那么在升级过程当中，能够将已知的Bug进行修复，提升了OpenStack云产品的稳定性，以避免在生产中发现问题，致使更大的损失。也符合软件升级螺旋式上升的特性。

6.5松耦合性。松耦合性是升级的一个重要目标，极大的下降了升级的成本投入，因为OpenStack组件都是松耦合的特色，只须要更改一个模块便可，实现合理的“即插即用”能够实现单一组件的升级，而没必要对OpenStack云产品作大的更改。缩短了从新编程消耗的时间，这是升级的必然趋势，提升了软件产品工做的效率，缩短了从新编译时间，也更符合无痛升级的特色。