directx最终用户运行时_如何将运行中的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到已经部署HAProxy和Keepalived的新网络节点。

下面的动画描绘了从原始控制平面迁移到新控制平面的过程，为清楚起见，仅显示了一部分服务。

最后，我们将使用实时迁移释放多个计算节点，在重新配置后在其上重新部署OpenStack服务，然后在其上实时迁移虚拟机。下面的动画显示了hypervisors到Kolla的过渡：

提示与技巧

描述了总体迁移策略之后，我们现在将介绍需要特别注意的任务，并为希望遵循相同方法的操作员提供提示。

配置迁移

为了使迁移无缝，我们希望使部署在新控制平面上的服务配置与原始配置尽可能接近。在某些情况下，这意味着要摆脱Kolla Ansible合理的默认设置，而要利用其广泛的自定义功能。在本节中，我们描述如何将现有配置集成到Kolla Ansible。

原始的配置管理工具将整个OpenStack配置文件保留在源代码控制下，并使用Jinja模板化。现有部署已升级了数次，配置文件没有根据标准进行调整。相比之下，Kolla Ansible使用分层方法，其中Kolla Ansible自身生成的配置与操作员指定的可以添加或重写合并在一起，可以是基于全局的、每个角色(nova)、每个服务(nova api)或每个主机(hypervisor042)。这样做的好处是减少了每次升级时要检查的配置数量，因为Kolla Ansible将跟踪其所使用选项的弃用和删除的情况。

oslo.config项目中的oslo-config-validator工具可帮助审核现有配置中弃用的选项。虽然在Stein中引入，但如果API并未发生实质性变化，则有需要使用较旧的版本来运行。例如，要使用stable/queens分支中的代码 审核nova.conf：

$ git clone -b stable/queens https://opendev.org/openstack/nova.git$ cd nova$ tox -e venv -- pip install --upgrade oslo.config # Update to the latest oslo.config release$ tox -e venv -- oslo-config-validator --config-file etc/nova/nova-config-generator.conf --input-file /etc/nova/nova.conf

这将输出标识已废弃和不建议使用的选项的信息：

ERROR:root:DEFAULT/verbose not foundWARNING:root:Deprecated opt DEFAULT/notify_on_state_change foundWARNING:root:Deprecated opt DEFAULT/notification_driver foundWARNING:root:Deprecated opt DEFAULT/auth_strategy foundWARNING:root:Deprecated opt DEFAULT/scheduler_default_filters found

更新已匹配所部署的发行版之后，所有其他选项都可以移至Kolla Ansible使用的角色配置文件。但是，我们希望根据Kolla Ansible模板(例如nova.conf.j2)来审核每个模板 ，以避免保留多余的选项并检测任何潜在的冲突。与Kolla Ansible的默认设置相比，通过减少自定义配置的数量，将来的升级将变得更加容易。

模板还需要从原始配置管理系统进行调整。Kolla Ansible依赖Jinja，后者可以使用Ansible中设置的变量。但是，当从Kayobe调用时，无法在Kolla Ansible的清单中设置额外的组变量，因此，您必须使用另一种方法代替cpu_allocation_ratio = {{cpu_allocation_ratio}}：

{% if inventory_hostname in groups['compute_big_overcommit'] %}cpu_allocation_ratio = 16.0{% elif inventory_hostname in groups['compute_small_overcommit'] %}cpu_allocation_ratio = 4.0{% else %}cpu_allocation_ratio = 1.0{% endif %}

配置Kolla Ansible以使用现有服务

前面我们曾描述过，我们的迁移策略是在使用现有Galera，Memcached和RabbitMQ集群的同时，在新的控制平面上逐步部署OpenStack服务。本节说明如何使用Kayobe和Kolla Ansible进行配置。

在Kolla Ansible中，许多部署设置是在ansible/group_vars/all.yml中配置的 ，包括RabbitMQ transport URL(rpc_transport_url)和数据库连接(database_address)。

操作员可以使用/etc/kayobe/kolla/globals.yml从Kayobe覆盖这些值 ：

rpc_transport_url: rabbit://username:password@ctrl01:5672,username:password@ctrl02:5672,username:password@ctrl03:5672

另一种方法是填充Kolla Ansible用来生成这些变量的组。在Kayobe中，我们可以为每个现有服务创建一个额外的组(例如ctrl_rabbitmq)，用现有主机填充它，并自定义Kolla Ansible inventory以将服务映射到它们。

在/etc/kayobe/kolla.yml中：

kolla_overcloud_inventory_top_level_group_map:  control:    groups:      - controllers  network:    groups:      - network  compute:    groups:      - compute  monitoring:    groups:      - monitoring  storage:    groups:      "{{ kolla_overcloud_inventory_storage_groups }}"  ctrl_rabbitmq:    groups:      - ctrl_rabbitmq​kolla_overcloud_inventory_custom_components: "{{ lookup('template', kayobe_config_path ~ '/kolla/inventory/overcloud-components.j2') }}"    

在/etc/kayobe/inventory/ hosts中：

[ctrl_rabbitmq]ctrl01 ansible_host=192.168.0.1ctrl02 ansible_host=192.168.0.2ctrl03 ansible_host=192.168.0.3

我们将 Kayobe source tree中的overcloud-components.j2复制到 我们的kayobe-config 存储库的/etc/kayobe/kolla/inventory/overcloud-components.j2中，并对其进行自定义：

[rabbitmq:children]ctrl_rabbitmq​[outward-rabbitmq:children]ctrl_rabbitmq

虽然与Kolla Ansible更好地集成在一起，但应谨慎使用此方法，以免在此过程中重新配置原始控制平面。操作员可以使用Kayobe的--limit和--kolla-limit选项将Ansible剧本限制为特定的组或主机。

自定义Kolla images

即使可以广泛配置Kolla Ansible，有时还是需要自定义Kolla images。例如，我们必须重建 heat-api容器映像，以便它使用不同的Keystone domain：Kolla使用heat_user_domain，而现有部署使用heat。

将修改推送到配置为由Kayobe提取的Kolla存储库后，您可以简单地使用kayobe overcloud容器映像构建命令来重建映像。

在新的控制平面上部署服务

在新的控制平面上部署服务之前，仔细检查我们的配置是否正确。Kayobe可以使用以下命令生成Kolla Ansible使用的配置：

$ kayobe overcloud service configuration generate --node-config-dir /tmp/kolla

要仅部署特定服务，操作员可以使用tags将Kolla Ansible限制为特定角色：

$ kayobe overcloud service deploy --kolla-tags glance

将资源迁移到新服务

大多数OpenStack服务将在部署后可立即开始管理现有资源。但是，有些服务需要操作员手动干预才能执行过渡，特别是在未将服务配置为具有高可用性的情况下。

Cinder

即使将卷数据保留在像Ceph集群这样的分布式后端上，每个卷也可以与特定的cinder-volume服务关联。可以从openstack volume show输出中的os-vol-host-attr：host字段中识别服务。

$ openstack volume show  -c os-vol-host-attr:host -f valuectrl01@rbd

有一个cinder-manage命令，可用于将卷从一种cinder-volume服务迁移到另一种：

$ cinder-manage volume update_host --currenthost ctrl01@rbd --newhost newctrl01@rbd

但是，没有只迁移特定卷的命令，因此如果要迁移到更多的cinder卷服务，则在cinder调度程序在其上分配新卷之前，某些卷将没有要管理的卷。

不要将此命令与设计用于在不同后端之间传输卷数据的cinder migrate混淆。请注意，当目标是使用同一Ceph后端的cinder卷服务时，很可能会删除您的卷数据！

Neutron

除非在Neutron中配置了L3高可用，否则路由器将被分配给特定的neutron-l3 agent服务。可用以下命令替换现有服务：

$ openstack network agent remove router --l3 $ openstack network agent add router --l3 

同样，您可以使用 openstack network agent remove network --dhcp and openstack network agent add network --dhcp 命令来更新DHCP agent。

热迁移实例

除了新的控制平面外，系统还添加了一些其他计算主机，以提供可以承载第一批热迁移实例的免费资源。一旦配置为Nova hypervisors，我们发现即使源hypervisors使用相同的硬件，也无法将实例迁移到它们，因为CPU标志不匹配。

这是由于BIOS版本不匹配引起的：生产中的现有虚拟机监控程序已更新为最新的BIOS，以防止Spectre和Meltdown漏洞，但是这些新的hypervisors没有，从而导致了不同的CPU标志。

这很好地提醒您，在异构基础架构中，操作员应检查Nova使用的cpu_mode。

停机时间如何？

尽管我们希望最大程度地减少对最终用户及其工作流程的影响，但是在该云环境上没有运行需要零停机时间的关键服务。 如果有必要，我们将在删除旧集群之前探索动态的将新控制节点添加到现有集群中。 相反，这也是将几个关键组件的配置重新初始化为原始干净状态的机会。