(Be sure to checkout the FREE SQLpassion Performance Tuning Training Plan - you get a weekly email packed with all the essential knowledge you need to know about performance tuning on SQL Server.)

Over the last few days I have reworked my home network design, and introduced a new subnet for all my SQL Server based VMs that are running in my VMware vSAN powered Home Lab. In this blog posting I want to describe the various steps that are necessary to move a SQL Server Availability Group into a different subnet.

Network Configuration Overview

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