8.2. 自定义 overcloud 网络


您可以为 overcloud 自定义物理网络的配置。例如,您可以使用 Jinja2 ansible 格式的 NIC 模板文件为网络接口控制器(NIC)创建配置文件,即 j2

8.2.1. 定义自定义网络接口模板

您可以创建一组自定义网络接口模板,为 overcloud 环境中的每个节点定义 NIC 布局。overcloud 核心模板集合包含一组用于不同用例的默认 NIC 布局。您可以使用带有 .j2.yaml 扩展的 Jinja2 格式文件来创建自定义 NIC 模板。director 在部署期间将 Jinja2 文件转换为 YAML 格式。

然后,您可以将 overcloud-baremetal-deploy.yaml 节点定义文件中的 network_config 属性设置为自定义 NIC 模板,以便为特定节点置备网络。有关更多信息,请参阅为 overcloud 置备裸机节点

8.2.1.1. 创建自定义 NIC 模板

创建一个 NIC 模板,为 overcloud 环境中的每个节点自定义 NIC 布局。

流程

  1. 将您需要的示例网络配置模板从 /usr/share/ansible/roles/tripleo_network_config/templates/ 复制到环境文件目录中:

    $ cp /usr/share/ansible/roles/tripleo_network_config/templates/<sample_NIC_template> /home/stack/templates/<NIC_template>
    • <sample_NIC_template > 替换为您要复制的示例 NIC 模板的名称,如 single_nic_vlans/single_nic_vlans.j2
    • <NIC_template > 替换为自定义 NIC 模板文件的名称,如 single_nic_vlans.j2
  2. 更新自定义 NIC 模板中的网络配置,以匹配 overcloud 网络环境的要求。有关可用于配置 NIC 模板的属性的详情,请参考 网络接口配置选项。有关 NIC 模板示例,请参阅自定义 网络接口示例
  3. 创建或更新现有环境文件以启用自定义 NIC 配置模板:

    parameter_defaults:
      ControllerNetworkConfigTemplate: '/home/stack/templates/single_nic_vlans.j2'
      CephStorageNetworkConfigTemplate: '/home/stack/templates/single_nic_vlans_storage.j2'
      ComputeNetworkConfigTemplate: '/home/stack/templates/single_nic_vlans.j2'
  4. 如果您的 overcloud 使用默认的内部负载均衡,请在环境文件中添加以下配置来为 Redis 和 OVNDB 分配可预测的虚拟 IP:

    parameter_defaults:
      RedisVirtualFixedIPs: [{'ip_address':'<vip_address>'}]
      OVNDBsVirtualFixedIPs: [{'ip_address':'<vip_address>'}]
    • <vip_address > 替换为分配池范围之外的 IP 地址。

8.2.1.2. 网络接口配置选项

使用下表来了解用于配置网络接口的可用选项。

interface

定义一个网络接口。网络接口名称使用实际接口名称(eth0、eth1、 enp0s25)或一组编号的接口(nic1nic 2、nic3)。 当使用编号接口(如 nic1nic2 )时,角色中的主机网络接口不必完全相同,而不是命名的接口,如 eth0eno2。例如,一个主机可能有一个接口 em1em2,而另一个主机有 eno1eno2,但您可以将两个主机的 NIC 指代为 nic1nic2

编号的接口的顺序与命名的网络接口类型的顺序对应:

  • ethX 接口,如 eth 0、eth1 等。它们通常位于板上接口。
  • enoX 接口,如 eno0eno1 等。它们通常位于板上接口。
  • enX 接口,按字母数字排序,如 enp3s 0、enp3s1、 ens3 等。这些通常是附加组件接口。

编号的 NIC 方案仅包含实时接口,例如,如果接口已将电缆附加到交换机。如果您有一些具有四个接口的主机以及一些接口,请使用 nic1nic4,并且每个主机上仅附加四个电缆。

  - type: interface
    name: nic2
表 8.1. 接口选项
选项默认描述

name

 

接口的名称。网络接口名称使用实际接口名称(eth0、eth1、 enp0s25)或一组编号的接口(nic1nic 2、nic3)。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给接口的 IP 地址列表。

Routes

 

分配给接口的路由列表。如需更多信息,请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

primary

False

将接口定义为主接口。

persist_mapping

False

编写设备别名配置而不是系统名称。

dhclient_args

None

要传递给 DHCP 客户端的参数。

dns_servers

None

您要用于接口的 DNS 服务器列表。

ethtool_opts

 

将这个选项设置为 "rx-flow-hash udp4 sdfn",以便在某些 NIC 上使用 VXLAN 时提高吞吐量。

vlan

定义 VLAN。使用从 parameters 部分传递的 VLAN ID 和子网。

例如:

  - type: vlan
    device: nic{{ loop.index + 1 }}
    mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
    vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
    addresses:
    - ip_netmask:
      {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
  routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
表 8.2. VLAN 选项
选项默认描述

vlan_id

 

VLAN ID。

device

 

用于附加 VLAN 的父设备。当 VLAN 不是 OVS 网桥的成员时,请使用此参数。例如,使用此参数将 VLAN 附加到绑定接口设备。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给 VLAN 的 IP 地址列表。

Routes

 

分配给 VLAN 的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

primary

False

将 VLAN 定义为主接口。

persist_mapping

False

编写设备别名配置而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

用于 VLAN 的 DNS 服务器列表。

ovs_bond

在 Open vSwitch 中定义将两个或多个 接口 接合在一起的绑定。这有助于冗余并增加带宽。

例如:

  members:
    - type: ovs_bond
      name: bond1
      mtu: {{ min_viable_mtu }}
      ovs_options: {{ bond_interface_ovs_options }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu }}
表 8.3. ovs_bond options
选项默认描述

name

 

绑定的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给绑定的 IP 地址列表。

Routes

 

分配给绑定的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

primary

False

将接口定义为主接口。

成员

 

要在绑定中使用的一系列接口对象。

ovs_options

 

在创建绑定时传递给 OVS 的一组选项。

ovs_extra

 

在绑定的网络配置文件中,设置为 OVS_EXTRA 参数的一组选项。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时应用。

persist_mapping

False

编写设备别名配置而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

要用于绑定的 DNS 服务器列表。

ovs_bridge

在 Open vSwitch 中定义一个网桥,将多个 interface, ovs_bond, 和 vlan 对象连接在一起。

网络接口类型 ovs_bridge 参数名称。

注意

如果您有多个网桥,则必须使用除接受默认名称 bridge_name 以外的不同网桥名称。如果不使用不同的名称,则在聚合阶段,则两个网络绑定将放置在同一网桥上。

如果您要为外部 tripleo 网络定义 OVS 网桥,则保留 bridge_nameinterface_name 值作为部署框架,会自动将这些值替换为外部网桥名称和外部接口名称。

例如:

  - type: ovs_bridge
    name: br-bond
    dns_servers: {{ ctlplane_dns_nameservers }}
    domain: {{ dns_search_domains }}
    members:
    - type: ovs_bond
      name: bond1
      mtu: {{ min_viable_mtu }}
      ovs_options: {{ bound_interface_ovs_options }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu }}
注意

OVS 网桥连接到 Networking 服务(neutron)服务器来获取配置数据。如果 OpenStack 控制流量(通常是 Control Plane 和 Internal API 网络)放置在 OVS 网桥上,那么每当您升级 OVS 时,与 neutron 服务器的连接将会丢失,或者 OVS 网桥由 admin 用户或进程重启。这会导致停机。如果在这些情况下无法接受停机时间,您必须将 Control 组网络放在单独的接口或绑定中,而不是 OVS 网桥:

  • 当您将 Internal API 网络放在 provisioning 接口和 OVS 网桥到第二个接口上时,您可以达到最小设置。
  • 要实现绑定,至少需要两个绑定(我们的网络接口)。将控制组放在 Linux 绑定(Linux 网桥)上。如果交换机不支持 LACP 回退到单一接口进行 PXE 引导,那么这个解决方案至少需要 5 个 NIC。
表 8.4. ovs_bridge options
选项默认描述

name

 

网桥的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给网桥的 IP 地址列表。

Routes

 

分配给网桥的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

成员

 

要在网桥中使用的一系列接口、VLAN 和绑定对象。

ovs_options

 

在创建网桥时传递给 OVS 的一组选项。

ovs_extra

 

一组选项,用于在网桥的网络配置文件中设置为 OVS_EXTRA 参数。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时应用。

persist_mapping

False

编写设备别名配置而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

要用于网桥的 DNS 服务器列表。

linux_bond

定义将两个或多个 接口 接合在一起的 Linux 绑定。这有助于冗余并增加带宽。确保在 bonding_options 参数中包含基于内核的绑定选项。

例如:

- type: linux_bond
  name: bond1
  mtu: {{ min_viable_mtu }}
  bonding_options: "mode=802.3ad lacp_rate=fast updelay=1000 miimon=100 xmit_hash_policy=layer3+4"
  members:
    type: interface
    name: ens1f0
    mtu: {{ min_viable_mtu }}
    primary: true
  type: interface
    name: ens1f1
    mtu: {{ min_viable_mtu }}
表 8.5. linux_bond options
选项默认描述

name

 

绑定的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给绑定的 IP 地址列表。

Routes

 

分配给绑定的路由列表。请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

primary

False

将接口定义为主接口。

成员

 

要在绑定中使用的一系列接口对象。

bonding_options

 

创建绑定时的一组选项。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时应用。

persist_mapping

False

编写设备别名配置而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

要用于绑定的 DNS 服务器列表。

linux_bridge

定义一个 Linux 网桥,它将多个 interface, linux_bond, 和 vlan 对象连接在一起。外部网桥也为参数使用两个特殊值:

  • bridge_name,它被外部网桥名称替代。
  • interface_name,它被外部接口替换。

例如:

  - type: linux_bridge
      name: bridge_name
      mtu:
        get_attr: [MinViableMtu, value]
      use_dhcp: false
      dns_servers:
        get_param: DnsServers
      domain:
        get_param: DnsSearchDomains
      addresses:
      - ip_netmask:
          list_join:
          - /
          - - get_param: ControlPlaneIp
            - get_param: ControlPlaneSubnetCidr
      routes:
        list_concat_unique:
          - get_param: ControlPlaneStaticRoutes
表 8.6. linux_bridge options
选项默认描述

name

 

网桥的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给网桥的 IP 地址列表。

Routes

 

分配给网桥的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

成员

 

要在网桥中使用的一系列接口、VLAN 和绑定对象。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时应用。

persist_mapping

False

编写设备别名配置而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

要用于网桥的 DNS 服务器列表。

Routes

定义应用到网络接口、VLAN、网桥或绑定的路由列表。

例如:

  - type: linux_bridge
    name: bridge_name
    ...
    routes: {{ [ctlplane_host_routes] | flatten | unique }}
选项默认描述

ip_netmask

目标网络的 IP 和子网掩码。

default

False

将此路由设置为默认路由。等同于设置 ip_netmask: 0.0.0.0/0

next_hop

用于访问目标网络的路由器的 IP 地址。

8.2.1.3. 自定义网络接口示例

以下示例演示了如何自定义网络接口模板。

分隔控制组和 OVS 网桥示例

以下示例 Controller 节点 NIC 模板配置与 OVS 网桥分开的控制组。该模板使用五个网络接口,并为编号的接口分配多个标记的 VLAN 设备。该模板在 nic4nic5 上创建 OVS 网桥。

network_config:
- type: interface
  name: nic1
  mtu: {{ ctlplane_mtu }}
  use_dhcp: false
  addresses:
  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
  routes: {{ ctlplane_host_routes }}
- type: linux_bond
  name: bond_api
  mtu: {{ min_viable_mtu_ctlplane }}
  use_dhcp: false
  bonding_options: {{ bond_interface_ovs_options }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  members:
  - type: interface
    name: nic2
    mtu: {{ min_viable_mtu_ctlplane }}
    primary: true
  - type: interface
    name: nic3
    mtu: {{ min_viable_mtu_ctlplane }}
{% for network in role_networks if not network.startswith('Tenant') %}
- type: vlan
  device: bond_api
  mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
  vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
  addresses:
  - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
  routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
{% endfor %}
- type: ovs_bridge
  name: {{ neutron_physical_bridge_name }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  members:
  - type: linux_bond
    name: bond-data
    mtu: {{ min_viable_mtu_dataplane }}
    bonding_options: {{ bond_interface_ovs_options }}
    members:
    - type: interface
      name: nic4
      mtu: {{ min_viable_mtu_dataplane }}
      primary: true
    - type: interface
      name: nic5
      mtu: {{ min_viable_mtu_dataplane }}
{% for network in role_networks if network.startswith('Tenant') %}
  - type: vlan
    device: bond-data
    mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
    vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
    addresses:
    - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
    routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}

多个 NIC 示例

以下示例使用第二个 NIC 连接到具有 DHCP 地址的基础架构网络,以及绑定的另一个 NIC。

network_config:
  # Add a DHCP infrastructure network to nic2
  - type: interface
    name: nic2
    mtu: {{ tenant_mtu }}
    use_dhcp: true
    primary: true
  - type: vlan
    mtu: {{ tenant_mtu }}
    vlan_id: {{ tenant_vlan_id }}
    addresses:
    - ip_netmask: {{ tenant_ip }}/{{ tenant_cidr }}
    routes: {{ [tenant_host_routes] | flatten | unique }}
  - type: ovs_bridge
    name: br-bond
    mtu: {{ external_mtu }}
    dns_servers: {{ ctlplane_dns_nameservers }}
    use_dhcp: false
    members:
      - type: interface
        name: nic10
        mtu: {{ external_mtu }}
        use_dhcp: false
        primary: true
      - type: vlan
        mtu: {{ external_mtu }}
        vlan_id: {{ external_vlan_id }}
        addresses:
        - ip_netmask: {{ external_ip }}/{{ external_cidr }}
        routes: {{ [external_host_routes, [{'default': True, 'next_hop': external_gateway_ip}]] | flatten | unique }}

8.2.1.4. 为预置备节点自定义 NIC 映射

如果使用预置备节点,您可以使用以下方法之一为特定节点指定 os-net-config 映射:

  • 在环境文件中配置 NetConfigDataLookup heat 参数,并运行不带 --network-configopenstack overcloud node provision 命令。
  • 在节点定义文件 overcloud-baremetal-deploy.yaml 中配置 net_config_data_lookup 属性,并使用 --network-config 运行 openstack overcloud node provision 命令。
注意

如果没有使用预置备节点,则必须在节点定义文件中配置 NIC 映射。有关配置 net_config_data_lookup 属性的更多信息,请参阅 裸机节点置备属性

您可以为每个节点上的物理接口分配别名,以预先确定哪些物理 NIC 映射到特定别名,如 nic1nic2,您可以将 MAC 地址映射到指定的别名。您可以使用 MAC 地址或 DMI 关键字映射特定节点,也可以使用 DMI 关键字映射一组节点。以下示例配置三个节点,以及两个节点组,其别名指向物理接口。生成的配置由 os-net-config 应用。在每个节点上,您可以在 /etc/os-net-config/mapping.yaml 文件的 interface_mapping 部分中看到应用的配置。

示例 1:在 os-net-config-mappings.yaml中配置 NetConfigDataLookup 参数

NetConfigDataLookup:
  node1: 1
    nic1: "00:c8:7c:e6:f0:2e"
  node2:
    nic1: "00:18:7d:99:0c:b6"
  node3: 2
    dmiString: "system-uuid" 3
    id: 'A8C85861-1B16-4803-8689-AFC62984F8F6'
    nic1: em3
  # Dell PowerEdge
  nodegroup1: 4
    dmiString: "system-product-name"
    id: "PowerEdge R630"
    nic1: em3
    nic2: em1
    nic3: em2
  # Cisco UCS B200-M4"
  nodegroup2:
    dmiString: "system-product-name"
    id: "UCSB-B200-M4"
    nic1: enp7s0
    nic2: enp6s0

1
node1 映射到指定的 MAC 地址,并将 nic1 分配为该节点上的 MAC 地址的别名。
2
使用系统 UUID "A8C85861-1B16-4803-8689-AFC62984F8F6"将 node3 映射到节点,并将 nic1 分配为这个节点上的 em3 接口的别名。
3
dmiString 参数必须设置为有效的字符串关键字。有关有效字符串关键字的列表,请查看 DMIDECODE (8)手册页。
4
nodegroup1 中的所有节点映射到具有产品名称为 "PowerEdge R630" 的节点,并将 nic1nic2nic3 分配为该节点上命名接口的别名。
注意

通常,os-net-config 只注册已以 UP 状态连接的接口。但是,如果您使用自定义映射文件的硬编码接口,接口也会注册,即使它处于 DOWN 状态。

示例 2:在 overcloud-baremetal-deploy.yaml - 特定节点中配置 net_config_data_lookup 属性

- name: Controller
  count: 3
  defaults:
    network_config:
      net_config_data_lookup:
        node1:
          nic1: "00:c8:7c:e6:f0:2e"
        node2:
          nic1: "00:18:7d:99:0c:b6"
        node3:
          dmiString: "system-uuid"
          id: 'A8C85861-1B16-4803-8689-AFC62984F8F6'
          nic1: em3
        # Dell PowerEdge
        nodegroup1:
          dmiString: "system-product-name"
          id: "PowerEdge R630"
          nic1: em3
          nic2: em1
          nic3: em2
        # Cisco UCS B200-M4"
        nodegroup2:
          dmiString: "system-product-name"
          id: "UCSB-B200-M4"
          nic1: enp7s0
          nic2: enp6s0

示例 3:在 overcloud-baremetal-deploy.yaml 中配置 net_config_data_lookup 属性 - 角色的所有节点

- name: Controller
  count: 3
  defaults:
    network_config:
      template: templates/net_config_bridge.j2
      default_route_network:
      - external
  instances:
  - hostname: overcloud-controller-0
    network_config:
      <name/groupname>:
        nic1: 'XX:XX:XX:XX:XX:XX'
        nic2: 'YY:YY:YY:YY:YY:YY'
        nic3: 'ens1f0'

8.2.2. 可组合网络

如果要在不同网络上托管特定的网络流量,可以创建自定义可组合网络。director 提供了一个启用了网络隔离的默认网络拓扑。您可以在 /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml 中找到此配置。

overcloud 默认使用以下预定义网络段集合:

  • 内部 API
  • 存储
  • 存储管理
  • 租户
  • 外部

您可以使用可组合网络为各种服务添加网络。例如,如果您有一个专用于 NFS 流量的网络,您可以将其提供给多个角色。

director 支持在部署和更新阶段创建自定义网络。您可以将这些额外网络用于裸机节点、系统管理,或为不同的角色创建单独的网络。您还可以使用它们创建多组网络,以便在网络间路由流量的分割部署。

8.2.2.1. 添加可组合网络

使用可组合网络为各种服务添加网络。例如,如果您有一个专用于存储备份流量的网络,您可以将网络提供给多个角色。

流程

  1. 列出可用的网络配置文件示例:

    $ ll /usr/share/openstack-tripleo-heat-templates/network-data-samples/
    -rw-r--r--. 1 root root 1554 May 11 23:04 default-network-isolation-ipv6.yaml
    -rw-r--r--. 1 root root 1181 May 11 23:04 default-network-isolation.yaml
    -rw-r--r--. 1 root root 1126 May 11 23:04 ganesha-ipv6.yaml
    -rw-r--r--. 1 root root 1100 May 11 23:04 ganesha.yaml
    -rw-r--r--. 1 root root 3556 May 11 23:04 legacy-routed-networks-ipv6.yaml
    -rw-r--r--. 1 root root 2929 May 11 23:04 legacy-routed-networks.yaml
    -rw-r--r--. 1 root root  383 May 11 23:04 management-ipv6.yaml
    -rw-r--r--. 1 root root  290 May 11 23:04 management.yaml
    -rw-r--r--. 1 root root  136 May 11 23:04 no-networks.yaml
    -rw-r--r--. 1 root root 2725 May 11 23:04 routed-networks-ipv6.yaml
    -rw-r--r--. 1 root root 2033 May 11 23:04 routed-networks.yaml
    -rw-r--r--. 1 root root  943 May 11 23:04 vip-data-default-network-isolation.yaml
    -rw-r--r--. 1 root root  848 May 11 23:04 vip-data-fixed-ip.yaml
    -rw-r--r--. 1 root root 1050 May 11 23:04 vip-data-routed-networks.yaml
  2. 将您需要的示例网络配置文件从 /usr/share/openstack-tripleo-heat-templates/network-data-samples 复制到环境文件目录中:

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml /home/stack/templates/network_data.yaml
  3. 编辑 network_data.yaml 配置文件并为新网络添加一个部分:

    - name: StorageBackup
      vip: false
      name_lower: storage_backup
      subnets:
        storage_backup_subnet:
          ip_subnet: 172.16.6.0/24
          allocation_pools:
            - start: 172.16.6.4
            - end: 172.16.6.250
          gateway_ip: 172.16.6.1

    为您的环境配置任何其他网络属性。有关可用于配置网络属性的属性的更多信息,请参阅 网络定义文件配置选项

  4. 如果您要部署 Red Hat Ceph Storage 并使用 NFS,请确保包含一个隔离的 StorageNFS 网络。这些文件中存在以下示例:

    • /usr/share/openstack-tripleo-heat-templates/network-data-samples/ganesha.yaml
    • /usr/share/openstack-tripleo-heat-templates/network-data-samples/ganesha-ipv6.yaml

      自定义这些网络设置,包括 VLAN ID 和子网范围。如果不需要 IPv4 或 IPv6,您可以省略对应的子网:

      Example:

      - name: StorageNFS
        enabled: true
        vip: true
        name_lower: storage_nfs
        subnets:
          storage_nfs_subnet:
            vlan: 70
            ip_subnet: 172.17.0.0/20
            allocation_pools:
              - start: 172.17.0.4
              - end: 172.17.0.250
          storage_nfs_ipv6_subnet:
            ipv6_subnet: fd00:fd00:fd00:7000::/64
            ipv6_allocation_pools:
              - start: fd00:fd00:fd00:7000::4
              - end: fd00:fd00:fd00:7000::fffe
    • 此网络将由 overcloud 部署和网络服务(neutron)提供商网络共享,后者为消费者(如计算服务(nova)虚拟机)用于挂载共享的用户设置 post-overcloud 部署。
    • 将 sizable 范围保留在此示例中指定的分配池之外,以便在 overcloud 网络服务存储NFS 提供商网络的子网定义中使用 sizable 范围。
  5. 当您添加包含虚拟 IP 的额外可组合网络并希望将一些 API 服务映射到此网络时,请使用 CloudName{network.name} 定义来为 API 端点设置 DNS 名称:

    CloudName{{network.name}}

    Example:

    parameter_defaults:
      ...
      CloudNameOcProvisioning: baremetal-vip.example.com
  6. 将您需要的示例网络 VIP 定义模板从 /usr/share/openstack-tripleo-heat-templates/network-data-samples 复制到环境文件目录中。以下示例将 vip-data-default-network-isolation.yaml 复制到名为 vip_data.yaml 的本地环境文件:

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/vip-data-default-network-isolation.yaml  /home/stack/templates/vip_data.yaml
  7. 编辑 vip_data.yaml 配置文件。虚拟 IP 数据是虚拟 IP 地址定义列表,各自包含分配 IP 地址的网络的名称:

    - network: storage_mgmt
      dns_name: overcloud
    - network: internal_api
      dns_name: overcloud
    - network: storage
      dns_name: overcloud
    - network: external
      dns_name: overcloud
      ip_address: <vip_address>
    - network: ctlplane
      dns_name: overcloud
    - network: storage_nfs
      dns_name: overcloud
      ip_address: <vip_address>
    • <vip_address > 替换为所需的虚拟 IP 地址。

    有关您可以在 VIP 定义文件中配置网络 VIP 属性的属性的更多信息,请参阅 Network VIP 属性属性

  8. 复制示例网络配置模板。Jinja2 模板用于定义 NIC 配置模板。如果其中一个示例与您的要求匹配,浏览 /usr/share/ansible/roles/tripleo_network_config/templates/ 目录中提供的示例。如果示例与您的要求不匹配,请复制示例配置文件,并根据您的需要进行修改:

    $ cp /usr/share/ansible/roles/tripleo_network_config/templates/single_nic_vlans/single_nic_vlans.j2 /home/stack/templates/
  9. 编辑 single_nic_vlans.j2 配置文件:

    ---
    {% set mtu_list = [ctlplane_mtu] %}
    {% for network in role_networks %}
    {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
    {%- endfor %}
    {% set min_viable_mtu = mtu_list | max %}
    network_config:
    - type: ovs_bridge
      name: {{ neutron_physical_bridge_name }}
      mtu: {{ min_viable_mtu }}
      use_dhcp: false
      dns_servers: {{ ctlplane_dns_nameservers }}
      domain: {{ dns_search_domains }}
      addresses:
      - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
      routes: {{ ctlplane_host_routes }}
      members:
      - type: interface
        name: nic1
        mtu: {{ min_viable_mtu }}
        # force the MAC address of the bridge to this interface
        primary: true
    {% for network in role_networks %}
      - type: vlan
        mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
        vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
        addresses:
        - ip_netmask:
            {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
        routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
    {% endfor %}
  10. overcloud-baremetal-deploy.yaml 配置文件中设置 network_config 模板:

    - name: CephStorage
      count: 3
      defaults:
        networks:
        - network: storage
        - network: storage_mgmt
        - network: storage_backup
        network_config:
          template: /home/stack/templates/single_nic_vlans.j2

    如果您要为将 CephFS-NFS 后端与共享文件系统服务(manila)一起使用存储NFS 网络,请编辑 ControllerControllerStorageNfs 部分,而不是 network_config 部分,因为 StorageNFS 网络及其 VIP 连接到 Controller 节点:

    - name: ControllerStorageNfs
      count: 3
      hostname_format: controller-%index%
      instances:
      - hostname: controller-0
        name: controller-0
      - hostname: controller-1
        name: controller-1
      - hostname: controller-2
        name: controller-2
      defaults:
        profile: control
        network_config:
          template: /home/stack/templates/single_nic_vlans.j2
        networks:
        - network: ctlplane
          vif: true
        - network: external
        - network: internal_api
        - network: storage
        - network: storage_mgmt
        - network: tenant
        - network: storage_nfs
  11. 调配 overcloud 网络。此操作会生成一个输出文件,它将在部署 overcloud 时使用环境文件:

    (undercloud)$ openstack overcloud network provision \
    --output <deployment_file> /home/stack/templates/<networks_definition_file>.yaml
    • <networks_definition_file > 替换为网络定义文件的名称,如 network_data.yaml 或 StorageNFS 网络文件的名称,如 network_data_ganesha.yaml
    • <deployment_file > 替换为用于部署命令生成的 heat 环境文件的名称,如 /home/stack/templates/overcloud-networks-deployed.yaml
  12. 置备网络 VIP 并生成 vip-deployed-environment.yaml 文件。在部署 overcloud 时,您可以使用此文件:

    (overcloud)$ openstack overcloud network vip provision  --stack <stack> --output <deployment_file> /home/stack/templates/vip_data.yaml
    • 将 & lt;stack > 替换为置备网络 VIP 的堆栈名称。如果未指定,则默认为 overcloud。
    • <deployment_file > 替换为用于部署命令生成的 heat 环境文件的名称,如 /home/stack/templates/overcloud-vip-deployed.yaml

8.2.2.2. 在角色中包含可组合网络

您可以将可组合网络分配给您的环境中定义的 overcloud 角色。例如,您可以包括带有 Ceph Storage 节点的自定义 StorageBackup 网络,或者您可以将 CephFS-NFS 网络与共享文件系统服务(manila)一起使用。如果您使用 director 中默认包含的 ControllerStorageNfs 角色,则已为您添加一个 StorageNFS 网络。

流程

  1. 如果您还没有自定义 roles_data.yaml 文件,请将默认值复制到您的主目录中:

    $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data.yaml
  2. 编辑自定义 roles_data.yaml 文件。
  3. 在网络列表中包含您要添加 网络 的角色的网络名称。

    • 在本例中,您要将 StorageBackup 网络添加到 Ceph Storage 角色中:

      - name: CephStorage
        description: |
          Ceph OSD Storage node role
        networks:
          Storage
            subnet: storage_subnet
          StorageMgmt
            subnet: storage_mgmt_subnet
          StorageBackup
            subnet: storage_backup_subnet
    • 在本例中,您要将 StorageNFS 网络添加到 Controller 节点:

      - name: Controller
        description: |
          Controller role that has all the controller services loaded, handles
          Database, Messaging and Network functions, and additionally runs a ganesha
          service as a CephFS to NFS gateway.  The gateway serves NFS exports via a
          VIP on a new isolated StorageNFS network.
        # ganesha service should always be deployed in HA configuration.
        CountDefault: 3
        tags:
          - primary
          - controller
        networks:
          External:
            subnet: external_subnet
          InternalApi:
            subnet: internal_api_subnet
          Storage:
            subnet: storage_subnet
          StorageMgmt:
            subnet: storage_mgmt_subnet
          Tenant:
            subnet: tenant_subnet
          StorageNFS:
            subnet: storage_nfs_subnet
  4. 将自定义网络添加到对应的角色后,保存文件。

运行 openstack overcloud deploy 命令时,使用 -r 选项包含自定义 roles_data.yaml 文件。如果没有 -r 选项,部署命令将使用一组默认的角色,以及它们对应的网络。

8.2.2.3. 将 OpenStack 服务分配给可组合网络

每个 OpenStack 服务都分配给资源 registry 中的默认网络类型。这些服务绑定到网络类型分配的网络中的 IP 地址。虽然 OpenStack 服务在这些网络中划分,但实际的物理网络数量可能会因网络环境文件中定义的不同。您可以通过在环境文件中定义新网络映射将 OpenStack 服务重新分配给不同的网络类型,如 /home/stack/templates/service-reassignments.yamlServiceNetMap 参数决定您要用于每个服务的网络类型。

例如,您可以通过修改突出显示的部分,将存储管理网络服务重新分配给 Storage Backup Network:

parameter_defaults:
  ServiceNetMap:
    SwiftStorageNetwork: storage_backup
    CephClusterNetwork: storage_backup

将这些参数改为 storage_backup 将这些服务放在 Storage Backup 网络中,而不是 Storage Management 网络。这意味着,您只需要为 Storage Backup 网络而不是 Storage Management 网络定义一组 parameter_defaults

director 将自定义 ServiceNetMap 参数定义合并到预定义的默认值列表中,它从 ServiceNetMapDefaults 获取并覆盖默认值。director 将完整列表(包括自定义)返回到 ServiceNetMap,后者用于为各种服务配置网络分配。例如,GaneshaNetwork 是 CephFS-NFS 的 NFS 网关的默认服务网络。此网络默认为 storage_nfs,同时回退到外部或 ctlplane 网络。如果您使用不同的网络而不是默认的隔离的 StorageNFS 网络,则必须使用 ServiceNetMap 参数定义更新默认网络。

Example:

parameter_defaults:
  ServiceNetMap:
    GaneshaNetwork: <manila_nfs_network>
  • <manila_nfs_network > 替换为自定义网络的名称。

服务映射适用于使用 Pacemaker 的节点的 network_data.yaml 文件中的 vip: true 网络。overcloud 负载均衡器将来自 VIP 的流量重定向到特定的服务端点。

注意

您可以在 /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml 文件中的 ServiceNetMapDefaults 参数中找到默认服务的完整列表。

8.2.2.4. 启用自定义可组合网络

使用其中一个默认 NIC 模板启用自定义可组合网络。在本例中,将 Single NIC 与 VLAN 模板一起使用(custom_single_nic_vlans)。

流程

  1. 查找 stackrc undercloud 凭证文件:

    $ source ~/stackrc
  2. 置备 overcloud 网络:

    $ openstack overcloud network provision \
      --output overcloud-networks-deployed.yaml \
      custom_network_data.yaml
  3. 置备网络 VIP:

    $ openstack overcloud network vip provision \
        --stack overcloud \
        --output overcloud-networks-vips-deployed.yaml \
         custom_vip_data.yaml
  4. 置备 overcloud 节点:

    $ openstack overcloud node provision \
        --stack overcloud \
        --output overcloud-baremetal-deployed.yaml \
        overcloud-baremetal-deploy.yaml
  5. 构建 openstack overcloud deploy 命令,按所需顺序指定配置文件和模板,例如:

    $ openstack overcloud deploy --templates \
      --networks-file network_data_v2.yaml \
      -e overcloud-networks-deployed.yaml \
      -e overcloud-networks-vips-deployed.yaml \
      -e overcloud-baremetal-deployed.yaml
      -e custom-net-single-nic-with-vlans.yaml

本例命令可在 overcloud 中的节点间部署可组合网络,包括您的额外网络。

8.2.2.5. 重命名默认网络

您可以使用 network_data.yaml 文件修改默认网络的用户可见名称:

  • InternalApi
  • 外部
  • 存储
  • StorageMgmt
  • 租户

要更改这些名称,请不要修改 name 字段。相反,将 name_lower 字段更改为网络的新名称,并使用新名称更新 ServiceNetMap。

流程

  1. network_data.yaml 文件中,为每个您要重命名的网络在 name_lower 参数中输入新名称:

    - name: InternalApi
      name_lower: MyCustomInternalApi
  2. service_net_map_replace 参数中包含 name_lower 参数的默认值:

    - name: InternalApi
      name_lower: MyCustomInternalApi
      service_net_map_replace: internal_api

8.2.3. 其他 overcloud 网络配置

本章介绍了 第 8.2.1 节 “定义自定义网络接口模板” 中概述的概念和程序,并提供一些额外的信息来帮助配置 overcloud 网络的部分。

8.2.3.1. 配置路由和默认路由

您可以通过以下两种方式之一设置主机的默认路由。如果接口使用 DHCP,并且 DHCP 服务器提供网关地址,则系统将使用该网关的默认路由。否则,您可以在具有静态 IP 的接口上设置默认路由。

虽然 Linux 内核支持多个默认网关,但它仅使用具有最低指标的网关。如果有多个 DHCP 接口,这可能会导致无法预计的默认网关。在这种情况下,建议为使用默认路由的接口以外的接口设置 defroute: false

例如,您可能希望 DHCP 接口(nic3)作为默认路由。使用以下 YAML 代码片段,禁用另一 DHCP 接口(nic2)上的默认路由:

# No default route on this DHCP interface
- type: interface
  name: nic2
  use_dhcp: true
  defroute: false
# Instead use this DHCP interface as the default route
- type: interface
  name: nic3
  use_dhcp: true
注意

defroute 参数仅适用于通过 DHCP 获取的路由。

要在具有静态 IP 的接口上设置静态路由,请指定到子网的路由。例如,您可以通过 Internal API 网络上的 172.17.0.1 上的网关设置到 10.1.2.0/24 子网的路由:

    - type: vlan
      device: bond1
      vlan_id: 9
      addresses:
      - ip_netmask: 172.17.0.100/16
      routes:
      - ip_netmask: 10.1.2.0/24
        next_hop: 172.17.0.1

8.2.3.2. 配置基于策略的路由

要从 Controller 节点上的不同网络配置无限访问,请配置基于策略的路由。基于策略的路由使用路由表,在具有多个接口的主机上,您可以根据源地址通过特定接口发送流量。您可以将来自不同源的数据包路由到不同的网络,即使目的地是相同的。

例如,您可以将路由配置为根据数据包的源地址将流量发送到内部 API 网络,即使默认路由是 External 网络。您还可以为每个接口定义特定的路由规则。

Red Hat OpenStack Platform 使用 os-net-config 工具为您的 overcloud 节点配置网络属性。os-net-config 工具管理 Controller 节点上的以下网络路由:

  • /etc/iproute2/rt_tables 文件中的路由表
  • /etc/sysconfig/network-scripts/rule-{ifname} 文件中的 IPv4 规则
  • /etc/sysconfig/network-scripts/rule6-{ifname} 文件中的 IPv6 规则
  • /etc/sysconfig/network-scripts/route-{ifname}中的路由表特定路由

先决条件

流程

  1. /home/stack/templates/custom-nics 目录创建自定义 NIC 模板中的 接口 条目,为接口定义路由,并定义与部署相关的规则:

      network_config:
      - type: interface
        name: em1
        use_dhcp: false
        addresses:
          - ip_netmask: {{ external_ip }}/{{ external_cidr}}
        routes:
          - default: true
            next_hop: {{ external_gateway_ip }}
          - ip_netmask: {{ external_ip }}/{{ external_cidr}}
            next_hop: {{ external_gateway_ip }}
            table: 2
            route_options: metric 100
        rules:
          - rule: "iif em1 table 200"
            comment: "Route incoming traffic to em1 with table 200"
          - rule: "from 192.0.2.0/24 table 200"
            comment: "Route all traffic from 192.0.2.0/24 with table 200"
          - rule: "add blackhole from 172.19.40.0/24 table 200"
          - rule: "add unreachable iif em1 from 192.168.1.0/24"
  2. 在部署命令中包含您的自定义 NIC 配置和网络环境文件,以及与部署相关的任何其他环境文件:

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/<custom-nic-template>
    -e <OTHER_ENVIRONMENT_FILES>

验证

  • 在 Controller 节点上输入以下命令来验证路由配置是否正常工作:

    $ cat /etc/iproute2/rt_tables
    $ ip route
    $ ip rule

8.2.3.3. 配置巨型帧

最大传输单元(MTU)设置决定了通过单个以太网帧传输的最大数据量。使用较大的值会降低开销,因为每个帧以标头的形式添加数据。默认值为 1500,使用较高的值需要配置交换机端口来支持巨型帧。大多数交换机支持至少 9000 的 MTU,但很多交换机默认配置为 1500。

VLAN 的 MTU 不能超过物理接口的 MTU。确保在绑定或接口中包含 MTU 值。

存储、存储管理、内部 API 和租户网络都可以从巨型帧中受益。

您可以在 jinja2 模板或 network_data.yaml 文件中更改 mtu 的值。如果您在 network_data.yaml 文件中设置了值,它将在部署过程中呈现。

警告

路由器通常不能跨第 3 层边界转发巨型帧。为避免连接问题,请不要更改 Provisioning 接口、外部接口和任何浮动 IP 接口的默认 MTU。

---
{% set mtu_list = [ctlplane_mtu] %}
{% for network in role_networks %}
{{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
{%- endfor %}
{% set min_viable_mtu = mtu_list | max %}
network_config:
- type: ovs_bridge
  name: bridge_name
  mtu: {{ min_viable_mtu }}
  use_dhcp: false
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  addresses:
  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
  routes: {{ [ctlplane_host_routes] | flatten | unique }}
  members:
  - type: interface
    name: nic1
    mtu: {{ min_viable_mtu }}
    primary: true
  - type: vlan
    mtu: 9000  1
    vlan_id: {{ storage_vlan_id }}
    addresses:
    - ip_netmask: {{ storage_ip }}/{{ storage_cidr }}
    routes: {{ [storage_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ storage_mgmt_mtu }} 2
    vlan_id: {{ storage_mgmt_vlan_id }}
    addresses:
    - ip_netmask: {{ storage_mgmt_ip }}/{{ storage_mgmt_cidr }}
    routes: {{ [storage_mgmt_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ internal_api_mtu }}
    vlan_id: {{ internal_api_vlan_id }}
    addresses:
    - ip_netmask: {{ internal_api_ip }}/{{ internal_api_cidr }}
    routes: {{ [internal_api_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ tenant_mtu }}
    vlan_id: {{ tenant_vlan_id }}
    addresses:
    - ip_netmask: {{ tenant_ip }}/{{ tenant_cidr }}
    routes: {{ [tenant_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ external_mtu }}
    vlan_id: {{ external_vlan_id }}
    addresses:
    - ip_netmask: {{ external_ip }}/{{ external_cidr }}
    routes: {{ [external_host_routes, [{'default': True, 'next_hop': external_gateway_ip}]] | flatten | unique }}
1
jinja2 模板中直接更新 MTU 值。
2
部署期间,MTU 值从 network_data.yaml 文件获取。

8.2.3.4. 配置 ML2/OVN 北向路径 MTU 发现,以实现巨型帧碎片

如果内部网络上的虚拟机向外部网络发送巨型帧,并且内部网络的最大传输单元(MTU)超过外部网络的 MTU,则北向帧可以轻松地超过外部网络的容量。

ML2/OVS 会自动处理通过数据包问题进行这一处理,ML2/OVN 会自动为 TCP 数据包处理它。

但是,为了确保在使用 ML2/OVN 机制驱动程序的部署中正确处理 oversized northbound UDP 数据包,您需要执行额外的配置步骤。

这些步骤将 ML2/OVN 路由器配置为将 ICMP "fragmentation required" 数据包返回到发送虚拟机,其中发送应用可以将有效负载分成较小的数据包。

注意

在 east/west 流量中,RHOSP ML2/OVN 部署不支持在 east/west 路径上大于最小 MTU 的数据包碎片。例如:

  • VM1 位于 Network1 上,MTU 为 1300。
  • VM2 位于 Network2 上,MTU 为 1200。
  • VM1 和 VM2 之间的指示的 ping 大小为 1171 或小于成功。大小大于 1171 的 ping 会导致数据包丢失的 100%。

    由于没有客户的具体要求,红帽还没有计划提供对它的支持。

流程

  1. 在 ml2_conf.ini 的 [ovn] 部分中设置以下值:

    ovn_emit_need_to_frag = True

8.2.3.5. 在中继接口上配置原生 VLAN

如果中继接口或绑定在原生 VLAN 上有一个网络,IP 地址会直接分配给网桥,且没有 VLAN 接口。

以下示例配置了一个绑定接口,其中 External 网络位于原生 VLAN 中:

network_config:
- type: ovs_bridge
  name: br-ex
  addresses:
  - ip_netmask: {{ external_ip }}/{{ external_cidr }}
  routes: {{ external_host_routes }}
  members:
  - type: ovs_bond
    name: bond1
    ovs_options: {{ bond_interface_ovs_options }}
    members:
    - type: interface
      name: nic3
      primary: true
    - type: interface
      name: nic4
注意

当您将 address 或 route 语句移到网桥时,从网桥中删除对应的 VLAN 接口。对所有适用的角色进行更改。External 网络仅在控制器上,因此只有控制器模板需要更改。Storage 网络附加到所有角色,因此如果 Storage 网络位于默认的 VLAN 中,则所有角色都需要修改。

8.2.3.6. 增加 netfilter 跟踪的最大连接数

Red Hat OpenStack Platform (RHOSP)网络服务(neutron)使用 netfilter 连接跟踪来构建有状态防火墙,并在虚拟网络上提供网络地址转换(NAT)。在某些情况下,可能会导致内核空间达到最大连接限制,并产生错误,如 nf_conntrack: table full, discard packet。您可以增加连接跟踪(conntrack)的限制,并避免这些类型的错误。您可以在 RHOSP 部署中增加一个或多个角色的 conntrack 限制,或跨所有节点增加 conntrack 限制。

先决条件

  • 成功安装 RHOSP undercloud。

流程

  1. stack 用户身份登录 undercloud 主机。
  2. 提供 undercloud 凭证文件:

    $ source ~/stackrc
  3. 创建自定义 YAML 环境文件。

    示例

    $ vi /home/stack/templates/custom-environment.yaml

  4. 您的环境文件必须包含关键字 parameter_defaultsExtraSysctlSettings。为 netfilter 可在变量 net.nf_conntrack_max 中跟踪的最大连接数输入新值。

    示例

    在本例中,您可以在 RHOSP 部署中的所有主机中设置 conntrack 限制:

    parameter_defaults:
      ExtraSysctlSettings:
        net.nf_conntrack_max:
          value: 500000

    使用 & lt;role>Parameter 参数为特定角色设置 conntrack 限制:

    parameter_defaults:
      <role>Parameters:
        ExtraSysctlSettings:
          net.nf_conntrack_max:
            value: <simultaneous_connections>
    • <role > 替换为角色的名称。

      例如,使用 ControllerParameters 为 Controller 角色设置 conntrack 限制,或 ComputeParameters 为 Compute 角色设置 conntrack 限制。

    • 将 < simultaneous_connections > 替换为您要允许的同时连接数量。

      示例

      在本例中,您只能在 RHOSP 部署中为 Controller 角色设置 conntrack 限制:

      parameter_defaults:
        ControllerParameters:
          ExtraSysctlSettings:
            net.nf_conntrack_max:
              value: 500000
      注意

      net.nf_conntrack_max 的默认值为 500000 连接。最大值为: 4294967295

  5. 运行部署命令,并包含核心 heat 模板、环境文件以及新的自定义环境文件。

    重要

    环境文件的顺序非常重要,因为后续环境文件中定义的参数和资源更为优先。

    示例

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/custom-environment.yaml

8.2.4. 网络接口绑定

您可以在自定义网络配置中使用各种绑定选项。

8.2.4.1. overcloud 节点的网络接口绑定

您可以将多个物理 NIC 捆绑在一起组成一个逻辑频道,称为绑定。您可以配置绑定,为高可用性系统提供冗余性或增加吞吐量。

Red Hat OpenStack Platform 支持 Open vSwitch (OVS)内核绑定、OVS-DPDK 绑定和 Linux 内核绑定。

表 8.7. 支持的接口绑定类型
绑定类型类型值允许的网桥类型允许的成员

OVS 内核绑定

ovs_bond

ovs_bridge

interface

OVS-DPDK 绑定

ovs_dpdk_bond

ovs_user_bridge

ovs_dpdk_port

Linux 内核绑定

linux_bond

ovs_bridgelinux_bridge

interface

重要

不要在同一节点上组合 ovs_bridgeovs_user_bridge

8.2.4.2. 创建 Open vSwitch (OVS)绑定

您可以在网络接口模板中创建 OVS 绑定。例如,您可以创建一个绑定作为 OVS 用户空间网桥的一部分:

- type: ovs_user_bridge
  name: br-dpdk0
  members:
  - type: ovs_dpdk_bond
    name: dpdkbond0
    rx_queue: {{ num_dpdk_interface_rx_queues }}
    members:
    - type: ovs_dpdk_port
      name: dpdk0
      members:
      - type: interface
        name: nic4
    - type: ovs_dpdk_port
      name: dpdk1
      members:
      - type: interface
        name: nic5

在本例中,您可以从两个 DPDK 端口创建绑定。

ovs_options 参数包含绑定选项。您可以使用 BondInterfaceOvsOptions 参数在网络环境文件中配置绑定选项:

parameter_defaults:
  BondInterfaceOvsOptions: "bond_mode=active_backup"

8.2.4.3. Open vSwitch (OVS)绑定选项

您可以使用 NIC 模板文件中的 ovs_options heat 参数设置各种 Open vSwitch (OVS)绑定选项。active-backup、balance-tlb、balance-alb 和 balance-slb 模式不需要交换机的任何具体配置。

bond_mode=balance-slb
源负载平衡(slb)根据源 MAC 地址和输出 VLAN 平衡流,并在流量模式更改时定期重新平衡。当您使用 balance-slb 绑定选项配置绑定时,远程交换机不需要配置。Networking 服务(neutron)将每个源 MAC 和 VLAN 对分配给链接,并通过该链接传输来自该 MAC 和 VLAN 的所有数据包。使用基于源 MAC 地址和 VLAN 号的简单哈希算法,随着流量模式的变化,定期重新平衡。balance-slb 模式与 Linux 绑定驱动程序使用的模式 2 绑定类似,但与模式 2 不同,但 balance-slb 不需要任何 swtich 的具体配置。您可以使用 balance-slb 模式来提供负载均衡,即使交换机没有配置为使用 LACP。
bond_mode=active-backup
当您使用 active-backup 绑定模式配置绑定时,网络服务会将一个 NIC 保留为待机。当活跃连接失败时,待机 NIC 会恢复网络操作。物理交换机仅显示一个 MAC 地址。这个模式不需要切换配置,当链接连接到单独的交换机时,可以正常工作。这个模式不提供负载均衡。
lacp=[active | passive | off]
控制链路聚合控制协议(LACP)行为。只有某些交换机支持 LACP。如果您的交换机不支持 LACP,请使用 bond_mode=balance-slbbond_mode=active-backup
other-config:lacp-fallback-ab=true
如果 LACP 失败,将 active-backup 设置为绑定模式。
other_config:lacp-time=[fast | slow]
将 LACP heartbeat 设置为 1 秒 (fast) 或 30 秒 (slow)。默认设置会较慢。
other_config:bond-detect-mode=[miimon | carrier]
将链路检测设置为使用 miimon heartbeats (miimon)或监控载体(carrier)。默认值为 carrier。
other_config:bond-miimon-interval=100
如果使用 miimon,请设置心跳间隔(毫秒)。
bond_updelay=1000
设置链接必须激活的时间间隔(毫秒),以防止流动。
other_config:bond-rebalance-interval=10000
设置在绑定成员之间流重新平衡的时间间隔(毫秒)。将此值设置为 0,以禁用绑定成员之间的流重新平衡。

8.2.4.5. 创建 Linux 绑定

您可以在网络接口模板中创建 Linux 绑定。例如,您可以创建一个绑定两个接口的 Linux 绑定:

- type: linux_bond
  name: bond_api
  mtu: {{ min_viable_mtu_ctlplane }}
  use_dhcp: false
  bonding_options: {{ bond_interface_ovs_options }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  members:
  - type: interface
    name: nic2
    mtu: {{ min_viable_mtu_ctlplane }}
    primary: true
  - type: interface
    name: nic3
    mtu: {{ min_viable_mtu_ctlplane }}

bonding_options 参数为 Linux 绑定设置特定的绑定选项。

模式
设置绑定模式,示例中是 802.3ad 或 LACP 模式。有关 Linux 绑定模式的更多信息,请参阅 Red Hat Enterprise Linux 9 配置和管理网络指南中的 "上游交换配置取决于绑定模式 "。
lacp_rate
定义是否每 1 秒发送 LACP 数据包,或者每 30 秒发送一次。
updelay
定义接口在用于流量前必须处于活跃状态的最短时间。这个最小配置有助于缓解端口流中断。
miimon
用于使用驱动程序的 MIIMON 功能监控端口状态的时间间隔(毫秒)。

使用以下附加示例来配置您自己的 Linux 绑定:

  • 使用一个 VLAN 将 Linux 绑定设置为 active-backup 模式:

    ....
    
    - type: linux_bond
      name: bond_api
      mtu: {{ min_viable_mtu_ctlplane }}
      use_dhcp: false
      bonding_options: "mode=active-backup"
      dns_servers: {{ ctlplane_dns_nameservers }}
      domain: {{ dns_search_domains }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu_ctlplane }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu_ctlplane }}
      - type: vlan
        mtu: {{ internal_api_mtu }}
        vlan_id: {{ internal_api_vlan_id }}
        addresses:
        - ip_netmask:
            {{ internal_api_ip }}/{{ internal_api_cidr }}
          routes:
            {{ internal_api_host_routes }}
  • OVS 网桥上的 Linux 绑定。绑定设置为 802.3ad LACP 模式,它带有一个 VLAN:

    - type: linux_bond
      name: bond_tenant
      mtu: {{ min_viable_mtu_ctlplane }}
      bonding_options: "mode=802.3ad updelay=1000 miimon=100"
      use_dhcp: false
      dns_servers: {{ ctlplane_dns_nameserver }}
      domain: {{ dns_search_domains }}
      members:
        - type: interface
          name: p1p1
          mtu: {{ min_viable_mtu_ctlplane }}
        - type: interface
          name: p1p2
          mtu: {{ min_viable_mtu_ctlplane }}
        - type: vlan
          mtu: {{ tenant_mtu }}
          vlan_id: {{ tenant_vlan_id }}
          addresses:
            - ip_netmask:
               {{ tenant_ip }}/{{ tenant_cidr }}
          routes:
            {{ tenant_host_routes }}
    重要

    您必须设置 min_viable_mtu_ctlplane,然后才能使用它。将 /usr/share/ansible/roles/tripleo_network_config/templates/2_linux_bonds_vlans.j2 复制到您的 templates 目录中,并根据您的需要进行修改。如需更多信息,请参阅 可组合网络,并参考与网络配置模板相关的步骤。

8.2.5. 更新网络配置文件的格式

Red Hat OpenStack Platform (RHOSP) 17.0 中更改了网络配置 yaml 文件格式。网络配置文件 network_data.yaml 的结构已更改,NIC 模板文件格式已从 yaml 文件格式改为 Jinja2 ansible 格式 j2

您可以使用以下转换工具将当前部署中的现有网络配置文件转换为 RHOSP 17+ 格式:

  • convert_v1_net_data.py
  • convert_heat_nic_config_to_ansible_j2.py

您还可以手动转换现有的 NIC 模板文件。

您需要转换的文件包括:

  • network_data.yaml
  • 控制器 NIC 模板
  • 计算 NIC 模板
  • 任何其它自定义网络文件

8.2.5.1. 更新网络配置文件的格式

Red Hat OpenStack Platform (RHOSP) 17.0 中更改了网络配置 yaml 文件的格式。您可以使用 convert_v1_net_data.py 转换工具,将当前部署中的现有网络配置文件转换为 RHOSP 17+ 格式。

流程

  1. 下载转换工具:

    • /usr/share/openstack-tripleo-heat-templates/tools/convert_v1_net_data.py
  2. 将 RHOSP 16+ 网络配置文件转换为 RHOSP 17+ 格式:

    $ python3 convert_v1_net_data.py <network_config>.yaml
    • 将 < network_config > 替换为您要转换的现有配置文件的名称,如 network_data.yaml

8.2.5.2. 自动将 NIC 模板转换为 Jinja2 Ansible 格式

在 Red Hat OpenStack Platform (RHOSP) 17.0 中,NIC 模板文件格式已从 yaml 文件格式改为 Jinja2 Ansible 格式 j2

您可以使用 convert_heat_nic_config_to_ansible_j2.py 转换工具,将当前部署中的现有 NIC 模板文件转换为 Jinja2 格式。

您还可以手动转换现有的 NIC 模板文件。如需更多信息,请参阅 手动将 NIC 模板转换为 Jinja2 Ansible 格式

您需要转换的文件包括:

  • 控制器 NIC 模板
  • 计算 NIC 模板
  • 任何其它自定义网络文件

流程

  1. stack 用户的身份登录 undercloud。
  2. Source stackrc 文件:

    [stack@director ~]$ source ~/stackrc
  3. 将转换工具复制到 undercloud 上的当前目录:

    $ cp /usr/share/openstack-tripleo-heat-templates/tools/convert_heat_nic_config_to_ansible_j2.py .
  4. 将计算和控制器 NIC 模板文件以及任何其他自定义网络文件转换为 Jinja2 Ansible 格式:

    $ python3 convert_heat_nic_config_to_ansible_j2.py \
     [--stack <overcloud> | --standalone] --networks_file <network_config.yaml> \
     <network_template>.yaml
    • <overcloud> 替换为 overcloud 堆栈的名称或 UUID。如果未指定 --stack,堆栈默认为 overcloud

      注意

      您只能在 RHOSP 16 部署中使用 --stack 选项,因为它需要在 undercloud 节点上运行编排服务(heat)。从 RHOSP 17 开始,RHOSP 部署使用临时 heat,它会在容器中运行编排服务。如果编排服务不可用,或者没有堆栈,则使用 --standalone 选项而不是 --stack

    • <network_config.yaml > 替换为描述网络部署的配置文件的名称,如 network_data.yaml
    • 将 < network_template > 替换为您要转换的网络配置文件的名称。

    重复此命令,直到您转换了所有自定义网络配置文件。convert_heat_nic_config_to_ansible_j2.py 脚本为您传递给它的每个 yaml 文件生成一个 .j2 文件,以进行转换。

  5. 检查每个生成的 .j2 文件,以确保配置正确并完成您的环境,并手动处理工具生成的注释,以突出显示无法转换配置的位置。有关手动将 NIC 配置转换为 Jinja2 格式的更多信息,请参阅 Heat 参数到 Ansible 变量映射
  6. 配置 network-environment.yaml 文件中的 *NetworkConfigTemplate 参数,使其指向生成的 .j2 文件:

    parameter_defaults:
      ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2'
      ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
  7. 从您的 network-environment.yaml 文件中删除旧网络配置文件的 resource_registry 映射:

    resource_registry:
      OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
      OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml

8.2.5.3. 手动将 NIC 模板转换为 Jinja2 Ansible 格式

在 Red Hat OpenStack Platform (RHOSP) 17.0 中,NIC 模板文件格式已从 yaml 文件格式改为 Jinja2 Ansible 格式 j2

您可以手动转换现有的 NIC 模板文件。

您还可以使用 convert_heat_nic_config_to_ansible_j2.py 转换工具,将当前部署中的现有 NIC 模板文件转换为 Jinja2 格式。如需更多信息,请参阅自动将 NIC 模板转换为 Jinja2 ansible 格式

您需要转换的文件包括:

  • 控制器 NIC 模板
  • 计算 NIC 模板
  • 任何其它自定义网络文件

流程

  1. 创建 Jinja2 模板。您可以通过从 undercloud 节点上的 /usr/share/ansible/roles/tripleo_network_config/templates/ 目录中复制示例模板来创建新模板。
  2. 将 heat 内部函数替换为 Jinja2 过滤器。例如,使用以下过滤器来计算 min_viable_mtu

    {% set mtu_list = [ctlplane_mtu] %}
    {% for network in role_networks %}
    {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
    {%- endfor %}
    {% set min_viable_mtu = mtu_list | max %}
  3. 使用 Ansible 变量为您的部署配置网络属性。您可以手动配置每个网络,或通过迭代 role_networks 来配置每个网络:

    • 要手动配置每个网络,请将每个 get_param 函数替换为对应的 Ansible 变量。例如,如果您当前的部署使用 get_param: InternalApiNetworkVlanID 配置 vlan_id,然后将以下配置添加到您的模板中:

      vlan_id: {{ internal_api_vlan_id }}
      表 8.9. 从 heat 参数映射到 Ansible vars的网络属性示例
      yaml 文件格式Jinja2 ansible 格式,j2
      - type: vlan
        device: nic2
        vlan_id:
          get_param: InternalApiNetworkVlanID
        addresses:
        - ip_netmask:
            get_param: InternalApiIpSubnet
      - type: vlan
        device: nic2
        vlan_id: {{ internal_api_vlan_id }}
        addresses:
        - ip_netmask: {{ internal_api_ip }}/{{ internal_api_cidr }}
    • 要编程地配置每个网络,请将 Jinja2 for-loop 结构添加到您的模板,该模板使用 role_networks 通过其角色名称检索可用的网络。

      示例

      {% for network in role_networks %}
        - type: vlan
          mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
          vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
          addresses:
          - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
          routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
      {%- endfor %}

    有关 heat 参数与 Ansible 变量等效的映射的完整列表,请参阅 Heat 参数到 Ansible 变量映射

  4. 配置 network-environment.yaml 文件中的 *NetworkConfigTemplate 参数,使其指向生成的 .j2 文件:

    parameter_defaults:
      ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2'
      ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
  5. 从您的 network-environment.yaml 文件中删除旧网络配置文件的 resource_registry 映射:

    resource_registry:
      OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
      OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml

8.2.5.4. Heat 参数到 Ansible 变量映射

NIC 模板文件格式已从 yaml 文件格式改为 Jinja2 ansible 格式 j2,在 Red Hat OpenStack Platform (RHOSP) 17.x 中。

要手动将现有 NIC 模板文件转换为 Jinja2 ansible 格式,您可以将 heat 参数映射到 Ansible 变量,以配置部署中预置备节点的网络属性。如果您运行 openstack overcloud node provision 而无需指定 --network-config 可选参数,您还可以将 heat 参数映射到 Ansible 变量。

例如,如果您当前的部署使用 get_param: InternalApiNetworkVlanID 配置 vlan_id,则将其替换为新 Jinja2 模板中的以下配置:

vlan_id: {{ internal_api_vlan_id }}
注意

如果您使用 --network-config 可选参数运行 openstack overcloud node provision 来置备节点,则必须使用 overcloud-baremetal-deploy.yaml 中的参数为您的部署配置网络属性。如需更多信息,请参阅 Heat 参数用于置备定义文件映射

下表列出从 heat vars 到等效的 Ansible 变量的可用映射

表 8.10. 从 heat 参数映射到 Ansible vars
Heat 参数Ansible 变量

BondInterfaceOvsOptions

{{ bond_interface_ovs_options }}

ControlPlaneIp

{{ ctlplane_ip }}

ControlPlaneDefaultRoute

{{ ctlplane_gateway_ip }}

ControlPlaneMtu

{{ ctlplane_mtu }}

ControlPlaneStaticRoutes

{{ ctlplane_host_routes }}

ControlPlaneSubnetCidr

{{ ctlplane_subnet_cidr }}

DnsSearchDomains

{{ dns_search_domains }}

DnsServers

{{ ctlplane_dns_nameservers }}

注意

此 Ansible 变量填充在 undercloud.conf 中为 DEFAULT/undercloud_nameservers%SUBNET_SECTION%/dns_nameservers 配置的 IP 地址。%SUBNET_SECTION%/dns_nameservers 的配置会覆盖 DEFAULT/undercloud_nameservers 的配置,以便您可以将不同的 DNS 服务器用于 undercloud 和 overcloud,以及不同置备子网中的节点的不同 DNS 服务器。

NumDpdkInterfaceRxQueues

{{ num_dpdk_interface_rx_queues }}

配置没有在表中列出的 heat 参数

要配置没有在表中列出的 heat 参数,您必须将参数配置为 {{role.name}}ExtraGroupVars。将参数配置为 {{role.name}}ExtraGroupVars 参数后,您可以在新模板中使用该参数。例如,要配置 StorageSupernet 参数,请在网络配置文件中添加以下配置:

parameter_defaults:
  ControllerExtraGroupVars:
    storage_supernet: 172.16.0.0/16

然后,您可以将 {{ storage_supernet }} 添加到 Jinja2 模板。

警告

如果将 --network-config 选项与节点置备一起使用,则此过程将无法正常工作。需要自定义 vars 的用户不应使用 --network-config 选项。相反,在创建 Heat 堆栈后,将节点网络配置应用到 config-download ansible 运行。

将 Ansible 变量语法转换为以编程方式配置每个网络

当您使用 Jinja2 for-loop 结构,通过迭代 role_networks 通过迭代 role_networks 来检索可用的网络,您需要检索每个网络角色的小写名称来添加到每个属性的前面。使用以下结构将 Ansible 变量 从上表转换为所需语法:

{{ lookup(‘vars’, networks_lower[network] ~ ‘_<property>’) }}

  • <property > 替换为您要设置的属性,如 ip,vlan_id, 或 mtu

例如,要动态填充每个 NetworkVlanID 的值,请将 {{ <network_name>_vlan_id }} 替换为以下配置:

{{ lookup(‘vars’, networks_lower[network] ~ ‘_vlan_id’) }}`

8.2.5.5. 用于置备定义文件映射的 Heat 参数

如果您使用 --network-config 可选参数运行 openstack overcloud node provision 命令置备节点,则必须使用节点定义文件 overcloud-baremetal-deploy.yaml 中的参数为您的部署配置网络属性。

如果您的部署使用预置备节点,您可以将 heat 参数映射到 Ansible 变量,以配置网络属性。如果您运行 openstack overcloud node provision 而无需指定 --network-config 可选参数,您还可以将 heat 参数映射到 Ansible 变量。有关使用 Ansible 变量配置网络属性的更多信息,请参阅 Heat 参数到 Ansible 变量映射

下表列出了从 heat 参数到节点定义文件 overcloud-baremetal-deploy.yaml 中等同的 network_config 属性的可用映射。

表 8.11. 从 heat 参数映射到节点定义文件 overcloud-baremetal-deploy.yaml
Heat 参数network_config 属性

BondInterfaceOvsOptions

bond_interface_ovs_options

DnsSearchDomains

dns_search_domains

NetConfigDataLookup

net_config_data_lookup

NeutronPhysicalBridge

physical_bridge_name

NeutronPublicInterface

public_interface_name

NumDpdkInterfaceRxQueues

num_dpdk_interface_rx_queues

{{role.name}}NetworkConfigUpdate

network_config_update

下表列出了从 heat 参数到网络定义文件 network_data.yaml 中等效的属性的可用映射。

表 8.12. 从 heat 参数映射到网络定义文件 network_data.yaml
Heat 参数IPv4 network_data.yaml propertyIPv6 network_data.yaml property

<network_name>IpSubnet

- name: <network_name>
  subnets:
    subnet01:
      ip_subnet: 172.16.1.0/24
- name: <network_name>
  subnets:
    subnet01:
      ipv6_subnet: 2001:db8:a::/64

<network_name>NetworkVlanID

- name: <network_name>
  subnets:
    subnet01:
      ...
      vlan: <vlan_id>
- name: <network_name>
  subnets:
    subnet01:
      ...
      vlan: <vlan_id>

<network_name>Mtu

- name: <network_name>
  mtu:
- name: <network_name>
  mtu:

<network_name>InterfaceDefaultRoute

- name: <network_name>
  subnets:
    subnet01:
      ip_subnet: 172.16.16.0/24
      gateway_ip: 172.16.16.1
- name: <network_name>
  subnets:
    subnet01:
      ipv6_subnet: 2001:db8:a::/64
      gateway_ipv6: 2001:db8:a::1

<network_name>InterfaceRoutes

- name: <network_name>
  subnets:
    subnet01:
      ...
      routes:
        - destination: 172.18.0.0/24
          nexthop: 172.18.1.254
- name: <network_name>
  subnets:
    subnet01:
      ...
      routes_ipv6:
        - destination: 2001:db8:b::/64
          nexthop: 2001:db8:a::1

8.2.5.6. 对网络数据模式的更改

在 Red Hat OpenStack Platform (RHOSP) 17 中更新了网络数据模式。RHOSP 16 及更早版本中使用的网络数据模式之间的主要区别,以及 RHOSP 17 及之后的版本中使用的网络数据模式,如下所示:

  • 基础子网已移到 子网 映射中。这与非路由和路由部署的配置一致,如 spine-leaf 网络。
  • enabled 选项不再用于忽略禁用的网络。相反,您必须从配置文件中删除禁用的网络。
  • 随着使用它的 heat 资源已被删除,不再需要 compat_name 选项。
  • 以下参数不再在网络级别有效: ip_subnet,gateway_ip,allocation_pools,routes,ipv6_subnet,gateway_ipv6,ipv6_allocation_pools, 和 routes_ipv6。这些参数仍然在子网级别使用。
  • 引入了一个新的参数 physical_network,用于在 metalsmith 中创建 ironic 端口。
  • 新的参数 network_typesegmentation_id 替换 {{network.name}}NetValueSpecs,用于将网络类型设置为 vlan
  • RHOSP 17 中弃用了以下参数:

    • {{network.name}}NetCidr
    • {{network.name}}SubnetName
    • {{network.name}}Network
    • {{network.name}}AllocationPools
    • {{network.name}}Routes
    • {{network.name}}SubnetCidr_{{subnet}}
    • {{network.name}}AllocationPools_{{subnet}}
    • {{network.name}}Routes_{{subnet}}
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.