Several months ago I wrote a blog post on how VMware App Volumes can be deployed in a multi-site deployment. You can find the blog here.
With the release of App Volumes 2.10, for more information on the release see the information here, there has been a great improvement of the way App Volumes handles Storage replication. In this Blog I will explain how the new storage replication works and how to configure your storage groups to take advantage of this improved feature.
The main change that has happened when when looking at configuring storage groups and datastore’s is the ability to make datastore’s non-attaching. What does this mean, well basically a non-attaching datastore would be a place to create AppStacks but those AppStacks would never be attached to a desktop from this datastore.
The non-attached datastore would then be a member of a storage group or a number of storage groups. These storage groups would then replicate the AppStacks from the non-attached storage to all the other datastore’s with in the storage group.
Now how will this look when deploying App Volumes to multiple sites here is a high level architecture of how this could be deployed. As you can see from this diagram at least 1 vCenter from each site will need access to the non-attached datastore.
How to create the New Storage Group
First create the non attachable storage
With in the App Volumes Manager click on Infrastructure, Storage then select the storage to be non-attachable then click Make As Non Attachable.
Now create a Storage group
With in the App Volumes Manager click on Infrastructure, Storage Groups then click Create Storage Group
Give the storage Group a Name. Then select the required options. When choosing the datastore’s make sure to include the datastore’s that will be used to attach the AppStacks from as well as the non-attachable datastore. Click Create.
As you can see from the image below I have created 2 Storage Groups one for each site and the Non-Attached storage, NFS2, is included in each Storage Group.
Now all you need to do is create AppStacks on the non-attachable storage and they will automatically be copied to all the other datastores in the storage groups.
Hello,
I’ve just done this, and it worked nicely – I think you’ve missed an important step though.
Updating existing AppStacks will not work in this state as the Reference machine will attempt to mount it on the non-attachable storage for writing. For this to work, I had to mark it as attachable again, make my changes, make it non-attachable again, then press the Replicate Button to push it out to all of the other storage group members. Is this the right approach?
LikeLike
Personally I would create AppStacks using a separate datastore and then copy the AppStack to the non-attached datastore, this way you wouldn’t need to make and changes and the AppStack will sync to all datastores in the group.
LikeLike
@vDelboy. How are you copying the AppStacks from the template datastore over to the non-attached datastore? Simply going into datastore browser and performing a copy-paste?
LikeLike
Yes I would just do Copy and Paste from with in the datastore’s
LikeLike
If the non-attached datastore is part of a storage group that has auto-import, auto-replication turned on already, wouldn’t the appstacks in other datastore(s) just be imported/replicated to the non-attaching datastore anyways? Why do you need to copy manually?
LikeLike
Yes they should be, in that case there would be no need. It just depends on where you create the AppStacks and how you have your storage group configured
LikeLike
This is true, but remember my original point about the need to mark as attachable again in order to make updates. The manual copy is quite a phaff so looking forward to seeing the AppScaling import feature in action once AppVolumes 3.0 is released.
LikeLike
@vEFFORT – I’m not sure what you mean with respect to your last comment today “This is true, but remember my original point about the need to mark as attachable again in order to make updates…”
My “transfer storage” is marked as non-attachable. I simply include it into the storage group. The storage group will automatically import/replicate AppStacks into the “transfer storage”. My provisioning machine never uses the “transfer storage” at all – so there’s never any need to mount it. It’s job is simply shared storage between two sites to facilitate AppStacks being available at both sites.
LikeLiked by 1 person
Okay so you are talking about a storage area purely for the purposes of being a storage group replication source. Where do you managed your creations/updates to AppStacks from your reference machine?
LikeLike
When I need to create/update an AppStack my provisioning machine mounts a vmdk that resides in one of the “attached” datastores within the storage group. In the diagram above in this blog, that would be datastore 1, datastore 2 in SiteA
LikeLike
This is great and like you point and approach above vDelboy!
LikeLike
Can I use NFS or VMFS as non attached datastores and replicate it to Virtual SAN datastores when having 2 Horizon View pods using Virtual SAN?
LikeLike
Yes you can use either NFS or VMFS as the non attached storage
LikeLike
Hi. What about writeable volumes. Does this solution also replicate them across the sites? If not, how do we handle replicating writeable volumes across sites?
LikeLike
No this would only be for AppStacks. It is currently not supported for writable volumes.
LikeLike
Thanks. Quick question. I see that version 2.10 supports multi-vcenter. I’m just trying to understand what that means. In a cloud-pod architecture with seperate sites, each having their own vCenter, ESXi servers and storage does this mean that I can stand up an App Volumes Manager in site A, add both vCenters (one from each site) as Machine Managers and I will be able to deploy App Stacks to both sites?
This multi-vCenter support sounds more like if a single site has multiple vCenters and each vCenter shares the same datastores that a single App Volumes Manager would be able to manage the App Stacks for each site.
For the true cloud-pod architecture it sounds like your diagram above that depicts to disparate App Volume Managers (each pointing to their own database) each managing their own vCenter(s) and App Stacks. So, unless each of my sites have multiple vCenters then in a cloud pod design I don’t have to worry about multi-vCenter support? Is this correct?
LikeLike
Here is a post I wrote on multi site support http://blogs.vmware.com/consulting/2015/06/vmware-app-volumes-multi-vcenter-multi-site-deployments.html Hope this helps
LikeLike
Hi vDelboy. I’ve seen it 🙂 Unfortunately, it doesn’t answer my question. It doesn’t clarify if multi-vCenter support means a single App Vol Manager can support vCenter instances across sites, each with separate storage. It looks like multi-vCenter support means a single App Vol Manager can support multiple vCenter instances within the same site, with those vCenters being able to see the same storage.
I’m just trying to figure out if a true multi site View architecture needs separate instances of App Vol Manager installed at each site. I think it does, but haven’t gotten any clarity from “App Vol 2.10 now supports mutli-vCenter).
LikeLike
So yes you would need to deploy app volumes managers at each site, these can share a clustered database so you don’t have to manager separately
LikeLike
Thanks!
LikeLike
Appreciate your blog posst
LikeLike