OpenStack：克服开源云平台的升级障碍
OpenStack正逐渐被接受为企业级框架，用于自动化数据中心基础设施，并使组织能够运行各种各样的应用程序和服务。
该平台于2010年开始生产，作为托管提供商Rackspace和美国国家航空航天局的联合项目。它已经发展成为迄今为止最大的开源项目之一，由OpenStack社区举行的两年一度的会议推动发布，其中下一个版本的优先事项被淘汰。
市场研究表明，越来越多的企业OpenStack部署正在从试点项目（或测试和开发平台）转向全面的生产状态，但还有待解决的问题。其中最主要的是确保在升级到最新版本时平滑更新构成OpenStack的无数组件。
OpenStack早期版本的升级总是存在问题，部分原因是大部分开发工作侧重于将其作为基础设施作为服务平台充分运行所需的功能。
早期采用者经常发现自己面临着难以置信的选择。他们可以在安装新代码的同时将OpenStack基础架构脱机，也可以根据新代码将工作负载移至完全独立的部署。
较新的OpenStack版本，例如今年早些时候公布的Ocata版本，更侧重于稳定性和可靠性，重点放在所有模块上，从一个版本升级到下一个版本，尽可能接近零停机时间。
然而，一半以上的OpenStack用户仍然运行的平台版本超过两个版本，最新的用户调查结果显示。
这意味着就OpenStack官方的生命周期而言，它们的版本“不受支持”。然而，打包和分发OpenStack构建的公司通常会提供更长时间的商业支持 - 通常是三到五年。
更重要的是，这可能意味着他们正在使用OpenStack软件模块，这些软件模块自发布以来就被认为具有安全漏洞和问题。
早期采用者使用旧版本
经常出现的是，许多用户仍然在运行旧版本，因为他们是早期采用者，修改了OpenStack版本，使其更适合自己的需求，或者更好地适应现有的IT环境。
“很多OpenStack的早期采用者都在研究这项技术，并且认为它将在敏捷性和灵活性方面提供巨大的潜力，但也可能需要一些工作来适应其组织，并将其与他们自己现有的平台和系统，“OpenStack的Ubuntu产品经理Mark Baker说，Canonical是OpenStack分布最广泛的开发商之一。
这可能涉及自定义代码本身，或者可能从上游导入模块，这意味着他们已经采取了诸如Keystone认证服务的项目，并将其部署到开发前的OpenStack构建中。
Baker说：“我们已经看到客户基于Ubuntu 14.04初始版本的示例，并且由于他们想要一些特定的网络或虚拟化功能，所以他们已经应用补丁来提供这些功能。
“由于OpenStack已经成熟并能够利用虚拟化层中的优势，他们可能已经将该虚拟化堆栈的后期版本或Open vSwitch放在一起，您最终将运行一个不可更新的混合环境办法。”
升级OpenStack
在某些情况下，升级OpenStack也意味着更新操作系统层，而且这不可能使用可用的自动更新工具来实现。
具有讽刺意味的是，将OpenStack适应组织的确切要求的能力是其主要卖点之一。
“不幸的是，OpenStack的价值主张在很大程度上围绕着它很容易定制和高度可插拔。OpenStack专家Mirantis的联合创始人Boris Renski说，这个非常有价值的主张是一个反模式，当涉及云中断时，基础架构堆栈高度垂直整合。
Mirantis的风格本身就是“纯粹玩”的OpenStack分销商，因为它提供了平台直接构建的服务和支持，而不是将其与一些版本的Linux集成在一起，正如许多其他经销商（如Canonical和Red Hat）所做的那样。
也许不足为奇的是，Mirantis一直在为OpenStack用户量身定制一个标准的OpenStack发行版和使用诸如持续集成/持续部署（CI / CD）等技术的优点，以使其基础架构与当前的发行版本保持一致。
OpenStack定制复杂性
这并不意味着OpenStack用户应该避免定制他们的部署，而是在对实际代码本身进行更改时仔细考虑。
“OpenStack的一个优点在于它有一套全面的应用程序接口（ API）服务，您可以将不同的存储技术和不同的网络技术插入其中，并且有一个非常健康的生态系统，围绕OpenStack和发行版就像我们一样，“他说。
“OpenStack与第三方模块结合使用的挑战并不多，因为大家都在这样做。这本身并不是问题 - 你看到那些基本上开发自己的OpenStack的公司，从上游代码开始，或者按照我们这样的分销，然后定制代码，自定义包装和定制工具它。”
Renski支持这一观点，并倡导使用“标准部署范例和插件”，这是由于整个社区广泛使用的。
他说：“可以在这里调整一些旋钮，或者与诸如（轻量级目录访问协议）LDAP或计费的外部系统集成，但应该不惜一切代价避免堆栈的变化。”
企业开源采用的途径
来自OpenStack供应商的消息是坚持发布代码，并自然地从供应商部署商业支持的OpenStack分发。
作为这样的自助服务，Linux的企业接受之路在过去20年左右也是类似的道路。虽然Linux仍然是开放源码，但企业现在通常仅从少数几家商业供应商（如Red Hat，Canonical或Suse）获取资源。
这突出表明，虽然许多开源软件项目可能可以免费下载和使用，但是当您的业务依赖于任何特定技术的顺利运行时，技术支持和运营协助就值得支付。
“我们看到更多的OpenStack用户正在转向像我们这样的分销渠道，因为他们的理解是他们不想将宝贵的开发资源投入到基础设施层的创新中。他们希望将这些资源集中在创新应用领域，从而更有效地进行竞争。“贝克说。
这并不能帮助那些面临一个棘手的手动升级过程的早期采用者，这很有可能需要开发人员或顾问帮助自定义OpenStack部署的帮助。
根据Ovum首席分析师Roy Illsley的说法，所有这一切都指出，部署和维护OpenStack基础设施的过程需要改进。
他说：“OpenStack必须提供一个更简单的升级过程（在下一个版本的路线图上），以便在不受支持的版本上不再支持更多的工作负载。
OpenStack Foundation的生命周期政策受到质疑
此外，Illsley对OpenStack基金会的生命周期政策提出质疑，该政策仅支持最新版本及其直接前身，当新版本只有六个月的时间。
他说：“目前基于时间结束支持的方法显然不能为用户提供支持，所以OpenStack必须以不同的方式思考，并使用可组合的概念来开发更好的模型。
这意味着OpenStack需要变得更加模块化，以便堆栈的各个组件可以更容易地替换为满足特定用户需求的其他组件。
巧合的是，也许不是，这是OpenStack基金会现在似乎正在推动其开发团队采取的方向。在最近的波士顿OpenStack峰会上，首席运营官马克·科利尔（Mark Collier）谈到了“可组合的开放式基础架构”，并呼吁OpenStack开发人员努力实现这一模式。
他说：“通过将不同的项目，不同的服务合在一起，将更多的价值带到一起的机会比以往任何时候都更大，但如果我们不以可以组合的方式创造更多价值，也是一个挑战。”
切除复杂性
设计为可组合意味着模块之间必须有良好的接口，但开发人员也需要减少不必要的复杂性。
Collier引用这种方法的一个例子是Swift对象存储模块，开发用于为OpenStack部署提供存储支持，但也可以在其他环境中作为软件定义的存储平台进行部署和操作。
Collier说：“Swift可能是最前瞻性的项目之一，因为它是从第一天开始构建的，可以组合，意味着它被构建为与OpenStack或其他OpenStack组件一起使用。
所有这些都可能对OpenStack用户有一个熟悉的戒指：“别担心，将来会有更好的事情。只要相信我们。“
原文： http://www.computerweekly.com/feature/Getting-stuck-on-OpenStack-Overcoming-the-open-source-cloud-platforms-upgrade-barriers