The tricky part is in this requirement:
You need to ensure that database remains available if a catastrophic
server failure or a disk failure occurs. You need to maintain
transactional consistency of the data across both servers. You need to
achieve these goals without manual intervention.
The disk failure part means a failover cluster alone won't work because the storage is shared with both nodes. If the storage where the data files live fails, then both nodes will be affected.
However, a 2-node synchronous Availability Group isn't the answer either, because as Microsoft's own documentation points out:
If primary's session-timeout period is exceeded by a secondary replica, the primary replica temporarily shifts into asynchronous-commit mode for that secondary replica. When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.
Read further in that link in the "Factors That Disrupt Data Synchronization" section, and Microsoft elaborates on the reasons why you can't guarantee that a 2-node AG will not lose data on failover.
So what's the right answer for SQL Server 2012?
There isn't one. You can't guarantee zero data loss with 2 independent SQL Server 2012s without third party tools (like SAN replication, and even then, there's a ton of work involved.) I'm guessing the question came from a test or certification written by somebody without real-world experience. That wouldn't be the first time, and it won't be the last.
Is there a right answer for later versions?
Yes, SQL Server 2017 introduced a new REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT setting at the Availability Group level. The default is 0, which means as long as the primary receives the transaction, it's committed. You can change that to 1 (or more), which means that if at least that number of secondaries don't also commit the transaction, then the transaction fails.
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.
Best Answer
You're receiving the informational message because you've removed the possible vote (node weight of 0) of the replica. Since it won't ever have a vote, it also won't ever be able to stand on its own should any issues arise with the cluster, since this effectively removed the dynamic quorum aspect of clustering when this node owns anything.
This truly may be what you want, for example as a DR node whose availability you don't want impacting the production nodes. In that case, as long as you understand the situations you're protecting against and meeting those then I don't see a problem setting it like this (which is effectively that you know better than the cluster).