如何将运行中的OpenStack迁移到Kolla

使用容器化部署OpenStack基础设施带来了许多运维管理上的好处，例如依赖关系的隔离和部署的可重复性，特别是与CI/CD方法结合使用时。Kolla项目提供了帮助部署和操作容器化OpenStack的工具。当前使用Kolla容器配置一个全新的OpenStack环境已经有了很完善的文档，其中Kolla Ansible子项目提供了完整的方案。然而，将现有的OpenStack迁移到Kolla容器可能需要一种更特别的方法，特别是为了将对最终用户的影响降到最低。

我们最近使用Kolla和Kayobe帮助一家公司将现有的OpenStack queens版本最终迁移到容器中，该项目旨在简化裸机节点的使用和配置。这篇博客文章描述了我们为减少对最终用户的影响而采用的迁移策略，并分享了我们在迁移过程中学到的知识。

现有的OpenStack环境

当前的云环境运行的是使用CentOS RPM包安装的OpenStack Queens版本。该环境有16个控制节点，每个服务都部署在两台（用于OpenStack服务）或三台（用于Galera和RabbitMQ）服务器上，以实现高可用性。计算节点包含40个不同的类型服务器，因此导致了CPU，RAM甚至网络接口名称的异构结构（某些节点使用板载以太网接口，另一些节点使用PCI卡）。

一个独立的Ceph集群用作所有需要大量存储的OpenStack服务的后端：Glance，Cinder，Gnocchi以及Nova实例的磁盘（即，没有用户数据存储在计算节点上）。

新的硬件服务器

我们还计划购买新的控制服务器，根据我们的经验和[来自Kolla Ansible的建议，采用以下配置：

• 托管控制服务（如API和数据库）的三个控制器节点

• 两个网络节点运行Neutron agent以及HAProxy/Keepalived

• 三个监控节点，提供集中的日志记录，用于指标收集和告警，这是现有部署中严重缺乏的功能

我们的目标是迁移整个OpenStack环境从而使用Kolla容器，并由Kolla Ansible和Kayobe进行管理，在新的控制平面硬件上运行控制服务，并重新配置计算节点，从而对用户及其工作流程的影响降到最小。

迁移策略

通过使用小规模的测试环境，我们制定了迁移策略。基础架构的管理员将使用他们现有的预配置系统Foreman在新的控制平面上安装CentOS 7。我们将使用Kayobe 安装以及配置新节点的主机OS]，以使其准备部署Kolla容器：配置多个VLAN接口和网络，创建LVM卷，安装Docker等。

然后，我们将在此控制平面上部署OpenStack服务。为了降低迁移的风险，我们的策略是逐步重新配置负载均衡器，以指向每个OpenStack服务的新控制器，同时确认它们不会引起错误。如果出现任何问题，我们将能够快速恢复到原始控制平面上运行的API服务。新的控制器上还将建立新的Galera，Memcached和RabbitMQ集群，尽管现有的集群现在仍将由OpenStack服务使用。然后，在确保所有资源都由新的OpenStack服务管理之后，我们将逐步关闭原始服务。

然后，在计划的停机时间内，我们将复制SQL数据库的内容，重新配置所有服务（在控制平面上以及计算平面上）以使用新的Galera，Memcached和RabbitMQ群集，并迁移负载均衡的虚拟IP到