I'm reviewing a two-node Windows Server Failover Cluster running SQL Server on virtual machines, with Dell Unity 480F SAN storage. The environment currently uses Always On Availability Groups, and one database, testdb, is synchronized correctly.
The problem is that the critical database R26UAT22 does not come online after Node-1 fails over to Node-2. Investigation showed that the database was restored to a temporary VMDK on Node-1's local F: drive after restoring directly to the shared RDM storage proved unusually slow. The database was never moved back to the shared E: drive and was never added to the Availability Group. Since Node-2 has no F: drive, it cannot access the database after failover.
My understanding is that Always On Availability Groups are designed for separate storage on each replica, with data synchronized over the network. A shared RDM is normally associated with a SQL Server Failover Cluster Instance, where the active node accesses the shared storage and the nodes take turns hosting the instance.
The two options I'm considering are:
1. Keep the Availability Group, provide equivalent local storage to Node-2, and add R26UAT22 to the AG after properly restoring and synchronizing it.
2. Keep the shared RDM design and rebuild the SQL environment as a Failover Cluster Instance, which would require significant downtime.
Am I understanding the AG-versus-FCI storage distinction correctly? Is there a hybrid design I'm overlooking, or is this simply an improperly designed and partially configured environment? Also, what is the clearest way to explain the risks and recommended path to a nontechnical client?
4 Answers
For a nontechnical explanation, say that the current system has two different spare-tire designs mixed together. One design keeps a separate copy of the database on each server and synchronizes them; the other lets either server use the same shared disk, but only one server at a time. The affected database currently exists on only one server, so there is no usable backup copy when that server fails. Recommend either completing the separate-copy design or rebuilding around the shared-disk design, rather than continuing with the hybrid state.
Your diagnosis of the immediate failure is correct: the database is only on Node-1’s F: drive, is not part of the AG, and Node-2 cannot access it. An Availability Group normally uses independent storage on each replica and synchronizes changes between them; it does not have both servers actively writing to the same database files on a shared disk. Shared storage is generally the model for a SQL Server Failover Cluster Instance, not a standard AG.
Rather than moving one database and hoping there are no other surprises, consider treating the existing environment as untrusted. If you have the time and expertise, build a clean two-node SQL cluster, configure the intended HA technology from the start, restore or migrate the databases, test failover, and then retire the old setup. It may require planned maintenance, but it gives you a documented and repeatable configuration.
The fact that one database was left on temporary local storage suggests there may be other undocumented configuration problems, so a clean rebuild is worth presenting as an option.
If the client chooses AG, provide each node with suitable local storage and configure the database properly as an AG replica. This uses additional storage, but it avoids shared-disk dependencies and is usually simpler to operate. Before committing, verify SQL Server editions, replica settings, backup and restore procedures, service accounts, listener and cluster dependencies, and perform an actual failover test.
That matches what I found. The main concern is whether repairing this isolated database is wise given how much of the existing environment was configured inconsistently.