Hyper-V and Storage Replicas (Part 2)

If you would like to read the other parts in this article series please go to:

Hyper-V and Storage Replicas (Part 1)

In my previous article in this series, I talked at a high level about Storage Spaces Direct and about storage replication. In this article, I want to continue the discussion by showing you how Storage Spaces Direct works. In doing so, I will walk you through the process of performing server to server replication.

The first step in enabling storage replication is to install the required components. To do so, open the Server Manager and choose the Add Roles and Features command from the Manage menu. You will need to install the File Server role and the Storage Services role. Both of these roles are a part of the File and ISCSI Services role, as shown below.

You must install the File Server and Storage Services roles.

In addition, you will also need to install the Storage Replica feature. Upon selecting this feature for installation, the wizard will indicate that you also need to install the Storage Replica Module for Windows PowerShell. Click the Add Features button to install this feature. You can see the Storage Replica feature in the figure below.

You will need to install the Storage Replica feature.

For the sake of demonstration, I have set up two virtual machines, each of which is running Windows Server 2016. Both machines are equipped with three virtual hard disks – a system disk, a data disk, and a disk that can be used for the change logs. The disks are identical from one VM to the next.

In a production environment, you would also need to make sure that you have high speed connectivity between the two servers (at least 1 gigabit), and that your firewalls allow ICMP and SMB traffic. In my case, both VMs are also joined to a domain.

The first step in the configuration process is to define our log volumes and our data volumes on both the source and the destination server. Remember, the log volumes must have the same capacity and sector size on both servers. The same is also true of the data volume.

In a production environment, you would probably want to use Windows Storage Spaces to set up RAID arrays for the data volume, and you would generally want to place the logs onto a solid state disk. In my case, both servers are virtual, so the underlying storage is all of the same type. Hence, I won’t be creating any fancy array structures. I do however, need to define some volumes.

In my case, I began the configuration process by launching the Disk Management console by entering the DiskMgmt.MSC command at the run prompt. If you look at the figure below, you can see that each server contains a system disk (C:) and a DVD drive (E:). There are also two 100 GB disks on each server that are currently offline. Hence, the first step in the configuration process is to bring these disks online. This is done by right clicking on the disk (in the area of the interface that says Disk1 or Disk2) and then choosing the Online command from the shortcut menu. Do this for each offline disk on both servers.

This is the system’s initial state.

After bringing the disks online, the console will show the disks as being online, but not initialized. To initialize the disks, right click on the disks as you did before, and then choose the Initialize Disk command from the shortcut menu. Again, repeat the process for each non-initialized disk. I am initializing my disks as GPT.

Once the disks have been initialized, the disk space (the area shown in black in the figure above) will be reported as unallocated. As such, we are going to need to create some storage volumes. Right click on the unallocated space, and choose the New Simple Volume option from the resulting shortcut menu, as shown in the figure below.

Create a new simple volume on the unallocated space.

At this point, the New Simple Volume Wizard will appear. Click Next to bypass the wizard’s Welcome screen. When you do, you will see a screen asking you to specify the volume size. For our purposes, just go with the defaults. It is a good idea however, to document the value so that you can make sure to use an identical volume size on the replica server. In my case, the volume size is 102270 MB.

Click Next, and you will be asked to choose a drive letter for the disk. Technically, you can use any drive letter that you want, so long as the drive letter is not already in use. Even so, I recommend being consistent with your drive letters, because doing so will make your systems easier to manage. For the purposes of this article series, I am going to use the drive letter D: to represent the data drive, and I will use the drive letter L: as the drive letter for the log drive.

Upon selecting your drive letter, click Next and you will be prompted to specify the file system and allocation size. Again, the defaults are fine for demonstration purposes. The important thing is to be consistent across both systems. Click Next, followed by Finish, and the disk will be prepared. You can see the outcome in the figure below. If your console does not display the expected results, try refreshing the console.

All of the disks have been prepared.

As previously mentioned, I decided to use D: as my Data drive and L: as my log drive. But what if one of those drive letters had been in use? One option would be to remap the existing drive letter. You can do that by right clicking on the volume and choosing the Change Drive Letter and Paths option from the shortcut menu, as shown below. Keep in mind that changing a drive letter can cause applications to break if those applications are expecting to find resources on a specific drive.

You can change a volume’s drive letter by right clicking on the volume and choosing the Change Drive Letter and Paths option.

Another thing that you can do is to change the volume name. To do so, right click on a volume and select the Properties command from the shortcut menu. When the Volume Properties sheet appears, go to the General tab and enter the desired volume name, as shown in the figure below.