Building Network Automation Solutions
6 week online course starting in September 2017

OpenStack Networking, Availability Zones and Regions

One of my ExpertExpress engagements focused on networking in a future private cloud that might be built using OpenStack. The customer planned to deploy multiple data centers, and I recommended that they do everything they can to make sure they don’t make them a single failure domain.

Next step: translate that requirement into OpenStack terms.

OpenStack supports multiple levels of failure isolation, including availability zones and regions:

  • Availability zone is primarily a Nova (read: compute) construct similar to VMware HA cluster. AZ awareness was added to Neutron not so long ago, but it seems to be just that: awareness (or as the documentation says: hints).

AWS VPC provides better isolation: you might configure a VPC to span more than one availability zone, but you cannot stretch a subnet across more than one availability zone. Contrary to evangelists working for networking vendors AWS architects obviously know how to make a stable network.

  • Regions are distinct API entry points similar to VMware vCenter instances – just the thing to use if you want the data centers to be independent.

It’s my understanding that you cannot span a tenant network across multiple regions… at least I haven’t found any multi-region confederation capability in OpenStack documentation (apart the ability to select regions in client-facing dashboards).

You can configure the same set of provider networks in multiple OpenStack regions and connect them outside of OpenStack using VLANs or VRFs.

Of course one might use an SDN controller underneath Neutron (Contrail or Nuage VSP come to mind) and use BGP to link multiple instances assuming you can somehow synchronize L3VPN RT/RD values across OpenStack instances (similar to AWS VPC peering), but it might be simpler to connect regions across provider networks.

Have I missed something? Comments are (as always) most welcome!

Want to discuss viability of OpenStack in your private cloud or integration of your data center with public OpenStack offerings? Why don't you enroll into the Building the Next-Generation Data Center online course?

4 comments:

  1. I don't think you've missed anything, separating each datacenter into regions is something future users of this cloud will appreciate. As a customer driving APIs it doesn't really matter in cost if separation is implemented as AZs or regions. As an operator and for simplicity of design, it DOES matter. A lot.

    There is so many things that can go wrong though :-) Hopefully the team building this will know and understand that they will need a "code-defined" way of building x regions - and still share common configuration data across regions. This ability should include _all_ the network setup.

    For cross-region traffic I normally recommend routing dedicated internal-only Neturon networks through GRE tunnels secured with IPsec. IPsec is not hard when you only need to deal with policy for the two endpoints :)

    ReplyDelete
  2. With regards to your AWS VPC peering comment and link, is this in relation to VPC peering across regions? If so, it is not supported and is listed as one of the limitations;

    "You cannot create a VPC peering connection between VPCs in different regions."

    ReplyDelete
  3. Hi Ivan,

    You are spot on. We at CPLANE NETWORKS, the other SDN controller company you didn't mention, provide Multi-Domain Networking by tying together Multiple OpenStack instances across regions using Other WAN technology VLAN, VPN MPLS. Subnets are isolated to OpenStack instances. We also provide an Orchestration layer above OpenStack to manage these domain on a global scale. We have a lot of experience in this and have looked at the problem many ways and as you say, anyone trying to do this purely under OpenStack is a fools errand.

    Thanks again for your insightful commentary and alignment of ideas.

    ReplyDelete
  4. Another way to keep tenant networking but link those networks together is using VPNaaS. This will allow the tenant to create the network connection across both regions and still stay within the tenant space, unlike having to use provider networks and other methods. This is more multi-tenant friendly and probably a bit more self-service than the other options.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.