TL;DR – If you want to get straight to the API part, skip in down to the section “Zerto Migration Orchestration and REST APIs”.
This is the third and final post sponsored by Zerto, and if you are averse to me getting paid for this,
who the heck do you think you are? I encourage you to read the first paragraph of Zerto’s Continuous Data Protection for Kubernetes, Part 1: What is It? where I address that very topic.
In fact, read the whole thing. . . . I’ll wait . . . .
. . . WELCOME BACK!
This time we are looking at Zerto’s features available for migration and there’s a (sort of related?) side bonus near the end, where we inspect the Zerto REST API.
Zerto specializes in storage protection and replication, but with the added ability to protect (or migrate) up to the application layer. Their claim to fame is location/platform/storage agnostic DR, backups, synchronization, migrations, and archival.
Before We Begin: A Disclaimer About the Content Here
The content here is combining my experiences with the content from the excellent ZertoCON 2021 presentation Dispelling Ghosts of Migrations Past, by Steve Blow at Zerto. As far as I know, you can still register for this event and access the on-demand recordings. I highly recommend them!
Considerations for Migration in General
Before we dive in, migrations are not something we’ve really tackled here on TOC, so, if you are unfamiliar with what you must consider, let’s talk about what you’d need to consider for migrations of all types.
- Licensing: Long term vs. short term migrations? Are you doing this as a one-time phenomenon, or is it long term where you are doing migrations all the time.
- Lift and Shift? Lift and shift, meaning that you are migrating the application with few to no changes, has gotten a bad rap in the industry. It is still a thing, and happens all the time, but I would recommend, as would most others, to consider re-factoring the application if you have the time.
- Source/Destination Considerations: I know this may seem obvious, but to what extent will you do this across . . . (buzzword alert) . . . multiple clouds, and so on? You would not just be doing a migration, you’d be doing a conversion (a vSphere VM to EC2 instance, for example).
- Related Resources: What about VMs/Pods (WHATEVER!) that are related and need to be migrated together? The idea of VPG’s are also available in Zerto for Kubernetes, which, I wrote about!
- Testing Before “Flipping the Switch”: Can we test and validate the applications on the destination side first before we consider the migration complete and flip the switch, as it were? Furthermore, minimize downtime while the switch happens.
- Side-by-side and Rollback Options: Can we do side-by-side and rollback easily?
- IP Address Changes: Most likely, there will need to be IP changes, how do we deal with that?
- Moving the Data: Synchronization in the backgound vs. other methods. If you have to move 12TB of data related to an application, you don’t typically have the ability to have the application associated with it down for the days (weeks?) it might take to replicate that data. Can we also throttle it?
- Monitoring and Alerting: What if you want to know if a Migration is unsuccessful while you sleep?
- Automation: To what extent can all the above be automated, from migration initiation on down to IP address changes, on down to testing, on down to automated rollbacks?
That’s a lot right? But, as you may have guessed by now, the cheesy “always be closing” line here is that Zerto has already considered these things for you.
Haha! Where did you think this blog post was going?
But I must admit, what’s the point of all this? You think Zerto is the only product out there that does at least some of what’s listed above? Of course not. But while attending ZertoCON 2021, what struck a chord with me is the whole idea of Data Protection as Code, so assuming we have grasped the considerations, how can we automate all of this?
Zerto Migration Orchestration and REST APIs
As far as migrations go, the more integrated the platform the better, even if you have to code it. It’s much easier if there is a solution that makes all of the above listed stuff happen automatically and/or in the background.
As an IaC Engineer (man that sounds pretentious, but I’ll roll with it), I want to take this into the direction of inspecting what’s available through the Zerto API.
Why? My first and last question I have for every vendor is “can this happen while I sleep?” I don’t want to babysit it; I want it to happen in the background automatically.
So I cracked open the lab “Automating Zerto 8.5 with REST APIs” on the MyZerto site. It’s free and it’s repeatable.
They use powershell in that example, which is a perfectly valid method for manipulating the Zerto API, but it’s not the best method for what I would call “Visualizing the API” . . .
** JAZZ HANDS **
For that, we’re going to use Postman.
“Visualizing the API” . . . ** JAZZ HANDS ** . . . is relevant because this is always a good start for automating anything. This is the first thing I do if I have to go toe-to-toe with an API. Knowing the uri resources that can be manipulated is Job #1 for you as an automator so you can create your own workflows on how actions are automated. Besides, connecting successfully to the API is sometimes half the battle, depending on auth method, and so on.
I realize what I am doing here is “tip of the iceberg”, but it will give you an idea on how to automate with Zerto if you are even nominally api-adept.
Connecting to Zerto’s API with Postman
First we’re going to get the Session token for use with ensuing connections. There are ways of coding this out in Powershell (or whatever) so it’s seamless and so on, but here we are going to do the session token
POST request and the ensuing
GET request separately.
Open Postman and create a new request.
Select the Authorization tab and select Basic Auth. Enter the Username and Password for your Zerto site:
This will be a
https://zerto_ip:9669/v1/session/add (where zerto_ip is your Zerto management server).
Make sure you have the Postman console open, and what should be returned there is a
Status 200 message with a field called x-zerto-session with a key as its value. I blurred it here out of an abundance of caution, but the token does expire after 30 minutes if you don’t use it. You’ll need that info:
Open a new Request in Postman, change the request to
GET, change the request url to
https://zerto_ip:9669/v1/ and alter the Authorization to API Key. Change the following:
Value: The value above under the red arrow.
Clicking Send, now you should have you a list of all possible objects that can be manipulated in Zerto. I will list them here without the data for ease of reading (and blurring the IPs would be, like, a lot of work):
"https://zerto_ip:9669/v1/events" "https://zerto_ip:9669/v1/vpgs" "https://zerto_ip:9669/v1/vms" "https://zerto_ip:9669/v1/vras" "https://zerto_ip:9669/v1/peersites" "https://zerto_ip:9669/v1/session" "https://zerto_ip:9669/v1/tasks" "https://zerto_ip:9669/v1/serviceprofiles" "https://zerto_ip:9669/v1/virtualizationsites" "https://zerto_ip:9669/v1/zorgs" "https://zerto_ip:9669/v1/localsite" "https://zerto_ip:9669/v1/flra" "https://zerto_ip:9669/v1/alerts" "https://zerto_ip:9669/v1/vpgSettings" "https://zerto_ip:9669/v1/downloads" "https://zerto_ip:9669/v1/license" "https://zerto_ip:9669/v1/zsspsessions" "https://zerto_ip:9669/v1/reports/resources" "https://zerto_ip:9669/v1/reports/recovery" "https://zerto_ip:9669/v1/datastores" "https://zerto_ip:9669/v1/volumes" "https://zerto_ip:9669/v1/GuestOSCredentials" "https://zerto_ip:9669/v1/ltr/catalog/fs" "https://zerto_ip:9669/v1/ltr/restore"
And of course, doing a
GET on any of these, will list all of the objects available in that category.
Performing actions on each is now simply taking a look at the aforementioned Zerto docs and coding out the actions through Powershell (psst . . . use the MyZerto lab!).