이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 9. Custom composable networks


This chapter follows on from the concepts and procedures outlined in Chapter 8, Basic network isolation and shows you how to configure the overcloud with an additional composable network. This includes configuration of the following files and templates:

  • The environment file to enable network isolation (/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml).
  • The environment file to configure network defaults (/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml).
  • A custom network_data file to create additional networks outside of the defaults.
  • A custom roles_data file to assign custom networks to roles.
  • Templates to define your NIC layout for each node. The overcloud core template collection contains a set of defaults for different use cases.
  • An environment file to enable NICs. This example uses a a default file located in the environments directory.
  • Any additional environment files to customize your networking parameters. This example uses an environment file to customize OpenStack service mappings to composable networks.

The following content in this chapter shows you how to define each of these aspects.

9.1. Composable networks

The overcloud uses the following pre-defined set of network segments by default:

  • Control Plane
  • Internal API
  • Storage
  • Storage Management
  • Tenant
  • External
  • Management (optional)

You can use Composable networks to add networks for various services. For example, if you have a network dedicated to NFS traffic, you can present it to multiple roles.

Director supports the creation of custom networks during the deployment and update phases. These additional networks can be used for ironic bare metal nodes, system management, or to create separate networks for different roles. You can also use them to create multiple sets of networks for split deployments where traffic is routed between networks.

A single data file (network_data.yaml) manages the list of networks to be deployed. Include this file with your deployment command using the -n option. Without this option, the deployment uses the default file (/usr/share/openstack-tripleo-heat-templates/network_data.yaml).

9.2. Adding a composable network

This procedure shows you how to add an additional composable network to your overcloud.

Procedure

  1. Copy the default network_data file:

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
  2. Edit the local copy of the network_data.yaml file and add a section for your new network. For example:

    - name: StorageBackup
      name_lower: storage_backup
      vlan: 21
      vip: true
      ip_subnet: '172.21.1.0/24'
      allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
      gateway_ip: '172.21.1.1'

You can use the following parameters in your network_data file:

name
Sets the human readable name of the network. This parameter is the only mandatory parameter. You can also use name_lower to normalize names for readability. For example, changing InternalApi to internal_api.
name_lower
Sets the lowercase version of the name, which the director maps to respective networks assigned to roles in the roles_data file.
vlan
Sets the VLAN to use for this network.
vip: true
Creates a virtual IP address (VIP) on the new network. This IP is used as the target IP for services listed in the service-to-network mapping parameter (ServiceNetMap). Note that VIPs are only used by roles that use Pacemaker. The overcloud’s load-balancing service redirects traffic from these IPs to their respective service endpoint.
ip_subnet
Sets the default IPv4 subnet in CIDR format.
allocation_pools
Sets the IP range for the IPv4 subnet
gateway_ip
Sets the gateway for the network.
routes

Adds additional routes to the network. Uses a JSON list containing each additional route. Each list item contains a dictionary value mapping. The example demonstrates the syntax:

  routes: [{'destination':'10.0.0.0/16', 'nexthop':'10.0.2.254'}]
subnets

Creates additional routed subnets that fall within this network. This parameter accepts a dict value containing the lowercase name of the routed subnet as the key and the previously mentioned vlan, ip_subnet, allocation_pools, and gateway_ip parameters as the value mapped to the subnet. The following example demonstrates this layout:

- name: StorageBackup
  name_lower: storage_backup
  vlan: 200
  vip: true
  ip_subnet: '172.21.0.0/24'
  allocation_pools: [{'start': '171.21.0.4', 'end': '172.21.0.250'}]
  gateway_ip: '172.21.0.1'
  subnets:
    storage_backup_leaf1:
      vlan: 201
      ip_subnet: '172.21.1.0/24'
      allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
      gateway_ip: '172.19.1.254'

This mapping is often used in spine leaf deployments. For more information, see the "Spine Leaf Networking" guide.

Include the custom network_data file with your deployment using the -n option. Without the -n option, the deployment command uses the default set of networks.

9.3. Including a composable network in a role

You can assign composable networks to the roles defined in your environment. For example, you might include a custom StorageBackup network with your Ceph Storage nodes.

This procedure shows you how to add composable networks to a role in your overcloud.

Procedure

  1. If you do not already have a custom roles_data file, copy the default to your home directory:

    $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.
  2. Edit the custom roles_data file.
  3. Scroll to the role you want to add the composable network and add the network name to the list of networks. For example, to add the network to the Ceph Storage role, use the following snippet as a guide:

    - name: CephStorage
      description: |
        Ceph OSD Storage node role
      networks:
        - Storage
        - StorageMgmt
        - StorageBackup
  4. After adding custom networks to their respective roles, save the file.

When running the openstack overcloud deploy command, include the roles_data file using the -r option. Without the -r option, the deployment command uses the default set of roles with their respective assigned networks.

9.4. Assigning OpenStack services to composable networks

Each OpenStack service is assigned to a default network type in the resource registry. These services are then bound to IP addresses within the network type’s assigned network. Although the OpenStack services are divided among these networks, the number of actual physical networks can differ as defined in the network environment file. You can reassign OpenStack services to different network types by defining a new network map in an environment file, for example, /home/stack/templates/service-reassignments.yaml. The ServiceNetMap parameter determines the network types used for each service.

For example, you can reassign the Storage Management network services to the Storage Backup Network by modifying the highlighted sections:

parameter_defaults:
  ServiceNetMap:
    SwiftMgmtNetwork: storage_backup
    CephClusterNetwork: storage_backup

Changing these parameters to storage_backup places these services on the Storage Backup network instead of the Storage Management network. This means you only need to define a set of parameter_defaults for the Storage Backup network and not the Storage Management network.

The director merges your custom ServiceNetMap parameter definitions into a pre-defined list of defaults taken from ServiceNetMapDefaults and overrides the defaults. The director returns the full list, including customizations back to ServiceNetMap, which is used to configure network assignments for various services.

Service mappings apply to networks that use vip: true in the network_data file for nodes that use Pacemaker. The overcloud’s load balancer redirects traffic from the VIPs to the specific service endpoints.

Note

A full list of default services can be found in the ServiceNetMapDefaults parameter within /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml.

9.5. Enabling custom composable networks

This procedure shows you how to enable custom composable networks using one of the default NIC templates. In this case, it is the Single NIC with VLANs (single-nic-vlans).

Procedure

  1. When you run the openstack overcloud deploy command, ensure that you include the following files:

    • The custom network_data file.
    • The custom roles_data file with network-to-role assignments.
    • The rendered file name of the default network isolation.
    • The rendered file name of the default network environment file.
    • The rendered file name of the default network interface configuration.
    • Any additional environment files related to your network, such as the service reassignments.

For example:

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -r /home/stack/roles_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
    -e /home/stack/templates/service-reassignments.yaml \
    ...

This example command deploys the composable networks, including your additional custom networks, across nodes in your overcloud.

Important

Remember that you must render the templates again if you are introducing a new custom network, such as a management network. Simply adding the network name to the roles_data.yaml file is not sufficient.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.