FSLogix: Building an On-Premise resilient storage solution (Part 1)

When it comes to storing FSLogix containers, the default option would be to a simple Windows SMB share. When it comes to improving the resiliency and availability of the FSLogix containers, the default options are:

1. Cloud Cache
2. Azure Storage

Cloud Cache is a built-in mechanism of the FSLogix agent. The simplest explanation for how it works is that when the agent locates the FSLogix container to mount, it locates the providers in the CCDLocations registry value, then COPIES the contents of the container to a Local Cache; subsequent writes to the profile are done directly on that Local Cache copy of the user profile first, and then performed to all the other providers in the CCDLocations list.

The upside of this approach is that it's a built-in solution that doesn't require other resources. The downside is a painful list of poor sign-on and sign-off performance, high IOPS, high network usage and that it will inevitably wreck havoc on a non-persistent Virtual Desktop's RAM-based Write Cache. The workaround for the last problem is to set the CacheDirectory and ProxyDirectory values on a separate, persistent disk dedicated to the VDI host.

Azure Storage, well, requires access to an Azure subscription. Skip the BYO SMB share option and go with the PaaS options like Azure Files or Azure NetApp Files. The latter can be optimized for VDI workloads, higher IOPS, better snapshot restores, and replication to other regions.

So what if you want to keep your containers on premises, in the same data centers as the ones that your VDI cluster resides in? What if you don't have an enterprise SAN like NetApp's with SnapMirror for bit-level replication, the options are limited.

Challenge

You have two data centers where subnets do not span, but geographically close enough that the latency between them is sub 10ms round trip. This is quite common in large healthcare systems and mid-sized financial institutes. They want a resilient and highly available storage solution for FSLogix containers, but they do not have an enterprise SAN with bit-level replication between the datacenters. They do not wish to introduce third party solutions and use whatever they are currently entitled to with their Microsoft licenses.

They evaluated other replication approaches like Robocopy (file-level replication) and even third party utilities like BVCKUP2 (bit-level replication) and Rsysc, and found that despite the improved performance of BVCKUP2, there is no seamless failover of a VDI session in case a storage host fails. The user is required to terminate their session and start a new sign-in to mount the container from the secondary site.

The company, for whatever reason, is not in a position to introduce another replication solution like Resilio Connect.

Solution

A Windows Failover Stretch Cluster with Replication. This series of articles are step-by-step guides to build out this solution. 

A stretch cluster is a Windows Failover Cluster that spans multiple subnets (data centers), where two nodes share one set of storage in the first data center and two nodes share another set of storage in the second data center.

The diagram below illustrates what we will be doing:

For this case example, the VDI environments are hosted by a couple of Nutanix clusters - one in each data center. We'll set up a couple of iSCSI target volumes in each Nutanix cluster.

Within each cluster, these iSCSI volumes are accessed by a couple of Windows Server 2019 servers as part of a failover cluster. The four total servers will make up part of the stretch cluster (FAILOVER-CNO.domain.lab). 

Due to the low latency connection between the data centers, we'll use Windows' built-in Asynchronous Storage Replication between the shared volumes.

What's Next?

The series will appear in multiple parts:

• Part 2: Create and mount an iSCSI storage group (Nutanix?)
• Part 3: Create a Windows Server 2019 Stretch Cluster
• Part 4: Add the File Server Role and Configure Cluster Site Awareness
• Part 5: Enable Storage Replication
• Part 6: Provision the FSLogix Share
• Part 7: Deduplication (Optional)