VMware App Volumes Storage Group Improvements with 2.10

~ vDelboy

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.

Picture8

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.

Picture9

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.

Picture3

Now create a Storage group

With in the App Volumes Manager click on Infrastructure, Storage Groups then click Create Storage Group

Picture4

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.

Picture5

 

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.

Picture10

 

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.

23 thoughts on “VMware App Volumes Storage Group Improvements with 2.10”

  1. Pingback: VMware EUC a Year in Review | vDelboy'sView
  2. Pingback: App Volumes Performance and Scalability Testing – Reference Architecture Has Been Published! - VMware End-User Computing Blog - VMware Blogs

  3. 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?

    Like

    Reply

    1. 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.

      Like

      Reply

      1. @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?

        Like

      3. 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?

        Like

      4. 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

        Like

      5. 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.

        Like

    2. @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.

      Liked by 1 person

      Reply

      1. 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?

        Like

    3. 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

      Like

      Reply

  5. 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?

    Like

    Reply

  6. 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?

    Like

    Reply

  7. 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?

    Like

    Reply

      1. 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).

        Like

      2. 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

        Like

Leave a comment