Natestack
Enthusiast
Enthusiast

Writable Volumes Follow user on multiple Clusters ?

Jump to solution

Hi All,

Having a play with Writable Volumes.

Our setup
Appvolumes Version: 2.16
Windows 10 1709
UEM 9.7

Question I have is we currently have a STD desktop pool that is load balanced between 4 clusters.
I have found if we create a writable volume on Cluster 1, the user does not get the writable on another clusters without manually moving the writable volumes.

So given the user could be load balanced to any of the 4 clusters is there a way to have the writable follow the user when logging in?

Sorry if silly question.

Thanks, in advanced

0 Kudos
1 Solution

Accepted Solutions
Natestack
Enthusiast
Enthusiast

Cleaning up some old threads

ok issue we had was the backend storage could not talk with each other perms.

once we did this bam could have a writable on any datastore as the writable could talk with the VSAN

View solution in original post

0 Kudos
5 Replies
Ray_handels
Virtuoso
Virtuoso

If you make sure that you have 1 datastore that is available on all clusters you can use that specific datastore to store your writables. Writables are not build to be used on multiple datastores, you cannot replicate it to multiple datastores using Appvolumes, you can do this with Appstacks.

If you would like to do this (I would highly suggest NOT doing this) the only option you have is to use replicate from your storage vendor. This way you can use multiple Appvolumes managers to attach the writable on different storage locations. Thing is how do you make sure that the user always gets the latest writable? If your replicate or sync or whatever you use goes wrong, the user might lose information in his writable.

0 Kudos
Natestack
Enthusiast
Enthusiast

Awesome another thing appvolumes can’t do.

Surely VMware would know

if dealing with corporate clients that has several hundred or thousand users on a non persistent machines that applications don’t all store information in the users directory.

This is where a writable volume would come in handy.

that if we have STD pool over 4 clusters that we can’t use writables because  a user with a writable on cluster 1 logs in the next day on cluster 4 with no writable at all this is silly.

As you said Appstacks goes across datastores which is good doesn’t matter what datastor cluster the user logs into they will get applications but writables not.

honestly we want to use this application to solve issues and seems it can’t work unless you lock users to clusters

and if that cluster goes down we stuffed.

im tempted to just go back to physical at this point.

anyway rant over just disappointed in this technology sounds good but needs more work for corporate uses.

Thanks,

0 Kudos
Ray_handels
Virtuoso
Virtuoso

honestly we want to use this application to solve issues and seems it can’t work unless you lock users to clusters

and if that cluster goes down we stuffed.

First off, there's a place for everything in IT. We really like VDI and the way it works. I must say that we have a lot of users and just few VDI machines compared to amount of users (i believe a 1 on 20 ratio) due to part time employees and students. In regards to your remark above. If your user stores all his or her info on the local disk of the machine and the machine crashes he or she will also lose all data, it's just the way you look at it right?

That being said, I don't think you totally understand how Appvolumes works. Yes you can use it between multiple clusters, you can even use multiple vcenters with 1 Appvolumes environment. Thing is that a writable can only be stored at 1 location. This doesn't need to be a physical location on 1 specific disk. If you would have 1 datastores that you could attach to all clusters you can use that 1 single datastore to store all writable volumes. I really don't know it that is feasible or even doable for you, that's really up to you to decide.

We are now using multiple datastores that are attached to all servers within our environment so we can use writables all over the envrironment.

Same goes for Appstacks. As long as the datastores that hold the appstacks are capable of reaching each other within that 1 Appvolumes Manager you can replicate them. Hell you can even use 1 datastore to sync appstacks between datastores and set is as not attachable (so it's just a copy over the appstacks).

0 Kudos
macca2317
Contributor
Contributor

Would that be like an NFS data store?

For example I have 2 vCenters (8 clusters - 4 in each vCenter) and I use NFS storage that all clusters in both vCenters can access. However when I create a writeable volume is just stays as detached and does not work when creating it on the NFS storage.

The only information I can find in the VMware Documentation is:

pastedImage_1.png

Which is what we have setup and does not work on NFS.

Using a local vSAN datastore to a cluster works a treat but that datastore is local to that cluster which is why we are using NFS. Am I missing something?

0 Kudos
Natestack
Enthusiast
Enthusiast

Cleaning up some old threads

ok issue we had was the backend storage could not talk with each other perms.

once we did this bam could have a writable on any datastore as the writable could talk with the VSAN

View solution in original post

0 Kudos