- Storage Spaces Direct
- Windows Volume Mgmt.
- Windows File Systems
- Volume Shadowcopy Services
- Storage Replica
Storage Replica is a software implementation of volume replication technology, new with Windows 2016, that is designed for disaster recovery. It protects against hardware failure by exactly duplicating a volume block by block, and will also protect against site failure if it is used on stretched clusters that span two sites. Like any other replication technology, Storage Replica does not eliminate the need to take backups, as data corruption or user errors would be replicated. If you are not familiar with replication technology then maybe we should spell that out. Replication keeps two copies of a disk in exact synchronisation. So, if you rely on replication for backups and you accidentally format and wipe a volume, Storage Replica will oblige and format and wipe the replica too and you will have lost all your data. No backup, no data, lost forever. Take backups!
Storage Replica is also not intended to provide a second copy of data that can be updated, either locally or at a remote site as that would not be a valid disaster recovery copy.
While there are many hardware replication solutions on the market, they all require the same type of hardware at both sides. Because Storage Replica is a software implementation, it is storage-agnostic and supports unlike hardware.
Storage Replica supports both synchronous and asynchronous replication
When an application writes data out to storage, it waits until it gets confirmation that the write succeeded before it continues processing. With synchronous replication, the applicaton waits until it gets write confirmation from both the local and the remote site. If you want to provide zero data loss disaster recovery, your second disk needs to be several kilometers away from the primary disk, so to prevent the replication from affecting application performance, you need to use fast networks and fast disk subsystems. So why would you want to use synchronous replication? Well if you are working on financial systems like a bank, it should be obvious that it is essential that no financial transaction data be lost in a disaster. What about an airline booking site? Imagine the fuss if you had a disaster and lost 12 hours worth of bookings, so your customers have paid for their flights, but you have no record of them.
One of the features of replication is that the destination volume is not accessible while replicating. I've seen people complain about this on blogs, but for one thing, data is replicated at block level, so if you could update at file level, you would corrupt the data. For another thing, this data is for disaster recovery. If you start updating the target disk, then it is no longer a valid DR copy. The destination volume will be dismounted when replication is configured, and while it is possible that its drive letter may be visible in Explorer, you will not be able to access the volume itself.
Asynchronous replication simply means that the application will consider a write is complete when the data is safely stored on the source disks. Data is then written out to the remote disks later, without slowing down the application. This is quite adequate for many applications and is usually cheaper to implement than synchronous replication. Some implementations use snapshots for asynchronous replication, but Storage Replica implements asynchronous exactly like sychronous replication, without the need to acknowledge the write at the destination disk. There is no guarantee that both sites have identical copies of the data at the time of a failure, but it will work over slower networks and longer distances than synchronous replication.
I've mentioned a few terms above without really explaining what they mean.
With Windows Server 2016 Datacenter Edition, you can deploy storage replication in a stretch cluster, between cluster-to-cluster, and in server-to-server configurations.
If you want to test DR, or do site maintenance then you can switch the replication direction, so your DR site becomes the primary. However you must wait until the initial sync is complete before trying this.
Storage Replica uses consistency groups, where volumes can be grouped together and managed as an entity. For example, if you are replicating SQL databases that span multiple volumes, then it is essential that the replicated writes are sent out in the same order, otherwise the replicated database could be corrupt if a disaster happens. If the relevant volumes are in a consistency group, then Replica will write out the data to the destination server in the correct order.
You can configure Storage Replica using PowerShell commands or with the Windows Admin Center interface. This page describes the Windows Admin Center method and to use this, you will need to download and install Windows Admin Center and Remote Server Administration Tools on your PC. You also need to do quite a bit of preparation work as follows:
Provide two servers, preferrably in two different physical locations. If you are planing to use synchronous replication, then your 2 sites must be close enought for your network to provide an average of 5ms round trip latency. Each server should have at least 4GB RAM and need to be Domain Members n the same Active Directory forest. Install Windows Server 2016 Datacenter on both server nodes. It has to be the Datacenter edition, no other Windows variants will do.
To install Storage Replica
Navigate to Server Manager
Select one of the servers.
Navigate to Roles & Features.
Select Features > Storage Replica, and then click Install.
Your storage can be SAS JBODs, fibre channel SAN, iSCSI target, or local SCSI/SATA, but should be a mix of HDD and SSD media. You need two sets of storage, one for each side, and each server must only be able to see the storage on its own site, no sharing. The physical storage must have identical sector sizes. Remember, the volume that contains the Windows Operating System cannot be replicated.
Configure the storage at each site into at least two volumes, one for data and one for the logs. The log volumes should be configured from SSD media and need to be sized to at least 9GB, and identically sized at each site. Both Log and Data volumes must be initialized as GPT, not MBR.
The two servers need a minimum of one ethernet/TCP connection on each server for synchronous replication, but Remote Direct Memory Access (RDMA) would be better. For synchronous replication, the bandwidth must be enough to maintain your I/O write workload with about a 5ms latency. You also need to configure your firewall to allow bi-directional communication between the servers. Ports 455 (SMB), 5445 (SMB Direct) and 5985 (WS-MAN) could be required, but check with Microsoft for the current list.
Now you have all your hardware and software in place you can configure server-to-server replication
From the Windows Admin Center
Add the source server.
Select the 'Add' button.
Select 'Add server connection'.
Add in the Server Name, then select Submit.
Now, on the 'All Connections' page, select the source server.
Select 'Storage Replica' from 'Tools' panel.
Select 'New' to create a new partnership.
Provide the details of the partnership
The Source Server Name, RGname, Data Volume Name, Log Volume Name.
The Destination Server Name, RGname, Data Volume Name, Log Volume Name.
and when all the partner data is entered, hit 'Create'.