OpenStack your Windows Cluster with Neutron Allowed Address Pairs

Designing high availability for “cloudy” applications like an Apache web server is a fairly trivial task on OpenStack thanks to features like Load-Balancer as a Service (LBaaS).  However, the same is not necessarily true for traditional enterprise workloads like a Microsoft Windows Server Cluster. There are multiple challenges to address including shared block storage and Virtual IP addresses (VIPs) for your cluster.

My project didn’t require shared block storage for my cluster.  So, the major concern to address was the Cluster VIP:  Enter Neutron Allowed Address Pairs!

The smart folks at the Mirantis Murano project have been leveraging this feature to easily deploy Windows Clusters.  Allowed Address Pairs works with the Open vSwitch plugin (and a few others) to associate multiple IP addresses to a single Neutron port!  So, it’s a trivial task to assign your Cluster VIP to each of the NICs of your Cluster nodes.  Let’s see how it works…

Standard Disclaimer: This workflow is provided for educational purposes only with no warrant of support.  Consult Microsoft’s 3rd-Party Hypervisor Support Policies before deploying any such solution in Production!

First, verify that the Allowed Address Pairs extension is enabled for your Neutron Plugin:

  • neutron ext-list
| alias                 | name                            |
| <output>              | <output>                        |
| router                | Neutron L3 Router               |
| allowed-address-pairs | Allowed Address Pairs           |
| vpnaas                | VPN service                     |
| lbaas                 | LoadBalancing service           |

Second, deploy your cluster node VMs.

Third, get the port id and MAC address of each VM NIC:

  • nova interface-list windows-01
  • example output (simplified):
| Port State: ACTIVE                                |
| Port ID: 68a93094-7a84-4ff8-b158-a1080608b881     |
| Net ID: 4a73eb41-ba85-4eed-8afb-1e5c68fac61f      |
| IP addresses:                      |
| MAC Addr: fa:16:3e:b5:07:88                       |

Fourth, add the additional IP(s) to your VMs’ Neutron ports (repeat for each VM and make sure you specify the right port id and mac addresses!):

neutron port-update 68a93094-7a84-4ff8-b158-a1080608b881 \
--allowed-address-pairs type=dict list=true \
mac_address=fa:16:3e:b5:07:88,ip_address= \

Last, deploy Windows Server Failover Clustering and any other application clustering solutions (ex: SQL Server 2012 AlwaysOn Availability Groups) using the VIP(s) you just defined.

You do not need to specify multiple VIPs, but you may need them depending on which applications you are deploying.  For example, I was testing Microsoft SQL Server AlwaysOn Availability Groups; the Windows Server Failover Cluster requires a VIP, and the AlwaysOn Availability Group Listener also requires its own VIP.

Documentation on this feature is sparse.  So, thank you to the Mirantis folks and all the other ‘Stackers out there who published bits and pieces so that I could figure this out.

Are you working with Windows on OpenStack?  If so, share your helpful tips in the comments field below.

2 thoughts on “OpenStack your Windows Cluster with Neutron Allowed Address Pairs”

  1. Thanks! This got me pretty far down the road with AlwaysOn 2014. In my case I am running a private network which has a router then can hand out floating ips. I associated the vm’s with the private IP’s, and on their virtual network they can happily connect to the forwarder I have set up in MSSQL. However, I would like to be able to set up a VIP that is a floating IP so I could connect from my “real” network. Is there some way to associate a floating IP with the address pairs?

    1. Hello Dave,

      Thanks for stopping by the site. Hmm…I have not considered using floating VIP for my AAG Listener since my web and app servers communicate with the DB on the private net. Then, I would use LBaaS for my web servers to be accessed with a public floating VIP.

      I’m not sure what would be the best solution. Maybe create a neutron port with the allowed address as its IP and associate the floating IP with it? If the floating IP association works by ARPs, perhaps that may work?

      Either way, please share the solution once you’ve figured it out.


Leave a Reply

Your email address will not be published. Required fields are marked *