Search
SupportConsoleDevelopersStart a trialContact

Chapter 23. Using availability zones to make network resources highly available

download PDF

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 Deploying a Distributed Compute Node architecture guide.

23.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

23.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 Deploying a Distributed Compute Node architecture guide.

Procedure

  1. Log in to the undercloud as the stack user, and source the stackrc file to enable the director command line tools.

    Example

    $ source ~/stackrc

  2. Create a custom YAML environment file.

    Example

    $ vi /home/stack/templates/my-neutron-environment.yaml

    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.

  3. 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

    parameter_defaults:
  NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'

  4. Determine the AZs for the DHCP and the L3 agents, by entering values for the parameters, NeutronDhcpAgentAvailabilityZone and NeutronL3AgentAvailabilityZone, respectively.

    Example

    parameter_defaults:
  NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'
  NeutronL3AgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'
  NeutronDhcpAgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'

    Important

    In DCN environments, define a single AZ for NeutronDhcpAgentAvailabilityZone so that ports are scheduled in the AZ relevant to the particular edge site.

  5. 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

    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'

  6. 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

    $ openstack overcloud deploy --templates \
-e <your-environment-files> \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/\
my-neutron-environment.yaml

Verification

  • Confirm that availability zones are properly defined, by running the availability zone list command.

    Example

    $ openstack availability zone list

    Sample output

    +----------------+-------------+
| Zone Name      | Zone Status |
+----------------+-------------+
| az-central     | available   |
| az-datacenter1 | available   |
| az-datacenter2 | available   |
+----------------+-------------+

Additional resources

23.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 Deploying a Distributed Compute Node architecture guide.

    Important

    Ensure that all router gateway ports reside on the OpenStack Controller nodes by setting OVNCMSOptions: 'enable-chassis-as-gw' and by providing one or more AZ values for the OVNAvailabilityZone parameter. Performing these actions prevent the routers from scheduling all chassis as potential hosts for the router gateway ports.

Procedure

  1. Log in to the undercloud as the stack user, and source the stackrc file to enable the director command line tools.

    Example

    $ source ~/stackrc

  2. Create a custom YAML environment file.

    Example

    $ vi /home/stack/templates/my-neutron-environment.yaml

    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.

  3. 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

    parameter_defaults:
  NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'

  4. Determine the AZs for the gateway nodes (Controllers and Network nodes), by entering values for the parameter, OVNAvailabilityZone.

    Important

    The OVNAvailabilityZone parameter replaces the use of AZ values in the OVNCMSOptions parameter. If you use the OVNAvailabilityZone 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: 

    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'
    Important

    In DCN environments, define a single AZ for ControllerCentralParameter so that ports are scheduled in the AZ relevant to the particular edge site.

  5. By default, the router scheduler is AZLeastRoutersScheduler. If you want to change this, enter the new scheduler with the NeutronRouterSchedulerDriver parameters.

    Example

    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'

  6. 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

    $ openstack overcloud deploy --templates \
-e <your-environment-files> \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/\
my-neutron-environment.yaml

Verification

  • Confirm that availability zones are properly defined, by running the availability zone list command.

    Example

    $ openstack availability zone list

    Sample output

    +----------------+-------------+
| Zone Name      | Zone Status |
+----------------+-------------+
| az-central     | available   |
| az-datacenter1 | available   |
| az-datacenter2 | available   |
+----------------+-------------+

Additional resources

23.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

    $ openstack network create --availability-zone-hint zone-1 \
--availability-zone-hint zone-2 net1

    Sample output

    +---------------------------+--------------------------------------+
| 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                 |
+---------------------------+--------------------------------------+

  • 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

    $ openstack router create --ha --availability-zone-hint zone-1 \
--availability-zone-hint zone-2 router1

    Sample output

    +-------------------------+--------------------------------------+
| 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                 |
+-------------------------+--------------------------------------+

    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

    $ openstack network show net1

    Sample output

    +---------------------------+--------------------------------------+
| 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                 |
+---------------------------+--------------------------------------+

Additional resources

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.