对于IT团队来说，OpenStack部署并不总是一项容易的工作。本文将介绍Red Hat公司的Platform Director是如何帮助OpenStack实施和生命周期管理的。

Red Hat所提供的Platform Director在OpenStack部署中填补了一个非常有需求的漏洞。这个基于软件工具有助于消除猜测并减少与私有云计算部署相关的错误——这些问题一直都困扰着OpenStack的早期发展并终止了平台的生产使用。

Platform Director 是Red Hat公司Platform 7及其后续版本的一部分，它涵盖了从规划、部署、持续运营以及更新和扩展的所有内容。

该工具是基于所谓的OpenStack-on-OpenStack，或TripleO的。这是一个部署模式，它由一个在单个机器上运行的专用OpenStack管理层组成，管理员可以使用它来管理和监控一个面向用户的OpenStack云。TripleO的优点在于，它允许企业用户在一个已经运行的更简单单用途部署上开发一个通用的OpenStack部署。这可简化从沙箱版本的迁移。

通过使用TripleO，管理员可以部署一个管理节点引导OpenStack云——即所谓的“云下”。管理员在这个管理节点的基础之上构建生产OpenStack云计算——即所谓的“过云”。他们可以使用命令行实用程序或基于Web图形用户界面来访问Platform Director的应用程序编程接口（API）。

基于云裸机进交互使用Ironic（OpenStack裸机配置服务），进行PXE引导。这需要一大堆的支持驱动程序来确保其硬件与Ironic兼容，但是Red Hat已为用户提供了绝大多数的驱动程序。

开始使用Red Hat OpenStack Platform Director

Platform Director会进行硬件检查并根据节点资源和运行性能自动分配角色。相对于之前采用手动方法来验证节点并为节点分配角色的方法，这是一个重大改进，它是大型OpenStack部署的一个关键功能。

Platform Director拥有一套验证工具，可用于验证任何的用户模板，其中也包括了网络文件。管理员还可以使用这些工具用于更新和扩展。当部署过云时，还有另一个可能自动验证和测试它的工具集Tempestt。

Platform Director中的一组OpenStack Heat模板为强大的高可用性集群提供了最佳做法。这些模板包含了开发人员和用户的经验，它们为OpenStack部署实施提供了有价值的操作信息。例如，它们足够复杂可以确定用户是否需要SSL端点用于加密通信。

使用Platform Director管理OpenStack生命周期

OpenStack部署的第一个阶段是规划。Platform Director拥有定义网络和存储拓扑的配置文件、用于OpenStack模块的操作参数、插件集成以及用于所选配置的其他设置详细信息。然后，这个工具就可以验证硬件以确保其是否准备就绪。

接下来是部署阶段。这是Platform Director大部分功能发挥作用的一个阶段。这款工具验证所选配置，然后从头至尾地编排OpenStack的部署，处理软硬件设置，然后配置OpenStack本身以实现最优性能。

一旦生产版本正式运行，Platform Director可有助于执行软件升级，其中包括小规模安全更新和OpenStack部署的主要版本。为了解决集群扩展与收缩问题，这款工具还能够监控节点和网络运行状况，并从拓扑结构中增加或删除节点。它还能够变更配置参数。

使用Platform Director执行OpenStack更新

Platform Director提供了一种在整个集群中以同步方式更新OpenStack软件的方法。Platform Director的每一版都支持对之前主要版本的管理，以便安全地进行版本升级。可以使用替代方案来维护集群软件，但这会让Platform Director的许多优点无用武之地。第三方工具可以访问Platform Director的API，所以扩展工具集是可行的。

配合OpenStack Nova计算，Platform Director可以检测出任何新的节点，并自动执行它们的部署、安装和运行状态检查。这就让管理员能够随着时间的推移按照他们OpenStack部署的发展而增加不同的节点模式。

自动化以及策略驱动与模板驱动的扩展收缩过程控制，让用户能够更容易地部署大型集群并减少错误。由于Platform Director对新节点和后续部署堆栈使用它的验证工具，所以安装的质量和一致性通常都较高。

升级到新OpenStack版本

随着OpenStack的每个主要版本的发布，这个平台的模块间API通常会发生变化。这需要一个同步过程来一起更新所有的节点。在更新后验证所有的节点也是至关重要的，因为这一步可以识别出任何没有执行更新过程的节点，并以此为依据将其从集群中降级。

次要的OpenStack版本变更不应该改变API，但是要确保集群节点在次要版本中保持相同的版本级别。Platform Director中的验证工具能够检查升级是否完全实施，并验证配置脚本从而控制OpenStack在每一个节点上的运行。

在OpenStack主要版本更新前完成所有节点的增加与删除操作。这将有助于确保新节点的一致性，并允许用户在更新之前以工作模式对集群进行测试。