As a member of the Veeam Vanguards here at VeeamON 2017 we got to spend a couple of hours with Michael White (@mwVme) who gave us an update on Veeam Availability Orchestrator – Veeams’ answer to orchestrating and automating fail-over to their replicated VMs. Michael certainly is a great choice when looking for someone to evangelize this product as he had a number of examples of DR situations he has either helped with, or orchestrated companies through – which had both good and bad outcomes! But back to topic – VAO was announced a while back, in fact, over a year ago Veeam announced their plans for VAO during their “Next big thing” event in April of 2016. Since then I’ve got to see the application move along through various beta stages and was pleasantly surprised to see how the product has matured as they gear up for their 1.0 release (no, I don’t know when that is).
For those not familiar with VAO let me give you a little bit of a breakdown. VAO is essentially a wrapper, or an engine that simply interacts with other Veeam products via API calls. Think Veeam ONE, Veeam Business View, and Veeam Backup & Replication all talking together to one centralized Disaster Recovery Orchestration machine. As far as the architecture there really isn’t anything special – it’s a web interface, with a SQL backend. As far as I know the only limitations associated with Veeam Availability Orchestrator are the fact that it is only supported within a VMware environment and that an Enterprise Plus license must be applied to the VBR instance VAO connects to.
So what does VAO do that VBR doesn’t?
Hearing the phrases like “testing our replicas” and “using the Virtual Labs” you might be wondering what exactly VAO does that VBR doesn’t. I mean, we have the SureReplica technology within VBR and it works great at testing whether or not we can recover so why would we need VAO? The answer here is really about the details. Sure, VAO doesn’t re-invent the wheel when it comes to DR testing – why would they force you to reconfigure all of those Virtual Labs again? They simply import them, along with a lot of information from VBR to use within VAO. That said though, VAO does much much more. From what I’ve seen we can basically break VAO down into three separate components.
Orchestration
VAO takes what you have already setup within VBR and allows you to automate and orchestrate around that. Meaning we already have replicated our VMs to a DR location, setup our fail-over plans and virtual labs, and completed configuration around re-iping and post fail-over scripts to handle our recovery. VAO takes all of this and adds flexibility into our recovery plans to execute and trigger pre and post fail-over scripts, along with per-VM testing scripts as well. At the moment we are limited to just PowerShell, however we may see more scripting languages supported come GA time. Essentially VAO gives us more flexibility in running and trigger external process during a fail-over even than what VBR provides on its’ own.
Automated DR Testing
VAO takes all of this fail-over orchestration and applies this to our testing environments as well. By giving use the ability to test, and test often we, as organizations can drastically increase our success rate when a true disaster occurs. Certainly virtualization has really impacted our ability to test DR plans, in a good way – but there are still a lot of challenges when it comes to performing a true test – VAO closes that gap even more.
Dynamic Documentation
Probably the biggest feature in my opinion of VAO is it’s ability to automatically and dynamically create Disaster Recovery documentation. DR documentation are often overlooked, and left sitting on some file server, stale and not updated at all. Environments today are under constant change, and when our production environments change so do our DR requirements. VAO does a good job at dynamically pulling in any new VMs added or older VMs removed and adjusting it’s documentation accordingly. In the end we are left with some nicely updated documentation and run books to reference when we the time comes that we need them.
All of this said though, to me the true value of VAO really is it’s ability to focus on the details. From what I’ve seen VAO does a great job at reporting any warnings, errors or failures as it applies to any DR test or fail-over event. Not just on its’ canned testing scripts (for instance connecting to a mailbox on a failed over exchange server), but on our custom built PowerShell scripts as well. Without this attention to detail a lot of assumptions and false positives can be “assumed” during a DR test – leaving us left with an inconsistent state during an actual fail-over event. VAO, in all of its reporting and messaging certainly provides a nice mechanism into the visibility of each and every VM, and each and every task associated with that VM inside of a fail-over plan.
We still don’t have a solid release date on VAO but in true Veeam fashion let me give you this estimate – “When its’ ready” 🙂
