如何建模可以帮助你避免在OpenStack中遇到问题
OpenStack 部署完就是一个 “僵栈StuckStack”，一般出于技术原因，但有时是商业上的原因，它是无法在没有明显中断，也不花费时间和成本的情况下升级的。在关于这个话题的最后一篇文章中，我们讨论了这些云中有多少陷入僵局，以及当时是怎么决定的与如今的大部分常识相符。现在 OpenStack 已经有 7 年了，最近随着容器编排系统的增长以及更多企业开始利用公共和私有的云平台，OpenStack 正面临着压力。
没有魔法解决方案
如果你仍在寻找一个可以没有任何问题地升级你现有的 僵栈StuckStack 的解决方案，那么我有坏消息给你：没有魔法解决方案，你最好集中精力建立一个标准化的平台，它可以有效地运营和轻松地升级。
廉价航空业已经表明，虽然乘客可能渴望最好的体验，可以坐在头等舱或者商务舱喝香槟，有足够的空间放松，但是大多数人会选择乘坐最便宜的，最终价值等式不要让他们付出更多的代价。工作负载是相同的。长期而言，工作负载将运行在最经济的平台上，因为在高价硬件或软件上运行的业务实际上并没有受益。
Amazon、Microsoft、Google 等大型公共云企业都知道，这就是为什么他们建立了高效的数据中心，并使用模型来构建、操作和扩展基础设施。长期以来，企业一直奉行以设计、制造、市场、定价、销售、实施为一体的最优秀的硬件和软件基础设施。现实可能并不总是符合承诺，但它现在还不重要，因为成本模式cost model在当今世界无法生存。一些组织试图通过改用免费软件替代，而不改变自己的行为来解决这一问题。因此，他们发现，他们只是将成本从获取软件变到运营软件上。好消息是，那些高效运营的大型运营商使用的技术，现在可用于所有类型的组织。
什么是软件模型?
虽然许多年来，软件程序由许多对象、进程和服务而组成，但近年来，程序是普遍由许多单独的服务组成，它们高度分布在数据中心的不同服务器以及跨越数据中心的服务器上。
OpenStack 服务的简单演示
许多服务意味着许多软件需要配置、管理并跟踪许多物理机器。以成本效益的方式规模化地进行这一工作需要一个模型，即所有组件如何连接以及它们如何映射到物理资源。为了构建模型，我们需要有一个软件组件库，这是一种定义它们如何彼此连接以及将其部署到平台上的方法，无论是物理的还是虚拟的。在 Canonical 公司，我们几年前就认识到这一点，并建立了一个通用的软件建模工具 Juju，使得运营商能够从 100 个通用软件服务目录中组合灵活的拓扑结构、架构和部署目标。
Juju 建模 OpenStack 服务
在 Juju 中，软件服务被定义为一种叫做 Charm 的东西。 Charms 是代码片段，它通常用 python 或 bash 编写，其中提供有关服务的信息 - 声明的接口、服务的安装方式、可连接的其他服务等。
Charms 可以简单或者复杂，具体取决于你想要赋予的功能。对于 OpenStack，Canonical 在上游 OpenStack 社区的帮助下，为主要 OpenStack 服务开发了一套完整的 Charms。Charms 代表了模型的说明，使其可以轻松地部署、操作扩展和复制。Charms 还定义了如何升级自身，包括在需要时执行升级的顺序以及如何在需要时优雅地暂停和恢复服务。通过将 Juju 连接到诸如 裸机即服务(MAAS) 这样的裸机配置系统，其中 OpenStack 的逻辑模型可以部署到物理硬件上。默认情况下，Charms 将在 LXC 容器中部署服务，从而根据云行为的需要，提供更大的灵活性来重新定位服务。配置在 Charms 中定义，或者在部署时由第三方工具(如 Puppet 或 Chef)注入。
这种方法有两个不同的好处：1 - 通过创建一个模型，我们从底层硬件抽象出每个云服务。2 - 使用已知来源的标准化组件，通过迭代组合新的架构。这种一致性使我们能够使用相同的工具部署非常不同的云架构，运行和升级这些工具是安全的。
通过全面自动化的配置工具和软件程序来管理硬件库存，运营商可以比使用传统企业技术或构建偏离核心的定制系统更有效地扩展基础架构。有价值的开发资源可以集中在创新应用领域，使新的软件服务更快上线，而不是改变标准的商品基础设施，这将会导致进一步的兼容性问题。
在下一篇文章中，我将介绍部署完全建模的 OpenStack 的一些最佳实践，以及如何快速地进行操作。如果你有一个现有的 僵栈StuckStack，那么虽然我们不能很容易地拯救它，但是与公有云相比，我们将能够让你走上一条完全支持的、高效的基础架构以及运营成本的道路。
即将举行的网络研讨会
如果你在旧版本的 OpenStack 中遇到问题，并且想要轻松升级 OpenStack 云并且无需停机，请观看我们的在线点播研讨会，从 Newton 升级到 Ocata 的现场演示。