Hello, hope you are well.
I am working on a customer IT Infrastructure and I have a query regarding the supportability of their Enterprise SQL Cluster. I suspect that the way they have configured it, renders it an unsupportable configuration by Microsoft and wondered what other people’s
thoughts are.
The setup is as follows.
There are three physical HP servers in the cluster. All three servers are of identical hardware specification. They all run the exact same Windows Server 2008 R2 Enterprise Operating System and SQL Server 2008 R2 Database server. They all run
the same service packs, patches and all have two local hardware mirrored disks containing the C:\ drive with the OS installed.
SERVER_1 and SERVER_2 are located at SITE_A
SERVER_3 is located at SITE_B
SERVER_3 is used as a DR server at SITE_B in the event of losing both SERVER_1 and SERVER_2 at SITE_A.
SITE_A and SITE_B are connected via a stretched VLAN so that all server IP Addresses are on the same network subnet.
SERVER_1 and SERVER_2 have iSCSI connected data partitions on a shared SAN storage where the SQL Program files and databases reside. SERVER_3 does not have visibility of this storage at SITE_A
Because of the speed limitations of the stretched VLAN a copy of the data on the storage from SITE_A is replicated to a separate SAN at SITE_B. SERVER_3 is configured to connect to this storage via iSCSI but only has read-only access. While SERVER_3 is a
member of the cluster, is does not have permission to control the clustered disk resources.
In the event of a major site failure at SITE_A resulting in SERVER_1 and SERVER_2 becoming unavailable, a manual process is followed to remove SERVER_1 and SERVER_2 from accessing the clustered resources. Then the replicated iSCSI storage at SITE_B is made
read-write and SERVER_3 is manually configured to allow access to this replicated copy of the storage through the cluster. This DR server then becomes the only node in the cluster until the issue with SITE_A is fixed. At this point the whole configuration
is reversed to back the way it was with SERVER_1 and SERVER_2 becoming owners of their SAN disks and SERVER_3 removed as an active member. Any changes made to the data while SERVER_3 was in use are replicating back across to the original SITE_A SAN storage
prior to SERVER_1 and SERVER_2 taking over.
To me this feels like fooling SERVER_3 into being a member of a cluster that it never has full control over and is fooled into thinking that the disks it connects to are the same disks that SERVER_1 and SERVER_2 share. The fact that a number of manual processes
are required to make service available through SERVER_3 in the event of a DR makes me suspect that Microsoft would deem this a non-supported configuration.
Any advice or opinion would be greatly appreciated.
Regards,
Dave