Chapter 20. Using availability zones to make network resources highly available Starting with version 16.2, Red Hat OpenStack Platform (RHOSP) supports RHOSP Networking service (neutron) availability zones (AZs). AZs enable you to make your RHOSP network resources highly available. You can group network nodes that are attached to different power sources on different AZs, and then schedule crucial services to be on separate AZs. Often Networking service AZs are used in conjunction with Compute service (nova) AZs to ensure that customers use specific virtual networks that are local to a physical site that workloads run on. For more information on Distributed Compute Node architecture see, the Distributed compute node and storage deployment guide. 20.1. About Networking service availability zones The required extensions that provide Red Hat OpenStack Platform (RHOSP) Networking service (neutron) availability zones (AZ) functionality are availability_zone , router_availability_zone , and network_availability_zone . The Modular Layer 2 plug-in with the Open vSwitch (ML2/OVS) mechanism driver support all of these extensions. Note The Modular Layer 2 plug-in with the Open Virtual Network (ML2/OVN) mechanism driver supports only router availability zones. ML2/OVN has a distributed DHCP server, so supporting network AZs is unnecessary. When you create your network resource, you can specify an AZ by using the OpenStack client command line option, --availability-zone-hint . The AZ that you specify is added to the AZ hint list. However, the AZ attribute is not actually set until the resource is scheduled. The actual AZ that is assigned to your network resource can vary from the AZ that you specified with the hint option. The reasons for this mismatch can be that there is a zone failure, or that the zone specified has no remaining capacity. You can configure the Networking service for a default AZ, in case users fail to specify an AZ when they create a network resource. In addition to setting a default AZ, you can also configure specific drivers to schedule networks and routers on AZs. Additional resources Configuring Network service availability zones with ML2/OVS Configuring Network service availability zones with ML2/OVN Manually Assigning availability zones to networks and routers 20.2. Configuring Network service availability zones for ML2/OVS You can set one or more default availability zones (AZs) that are automatically assigned by the Red Hat OpenStack Platform (RHOSP) Networking service (neutron) when users create networks and routers. In addition, you can also set the network and router drivers that the Networking service uses to schedule these resources for a respective AZ. The information contained in this topic is for deployments that run the RHOSP Networking service that uses the Module Layer 2 plug-in with the Open vSwitch mechanism driver (ML2/OVS). Prerequisites Deployed RHOSP 16.2 or later. Running the RHOSP Networking service that uses the ML2/OVS mechanism driver. When using Networking service AZs in distributed compute node (DCN) environments, you must match the Networking service AZ names to the Compute service (nova) AZ names. For more information, see the Distributed compute node and storage deployment guide. Procedure Log in to the undercloud as the stack user, and source the stackrc file to enable the director command line tools. Example Create a custom YAML environment file. Example Tip The Red Hat OpenStack Platform Orchestration service (heat) uses a set of plans called templates to install and configure your environment. You can customize aspects of the overcloud with a custom environment file , which is a special type of template that provides customization for your heat templates. In the YAML environment file, under parameter_defaults , enter the NeutronDefaultAvailabilityZones parameter and one or more AZs. The Networking service assigns these AZs if a user fails to specify an AZ with the --availability-zone-hint option when creating a network or a router. Important In DCN environments, you must match the Networking service AZ names with Compute service AZ names. Example Determine the AZs for the DHCP and the L3 agents, by entering values for the parameters, NeutronDhcpAgentAvailabilityZone and NeutronL3AgentAvailabilityZone , respectively. Example Important In DCN environments, define a single AZ for NeutronDhcpAgentAvailabilityZone so that ports are scheduled in the AZ relevant to the particular edge site. By default, the network and router schedulers are AZAwareWeightScheduler and AZLeastRoutersScheduler , respectively. If you want to change one or both of these, enter the new schedulers with the NeutronNetworkSchedulerDriver and NeutronRouterSchedulerDriver parameters, respectively. Example Run the openstack overcloud deploy command and include the core heat templates, environment files, and this new custom environment file. Important The order of the environment files is important because the parameters and resources defined in subsequent environment files take precedence. Example Verification Confirm that availability zones are properly defined, by running the availability zone list command. Example Sample output Additional resources About Networking service availability zones Configuring Network service availability zones with ML2/OVN Manually Assigning availability zones to networks and routers 20.3. Configuring Network service availability zones with ML2/OVN You can set one or more default availability zones (AZs) that are automatically assigned by the Red Hat OpenStack Platform (RHOSP) Networking service (neutron) when users create routers. In addition, you can also set the router driver that the Networking service uses to schedule these resources for a respective AZ. The information contained in this topic is for deployments that run the RHOSP Networking service that uses the Modular Layer 2 plug-in with the Open Virtual Network (ML2/OVN) mechanism driver. Note The ML2/OVN mechanism driver supports only router availability zones. ML2/OVN has a distributed DHCP server, so supporting network AZs is unnecessary. Prerequisites Deployed RHOSP 16.2 or later. Running the RHOSP Networking service that uses the ML2/OVN mechanism driver. When using Networking service AZs in distributed compute node (DCN) environments, you must match the Networking service AZ names to the Compute service (nova) AZ names. For more information, see the Distributed compute node and storage deployment guide. Procedure Log in to the undercloud as the stack user, and source the stackrc file to enable the director command line tools. Example Create a custom YAML environment file. Example Tip The Red Hat OpenStack Platform Orchestration service (heat) uses a set of plans called templates to install and configure your environment. You can customize aspects of the overcloud with a custom environment file , which is a special type of template that provides customization for your heat templates. In the YAML environment file, under parameter_defaults , enter the NeutronDefaultAvailabilityZones parameter and one or more AZs. Important In DCN environments, you must match the Networking service AZ names with Compute service AZ names. The Networking service assigns these AZs if a user fails to specify an AZ with the --availability-zone-hint option when creating a network or a router. Example Determine the AZs for the gateway nodes (Controllers and Network nodes), by entering values for the parameter, OVNAvailabilityZone . Important The OVNAvailability parameter replaces the use of AZ values in the OVNCMSOptions parameter. If you use the OVNAvailability parameter, ensure that there are no AZ values in the OVNCMSOptions parameter. Example In this example, roles have been predefined for Controllers for the az-central AZ, and Networkers for the datacenter1 and datacenter2 AZs: Important In DCN environments, define a single AZ for ControllerCentralParameter so that ports are scheduled in the AZ relevant to the particular edge site. By default, the router scheduler is AZLeastRoutersScheduler . If you want to change this, enter the new scheduler with the NeutronRouterSchedulerDriver parameters. Example Run the openstack overcloud deploy command and include the core heat templates, environment files, and this new custom environment file. Important The order of the environment files is important because the parameters and resources defined in subsequent environment files take precedence. Example Verification Confirm that availability zones are properly defined, by running the availability zone list command. Example Sample output Additional resources About Networking service availability zones Configuring Network service availability zones with ML2/OVS Manually Assigning availability zones to networks and routers 20.4. Manually Assigning availability zones to networks and routers You can manually assign a Red Hat OpenStack Platform (RHOSP) Networking service (neutron) availability zone (AZ) when you create a RHOSP network or a router. AZs enable you to make your RHOSP network resources highly available. You can group network nodes that are attached to different power sources on different AZs, and then schedule nodes running crucial services to be on separate AZs. Note If you fail to assign an AZ when creating a network or a router, the RHOSP Networking service automatically assigns to the resource the value that was specified to the RHOSP Orchestration service (heat) parameter. If no value is defined for NeutronDefaultAvailabilityZones the resources are scheduled without any AZ attributes. For RHOSP Networking service agents that use the Modular Layer 2 plug-in with the Open vSwitch (ML2/OVS) mechanism driver, if no AZ hint is supplied and no value specified for NeutronDefaultAvailabilityZones , then the Compute service (nova) AZ value is used to schedule the agent. Prerequisites Deployed RHOSP 16.2 or later. Running the RHOSP Networking service that uses either the ML2/OVS or ML2/OVN (Open Virtual Network) mechanism drivers. Procedure When you create a network on the overcloud using the OpenStack client, use the --availability-zone-hint option. Note The ML2/OVN mechanism driver supports only router availability zones. ML2/OVN has a distributed DHCP server, so supporting network AZs is unnecessary. In the following example, a network ( net1 ) is created and assigned to either AZ zone-1 or zone-2 : Network example Sample output When you create a router on the overcloud using the OpenStack client, use the --ha and --availability-zone-hint options. In the following example, a router ( router1 ) is created and assigned to either AZ zone-1 or zone-2 : Router example Sample output Notice that the actual AZ is not assigned at the time that you create the network resource. The RHOSP Networking service assigns the AZ when it schedules the resource. Verification Enter the appropriate OpenStack client show command to confirm in which zone the resource is hosted. Example Sample output Additional resources About Networking service availability zones Configuring Network service availability zones with ML2/OVS Configuring Network service availability zones with ML2/OVN

Commands:
source ~/stackrc
vi /home/stack/templates/my-neutron-environment.yaml
parameter_defaults: NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'
parameter_defaults: NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1' NeutronL3AgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1' NeutronDhcpAgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'
parameter_defaults: NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1' NeutronL3AgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1' NeutronDhcpAgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1' NeutronNetworkSchedulerDriver: 'neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler' NeutronRouterSchedulerDriver: 'neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler'
openstack overcloud deploy --templates -e <your-environment-files> -e /usr/share/openstack-tripleo-heat-templates/environments/services/ my-neutron-environment.yaml
openstack availability zone list
+----------------+-------------+ | Zone Name | Zone Status | +----------------+-------------+ | az-central | available | | az-datacenter1 | available | | az-datacenter2 | available | +----------------+-------------+
source ~/stackrc
vi /home/stack/templates/my-neutron-environment.yaml
parameter_defaults: NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'
parameter_defaults: NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1' ControllerCentralParameters: OVNCMSOptions: 'enable-chassis-as-gw' OVNAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1' NetworkerDatacenter1Parameters: OVNCMSOptions: 'enable-chassis-as-gw' OVNAvailabilityZone: 'az-datacenter1' NetworkerDatacenter2Parameters: OVNCMSOptions: 'enable-chassis-as-gw' OVNAvailabilityZone: 'az-datacenter2'
parameter_defaults: NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1' ControllerCentralParameters: OVNCMSOptions: 'enable-chassis-as-gw' OVNAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1' NetworkerDCN1Parameters: OVNCMSOptions: 'enable-chassis-as-gw' OVNAvailabilityZone: 'az-datacenter1' NetworkerDCN2Parameters: OVNCMSOptions: 'enable-chassis-as-gw' OVNAvailabilityZone: 'az-datacenter2' NeutronRouterSchedulerDriver: 'neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler'
openstack overcloud deploy --templates -e <your-environment-files> -e /usr/share/openstack-tripleo-heat-templates/environments/services/ my-neutron-environment.yaml
openstack availability zone list
+----------------+-------------+ | Zone Name | Zone Status | +----------------+-------------+ | az-central | available | | az-datacenter1 | available | | az-datacenter2 | available | +----------------+-------------+
openstack network create --availability-zone-hint zone-1 --availability-zone-hint zone-2 net1
+---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | UP | | availability_zone_hints | zone-1 | | | zone-2 | | availability_zones | | | created_at | 2021-07-31T22:14:12Z | | description | | | headers | | | id | ad88e059-e7fa-4cf7-8857-6731a2a3a554 | | ipv4_address_scope | None | | ipv6_address_scope | None | | mtu | 1450 | | name | net1 | | port_security_enabled | True | | project_id | cfd1889ac7d64ad891d4f20aef9f8d7c | | provider:network_type | vxlan | | provider:physical_network | None | | provider:segmentation_id | 77 | | revision_number | 3 | | router:external | Internal | | shared | False | | status | ACTIVE | | subnets | | | tags | [] | | updated_at | 2021-07-31T22:14:13Z | +---------------------------+--------------------------------------+
openstack router create --ha --availability-zone-hint zone-1 --availability-zone-hint zone-2 router1
+-------------------------+--------------------------------------+ | Field | Value | +-------------------------+--------------------------------------+ | admin_state_up | UP | | availability_zone_hints | zone-1 | | | zone-2 | | availability_zones | | | created_at | 2021-07-31T22:16:54Z | | description | | | distributed | False | | external_gateway_info | null | | flavor_id | None | | ha | False | | headers | | | id | ced10262-6cfe-47c1-8847-cd64276a868c | | name | router1 | | project_id | cfd1889ac7d64ad891d4f20aef9f8d7c | | revision_number | 3 | | routes | | | status | ACTIVE | | tags | [] | | updated_at | 2021-07-31T22:16:56Z | +-------------------------+--------------------------------------+
openstack network show net1
+---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | UP | | availability_zone_hints | zone-1 | | | zone-2 | | availability_zones | zone-1 | | | zone-2 | | created_at | 2021-07-31T22:14:12Z | | description | | | headers | | | id | ad88e059-e7fa-4cf7-8857-6731a2a3a554 | | ipv4_address_scope | None | | ipv6_address_scope | None | | mtu | 1450 | | name | net1 | | port_security_enabled | True | | project_id | cfd1889ac7d64ad891d4f20aef9f8d7c | | provider:network_type | vxlan | | provider:physical_network | None | | provider:segmentation_id | 77 | | revision_number | 3 | | router:external | Internal | | shared | False | | status | ACTIVE | | subnets | | | tags | [] | | updated_at | 2021-07-31T22:14:13Z | +---------------------------+--------------------------------------+