Q. I notice the SQL deployment in Azure has an IP address for the SQL cluster resource that moves between nodes. How does that work in Azure?
A. There are a huge number of templates available in Azure that demonstrate the deployment of many types of workload for both Windows and Linux. One of these templates deploys a complete SQL cluster and if you look inside the SQL cluster you will see the SQL listener resource has a valid IP address from the virtual subnet. This IP also moves between the VMs as the SQL resource fails over between the instances. This will bring up a question for many people as the traditional understanding is:
- vmNICs can have multiple IP addresses however this must be set from the Azure fabric
- You cannot statically configure IP addresses within a VM, they must use DHCP
- IP addresses cannot move between VMs
What is actually happening behind the scenes is that while the cluster nodes have the IP address of the SQL Endpoint and seem to move it between nodes, the actual IP address really resides on an internal load balancer (ILB) as the front-end IP address (the same IP address you see within the VMs as the IP for the SQL cluster resource). It is the ILB that receives the SQL requests and then sends the IP packets to whichever node is currently active (which is ascertained by the ILB via a custom probe that operates on a port that only the active node will respond to). The reason the nodes need to still know the IP address and be configured is that direct server return (DSR) is leveraged which means the response to the SQL request is sent directly from the active node to the requestor rather than going back via the load balancer (which would have to re-write the packet headers).