ProfileUnity ProfileDisk and FlexApp both utilize VHDs to provide end users with their profiles and applications. Providing resilient failover for VHDs can prove tricky depending on your environment and configuration, but a great option can be to leverage the Continuous Availability (CA) functionality with a Scale-Out File Server (SOFS). This feature was designed to be able to provide automatic failover for Hyper-V virtual machines, so it is perfect for deploying virtual hard disks.
Benefits of SOFS with CA includes:
- Active-active failover, meaning that if a file server goes down your users will remain connected to their profiles and applications with zero downtime
- High bandwidth as every node participates in providing the share’s content, maximizing performance
- Anti-affinity; if SOFS is running multiple active file shares, these will be run on different nodes
It is worth noting here that SOFS is not supported for normal file share content. Workloads that have lots of small files that are written to continuously result in a large overhead for SOFS, so it is not recommended to utilize SOFS for ProfileUnity portability or Folder Redirection, ONLY for VHD storage (ProfileDisk, FlexApp and the VHD module).
For customers that don’t have shared storage for their file servers, you can still deliver SOFS and CA with Storage Spaces Direct (S2D). S2D leverages local storage, and as it is supported now on virtual machines as well as physical it opens a much wider range of deployment options for customers.
S2D and SOFS provide the following benefits:
- Utilize ReFS to provide accelerated VHDX operations
- Easy to scale
- Flexible deployment; S2D can run on physical or virtual hardware, hypervisors such as VMware ESXi and Public Clouds like Azure are supported: https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-in-vm
Note: You will need Datacenter licensing to allow you to use S2D
In this post we won’t attempt to cover every installation or deployment option available, as this is more of a centralized and general summary of SOFS and CA through either a normal Failover Cluster or S2D.
Documentation and full installation instructions can be found on the Microsoft docs site here:
https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster
Deployment commands are done utilizing PowerShell. Anything in italics should be replaced with the correct names or IP addresses that are specific to your environment.
Option 1:
Deploying SOFS and CA via a normal two node Failover Cluster (these instructions are for deploying on VMware ESXi):
1. Create 2 Windows 2016/2019 virtual machines with equal hardware (nodes are recommended to share identical hardware to ensure consistent user experience)
2. Install and enable the failover cluster and file server feature on each server:
- Install-WindowsFeature -Name FS-FileServer
- Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
3. Test to ensure the feature has installed correctly (can be done on either server):
- Test-Cluster –Node fileserver1, fileserver2
4. Create your cluster:
- New-Cluster –Name clustername –Node fileserver1, fileserver2 –StaticAddress 192.168.x.x -NoStorage
5. You should be able to confirm your Cluster exists by opening Failover Cluster Manager
6. Decide how you want to provide a witness to your cluster. In this example we will be using a disk witness, but a cloud or file share witness are also supported:
- https://docs.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness
- https://docs.microsoft.com/en-us/windows-server/failover-clustering/file-share-witness
7. Provision two LUNs/volumes from your shared storage and connect them to the virtual machines. One share to hold your data and another to act as a disk witness.
- For example, I provision a 500GB volume and a 3GB volume to my file servers, connecting them via the inbuilt iSCSI initiator in Windows
8. In Disk Management, bring your disks online, initialize (GPT) and format the disks with ReFS
9. You can confirm the disks are available for use by the Failover Cluster and their name with the following:
- Get-ClusterAvailableDisk
10. We now need to add the disks to the Cluster:
- Get-ClusterAvailableDisk | Add-ClusterDisk
11. In Failover Cluster Manager, navigate to Storage > Disks and you should find your disks are available. Confirm the name of your witness disk (it should be either Cluster Disk 1 or 2)
12. Time to make our witness disk the actual cluster witness:
- Set-ClusterQuorum -DiskWitness "Cluster Disk x"
- Check in Failover Cluster Manager to see that it has been assigned to Disk Witness in Quorum
13. Next, add the data disk to Cluster Shared Volumes:
- Add-ClusterSharedVolume -Name "Cluster Disk x"
- Check in Failover Cluster Manager to see that is has been assigned to Cluster Shared Volume
14. Time to deploy the SOFS role!
- Add-ClusterScaleOutFileServerRole -Name sofsname -Cluster yourclustername
- Check in Failover Cluster Manager > Roles to see your SOFS
15. Finally deploy your Share, personally this is easiest through Failover Cluster Manager itself. Navigate to Roles, right click your SOFS and select Add File Share
- For the profile select SMB Share – Applications (this is important as it will set CA)
- In Share Location your shared data disk should be automatically selected
- Set your Share Name
- Local path should look like C:\ClusterStorage\Volume1\Shares\sharename
- Remote path should look like \\sofsname\sharename
- In Other Settings you should see that Enable continuous availability has already been set
- Set your relevant permissions for who you want to have access to the share
- Create and you are finished. You should now be able to navigate to your new file share to host your ProfileDisks and FlexApps
Option 2:
Deploying SOFS and CA via S2D (these instructions are for deploying on VMware ESXi):
1. Create 2 or 3 virtual machines:
- Decide whether you want a 2-way or 3-way mirror. A 3-way mirror gives you more bandwidth and greater resiliency but increases your used storage.
- Only a maximum of 3 nodes are supported if S2D is running as a VM.
- A witness will be required for a 2-node deployment. A disk witness is not supported for S2D so the witness can be either a file share or cloud storage. This setup will be based on using 3 nodes, but here are the instructions for setting up a cloud or file share witness if you are deploying only 2 nodes:
- When creating on ESXi, ensure that the PVSCSI adapter has been selected for connecting your virtual hard disks. If performing a clean installation of Windows, you may need to mount the VMware tools windows.iso and import the storage adapter driver to complete the installation.
- A minimum of two virtual hard disks must be connect for use with S2D, with these disks being the same size. If you need to increase capacity in the future, simply add more virtual hard disks of the same size to each node.
- If you are using Windows 2019 you MUST ensure the latest updates have been applied. Vanilla Windows 2019 was not ratified for S2D and you will run into errors when enabling S2D if updates are not present.
2. On each VM that have the S2D disks, run the PowerShell command:
- Get-PhysicalDisk
- This will show the disks but may highlight a potential issue. If a serial number is not present, then S2D will fail to pick up these disks and the deployment will fail. This is most likely if you are running S2D inside VMware virtual machines. To fix this, add the following to your virtual machines’ .vmx configuration file:
- disk.EnableUUID = "TRUE"
- Re-running the Get-PhysicalDisk command after restarting your VM should now show the serial number for your disks
3. Rename the “roles_install.ps1.txt” file to just .ps1 and edit it to include your S2D server names. Run this to install the required roles. Note that this does not install the Failover Cluster Manager role in case you are using nodes without a GUI, so you will have to install this separately where you want to manage your nodes.
4. Rename the “disk_clean.ps1.txt” file to just ps.1 and edit it to include your S2D server names. Run this to clean and prep your disks for utilization by S2D. The available disks for each node should be returned.
5. Now to test to see if our nodes are ready for clustering:
- Test-Cluster –Node s2dnode1, s2dnode2, s2dnode3 –Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration"
- If you are running S2D as VMs with less than 4 virtual hard disks for each node, you will have a warning in the validation report. This can be safely ignored, as 2 disks are the supported minimum when utilizing virtual rather than physical nodes.
6. Create your cluster:
- New-Cluster –Name clustername –Node s2dnode1, s2dnode2, s2dnode3 –StaticAddress 192.168.x.x -NoStorage
7. Time to enable Storage Spaces Direct:
- Enable-ClusterStorageSpacesDirect
- Remember if you are running PowerShell from a remote PC/server for management purposes then you can amend this to apply to the Cluster using -CimSession, for example: Enable-ClusterStorageSpacesDirect –CimSession clustername
- If you check in Failover Cluster Manager you should be able to confirm under Storage > Pools that a Cluster Pool has been created with all of the disks on your nodes
8. Next is to create a Volume from your S2D Cluster Pool. Luckily Microsoft have a new-volume command that does a lot of the leg work when it comes to creating this for us:
- New-Volume -FriendlyName "yourvolumename" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size sizeyouwantGB
- Note: this will default to using a mirror for the volume, you can change this by following this documentation: https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/create-volumes
- Check in Failover Cluster Manager and you should now have Cluster Shared Volume formatted with CSVFS_ReFS for use by SOFS
9. If you are running S2D as VMs then there a couple of other settings Microsoft recommend changing (ignore if using physical nodes):
- Run this to disable automatic drive replacement:
- Get-storagesubsystem clus* | set-storagehealthsetting -name "System.Storage.PhysicalDisk.AutoReplace.Enabled" -value "False"
- Set the following regkey on each machine to increase the I/O timeout value to stop possible storage latency from messing with your cluster:
- HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\spaceport\\Parameters\\HwTimeout
- dword: 00007530
10. Time to deploy the SOFS role! (steps are the same here as with using a standard Failover Cluster as per option 1 above):
- Add-ClusterScaleOutFileServerRole -Name sofsname -Cluster yourclustername
- Check in Failover Cluster Manager > Roles to see your SOFS
11. Finally deploy your Share, personally this is easiest through Failover Cluster Manager itself. Navigate to Roles, right click your SOFS and select Add File Share
- For the profile select SMB Share – Applications (this is important as it will set CA)
- In Share Location your shared data disk should be automatically selected
- Set your Share Name
- Local path should look like C:\ClusterStorage\Volume1\Shares\sharename
- Remote path should look like \\sofsname\sharename
- In Other Settings you should see that Enable continuous availability has already been set
- Set your relevant permissions for who you want to have access to the share
- Create and you are finished. You should now be able to navigate to your new fileshare to host your ProfileDisks and FlexApps
Product: ProfileUnity
Product Version: 6.8.4 and above