Traditionally we’ve faced a choice when deploying Nutanix NC2 on Azure when it came to the Flow Gateway.
With static routing (User Defined Routes – UDR) within Azure, the route table only supported directing traffic to a single IP address – so a single Flow Gateway.
Or with Dynamic Routing within Azure, we could use the Azure Route Server (ARS) service and configure a BGP relationship with NC2 (using BGP Speaker VMs) with 2-4 Flow Gateways in a highly available configuration.
The challenge traditionally has been that some customers don’t want to implement dynamic routing for the sake of NC2, but equally don’t want a single point of failure with a single Flow Gateway so had to make a decision one way or the other.
Not anymore however…!
Now we can have static routing AND have highly available Flow Gateways through the use of an Azure Internal Load Balancer (ILB) – as this would present the single IP address for the UDR on the route table.
I’ve had the pleasure of deploying this a few times in the last couple of weeks and found that I could push enough bandwidth through the ILB towards the back end Flow Gateways to fully saturate their defined SKU sizes (10/16Gbps).
Well worth taking this architecture decision into consideration if you have a deployment that isn’t ready for Dynamic Routing but doesn’t want to settle for a single point of failure. https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Cloud-Clusters-Azure:nc2-clusters-azure-migrate-to-scaled-out-flow-gateway-deployment-t.html
It also helps reduce VNET complexity with ExpressRoute as it supports the deployment of the Flow Gateways within the Prism Central VNET on a dedicated subnet rather than introducing a third VNET. This is just a nice thing to see too, helps simplify the delegated baremetal configuration.
Azure Route Server (ARS) is still of course the most flexible architecture if the organisation uses Dynamic Routing because it doesn’t sit in the traffic path like an ILB does but this scratches an itch nicely.