搜索

将网络服务迁移到 ML2/OVN 机制驱动程序

download PDF
Red Hat OpenStack Platform 16.2

将 Networking 服务(neutron)从 ML2/OVS 机制驱动程序迁移到 ML2/OVN 机制驱动程序

OpenStack Documentation Team

摘要

这是使用 Open Virtual Networking 的 Modular Layer 2 插件将 Red Hat OpenStack Platform Networking(neutron)从 Modular Layer 2 插件迁移到 Modular Layer 2 插件的说明指南。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。

在 JIRA 中提供文档反馈

使用 Create Issue 表单对文档提供反馈。JIRA 问题将在 Red Hat OpenStack Platform Jira 项目中创建,您可以在其中跟踪您的反馈进度。

  1. 确保您已登录到 JIRA。如果您没有 JIRA 帐户,请创建一个帐户来提交反馈。
  2. 点击以下链接打开 Create Issue 页面: Create Issue
  3. 完成 SummaryDescription 字段。在 Description 字段中,包含文档 URL、章节或章节号以及问题的详细描述。不要修改表单中的任何其他字段。
  4. 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.2OVN RHOSP 17.1OVS RHOSP 16.2OVS RHOSP 17.1附加信息

使用 OVN DHCP 置备裸机

OVN 上的内置 DHCP 服务器目前无法置备裸机节点。它无法为 provisioning 网络提供 DHCP。Chainbooting iPXE 需要标记(--dhcp-match 在 dnsmasq 中),这在 OVN DHCP 服务器中不被支持。See https://bugzilla.redhat.com/show_bug.cgi?id=1622154.

VLAN 项目(租户网络)端口的 VF (直接)端口的北/南路由

核心 OVN 限制。请参阅 https://bugs.launchpad.net/neutron/+bug/1875852

内部 DNS 记录的反向 DNS

See https://bugzilla.redhat.com/show_bug.cgi?id=2211426.

隔离网络的内部 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 流量。红帽建议在这种情况下使用 allow_automatic_l3agent_failover 功能,以便在一个网络节点失败时,路由器会重新调度到不同的节点。

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 地址。

  • 您已与红帽大客户经理或全球专业服务合作以规划迁移,并提交主动的支持问题单。请参阅 如何提交主动问题单

流程

  1. 创建 ML2/OVN 阶段部署,以获取目标 ML2/OVN 部署的基础配置,并测试目标部署的可行性。

    使用与迁移后生产部署相同的基本角色、路由和拓扑设计阶段部署。保存 overcloud-deploy.sh 文件以及部署引用的任何文件,如环境文件。稍后需要这些文件来配置迁移目标环境。

    注意

    这些文件仅用于创建 stage 部署并在迁移中。迁移后不要重新使用它们。

  2. 如果您的 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 参数。
  3. 安装 python3-networking-ovn-migration-tool。

    sudo dnf install python3-networking-ovn-migration-tool @container-tools

    @container-tools 参数也会安装容器工具(如果容器工具尚不存在)。

  4. 在 undercloud 上创建目录,再复制 Ansible playbook:

    mkdir ~/ovn_migration
    cd ~/ovn_migration
    cp -rfp /usr/share/ansible/networking-ovn-migration/playbooks .
  5. 将 ML2/OVN 阶段部署文件复制到迁移主目录,如 ~/ovn_migration

    阶段迁移部署文件包括 overcloud-deploy.sh 和部署引用的任何文件,如环境文件。将 overcloud-deploy.sh 副本重命名为 overcloud-deploy-ovn.sh。只将这个脚本用于迁移。不要将它用于其他目的。

  6. 在以下列表中找到您的迁移场景,并执行适当的步骤,以在 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
    • 保留任何自定义网络修改与迁移前相同。
    情景 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
  7. 确保所有用户在文件 overcloud-deploy-ovn.sh 上具有执行权限。这个脚本在迁移过程中需要执行特权。

    $ chmod a+x ~/overcloud-deploy-ovn.sh
  8. 使用 导出 命令设置以下与迁移相关的环境变量。例如:

    $ 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

  9. 确保位于 ovn-migration 目录中,再运行命令 ovn_migration.sh generate-inventory 生成清单文件 host _for_migrationansible.cfg 文件。

    $ ovn_migration.sh generate-inventory   | sudo tee -a /var/log/ovn_migration_output.txt
  10. 检查 host_for_migration 文件的准确性。

    1. 确保列表与您的环境匹配。
    2. 确保每个节点上存在 ovn 控制器。
    3. 确保没有列表标题(如 [ovn-controllers])下没有列表项。
    4. 从 ovn 迁移目录中,运行命令 ansible -i hosts_for_migration -m ping all
  11. 如果您的原始部署使用 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 机制驱动程序的容器镜像

先决条件

流程

  1. 运行 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
  2. 如果您的原始 OVS 部署使用 VXLAN 或 GRE 项目网络,请等待 DHCP 租期已在所有虚拟机实例上续订。这可能需要 24 小时,具体取决于租期续订设置和实例数量。
  3. 验证 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 发行版本的变体。

  4. 如果任何虚拟机实例没有更新,以反映对 DHCP 的 T1 参数的更改,重启它们。
  5. 降低预迁移 VXLAN 和 GRE 网络的 MTU:

    $ ovn_migration.sh reduce-mtu   | sudo tee -a /var/log/ovn_migration_output.txt

    这一步会降低 MTU 网络,并使用 adapted_mtu 标记已完成的网络。该工具仅适用于 VXLAN 和 GRE 网络。如果您的部署只有 VLAN 项目网络,此步骤不会更改任何值。

  6. 如果您在 VXLAN 或 GRE 项目网络上有任何静态 IP 分配的实例,请手动修改这些实例的配置来配置新的 Geneve MTU,这是当前的 VXLAN MTU 减 8 字节。例如,如果基于 VXLAN 的 MTU 是 1450,请将其改为 1442。

    注意

    只有在 VXLAN 或 GRE 项目网络上手动提供了静态 IP 分配和 MTU 设置,才执行此步骤。默认情况下,DHCP 提供 IP 分配和 MTU 设置。

  7. 继续 准备容器镜像以从 OVS 机制驱动程序迁移到 OVN 机制驱动程序

2.3. 准备容器镜像,以便将 ML2 机制驱动程序从 OVS 迁移到 OVN

环境评估和准备是成功迁移的关键。您的红帽大客户经理或全球专业服务将指导您完成这些步骤。

先决条件

流程

  1. 准备新容器镜像,以便在迁移到 ML2/OVN 后使用。

    1. 如果不存在,请在主目录中创建 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
    2. 验证 $HOME/overcloud-deploy-ovn.sh 和 $HOME/overcloud-deploy.sh 文件的末尾是否存在 containers-prepare-parameter.yaml
    3. containers-prepare-parameter.yaml 文件中的 neutron_driver 更改为 ovn:

      $ sed -i -E 's/neutron_driver:([ ]\w+)/neutron_driver: ovn/' $HOME/containers-prepare-parameter.yaml
    4. 验证对 neutron_driver 的更改:

      $ grep neutron_driver $HOME/containers-prepare-parameter.yaml
      neutron_driver: ovn
    5. 更新镜像:

      $ sudo openstack tripleo container image prepare \
      --environment-file /home/stack/containers-prepare-parameter.yaml
      注意

      提供 containers-prepare-parameter.yaml 文件的完整路径。否则,命令可以快速完成,而无需更新镜像列表或提供错误消息。

  2. 在 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
  3. 继续 从 ML2/OVS 迁移到 ML2/OVN

2.4. 将 ML2 机制驱动程序从 OVS 迁移到 OVN

ovn-migration 脚本执行与 ML2 机制驱动程序从 OVS 迁移到 OVN 的原位升级相关的环境设置、迁移和清理任务。

先决条件

流程

  1. 停止与网络服务(neutron) API 交互的所有操作,如创建新网络、子网或路由器,或在计算节点之间迁移虚拟机实例。

    在迁移过程中与网络 API 交互可能会导致未定义的行为。您可以在完成迁移后重启 API 操作。

  2. 运行 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-tunbr-migration ovs 网桥。
    • br-int 中删除以 qr-ha-qg- 开头的端口(使用 neutron-netns-cleanup)。
  • 通过网络服务 API 从数据库中删除网络服务(neutron)代理和网络服务 HA 内部网络。
  • 验证迁移前资源的连接。
  • 删除预迁移资源。
  • 创建迁移后资源。
  • 验证迁移后资源的连接。
  • 清理迁移后资源。
  • 重新运行部署工具,以便在 br-int 上更新 OVN。

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.