OpenStack更新：最小化风险和停机时间

为了使OpenStack部署更平稳安全运行，更新和打补丁是非常关键的工作。但是要执行这些更新任务，IT团队要投入的时间精力远不只是按按开关就可以的。

OpenStack平台由大约30个不同的模块组成，其中每个模块都有着相当复杂的功能和要求。OpenStack的开发团队也是基于开源的，这有可能导致不平衡的测试、文档和代码质量。

这就要求IT团队必须定期执行OpenStack更新以避免影响系统运行的稳定性。在很多方面，那就如同是维护一个操作系统（如Windows）一样，需要将bug修复更新保持至最新和确保安全性处于最佳水平。

但是，Windows和OpenStack之间的区别在于后者仍然处于变化较快的发展期，尤其是不同模块的成熟度水平有着较大差异。OpenStack的重要版本发布频率大约为六个月，而微软的发布周期为2-4年。此外，由于OpenStack整体软件成熟度水平不高，功能集在不断发展，所以在重要版本之间的小版本发布也是非常频繁且复杂。

直到近来，用于执行OpenStack更新的首选方法都是使用命令行界面（CLI），这种方法对于单个服务器是很好的，但对于大型节点集群则显得效率低下。对于大型集群执行更新来说，出现错误和更新失败的几率则会显著提高。

执行OpenStack更新的最佳做法

在理想的OpenStack更新中，IT人员应体用所有节点，打补丁，然后重新启动整个配置——但这种方法会导致大量的停机时间。在实施具体更新之前仔细分析更新内容可以提供一种替代解决方案。

寻找那些不对其他模块有依赖性且不会实质性改变存储数据结构的模块。Bug修复是最常见的OpenStack更新，这类更新可滚动应用于所有节点。

如果OpenStack更新影响了跨模块的交互，那么IT团队就需要一起更新这两个模块。但是，难题在于任何节点都可能与其他任何节点进行交互。最安全的打补丁方法就是关闭所有节点。但是，如果跨模块更新涉及了可以关闭的功能，那么就可以安全地重新启动系统。然后，当集群更新时，可再次打开功能。

一般来说，最好是一次更新一个OpenStack模块，然后确定集群是否稳定和无错误。当错误修复出错时，区域化方法可实现更为简便的调试。

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

OpenStack更新的自动化选项

OpenStack社区牢记了Windows中的教训。例如，实现OpenStack更新过程自动化是非常有意义的，因为此举将有助于实现停机时间和风险的最小化。而相关的实现工具在一些OpenStack发布版本中。

Red Hat公司的OpenStack平台软件包就是一个典型的例子。这个软件包可处理所有主要的升级任务，以及一些次要的更新。Red Hat试图避免在非重要发布版本中进行功能变更，例如可能具有跨模块影响的API。

其他的供应商也正在解决这个自动化问题。Platform9可实现OpenStack升级的自动化，而惠普企业、戴尔科技以及IBM也纷纷加入此行列。其他的软件供应商则包括Stratoscale、NephoScale 和 Mirantis。考虑到通过CLI方式手工实现OpenStack升级这一方式的复杂性，管理员应当使用这些软件包中的一种来控制升级过程，从而进一步降低风险。虽然它们还不够完美，因为跨模块的依赖性仍然会是这一过程复杂化，但是它们确实有助于主要版本的升级和发布。