将网络服务迁移到 ML2/OVN 机制驱动程序
将 Networking 服务(neutron)从 ML2/OVS 机制驱动程序迁移到 ML2/OVN 机制驱动程序
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。
在 JIRA 中提供文档反馈
使用 Create Issue 表单对文档提供反馈。JIRA 问题将在 Red Hat OpenStack Platform Jira 项目中创建,您可以在其中跟踪您的反馈进度。
- 确保您已登录到 JIRA。如果您没有 JIRA 帐户,请创建一个帐户来提交反馈。
- 点击以下链接打开 Create Issue 页面: Create Issue
- 完成 Summary 和 Description 字段。在 Description 字段中,包含文档 URL、章节或章节号以及问题的详细描述。不要修改表单中的任何其他字段。
- 点 Create。
第 1 章 规划 ML2 机制驱动程序从 OVS 迁移到 OVN
红帽强烈建议您在从 OVS 机制驱动程序迁移到 OVN 机制驱动程序前,从 RHOSP 16.2 升级到 RHOSP 17.1。
在大多数情形中,RHOSP 17.1 给迁移带来了更好的基线。例如,在 RHOSP 16.2 中,您无法从带有中继端口或 iptables 混合防火墙的 OVS 机制驱动程序迁移到 OVN 机制驱动程序。在 RHOSP 17.1 中,您可以:
另外,RHOSP 17.1 版本的 OVN 迁移工具的一些改进在 migration 工具的 16.2 版本中不可用。例如,RHOSP 17.1 迁移工具具有在迁移失败时恢复到 OVS 机制驱动程序的功能。
红帽选择 ML2/OVN 作为从 RHOSP 15.0 开始的所有新部署的默认机制驱动程序,因为它为大多数客户提供了 ML2/OVS 机制驱动程序的即时优势。在我们不断增强和改进 ML2/OVN 功能集的同时,这些版本会与每个发行版本相乘以。
ML2/OVS 机制驱动程序在 RHOSP 17.0 中已弃用。在几个发行版中,红帽将 ML2/OVS 替换为 ML2/OVN。
通过 RHOSP 17 发行版本提供对已弃用的 ML2/OVS 机制驱动程序的支持。在此期间,ML2/OVS 驱动程序处于维护模式,接收程序错误修复和正常支持,大多数新功能开发发生在 ML2/OVN 机制驱动程序中。
在 RHOSP 18.0 中,红帽计划完全删除 ML2/OVS 机制驱动程序并停止支持它。
如果您现有的 Red Hat OpenStack Platform(RHOSP)部署使用 ML2/OVS 机制驱动程序,请开始评估使用 ML2/OVN 机制驱动程序替换 ML2/OVS 机制驱动程序的好处和可行性。RHOSP 16.2 支持迁移,并将在 RHOSP 17.1 中被支持。RHOSP 17.0 中包括了迁移工具用于测试目的。
在试图从 ML2/OVS 迁移到 ML2/OVN 之前,红帽要求您提交积极的支持问题单。在没有主动支持问题单的情况下,红帽不支持迁移。请参阅 如何提交主动问题单。
在此评估早期与您的红帽大客户经理或红帽全球支持服务联系。除了帮助您提交必要的主动支持问题单外,如果您决定迁移,红帽还可以帮助您规划和准备,从以下基本问题开始规划和准备。
- 您应该何时迁移?
- 时间取决于多个因素,包括您的业务需求以及我们对 ML2/OVN 产品的持续改进的状态。请参阅 OVN 和 OVS 机制驱动程序和 ML2/OVS 中的功能支持到 ML2/OVN 原位迁移:验证和禁止的情况。
- 原位迁移或并行迁移?
根据各种因素,您可以选择以下基本方法进行迁移。
- 并行迁移。创建一个使用 ML2/OVN 的新并行部署,然后将操作移到该部署中。
-
原位迁移。使用 ovn_migration.sh 脚本,如本文档所述。请注意,红帽仅在由 RHOSP director 管理的部署中支持
ovn_migration.sh
脚本。
ML2/OVS 到 ML2/OVN 迁移以不完全逆转的方式改变环境。故障或中断的迁移可能会使 OpenStack 环境无法运作。在生产环境中迁移前,请主动提交支持问题单。然后与您的红帽大客户经理或红帽全球支持服务合作,创建备份和迁移计划,并在与生产环境类似的阶段环境中测试迁移。
1.1. OVN 和 OVS 机制驱动程序中的功能支持
检查 Red Hat OpenStack Platform (RHOSP)功能的可用性,作为 OVS 到 OVN 机制驱动程序迁移计划的一部分。
功能 | OVN RHOSP 16.2 | OVN RHOSP 17.1 | OVS RHOSP 16.2 | OVS RHOSP 17.1 | 附加信息 |
---|---|---|---|---|---|
使用 OVN DHCP 置备裸机 | 否 | 否 | 是 | 是 |
OVN 上的内置 DHCP 服务器目前无法置备裸机节点。它无法为 provisioning 网络提供 DHCP。Chainbooting iPXE 需要标记( |
VLAN 项目(租户网络)端口的 VF (直接)端口的北/南路由 | 否 | 否 | 是 | 是 | 核心 OVN 限制。请参阅 https://bugs.launchpad.net/neutron/+bug/1875852。 |
内部 DNS 记录的反向 DNS | 否 | 是 | 是 | 是 | |
隔离网络的内部 DNS 解析 | 否 | 否 | 是 | 是 | OVN 不支持隔离网络的内部 DNS 解析,因为它不为 DNS 服务分配端口。这不会影响 OVS 部署,因为 OVS 使用 dnsmasq。请参阅 https://issues.redhat.com/browse/OSP-25661。 |
安全组日志记录 | 技术预览 | 是 | 否 | 否 | RHOSP 不支持使用 OVS 机制驱动程序的安全组日志记录。 |
无状态安全组 | 否 | 是 | 否 | 否 | 请参阅 配置安全组。 |
负载均衡服务分布式虚拟路由(DVR) | 是 | 是 | 否 | 否 | OVS 机制驱动程序通过 Controller 或网络节点路由负载平衡服务流量,即使启用了 DVR。OVN 机制驱动程序通过 Compute 节点直接路由负载平衡服务流量。 |
IPv6 DVR | 是 | 是 | 否 | 否 | 使用 OVS 机制驱动程序时,RHOSP 不会将 IPv6 流量分发到 Compute 节点,即使启用了 DVR。所有入口/出口流量都通过集中式 Controller 或 Network 节点。如果您需要 IPv6 DVR,请使用 OVN 机制驱动程序。 |
DVR 和第 3 层高可用性(L3 HA) | 是 | 是 | 否 | 否 |
使用 OVS 机制驱动程序的 RHOSP 部署不支持 DVR 与 L3 HA 结合使用。如果您将 DVR 与 RHOSP director 搭配使用,则禁用 L3 HA。这意味着网络服务仍然在网络节点上调度路由器,并在 L3 代理间共享它们。但是,如果一个代理失败,由此代理托管的所有路由器也会失败。这只会影响 SNAT 流量。红帽建议在这种情况下使用 |
1.2. ML2/OVS 到 ML2/OVN 原位迁移:验证和禁止的情况
红帽继续测试和优化原位迁移方案。与您的红帽大客户经理或全球专业服务合作,以确定您的 OVS 部署是否满足有效的原位升级条件。
1.2.1. 验证 ML2/OVS 到 ML2/OVN 迁移场景
- DVR 到 DVR
启动:使用 DVR 的 OVS 的 RHOSP 16.1.1 或更高版本。
结束:使用 OVN 与 DVR 搭配 RHOSP 版本和发行版本.
SR-IOV 不会出现在启动环境或迁移期间或之后添加的。
- 仅限使用虚拟功能(VF)端口的集中式路由 + SR-IOV
启动:使用 OVS(无 DVR)和 SR-IOV 的 RHOSP 16.1.1 或更高版本。
结束:带有 OVN(无 DVR)和 SR-IOV 的 RHOSP 版本和发行版本。
工作负载只使用 SR-IOV 虚拟功能(VF)端口。SR-IOV 物理功能(PF)端口会导致迁移失败。
1.2.2. ML2/OVS 到 ML2/OVN 的原位迁移尚未被验证
在红帽宣布根本问题已解决前,您无法在以下情景中执行 ML2/OVS 到 ML2/OVN 迁移。
- OVS 部署使用网络功能虚拟化(NFV)
- 红帽支持使用 ML2/OVN 和 NFV 的新部署,但尚未成功将 ML2/OVS 和 NFV 部署迁移到 ML2/OVN。要跟踪这个问题的进度,请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1925290。
- 带有物理功能(PF)端口的 SR-IOV
- 当任何工作负载使用 SR-IOV PF 端口时,迁移测试会失败。要跟踪这个问题的进度,请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1879546。
- OVS 使用中继端口
- 如果您的 ML2/OVS 部署使用中继端口,请不要对 ML2/OVN 迁移执行 ML2/OVS。迁移无法正确设置 OVN 环境中的中继端口。要跟踪这个问题的进度,请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1857652。
- 带有 VLAN 项目(租户)网络的 DVR
- 不要通过 DVR 和 VLAN 项目网络迁移到 ML2/OVN。您可以使用集中式路由迁移到 ML2/OVN。要跟踪这个问题的进度,请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1766930。
1.2.3. ML2/OVS 到 ML2/OVN 原位迁移和安全组规则
确保源自 ML2/OVS 部署中的任何自定义安全组规则都与目标 ML2/OVN 部署兼容。
例如,默认安全组包含允许出口到 DHCP 服务器的规则。如果您在 ML2/OVS 部署中删除了这些规则,ML2/OVS 会自动添加允许 DHCP 服务器出口的隐式规则。ML2/OVN 不支持这些隐式规则,因此在目标 ML2/OVN 环境中,DHCP 和元数据流量将无法访问 DHCP 服务器,实例也不会引导。在这种情况下,要恢复 DHCP 访问,您可以添加以下规则:
# Allow VM to contact dhcp server (ipv4) openstack security group rule create --egress --ethertype IPv4 --protocol udp --dst-port 67 ${SEC_GROUP_ID} # Allow VM to contact metadata server (ipv4) openstack security group rule create --egress --ethertype IPv4 --protocol tcp --remote-ip 169.254.169.254 ${SEC_GROUP_ID} # Allow VM to contact dhcp server (ipv6, non-slaac). Be aware that the remote-ip may vary depending on your use case! openstack security group rule create --egress --ethertype IPv6 --protocol udp --dst-port 547 --remote-ip ff02::1:2 ${SEC_GROUP_ID} # Allow VM to contact metadata server (ipv6) openstack security group rule create --egress --ethertype IPv6 --protocol tcp --remote-ip fe80::a9fe:a9fe ${SEC_GROUP_ID}
第 2 章 将 ML2 机制驱动程序从 OVS 迁移到 OVN
2.1. 准备将 ML2 机制驱动程序从 OVS 迁移到 OVN 的环境
环境评估和准备是成功迁移的关键。您的红帽大客户经理或全球专业服务将指导您完成这些步骤。
先决条件
- 您的部署是最新的 RHOSP 16.2 版本。换句话说,如果您需要升级或更新 OpenStack 版本,请首先执行升级或更新,然后执行 ML2/OVS 到 ML2/OVN 迁移。
每个子网池至少有一个 IP 地址。
OVN 机制驱动程序为每个子网创建一个元数据端口。每个元数据端口从 IP 地址池声明 IP 地址。
- 您已与红帽大客户经理或全球专业服务合作以规划迁移,并提交主动的支持问题单。请参阅 如何提交主动问题单。
流程
创建 ML2/OVN 阶段部署,以获取目标 ML2/OVN 部署的基础配置,并测试目标部署的可行性。
使用与迁移后生产部署相同的基本角色、路由和拓扑设计阶段部署。保存
overcloud-deploy.sh
文件以及部署引用的任何文件,如环境文件。稍后需要这些文件来配置迁移目标环境。注意这些文件仅用于创建 stage 部署并在迁移中。迁移后不要重新使用它们。
如果您的 ML2/OVS 部署使用 VXLAN 或 GRE 项目网络,请在 setup-mtu-t1 步骤后调度等待最多 24 小时。
- 此等待周期允许虚拟机实例续订其 DHCP 租期并接收新的 MTU 值。在此期间,您可能需要在一些实例上手动设置 MTU,并重新启动一些实例。
- 24 小时是基于 86400 秒默认配置的时间。实际时间取决于 /var/lib/config-data/puppet-generated/neutron/dhcp_agent.ini dhcp_renewal_time 和 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf dhcp_lease_duration 参数。
安装 python3-networking-ovn-migration-tool。
sudo dnf install python3-networking-ovn-migration-tool @container-tools
@container-tools
参数也会安装容器工具(如果容器工具尚不存在)。在 undercloud 上创建目录,再复制 Ansible playbook:
mkdir ~/ovn_migration cd ~/ovn_migration cp -rfp /usr/share/ansible/networking-ovn-migration/playbooks .
将 ML2/OVN 阶段部署文件复制到迁移主目录,如
~/ovn_migration
。阶段迁移部署文件包括
overcloud-deploy.sh
和部署引用的任何文件,如环境文件。将overcloud-deploy.sh
副本重命名为overcloud-deploy-ovn.sh
。只将这个脚本用于迁移。不要将它用于其他目的。在以下列表中找到您的迁移场景,并执行适当的步骤,以在
overcloud-deploy-ovn.sh
中自定义openstack deploy
命令。- 情景 1: DVR 到 DVR,计算节点具有连接到外部网络
在 overcloud-deploy-ovn.sh 中的
openstack deploy
命令中添加以下环境文件。按照所示的顺序添加它们。此命令使用默认的neutron-ovn-dvr-ha.yaml
文件。如果您使用其他文件,替换命令中的文件名。-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-dvr-ha.yaml \ -e $HOME/ovn-extras.yaml
- 情景 2:集中路由到集中式路由(无 DVR)
-
如果您的部署使用 SR-IOV,请将服务定义
OS::TripleO::Services::OVNMetadataAgent
添加到文件roles_data.yaml
中的 Controller 角色。 保留迁移前自定义网桥映射。
在网络人员或组合的 networker/controller 节点上运行这个命令来获取当前的网桥映射:
sudo podman exec -it neutron_ovs_agent crudini --get /etc/neutron/plugins/ml2/openvswitch_agent.ini ovs bridge_mappings
输出示例
datacentre:br-ex,tenant:br-isolated
-
在 undercloud 上,为网桥映射创建一个环境文件:
/home/stack/neutron_bridge_mappings.yaml
。 在环境文件中设置默认值。例如:
parameter_defaults: ComputeParameters: NeutronBridgeMappings: "datacentre:br-ex,tenant:br-isolated"
在 overcloud-deploy-ovn.sh 中的
openstack deploy
命令中添加以下环境文件。按照所示的顺序添加它们。如果您的环境没有使用 SR-IOV,请省略 neutron-ovn-sriov.yaml 文件。文件 ovn-extras.yaml 尚不存在,但在运行openstack deploy
命令前由脚本 ovn_migration.sh 创建。-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-ha.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-sriov.yaml \ -e /home/stack/ovn-extras.yaml \ -e /home/stack/neutron_bridge_mappings.yaml
- 保留任何自定义网络修改与迁移前相同。
-
如果您的部署使用 SR-IOV,请将服务定义
- 情景 3:利用 Geneve 类型驱动程序到 DVR 的集中式路由,以及通过
br-ex
连接到外部网络的计算节点 - 警告
如果您的 ML2/OVS 部署使用集中式路由和 VLAN 项目(租户)网络,请不要使用 DVR 迁移到 ML2/OVN。您可以使用集中式路由迁移到 ML2/OVN。要跟踪这个限制的进度,请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1766930。
确保计算节点通过
br-ex
网桥连接到外部网络。例如,在一个环境文件中(如 compute-dvr.yaml)中设置以下内容:type: ovs_bridge # Defaults to br-ex, anything else requires specific # bridge mapping entries for it to be used. name: bridge_name use_dhcp: false members: - type: interface name: nic3 # force the MAC address of the bridge to this interface primary: true
确保所有用户在文件
overcloud-deploy-ovn.sh
上具有执行权限。这个脚本在迁移过程中需要执行特权。$ chmod a+x ~/overcloud-deploy-ovn.sh
使用
导出
命令设置以下与迁移相关的环境变量。例如:$ export PUBLIC_NETWORK_NAME=my-public-network
STACKRC_FILE - undercloud 中的 stackrc 文件。
默认: ~/stackrc
OVERCLOUDRC_FILE - undercloud 中的 overcloudrc 文件。
默认: ~/overcloudrc
OVERCLOUD_OVN_DEPLOY_SCRIPT - 部署脚本。
默认值: ~/overcloud-deploy-ovn.sh
PUBLIC_NETWORK_NAME -您的公共网络的名称。
默认: public。
IMAGE_NAME - 用于引导测试服务器的 glance 镜像的名称或 ID。
默认值: cirros.
镜像会在 pre-validation / post-validation 进程中自动下载。
VALIDATE_MIGRATION - 创建迁移资源以验证迁移。在开始迁移前,迁移脚本会引导服务器并验证在迁移后是否可以访问服务器。
默认值:True。
警告迁移验证至少需要两个可用的浮动 IP 地址、两个网络、两个子网、两个实例和两个路由器作为 admin。
另外,由 PUBLIC_NETWORK_NAME 指定的网络必须有可用的浮动 IP 地址,且您必须能够从 undercloud ping它们。
如果您的环境没有满足这些要求,请将 VALIDATE_MIGRATION 设置为 False。
SERVER_USER_NAME - 用于登录迁移实例的用户名。
默认值: cirros.
DHCP_RENEWAL_TIME - DHCP 续订时间(以秒为单位)在 DHCP 代理配置文件中配置。
默认:30
确保位于 ovn-migration 目录中,再运行命令
ovn_migration.sh generate-inventory
生成清单文件 host_for_migration
和ansible.cfg
文件。$ ovn_migration.sh generate-inventory | sudo tee -a /var/log/ovn_migration_output.txt
检查
host_for_migration
文件的准确性。- 确保列表与您的环境匹配。
- 确保每个节点上存在 ovn 控制器。
- 确保没有列表标题(如 [ovn-controllers])下没有列表项。
- 从 ovn 迁移目录中,运行命令 ansible -i hosts_for_migration -m ping all
如果您的原始部署使用 VXLAN 或 GRE,则需要调整最大传输单元(MTU)值。继续 调整 MTU,以便从 OVS 机制驱动程序迁移到 OVN 机制驱动程序。
如果您的原始部署使用 VLAN 网络,您可以跳过 MTU 调整,并继续 准备从 OVS 机制驱动程序迁移到 OVN 机制驱动程序的容器镜像。
2.2. 调整 MTU 以将 ML2 机制驱动程序从 OVS 迁移到 OVN
如果要使用 VXLAN 或 GRE 的 OVN 机制驱动程序从 RHOSP 16.2 迁移到带有 Geneve 的 OVN 机制驱动程序,您必须确保最大传输单元(MTU)设置小于或等于网络中的最小 MTU。
如果您的当前部署使用 VLAN 而不是 VXLAN 或 GRE,请跳过这个过程,并继续 从 OVS 机制驱动程序迁移到 OVN 机制驱动程序的容器镜像。
先决条件
- 您已完成了准备环境 从 OVS 机制驱动程序迁移到 OVN 机制驱动程序 的步骤。
- 您的预迁移部署是最新的 RHOSP 16.2 版本,带有 VXLAN。
流程
运行
ovn_migration.sh setup-mtu-t1
。这会降低运行 DHCP 代理的所有节点中 DHCP 服务器的 T1 参数,该服务器在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/dhcp_agent.ini 中配置dhcp_renewal_time
。$ ovn_migration.sh setup-mtu-t1 | sudo tee -a /var/log/ovn_migration_output.txt
- 如果您的原始 OVS 部署使用 VXLAN 或 GRE 项目网络,请等待 DHCP 租期已在所有虚拟机实例上续订。这可能需要 24 小时,具体取决于租期续订设置和实例数量。
验证 T1 参数是否已传播到现有虚拟机。
- 连接到其中一个计算节点。
通过附加到项目网络的 VM tap 之一运行
tcpdump
。如果 T1 传播成功,预计大约每 30 秒发生请求:
[heat-admin@overcloud-novacompute-0 ~]$ sudo tcpdump -i tap52e872c2-e6 port 67 or port 68 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap52e872c2-e6, link-type EN10MB (Ethernet), capture size 262144 bytes 13:17:28.954675 IP 192.168.99.5.bootpc > 192.168.99.3.bootps: BOOTP/DHCP, Request from fa:16:3e:6b:41:3d, length 300 13:17:28.961321 IP 192.168.99.3.bootps > 192.168.99.5.bootpc: BOOTP/DHCP, Reply, length 355 13:17:56.241156 IP 192.168.99.5.bootpc > 192.168.99.3.bootps: BOOTP/DHCP, Request from fa:16:3e:6b:41:3d, length 30013:17:56.249899 IP 192.168.99.3.bootps > 192.168.99.5.bootpc: BOOTP/DHCP, Reply, length 355
注意这个验证无法使用 cirros 虚拟机。cirros
udhcpc'
实现不会响应 DHCP 选项 58 (T1)。在属于完整的 Linux 虚拟机的端口中尝试此验证。红帽建议您检查工作负载中代表的所有不同操作系统,如 Windows 和 Linux 发行版本的变体。
- 如果任何虚拟机实例没有更新,以反映对 DHCP 的 T1 参数的更改,重启它们。
降低预迁移 VXLAN 和 GRE 网络的 MTU:
$ ovn_migration.sh reduce-mtu | sudo tee -a /var/log/ovn_migration_output.txt
这一步会降低 MTU 网络,并使用 adapted_mtu 标记已完成的网络。该工具仅适用于 VXLAN 和 GRE 网络。如果您的部署只有 VLAN 项目网络,此步骤不会更改任何值。
如果您在 VXLAN 或 GRE 项目网络上有任何静态 IP 分配的实例,请手动修改这些实例的配置来配置新的 Geneve MTU,这是当前的 VXLAN MTU 减 8 字节。例如,如果基于 VXLAN 的 MTU 是 1450,请将其改为 1442。
注意只有在 VXLAN 或 GRE 项目网络上手动提供了静态 IP 分配和 MTU 设置,才执行此步骤。默认情况下,DHCP 提供 IP 分配和 MTU 设置。
- 继续 准备容器镜像以从 OVS 机制驱动程序迁移到 OVN 机制驱动程序。
2.3. 准备容器镜像,以便将 ML2 机制驱动程序从 OVS 迁移到 OVN
环境评估和准备是成功迁移的关键。您的红帽大客户经理或全球专业服务将指导您完成这些步骤。
先决条件
- 您已完成了 为将 ML2 机制驱动程序从 OVS 迁移到 OVN 准备环境的步骤
- 如果您的原始部署使用 VXLAN 或 GRE,您还完成了 从 OVS 机制驱动程序迁移到 OVN 机制驱动程序的 Adjusing MTU 中的步骤。
流程
准备新容器镜像,以便在迁移到 ML2/OVN 后使用。
如果不存在,请在主目录中创建
containers-prepare-parameter.yaml
文件。$ test -f $HOME/containers-prepare-parameter.yaml || sudo openstack tripleo container image prepare default \ --output-env-file $HOME/containers-prepare-parameter.yaml
-
验证 $HOME/overcloud-deploy-ovn.sh 和 $HOME/overcloud-deploy.sh 文件的末尾是否存在
containers-prepare-parameter.yaml
。 将
containers-prepare-parameter.yaml
文件中的 neutron_driver 更改为 ovn:$ sed -i -E 's/neutron_driver:([ ]\w+)/neutron_driver: ovn/' $HOME/containers-prepare-parameter.yaml
验证对 neutron_driver 的更改:
$ grep neutron_driver $HOME/containers-prepare-parameter.yaml neutron_driver: ovn
更新镜像:
$ sudo openstack tripleo container image prepare \ --environment-file /home/stack/containers-prepare-parameter.yaml
注意提供
containers-prepare-parameter.yaml
文件的完整路径。否则,命令可以快速完成,而无需更新镜像列表或提供错误消息。
在 undercloud 上,验证更新的镜像。
. Log in to the undercloud as the user `stack` and source the stackrc file. $ source ~/stackrc $ openstack tripleo container image list | grep '\-ovn'
您的列表应类似以下示例。它包含 OVN 数据库、OVN 控制器、元数据代理和 neutron 服务器代理的容器。
docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-ovn-northd:16.2_20211110.2 docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-ovn-sb-db-server:16.2_20211110.2 docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-ovn-controller:16.2_20211110.2 docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-neutron-server-ovn:16.2_20211110.2 docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-ovn-nb-db-server:16.2_20211110.2 docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-neutron-metadata-agent-ovn:16.2_20211110.2
- 继续 从 ML2/OVS 迁移到 ML2/OVN。
2.4. 将 ML2 机制驱动程序从 OVS 迁移到 OVN
ovn-migration 脚本执行与 ML2 机制驱动程序从 OVS 迁移到 OVN 的原位升级相关的环境设置、迁移和清理任务。
先决条件
- 您已完成了 准备从 ML2/OVS 迁移到 ML2/OVN的步骤
- 如果您的原始部署使用 VXLAN 或 GRE,您还完成了 从 OVS 机制驱动程序迁移到 OVN 机制驱动程序的 Adjusing MTU 中的步骤。
- 您还可以通过 为从 OVS 机制驱动程序迁移到 OVN 机制驱动程序准备容器镜像 完成所有必要的迁移步骤。
流程
停止与网络服务(neutron) API 交互的所有操作,如创建新网络、子网或路由器,或在计算节点之间迁移虚拟机实例。
在迁移过程中与网络 API 交互可能会导致未定义的行为。您可以在完成迁移后重启 API 操作。
运行
ovn_migration.sh start-migration
以开始迁移过程。tee
命令创建脚本输出的副本,以进行故障排除。$ ovn_migration.sh start-migration | sudo tee -a /var/log/ovn_migration_output.txt
结果
该脚本执行以下操作:
- 创建迁移前资源(网络和虚拟机)以验证现有的部署和最终迁移。
- 更新 overcloud 堆栈以部署 OVN 以及引用实施服务,使用临时网桥 br-migration 而不是 br-int。临时网桥有助于限制迁移期间的停机时间。
- 通过运行 neutron-ovn-db-sync-util 生成 OVN 北向数据库。实用程序检查 Neutron 数据库以在 OVN 北向数据库中创建等效的资源。
- 将现有资源从 br-int 克隆到 br-migration,以允许 ovn 通过 br-migration 查找相同的资源 UUID。
- 将 ovn-controller 重定向到 br-int,而不是 br-migration。
删除 ML2/OVN 不使用的节点资源,包括以下内容:
- 清理网络命名空间(fip、snat、qq、qdhcp)。
-
删除
br-int
上的任何不必要的跳接端口。 -
移除
br-tun
和br-migration
ovs 网桥。 -
从
br-int
中删除以qr-
、ha-
和qg-
开头的端口(使用 neutron-netns-cleanup)。
- 通过网络服务 API 从数据库中删除网络服务(neutron)代理和网络服务 HA 内部网络。
- 验证迁移前资源的连接。
- 删除预迁移资源。
- 创建迁移后资源。
- 验证迁移后资源的连接。
- 清理迁移后资源。
-
重新运行部署工具,以便在
br-int
上更新 OVN。