Workspace One HA/DR

[antherITguy]

What's everyone doing for HA/DR for their on-prem environments?  I don't see any specific recommendations from VMware other than you should have a DR plan in place.  Our DB is already part of an Always On SQL group, just unsure about the procedure to stand-up the Console/DS servers in an event.

[LukeDC]

As long as your SQL database is available offsite and the rest of your infrastructure (Load balancer, firewall, etc) is also HA you should be ok. Just have the same pieces offsite and setup the Load balancers to only shoot people over there in the event (loss of service, disaster, whatever). You can have multiple DS, Console, ACC, etc. They all depend on a load balancer scheme to provide service.
Only caveat to understand is the ACC creates it's own cluster and is not load balanced by a load balancer, so the offsite ACC could be ready but disabled if you don't want traffic over there.
If you use SEG clustering, also keep that in mind.

[LukeDC]

Oh and the device scheduler service can only be running in one place at a time, so you'd have to keep that in mind as well.

[antherITguy]

So I could essentially clone my existing Console/DS servers, stand them up in an alternate site and give them new names.  Just make sure the device scheduler service is stopped?  How would upgrades work?

[LukeDC]

You just have to treat them as part of the family and upgrade them the same. Those parts are just application servers and they do nothing much on their own and really the only data you need depend on is in SQL. As long as they are in the load balance scheme you'll be good to go. A true DR would be a totally different WS1 instance and in that case you would have to enroll devices into the new system in case of a disaster. Not the best solution since it requires so much work to get back up and running.

[ChrisHuhnChrisH]

Is the device scheduler service the only one to be stopped on the 'at the ready' DS?

[LukeDC]

All the rest can stay running, the scheduler will stop itself if it detects another instance running on another server.

[ChrisHuhnChrisH]

Thanks, that is useful to know.
I incorrectly stated DS as the location for the device scheduler service - it's on the Console.

[MikeSimms]

Chris
The Device Scheduler service writes a flag in to the DB when it starts up, on the DR server the Device Scheduler service will start up and read the DB, when it finds the flag already set it will then stop its self.
We have a primary site and a DR site, with the DR site SQL DB in RO mode.  WE copy the transaction logs to a flat file on the primary and then copy the flat file to the DR site, they are then held for 4 hours before being merged into the DR DB, this 4 hours gives us time to recover if a major corruption happens in the production DB.  To fail over we stop the Device Services service on the primary, stop the log shipping on the primary DB, commit the changes to DR DB, start the Device Services service on the DR CS and then change our DNS to point to the DR site. So geographic DR on to totally separate hardware.
Mike

[ChrisHuhnChrisH]

Mike S.,
Our SQL team wants to manage the database Transactions from PR to DR. I like your 4 Hour delay, that is an excellent idea.
Thanks for that hint.