Moving a SQL Server Availability Group to a different Subnet

For almost my whole professional life I have used at home just a simple network configuration with a 192.168.1.0/24 subnet. But with that one and only subnet I have only the possibility for 254 different IP addresses, and over the time more and more IP addresses are in use.

I’m not using here every possible IP address, but I have logically splitted the one and only subnet into different IP address ranges that I have assigned to my various devices and servers:

192.168.1.1: Internet Router 192.168.1.2 192.168.1.4: Managed Network Switches 192.168.1.10 192.168.1.99: DHCP Range 192.168.1.160 192.168.1.169: IP Range for my physical ESXi Management Cluster Servers 192.168.1.180 192.168.1.189: IP Range for my physical ESXi Compute Cluster Servers 192.168.1.190 192.168.1.199: IP Range for my Management VMs (DC, DNS, VPN, WSUS, vCenter, Log Insight, vRealize, …) 192.168.1.200 192.168.1.209: IP Range for SQL Server Availability Groups 192.168.1.210 192.168.1.219: IP Range for SQL Server Client VMs 192.168.1.220 192.168.1.229: IP Range for standalone SQL Server VMs 192.168.1.230 192.168.1.239: IP Range for SQL Server Clusters

As you can see from this list, a lot of IP address ranges are already in use. And in the future I also want to work with additional topics like Docker, Kubernetes, PKS, NSX, Nested ESXi deployments, etc. And everything needs additional IP addresses…

Therefore I wanted to introduce additional subnets into my Home Lab setup to get access to more possible IP addresses. Therefore I have created an additional 192.168.100.0/24 subnet, and the Internet Router at 192.168.1.1 performs the routing between both subnets. The new 192.168.100.0/24 subnet contains now all my SQL Server related VMs, which where previously in the IP address range from 192.168.1.200 192.168.1.239.

Moving a SQL Server Availability Group to a different Subnet

At first it seems quite easy to move a SQL Server Availability Group into a different subnet, because you only have to change the IP addresses that are involved. In my case I had to change all IP addresses in the range from 192.168.1.200 192.168.1.239 to 192.168.100.200 192.168.100.239.

At the first step I have changed the IP addresses of the network adapters of the individual VMs as you can see in the following picture.

But that’s only the half part of the story. A SQL Server Availability Group has also an IP address in the windows Server Failover Cluster (WSFC). And that IP address also has to be changed. As you can see from the next picture, the Windows Server Failover Cluster was offline as soon as I have changed the IP addresses of the network adapters, because the Failover Cluster still had an IP address assigned that was part of a different subnet.

Therefore it is also very important that you are also changing the Cluster IP address of the Windows Server Failover Cluster.

As soon as I have also changed the Cluster IP address, the Availability Group was brought online again.

Summary

I you have to move a SQL Server Availability Group into a different subnet, please keep in mind to change all necessary IP addresses, otherwise you end up with a non-functional Availability Group.

Thanks for your time,

-Klaus