It is pretty darn cool – I have been working on this pretty much since I started at Veeam and today it is GA. I assume it is available for sale too. Veeam Availability Orchestrator (VAO) is a DR orchestration tool. This means you can do a test failover of your apps, confirm they work and then shut them down. You get a nice report. Once it works, you can do a real failover and run your app from your DR site and this is of course the best test you can do and make sure that all works for when you are doing a crisis type failover.
One of the things I like about VAO is how it can let you know when you plans change. And that report has the info on what changed, by who, and when (example). I love how I can put all of the important stuff into a template for the reports. Not just a logo, but also phone numbers and names of people that are important to the DR process.
It is important to understand when you buy a DR orchestration tool, that one of the key things is being able to test. That is to make sure your apps will work when you bring them back to life on the DR site. But, a test failover can be used for doing patch testing and security vulnerability testing. Both of those are best done in production but who wants to risk production? When it is done in the test it is production but there is no risk to impacting production and users. Everything that happens inside a test is gone when the test is done.
I would like to share some things to think about when you are doing DR work.
- Practice hard. And do it often. Not only will that make a real failover work better, but you will learn more about your apps.
- Package your tier 1 apps so you can do a proper test, and failover, of just that one app. Often you don’t have a real DR outage in the whole datacenter, but rather a portion of it. So being able to failover just the tier 1 app is very handy! Supports better testing too.
- If you have, or can do, a business impact assessment, you are in a much better position for BCDR success. A BIA report identifies the important apps, and what they need to work, and who knows the most about them. Very useful stuff for BCDR orchestration work!
- Automated testing is useful, and use it to make sure a manual test is worth doing. But do manual tests, and use people to confirm the app is working that know the app!
I wrote more about things you should be aware of in BCDR work in this article. I apologize for the gate, but that is something I cannot control. The info in the paper is definitely worth dealing with the gate.
So this cool product does failovers, and test failovers. But what else does it do that I can show you?
Readiness checks – this is something that you can initiate that very quickly checks all of the elements in the recovery plan – thing like does a script have credentials, is there replica’s at the recovery side. I like these checks as they are very quick and very useful – and they do not make changes. Here is a sample report out of my lab. I say simple but I mean only one VM. Note all the extra text and logo. Cool.
Failover reports – this report is pretty important. It needs to have lots of details – for troubleshooting and tuning of your failover. Here is a sample. Very good details, and notice at the bottom how after the failover is complete, we actually protect the VMs so they are backed up. All automatically. There is a step in the recovery of the Mail VM that is called Test. If you look closer at that you will realize it is a script that is executing. All the info around the script is captured in the history report. So when you mess up, like I did with the wrong credentials once you can see the problem in the history report and it makes it quicker and easier to fix!
Credential store – The administrator user of VAO can have credentials in the credential store but yet allow users to use them. The users using them will not know the password, in fact cannot know the password, but can use the credentials – for example, to execute a script with.
Script support – you can import PowerShell scripts that can be used as plan steps. So they can be used as part of the VM recovery process. I have written two articles on these scripts, the simple, and the advanced. But these scripts be used for what you need – to test the special software that only you know about, or it can be something that reaches inside a VM and tweaks something – like TSNames.ora for example. You can configure them centrally and yet plan creators could tweak them if necessary.
You can see above in the image all of the possible steps that you can use with a VM or VMs during your plan configuration so that the recovering VM does what is necessary. You can use things like verify Exchange mailbox during test or real recovery and of course that will confirm that Exchange is actually running. The step above called Test is one I added that creates a text file inside the VM and records date and time inside the text file.
Log Bundle – VAO works with the VAO UI, Veeam Backup & Replication, and Veeam ONE. Plus it can talk to more than one Veeam Backup & Replication server. And yes, it talks to itself too. So that is a lot of log files you need to gather. So, we have helped.
You can see above that there is both an embedded Veeam Backup server and an external one. Yet, all logs can be gotten right here! Very useful if you need to talk to support.
BTW, here is a tag that will show you all the technical VAO article on my blog. Some good stuff is already there – such as working with scripts.
So I think that this is a good look at VAO. It works. Give it a try but make sure you don’t think about protecting virtual machines, but protect services! If you want to learn more you can check out the pretty good help, but also get a NFR right here.
- 3/4/18 – added the link to help and NFR. Also, here is an article that a friend wrote that is a nice overview.
As always, questions or comments are welcome.
=== END ===