- This topic has 7 replies, 3 voices, and was last updated November 18, 2015 by
George P.
How to introduce new target ESXi hosts
-
George PNovember 3, 2015 11:16:00 PM
I’m running Zerto v3.5-U7 with one protected site and one recovery site, with a ZVM server in each site. I am doing an ESXi server refresh in the recovery site because my existing ESXi hosts are getting old and need replacing. I’m not sure what the exact terminology I should be using for my question is, but please point me to documents with instructions I need to follow in order to “move the existing recovery VRAs to the new ESXi hosts” (if this is possible), or if I need to deploy new VRAs onto the new ESXi hosts, “How to avoid having to resync the protected VPGs from scratch to the new ESXi VRAs” or perhaps I should be asking “How to point the protected VPGs to new recovery ESXi hosts/VRAs without having to resync the protected VPGs from scratch”.
The new ESXi hosts I’m building in the recovery site will be connected to new VMFS datastores as well, in case this needs to be factored into your responses.
Thanks in advance,
George.
George PNovember 4, 2015 01:08:49 AMHi again, I think I’ve worked it out…Please confirm this methodology:-
1. Deploy new VRAs to the new recovery ESXi hosts which are connected to their new Datastores.
2. On the protected site ZVM, I edit a VPG, press the configure button->highlight the VMDKs and press “Configure Selected Volume”-> change the recovery datastore to point to the new Datastore.
3. Under “VM Advanced settings”, change the “recovery host” and the “vm recovery datastore” and the “vm journal DS” and press save and ok and the zerto will trigger storage vmotions to move the recovery data and journal data to the new ESXi host/new Datastore without needing to do a full resync.
Am I right?
Shannon SNovember 4, 2015 04:19:29 PM
You’re on the right track. Here is the step-by-step in the documentation.
Senior Technical Architect at ZertoGeorge PNovember 4, 2015 09:52:32 PMHi Shannon, thanks very much for your reply. That step-by-step document says “The datastores used by the original VRA and the changed VRA must be accessible by both the original target host and by the changed target host.” In my situation, I may not be able to configure the original target host(s) and the new target host(s) to see/access the current VRA and new VRA. So if I deploy VRAs onto my new target host(s) (which are attached to a new storage system) and then I go into ZVM on my protected site and edit a VPG->highlight a VM in the VPG->press “configure”->under “VM Advanced Settings”, can I change the “Recovery Host”, the “VM Recovery Datastore” and the “VM Journal DS” to point to my new target host/Datastore and it will move the data etc to the new recovery host and Datastore without requiring a full resync of the VPG? If so, when I next edit the VPG, highlight a VM and press the Configure button, in the “Volumes” section, will the Recovery Volumes now show the new Recovery Datastores?
That step-by-step guide shows a graphic from Zerto v4.0 and it talks about using Storage vMotion after step 5. I’m running Zerto v3.5-u7, so are the instructions applicable to v3.5-u7 too? Also, does my recovery site VMware environment need to be licensed with Storage vMotion for that procedure to work?
Matthew CNovember 4, 2015 10:25:59 PMGeorge,
It sounds like you’re also refreshing storage in addition to the hosts themselves. That’s really 2 separate migrations. In order to completely avoid a delta sync, you’re going to need access to shared storage. You will need to connect your new hosts to the current storage, deploy new VRA’s to the new hosts, then reconfigure your VPG’s to use the new hosts for the destination recovery.
Doing that will only generate a bitmap sync, which is very fast.
Once you have all the VPG’s moved over to your new hosts, you’ll want to go into the Zerto manager, and gracefully uninstall the VRA’s from your old servers.
At this point your new hosts are fully deployed. If you then need to also migrate to new storage, you should connect your new hosts to the new storage, and go through the appropriate steps to storage vmotion, etc.
I have done many host upgrades since using Zerto and the easiest way is to use shared storage. The best part about it, is you can do it all during the middle of the work day with no down time.
Good luck!
George PNovember 4, 2015 10:51:35 PMHi mcompeau, yes you’re absolutely right – I am also refreshing the storage as well as the ESXi hosts in my recovery site. My current recovery ESXi hosts are connected to a shared storage system. My new recovery ESXi hosts will be connected to a new shared storage system.
I can connect a HBA port from one of my new ESXi hosts to the current storage and the other HBA port to the new storage, so that this new host sees the Datastores on both storage systems. With this being the case, will the procedure in my previous post work and avoid a full resync?
George.
Matthew CNovember 5, 2015 06:41:14 PMTo move to your new recovery hosts, yes, you will avoid a delta sync, and will only need a bitmap sync.
As for moving your journals to a new datastore, I’ll have to let the Zerto team answer that, as I’ve never actually moved a journal to a new datastore before. I believe, you can change the datastore within the Zerto VPG config, and it will move the data for you, however I’m not sure if that will trigger a delta sync or not. I’m guess at least a bitmap sync would be necessary.
George PNovember 18, 2015 03:30:48 AMHi all, I’ve successfully migrated my recovery site VRAs and replicated VM data/journals to my new set of ESXi hosts and their new storage. I attached one of the new hosts to both the old and new SANs which allowed me to use the “Change VM Recovery VRA” feature to migrate the replica VMs to the VRA on this new host. Then I had to edit each VPG and change the VM recovery Datastore, Journal Datastore and VMDKs to point to the the new storage and this did the actual move of the data. Once all the VPGs were moved to this new host/Datastores, I load balanced the replicas across all my recovery hosts/VRAs. Many thanks for all your tips/pointers/assistance.
George.