I have been testing Windows Storage Replica cluster (available in the upcoming Windows 10 Server) on VMware recently for the purposes of testing geographically dispersed windows failover clusters without depending on shared SAN disk .
I created a two node Windows failover cluster with the following configuration. Both VM’s are running in two separate datacenters with stretched VLANS, plus a windows fileshare witness is used for quorum located in a third witness site. Both sites are using separate vCenter servers.
- ESXi 5.5 update 2
- Guest OS – Set to Windows Server 2012
- Production Network using VMXNET3
- Cluster Heartbeat Network using E1000 – Separate physical network with no l3 routing
- 1x LSI Logic SAS SCSI controller for guest OS VMDK
- 1x thin provisioned VMDK for OS
- 1x LSI Logic SAS SCSI controller for Storage Replica with Physical Bus sharing enabled.
- 1x 40GB Eager Zero Thick VMDK Configured for Storage Replica Data
- 1x 10GB Eager Zero Thick VMDK Configured for Log
One problem that I discovered, was that the virtualized SCSI controller must be set to physical bus sharing mode as storage replica uses SCSI3 persistant reservations to lock access to the disk on each node, even though replication happens in-guest using SMB3. If SCSI bus sharing is not enabled, you will not be able to import the disks into cluster manager and therefore not be able to enable storage replica.
Note: If you have problemscreating an eager zero thick VMDK, enable fault tolerance on the VM. It will inflate the disks automatically for you.
If the disk configuration is configured correctly as above, you should then be able to successfully import the disks to windows failover cluster manager, and configure storage replica between the data VMDK’s. (40GB in the below screenshot)The 10GB VMDK’s are used for storage replica log.
To set the actual storage replica cluster up, I recommend following the excellent storage replica guide created by the Windows storage team located below http://go.microsoft.com/fwlink/?LinkID=514902
One thing I noticed was that the SOURCE replica disk must be a member of a cluster role before replication can be enabled, or Cluster Shared volumes must be enabled on the disk.
Once the replica is configured, you will notice the “replication role” in failover cluster manager becomes active. This specifies which disks are replication source and destination
Initial testing looks good, task manager was showing 1.6Gb/s a second network throughput while the initial sync was run.
One other issue I discovered was I was unable to reverse replication by failing over the CSV from one node to another, however using the new “Set-SRpartnership” powershell cmdlets to reverse replication worked fine. This should be fixed in a later beta of Windows server
I see some really good use cases for Storage Replica in the future, one example would be for SQL Server clustering. Now, SQL clustering without shared SAN requires database replication using always on availability groups which are only available at a high cost with the enterprise edition of SQL server.
SQL Standard edition still supports clustering, but only with shared disk. So with storage replica, you could potentially create SQL failover clusters using the cheaper SQL standard edition and place the databases on storage replica volumes instead of using database replication. SQL 2014 standard also supports cluster shared volumes which would add a few more good improvements when paired with storage replica.