If you are familiar with the Horizon Stack from VMware, you will find one of the strategy is to enable cross datacenter, Active/Active or BCP solution for End user computing environment e.g. VDI. While Cloud Pod Architecture is one key feature in Horizon View for supporting the cross datacenter access, we have to be careful on designing other top up solution to ensure a true cross datacenter VDI environment.

In one of the case recently I’ve worked in, Replicating App Volume App Stack becoming a challenge to me. I would explain the problem and the solution accordingly, but let me introduce a bit about the background and requirement of the VDI infrastructure needed by my customer.

Background

My customer is wishing to deploy an Duel Site VDI environment. Where primarily they would like their endusers connecting to one of their VDI datacenter and in case of issue, they can be redirected to the DR datacenter for getting the BCP workstations. So the required behaviour should be as following:

Normal Scenario – VDI end users should go to Production Environment and DR VDI environment being marked down in the Global Load Balancer

DR Scenario – Enable the DR environment and users are all pointed to the BCP VDI machine

So, to clarify, the above Architecture comprise of Two Separate Horizon View Instances but NOT a truly Active/Active VDI environment which leverage Cloud Pod Architecture in Horizon View. This is for fulfilling the BCP control requirement and also Dedicated VDI Pool Environment Across Site.

Problem

Actually the VDI Architecture is fine and user is satisfying with the performance and behaviour a lot, but later the day, they have embraced App Volume for performing the Application Virtualization. And those we have to setup Architecture for replicating the App Volume App Stacks Across two datacenters. Well, if you have luxury Active Active Storage, that’s nothing. And if you have Joint App Volume Manager across site, it would be nothing too as you can use storage group to replicate the AppStack Across two Sites. For the detail you can refer to the WhitePaper HERE

As mentioned, usually the following true Active/Active Deployment is a best approach. As you only keep one copy of configuration, including AppStack assignment. But we have to employ a “Clustered SQL Database” across site, to be particular Always-On would be the solution.

Yet, the point is, my customer do NOT have Always-On Architecture in their environment and this is why we have to setup separated SQL Database instances between Site. And we need to keep two copies of configuration. Yes, Manual Sync of certain configuration is expected. But the point is how can we sync the App Stack Across two sites

To synchronize the AppStacks between two App Volume Managers, actually we can just copy the AppStack VMDKs across the datacenter. Well… but is it really “Just” a copying task? For vSAN, the answer is negative, you cannot directly do a SCP across two vSAN Datastores. We need some steps as mentioned in the VMware Blog HERE. This is because of the fact that vSAN Datastore is Object Based Storage where the VMDK hierarchy is different from the traditional storage.

Solution

Thus, as a solution for the vSAN replication. We have to again leverage the Storage Group feature of the App Volume. Following diagram you can refer to what we wanna achieve:

In Site 1) we will setup a Storage Group #1 which includes vSAN Datastore and Another Traditional Storage (Either NFS/iSCSI/FC). And in Site 2) we have another Storage Group #2 which includes the vSAN Datastore from the DR site and the same Traditional Datastore we use in the Production Site. The point for doing so is because of the characteristic of vSAN to vSAN copying, we have to use a staging intermediate traditional datastore. And for simplicity, I use an NFS for sharing across two Sites.

So in the Production Site, we setup the Storage Group #1

We Include the Datastores vSAN and the staging NFS such that every new created appstacks would be sync across the two datastore

Do noted that the NFS Storage should be configured as not “Attachable”, this is because we want to have vSAN Datastore presenting the App Stack for performance purpose. But NFS is just acting as the Staging Storage and Not for Performance purpose.

In the DR site App Volume Manager, we need to create another Storage Group #2, which again includes the DR vSAN datastore and the staging NFS share.

Do remember to check the two check boxes “Automatically Import AppStacks” and “Automatically Replicate AppStacks”. This is very critical as the DR App Volume Manager do not have information about the App Stack, and this is why the “Import” action helps adding the App Stacks with the existing VMDK from the Production Site.

The App Stack added will have NO assignment, as again the DR App Volume Manager do NOT know what the assignment is in the Production App Volume Manager. So, we needed add again the assignment in the DR one to ensure the correct applications are granted to the appropriate users

Result

So, finally, no matter the End User is logging into the Production or DR site, they will have the same user experience. Yet as the replication across site is schedule based and if you would like to push the update across site, you can manual trigger replication at Storage Group view.

While Appvol01 is the Production Site, Appvol11 is the BCP environment and both see the same Firefox App Vol.