How to define OpenStack edge sites through Availability Zones

In an edge computing environment, control over where your instances are placed is everything. Being able to locate workloads closer to the user implies a physical affinity direction relative to the user, and thus some way to model that in the infrastructure, as well as some way to direct workloads accordingly. In OpenStack, that is done with Availability Zones.

Historically, availability zones were used in monolithic datacenter deployments to define boundaries between dependent systems. Ideally this provided a way for API users to place workloads on compute nodes that did not share critical resources, such as power, cooling, and networking. The important piece of data for placing an edge workload is more about the geography or distance from a user, but the fundamental idea is the same: choosing a group of resources that share some common attribute. Indeed, an edge site will also very likely not share many physical resources with another, being separated by some non-trivial distance compared to a monolithic datacenter arrangement.

The infrastructure setup must be done as an admin at setup time or when adding new compute nodes. Assume for the sake of discussion that we have the following sites:

•  A central-datacenter with two nodes hostA and hostB

•  An edge site called 'edge-east' with two compute nodes, hostC and hostD

•  An edge site called 'edge-west' with two compute nodes, hostE and hostF

The best practice here would be to configure three availability zones, one for each of the three sites we have. Further, the default AZ should generally be set to the central datacenter zone, so that any

instance booted without specifically targeting one of our edge sites will be placed in the datacenter. Currently, the compute services at the edge must host instances with ephemeral storage. The high level architectural view of this example looks like figure 1:

Figure 1: A high-level overview of an edge computing setup

Site Availability Zone Setup

First, we will create the three zones. Note that availability zones are special instances of host aggregates, so the commands we use for administering zones are actually for aggregates. The steps are:

$ openstack aggregate create central --zone central
$ openstack aggregate create east --zone east
$ openstack aggregate create west --zone west

In most cases, instances should be directed to specific edge sites as needed. Conversely, instances that do not need to be at an edge site should land on a host in the central datacenter, where capacity is larger.  To make sure that instances not targeted to a particular edge site are sent to the central datacenter, we need to configure Nova with:

[DEFAULT]
default_schedule_zone = central

In order to get director to do this for you, create a director environment file with the following and add to the deploy command line:

parameter_defaults:
  ControllerExtraConfig:
    nova::availability_zone::default_schedule_zone: central
    controller_classes:
      - ::nova::availability_zone

NOTE: If, for some reason it is desirable to force all instance boots to specify a zone, it is possible to create an empty zone and set that as the default. Doing so will cause the user to receive a message indicating that the default zone is “not available” without starting the instance build. This may be useful for cases where all capacity is at the edge sites, with no general central datacenter with capacity for untargeted workloads.

Next we need to assign our compute nodes to the proper zone so that the scheduler knows where they are located and how to answer requests for specific areas.

$ openstack aggregate add host central hostA
$ openstack aggregate add host central hostB
$ openstack aggregate add host east hostC
$ openstack aggregate add host east hostD
$ openstack aggregate add host west hostE
$ openstack aggregate add host west hostF

To check that the hosts are mapped properly, check the state of each aggregate and verify that the availability_zone is set, and that the relevant hosts are listed. For example, the central aggregate should look like this:

$ openstack aggregate show central

+-------------------+----------------------------+
| Field             | Value                      |
+-------------------+----------------------------+
| availability_zone | central                    |
| created_at        | 2019-01-30T14:52:10.000000 |
| deleted           | False                      |
| deleted_at        | None                       |
| hosts             | [u'hostA'. u’hostB’]       |
| id                | 1                          |
| name              | central                    |
| properties        |                            |
| updated_at        | None                       |
+-------------------+----------------------------+

Now that all of that is configured, we can boot some instances targeted at specific sites. First, we will boot an instance with no destination set, which should land in the central datacenter:

$ openstack server create --flavor tiny --image rhel test1

Check that the availability zone of this server was forced to be central:

$ openstack server show -f value -c OS-EXT-AZ:availability_zone -c OS-EXT-SRV-ATTR:host test1
central
hostA

Next, we will boot an instance specifically to run at the 'east' edge site:

$ openstack server create --flavor tiny --image rhel --availability-zone east test2

Which should land on either hostC or hostD to satisfy the requirement for being in the 'east' availability zone. Confirm that the host and zone are correct for this as well:

$ openstack server show -f value -c OS-EXT-AZ:availability_zone -c OS-EXT-SRV-ATTR:host test2
east
hostC

If you’d like to learn more about Red Hat’s edge computing approach, we invite you to visit "Understanding edge computing."