Chapter 9. Custom composable networks
You can create custom composable networks if you want to host specific network traffic on different networks. To configure the overcloud with an additional composable network, you must configure 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 default file that is 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.
Some of the files in the previous list are Jinja2 format files and have a .j2.yaml
extension. Director renders these files to .yaml
versions during deployment.
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 that is dedicated to NFS traffic, you can present it to multiple roles.
Director supports the creation of custom networks during the deployment and update phases. You can use these additional networks 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 that you want to deploy. Include this file with your deployment command using the -n
option. Without this option, the deployment uses the default /usr/share/openstack-tripleo-heat-templates/network_data.yaml
file.
9.2. Adding a composable network
Use composable networks to add networks for various services. For example, if you have a network that is dedicated to storage backup traffic, you can present the network to multiple roles.
Procedure
Copy the default
network_data.yaml
file:$ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
Edit the local copy of the
network_data.yaml
file and add a section for your new network:- 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.yaml
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, changeInternalApi
tointernal_api
. name_lower
-
Sets the lowercase version of the name, which director maps to respective networks assigned to roles in the
roles_data.yaml
file. vlan
- Sets the VLAN that you want 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 used only by roles that use Pacemaker. The overcloud 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 that contains each additional route. Each list item contains a dictionary value mapping. Use the following example 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 that contains the lowercase name of the routed subnet as the key and thevlan
,ip_subnet
,allocation_pools
, andgateway_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 common in spine leaf deployments. For more information, see the Spine Leaf Networking guide.
When you add an extra composable network that contains a virtual IP, and want to map some API services to this network, use the
CloudName{network.name}
definition to set the DNS name for the API endpoint:CloudName{{network.name}}
Here is an example:
parameter_defaults: ... CloudNameOcProvisioning: baremetal-vip.example.com
-
Include the custom
network_data.yaml
file in your deployment command using the-n
option. Without the-n
option, the deployment command uses the default set of networks. If you want a predictable virtual IP address (VIP), add a
VirtualFixedIPs
parameter for your custom network to theparameter_defaults
section of a heat environment file, for example,my_network_vips.yaml
:<% my_customer_network %>VirtualFixedIPs: [{'ip_address':'<% ipaddres %>'}]
Here is an example:
parameter_defaults: ... # Predictable VIPs StorageBackuptVirtualFixedIPs: [{'ip_address':'172.21.1.9'}]
-
Include the heat environment file,
my_network_vips.yaml
, in your deployment command by using the-e
option.
Additional resources
- Assigning predictable Virtual IPs
- Environment files
- overcloud deploy in the Command line interface reference
9.3. Including a composable network in a role
You can assign composable networks to the overcloud roles defined in your environment. For example, you might include a custom StorageBackup
network with your Ceph Storage nodes.
Procedure
If you do not already have a custom
roles_data.yaml
file, copy the default to your home directory:$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.
-
Edit the custom
roles_data.yaml
file. Include the network name in the
networks
list for the role that you want to add the network to. For example, to add theStorageBackup
network to the Ceph Storage role, use the following example snippet:- name: CephStorage description: | Ceph OSD Storage node role networks: - Storage - StorageMgmt - StorageBackup
- After you add custom networks to their respective roles, save the file.
When you run the openstack overcloud deploy
command, include the custom roles_data.yaml
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 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 that you want to use 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 that you must define a set of parameter_defaults
only for the Storage Backup network and not the Storage Management network.
Director merges your custom ServiceNetMap
parameter definitions into a pre-defined list of defaults that it obtains from ServiceNetMapDefaults
and overrides the defaults. Director returns the full list, including customizations, 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.yaml
file for nodes that use Pacemaker. The overcloud load balancer redirects traffic from the VIPs to the specific service endpoints.
You can find a full list of default services in the ServiceNetMapDefaults
parameter in the /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml
file.
9.5. Enabling custom composable networks
Enable custom composable networks using one of the default NIC templates. In this example, use the Single NIC with VLANs template (net-single-nic-with-vlans
).
Procedure
When you run the
openstack overcloud deploy
command, ensure that you include the following files:-
The custom
network_data.yaml
file. -
The custom
roles_data.yaml
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.
-
The custom
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.
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.
9.6. Renaming the default networks
You can use the network_data.yaml
file to modify the user-visible names of the default networks:
- InternalApi
- External
- Storage
- StorageMgmt
- Tenant
To change these names, do not modify the name
field. Instead, change the name_lower
field to the new name for the network and update the ServiceNetMap with the new name.
Procedure
In your
network_data.yaml
file, enter new names in thename_lower
parameter for each network that you want to rename:- name: InternalApi name_lower: MyCustomInternalApi
Include the default value of the
name_lower
parameter in theservice_net_map_replace
parameter:- name: InternalApi name_lower: MyCustomInternalApi service_net_map_replace: internal_api