OpenStack Neutron has since Mitaka had extensions available for availability zone based scheduling of routers and DHCP-agents. This is really useful if you have a cluster that is otherwise partitioned into availability zones (on the Cinder and Nova-levels.).
Setting up the server-side end
First of all, you will need:
- An OpenStack cluster, using Mitaka or newer
- Neutron-networking handling routers and/or dhcp-agents
Then you need to:
- Set availability zone in agent configuration by setting the
availability_zoneparameter in the
- Ensure that the availability_zone-related extensions are active within Neutron.
openstack extension list, you should see
As Mirantis have explained in a pretty good blogpost, the Availability Zone-concept behaves somewhat different in nova vs. cinder vs. neutron. What it boils down to, the Neutron implementation adds some scheduling hints - helping Neutron eliminating candidates for the resources you want to set up. If a L3 agent (router) were eligible to be scheduled on any network node in the cluster, setting an availability zone hint will limit the candidates to those network nodes which remain in the availability zones listed. No availability zone hint, means that anything goes.
Using the feature is as simple as adding
--availability-zone-hint AZ to any CLI calls, or set the
”availability_zone_hints”: ['AZ'] attribute when calling it through the API. As you may have noticed, the API takes an array, while the command line does not - you can however specify the parameter multiple times, with multiple values if you would like to specify multiple AZ hints over the CLI.
Does it work?
At my day job, we have been running this feature since we established our cluster right after Mitaka were released - and even though it has worked pretty well for us, we have noticed that basically no tools have caught up and adopted this feature. The only two places we can see the support for this is in the networking API (duh) and the official CLIs. This mean that it hasn’t been available in the OpenStack-dashboard, and anyone trying to use common cloud orchestration libraries against it haven’t been able to set these values.
So I’ve added support for it in Horizon 1, 2 and Shade. A coworker has done some work and fixed support for it in Gophercloud 1 , 2 and the OpenStack provider for Terraform. Another coworker has spent some time getting Heat up to speed with the functionality, but this has not yet been merged.
End users should have easier access to this feature as of the upcoming Queens-release - which will arrive two years after the initial release of the feature.