Veeam has a new tool in the fight for availability and it is called Veeam Availability Orchestrator (VAO). You have likely heard me mention it before. In it’s current state it is quite different then what it was when you may have see or heard about it before. It is not GA yet but I can talk about it.
What problem does it solve?
This is important to answer if in fact you will pay for it. Right?
You will be able to plan your DR failover, and test your plans. Generally DR tests fail at first. And sometimes when they fail and let DR test data into production they fail spectacularly and so that is to be avoided. So safe testing is key. Once you have your DR planned, and tested, you are now in a position to feel confident about your plans and that means you can survive. So yes, you can test safe with VAO.
Another problem is config drift, so that means when VMs are added or removed from your plan for example, and you don’t know about it. When that happens, sometimes it means your DR plan fails. That problem is solved with VAO too – by warning you when it happens.
Sometimes in DR tests or real recoveries a VM is recovered that is not properly running. This is solved in VAO with application tests, and yes, you can add in your own tests. Some of these tests are as simple as confirm Exchange is running by making sure a particular mailbox is present, but some are as complex as making sure a SharePoint farm is running. Veeam provides in VAO many different application test scripts.
Often people need to combine the virtualized DR test results and configuration with other plans. VAO provides the option to deliver history reports and config in PDF or DOCX which make combining much easier .
- It will orchestrate a recovery – meaning it will start VMs as they need to be started and not all at once. You can also practice this and tune it so that it all happens as quick as you need.
- You will be able to test applications during recovery to make sure they work – particularly good to do but also useful in a test as you are building your plans.
- Audit trail of who did what and when.
- Automatic config report produced (once per day) when a change happens. This helps as you will be alerted to those unexpected changes and can account for them before a real failover is required.
- You can edit your report template with your logo and your own info. This isn’t just about looking good as you can have contact names and phone number as well as any other info you think useful in a crisis.
What does it look like?
Here is some screenshots – this is a late build and the screens may not change by GA but they might too.
When the plan configuration changes, in the morning a report is produced and sent to the appropriate people. It is a report of the plan and its configuration. At the bottom is the what was changed by who.
This part of the report is still under development but you get the idea.
In this next screenshot you can see the steps that you can associate with a VM. These are subject to change as I know there are some new ones to be added shortly.
Any of these can be enabled, or disabled for use. But pretty cool stuff right – being able to do a decent application level of a test for Oracle or Exchange is pretty handy when you are building plans and doing failovers.
One very handy thing to note is that a number of those steps above are things I added. In 1.0 steps can be scripts created using PowerShell. They can be added easily to the list of steps we see above.
You use the + button and add a name and description and select your script. It can execute inside the recovering VM or on the VAO / Veeam server.
When you execute a test, or a failover you get a report. It has the results:
But it has a lot more info too. Like why I have a warning.
We can see a network error above. We have tried hard to have all of the errors in the execution report to help you understand what did not work and what you might need to do to solve it.
What else is there?
Aside from both DR testing and DR failover what are some things that VAO does that may be unexpected?
- Migrations to new datacenters – think about it – you can practice the migration, and make sure it works before you actually commit to the migration.
- Safe testing using production resources but outside of production with no chance of impacting production. These tests can be security vulnerability or patch testing. These are a very common activity that should be done within a safe and isolated environment – such as during a test failover! And testing a patch, on product bits is way different, and much better then testing in a lab.
- A VAO failover plan can trigger failover in other environments like AIX or HPUX through the use of scripts executed as part of the failover. This puts more things in one audit trail!
- You can include physical machines in your VAO recovery plan. Yes, that is true. Use something like VMware Converter to nightly convert the physical machine to vSphere. Then protect it in your plan. Test, confirm it works and now you have a protected physical machine – yes it recovers as virtual but that is better than not at all.
Is there something else to think about?
If you have an application that can protect itself that is better then using a tool like VAO to protect. So, for example, if you have a Application X environment with a Load Balancer out front, and it handles the failover when one component something fails, that will be faster and safer than using a tool to recovery.
A tool is about 20% of a BCDR solution, so it is good to work with people that understand that 20% and the other 80% which is about process and people. If possible work with a partner who knows BCDR AND VAO.
You will learn more over time about VAO from me. I think it is a super important tool and I hope you find it as useful as I do. BTW, don’t forget the words and pictures above are about a beta product that will change. I will update as necessary to keep this all correct.
Let me know if you have questions or comments,
=== END ===