SQL Server – Multi Subnet Always On High Availability

Does the Windows Failover Cluster for a multi-subnet SQL Server Availability Group require a static IP entry for each subnet?

The CNO will require an IP address for every subnet it could reside in.

I am running SQL Server 2012 on Windows Server 2012 Hyper V VMs in 2 separate subnets in the same domain. I understand that I will need an IP from each subnet when I create the listener for my AAG. What I am unclear on is the configuration of IPs on the underlying Windows Failover Cluster.

For the underlying WSFC you'll need at a minimum:

Node1 - IP Address for each unique subnet for each network interface

Node2 - IP Address for each unique subnet for each network interface

CNO - IP Address for each unique subnet

EX: 2 nodes, 2 subnets, 1 interface per node, subnets 192.168.1.1/24 and 192.168.2.1/24

Node1: 192.168.1.10

Node2: 192.168.2.10

CNO: 192.168.1.20, 192.168.2.20

Also, if the server hosting the secondary replica does require its own IP, does it also require its own unique cluster name (and can you explain why this is necessary)?

I'm not sure I understand this part of the question. All of the resources can only belong to a single cluster - there is no cluster inside of a cluster thing.

Edit - I looked at the link that you posted and I'm not sure why the author stated "•Cluster name for each node". My only guess is they meant each node needs a name and IP (for the node). Otherwise it's not a correct statement, the author should probably be contacted.

How would one approach this?

With a whole bunch of pre-move work :)

My initial thoughts are: /snipped for brevity

You have the right ideas, let me add a few more.

Pre-Work

• The cluster is now Multisubnet, we'll need to add an IP for the cluster name in the second subnet. This will be added to the cluster name resource as an 'OR' dependency as you've stated above. This can be added at any time (I'd add it pre-move). The cluster CAP will now have 2 IP addresses, one for each subnet.
• Firewall rules, etc.
• The listener (as you've already stated) will become multi-subnet. Another IP address will need to be added in the 'OR' dependency.
• Double check the setting of the client access point (CAP [aka VNN, aka network name]) for: HostRecordTTL and RegisterAllProvidersIP to make sure they are setup the way you want them. Note that you may want to use multiple listeners to facilitate clients that use older connection libraries not supporting the new keywords.
• Decide if you want to remove the replica from the AG (if it's going to take a while to physically move the server) or to just pause the AG. If the AG is removed, the databases will go back into a "restoring..." state and you'll be able to catch them up with restores at a later point after the server arrives and is setup.
• Quorum: There isn't much to say here, it's a 2 node cluster with 1 node getting airline miles. Included because we'll hit this later and it's a common question.

Post-Work

• The server should (with a new IP and proper firewall rules) be able to contact the cluster and join.
• Run cluster validation wizard. Save this report as the initial move report. We may need to look at it later. This will also verify most cluster related items and runs very quickly.
• Verify network latency. Set CrossSubnetDelay and CrossSubnetThreshold appropriately for the latency and health of the connection. No changes may be needed but it's good to double and triple check.
• Restore transaction logs/diffs/etc.
• Add the replica back into the AG
• Revisit Quorum. Even though there are just two nodes in the cluster, we'll want to double check we're not using a disk witness. Depending on the version of Windows we should/could use either a fileshare witness or Azure witness.

There may be additional items specific to your environment but that should be the gist of it. You've pretty much hit the nail on the head in your original question/post, this just adds in a little filler :)