App Volumes 2.10 and SQL Replication

[GoldTop]

I have a client scenario where we have 2 separate installs of App Volumes 2.10 in 2 sites with individual vCenters.  Appstacks will be replicated using storage groups but I was hoping to keep the assignment information in sync using SQL (2012 Standard Edition) replication.  I was looking for some guidance as to which specific tables will need to be replicated to achieve this.  From looking at them it seems I will need the below.

dbo.groups

dbo.org_units

snapvol*

I can't seem to find any official documentation for this from vmware or if it is even sensible to do this?  Wondered if anyone had thoughts around this.

Thanks!

[Ray_handels]

Yes, it isn't supported .

The thing is that it is much more than just these 2 tables. You also have to have the correct users in place and multiple more information.

You are trying to sync only assignments right?? Not trying to make an active backup for SQL??

[GoldTop]

Hi Ray,

Yes just trying to sync the assignments - there are 200 plus so don't want to have to keep these up to date manually.  If it's unsupported then client won't want to pursue that method.  That's a shame actually, would have been quite a nice way of doing it.

A one off job would do to start it off then could be updated manually as part of their capture process.

[Smoke14]

Why are you not creating a SQL Cluster (Always Active) across the two sites that way you can centrally AV manage your environment and you don't have to replicate anything when it comes to the database?

You will use Group sharing to replicate AppStack (vmdk) to your AV local storage.

[Ray_handels]

Hey Smoke,

I think that he is not setting up a backup but is actually using two different enviornments.

That being said, I do agree with you that it might just be easier to just create 1 enviornment.

[GoldTop]

Yes 2 separate environments.  Will look at option of deploying 1 and have a little read up of always on SQL groups but for that to fit would need to be able to tie specific storage groups to AV managers - is that going to be possible with a shared DB?  Actually that might be possible as the 2 respective vCenters can only see storage in their own site.

[Ray_handels]

I'm not quite sure if that will work because Appvolumes does need to see both storages so if you are to create 1 database with multiple AV managers (which is off course supported) these managers need to be able to access both datastores. Is it possible to add both datastores to both VCenters?

Do make sure if you do this to enable the setting "First mount volumes from a VMs local datastore when available." in the machine manager configuration tab. This will make sure that appstacks are attached from the same datastore as the machine resides on thus not having to many network traffic due to Appstacks being on a different datastores.

[GoldTop]

There is no local storage in play and it will not possible to put the appstacks on the same datastore as the View Desktop VMs.  

I can add both sets of datastores to both vCenters but the storage networks are isolated at present so will need to do some re configuration to make that happen.  Would need to avoid having any cross site attachments and don't think this setup would do that (with a shared DB)?

I can setup the 2nd site again with a reconfigured copy of the "production" DB - clean it up a bit and change the configuration then run them independently with a "swing datastore" volume and 2 storage groups to keep the appstacks in sync.  Assignments would have to be a manual process.

Not sure if v 3.0 might improve the situation when it is production ready!

[Smoke14]

You need to read through these to blogs.

https://vdelboysview.com/2015/11/30/vmware-app-volumes-storage-group-improvements-with-2-10/

VMware App Volumes™ with F5's Local Traffic Manager - VMware Consulting Blog - VMware Blogs

I have currently setup a two site (Active/Active) with AVM 2.10 installed in two separate vCenter. Just as the image in the first URL shows.

You only need one datastore that will span across all vCenters that will be set to un-attached is the AVM storage groups.

FYI, you will need one datastore for provisioning your AppStacks and then copy them over to the spanned un-attachable datastore or you will have to keep changing the status of the spanned datastore to attachable/un-attachable.

The most important part her is the SQL cluster (Spanned across all Sites) and the spanned datastore.

The second URL is for load balancing your AV infrastructure.

[GoldTop]

Thanks for that, appreciate the pointers.  I basically now have the setup as per the first URL bar the SQL cluster (current SQL server is housing multiple DBs so can't cluster it without some planning/discussions with various parties).

So for the moment have to have 2 separate DBs.  Long term I will look to get a cluster going but short term it looks like some manual steps to get the assignment information syncing.  Mirroring might be an option though.  Almost there - the rest of the DR solution is automated failover so would be nice to get this nice and slick too.