Veeam Availability Orchestrator v3 was a massive release that brought a great deal of features and functionality to this already awesome product, such as support for NetApp ONTAP Snapshots.
Today, I want to focus on one of the features that sometimes gets overlooked, the VAO v3 API. Since v1, VAO has had a Rest API that has been enhanced further with every release. The new features of VAO v3 have been seamlessly integrated into the Rest API.
Let’s take a closer look at the top three things you may have not realized you can do with the VAO API.
Use the Swagger UI to test automation features
Want to quickly test your API calls to make sure they’re working properly? VAO V3 has a Swagger UI you can find at https://your.fqdn.com:9898/swagger/ui/index. Please note that 9898 is the default port used by VAO during the installation process, so if you used a custom port, be sure to access it with that port number.
The Swagger UI is a great way to quickly test the API functionality you plan on using.
You can also use the Swagger UI to browse and get a better idea of how the VAO API works, or take a look at the VAO API documentation here.
You can use the API to preform operations on things like Recovery Locations, Site Scopes, and Orchestration Plans.
GET everything!
With the VAO API, you can get just about any property you can configure in the UI. This can be really helpful when you are integrating VAO into an existing management or monitoring tool in your environment.
This is especially helpful when you’re working with Orchestration Plans. While VAO generates dynamic, easy-to-use documentation, that documentation may not be helpful to the incident management system you have in your environment.
With the VAO API, you can get all the relevant information you may need for an Orchestration Plan, such as the VMs in the plan, the steps taken on each VM, and state information on the plan.
PUT and POST what you need, where you need it
You can also take things a step further with VAO.
While it’s simple to schedule Plan Executions from the VAO UI, you can also do this from the API in order to integrate with your existing processes using the PUT functionality of Plans. You can schedule Orchestration Plans to run at a specific time, or after another Orchestration Plan has been run.
Using POST functions, we can accomplish common VAO administrative tasks like Enabling/Disabling Plans, running readiness checks, and both running Failovers and Failbacks.
When it comes to VAO as a whole, Veeam has focused on features like the easy-to-use UI and RBAC in the form of Site Scopes to allow organizations to empower their application owners when it comes to creating and testing disaster recovery plans.
On the other hand, it’s important for a tool like VAO to seamlessly integrate with customer environments. That’s why with v3, the focus was the ability to GET and PUT just about everything.
Lifecycle of an Orchestration Plan, the API Way
After our application owners have created their Orchestration Plans, we can handle the rest of the lifecycle via the API.
We can start by finding out all the relevant information about our plan using the GET Plans API Call, and specify the ID of the specific plan we’re looking for more information on.
This is a great way for us to double check that our application owners have configured the plan with everything we know it needs.
{
"success": true,
"data": {
"$id": "1",
"id": "44d2e5d1-8758-4e8e-836c-3c2e50861a5a",
"planType": "Storage",
"recoveryLocationId": null,
"serverId": "d33afa61-263f-456c-aa05-bf2a33be4434",
"siteScopeId": "00105c6e-1998-45b3-a15f-efe0b097fdda",
"siteScopeName": "Admin Scope",
"name": "Site 2 NetApp ONTAP",
"state": "Unpublished",
"stateName": "Verified",
"stateOrder": "410. Verified",
"resultName": "Passed check",
"lastStableState": "Unpublished",
"lastStableStateName": "Verified",
"previousExecutionState": "Edit",
"reportTemplateId": "0939214c-0cbf-483d-be58-5c00534c85de",
"description": "",
"reportDocumentFormat": "Pdf",
"serverName": "TPM02-VAO3.AperatureLabs.biz",
"siteName": "Melissa Lab",
"scheduleInfo": null,
"nearestFailoverScheduleTime": null,
"scheduledTestsInfo": [],
"nearestTestScheduleTime": null,
"haltedReason": "Undefined",
"isEditingByCurrentUser": false,
"currentEditingUser": "",
"progress": 100,
"lastTestResult": "Undefined",
"lastTestTime": null,
"lastCheckResult": "Success",
"lastCheckTime": "2020-07-22T19:26:50.1045776Z",
"lastTestResultName": "Never",
"lastTestResultOrderNumber": 5,
"lastCheckResultName": "Passed",
"lastCheckResultOrderNumber": 4,
"virtualLabId": null,
"contactName": "",
"contactEmail": "",
"contactTel": "",
"isRunningState": false,
"isStableState": true,
"currentRunResult": "Undefined",
"currentTestResult": "Undefined",
"currentCheckResult": "Success",
"definitionReportStartTime": "2020-07-20T11:00:00Z",
"readinessCheckStartTime": "2020-07-20T12:00:00Z",
"targetRecoveryTimeObjective": 60,
"currentRecoveryTimeObjective": 4,
"targetRecoveryPointObjective": 1440,
"currentRecoveryPointObjective": 21,
"roles": [
"DRSiteAdmin"
]
}
}
We can find out quite a bit of information on our Plan by just performing a basic GET.
We know important information like the Orchestration Plan type, the Plan’s configured RPO and RTO, and if the last Readiness Check and Lab Tests were successful, if they were even run at all, and the current state of our plan. In this case, we can see that our application owner has not run a DataLab Test, so it may be a good time to reach out to them to find out why.
Beyond the basic information on our plan, we can also dive deeper with the additional GET functionality of our plans:
If the time comes to run an Orchestration Plan, you can also do that via the API using POST functionality.
When it’s time to run a failover, you can specify important parameters like the most recent restore point when restoring a VM replica, and whether or not to protect NetApp ONTAP volumes after failover.
We just talked about the top three things you can do with the VAO API; test your API calls and get a feel for how things work with the Swagger UI, GET any information you need about your VAO environment, and PUT/POST when it comes time to get ready for a successful failover.
Why this matters for disaster recovery
Now, let’s switch gears and recap the three ways why this is a big deal for VAO customers.
The Restful API allows for integration into existing systems in your environment. Whether it be a monitoring, management, or ticketing system, the VAO API is capable of providing all of the data you may need.
This can be a big part of integrating a disaster recovery tool into your environment.
If you’re not already leveraging APIs in your environment, keep in mind VAO has a simple and easy-to-use HTML5 interface that can be accessed from any device, and the API is there for you if you ever need it.
You can take a look at the full VAO v3 API reference here.
If you want to take a closer look for yourself, don’t miss the 30-day free trial of VAO.
