App Volumes multi-Data center design?

[VUTiger]

We are deploying Horizon View between two datacenters about 30miles apart.  They are interconnected with a dual 10Gb vpc link so our roundtrip latency is only 2ms.

As this is a greenfield install we are starting redundant across the board, two internal connection servers per site, 2 security servers with thier own connection servers per site.

We do not have vplex or stretched cluster but with load balancing and multi-site availability we can build it so everything stays up and users can connect to either datacenter and continue to work.

App Volumes is a newly added feature we are loving, however managing muli-site with this is interesting.  As of 2.5 we were planning on 2 app volume servers per site connection to external SQL DB and just deploying the app stacks in pairs between datacenters.

However in the new version (2.6) they add multi-vcenter support as well as storage groups.

We are trying to determine if 1 pair of app volumes with DB/host failover would suffice or if the multi-vcenter is targeted at internal site pods and ability to expand sites with multi-vcenters at one datacenter.

Anyone know or have some thoughts to weigh in on this? 

With one central app volumes and ability to add multi-vcenter to it and storage groups we could target app stacks to specific vcenters storage and attach accordingly (App-stack update and name it Primary-DC1 and do another update and call it Primary-DC2 and go from there from one central location)

Are we adding a single point of failure that requires a "manual Fail over" where cloud pod and active-active provide everything else to be online regardless of site failure.

Thanks for any help, ideas or insights!

[elgwhoppo]

Awesome, thanks man! Updated my post with option 1b:

[elgwhoppo]

So I just tested in the lab...the storage groups only replicate AppStacks, not writable volumes. Well that's a bummer. So that drawing I made is just completely wrong then.

[Ray_handels]

We are having the exact same issue and to be honest our setup looks quite like the both of you have now. As far as i know Appvolumes doesn't have a feature for syncing the writable volumes yet because they must not be attached to be able to sync um and there is no guaranteeing that.

We are still looking at a way to backup the writable volumes (because well, appstacks are static). We looked at VEEAM (can backup disks buit transfers them into Thcik disks), VMWare themselves for a soultion and are also looking at a fix with our storage vendor (TinTri). They have a functionality which is called syncVM. We asked (and urged) them to look into a feature called syncVMDK. This way we could sync the writable volume on a storage base which is much quicker than using a third party tool..

Any suggestions are appreciated though .

[iforbes]

Was anyone able to get any traction on easily replicating the writeable volumes between sites in a cloud pod architecture?

[nonsparker]

I would like to know this as well.

[Ray_handels]

Man this is a very old thread .

We were able to eventually copy the writbale volumes from 1 storage to another using a Windows server with NFS client and a very nifty script. There is a fling now for backing up writable volumes but to be honest i don't think that connecting to a VM to backup the writable volume is not the way to go for as far as Í think. We have almost 1000 writable volumes, if we need to backup those using an attach to a backup VM it will take ages to backup all info.

[elgwhoppo]

@Ray, have you tested the process of importing and re-assigning all the writable volumes into another AppVolumes instance? Pretty sure that would be a manual import and assignment for every single user, but I could be wrong.

[Ray_handels]

Yes we did. We have copied them from one store to another and just imported it. You don't need to assign it for every user. The assignment set for the writable volume is in the VMDK itself.