Blog

Zerto Architecture – How does it work…

It is important for me to understand a product I work with so that I can not only ensure that the product is fit for purpose but understand how it works and what elements it can exposure or potentially put pressure on, this also helps me write a effective design. One of things I wanted to grasp with Zerto was the method in which its copies the IO from a VM to replicate those blocks, does it intercept that IO? Does it slow down the process of writing to disk? Could it cause latency or outages? Well below is an abstract from a design in which I hope it answers those questions.

 

Zerto is a third party piece of software that is Hypervisor agnostic and will work with any hypervisor where there are exposed APIs available for then to work with. In my labs I have worked with it in vSphere environments and this article will focus on how VMware enables the ability for Zerto to take advantage of their APIs. Essentially Zerto is made of 2 main components, which are the driving force behind the product.

 

  • ZVM – The Zerto Virtual Manager is a Windows management server and is by definition the management of the solution. One of these is required per site or from a VMware perspective per vCenter.
  • VRA – A Zerto Virtual Replication Appliance a debian based VM is essentially the replication engine that manages the changed blocks the replication and the compression of the data.

The architecture works in that the ZVMs are connected or paired with each other across sites and the VRA’s are then paired via the ZVM, but once replication is configured the 2 VRAs are in constant sync. The solution will support replication across sites even of different geographical locations and intra-site, within the same vCenter. As this replication happens over IP it is important to mention that in order for the solution to work the sites must be on the same network or have connectivity of at least 5MB over a VPN etc, however in order to achieve the best results and depending on how much data is required to be replicated a much higher available bandwidth would be desirable. The initial sync can be reduced by pre-seeding where the data is copied by another means such as storage replication for example or has been replicated previously.

 

The architecture works in that the ZVMs are connected or paired with each other across sites and the VRA’s are then paired via the ZVM, but once replication is configured the 2 VRAs are in constant sync. The solution will support replication across sites even of different geographical locations and intra-site, within the same vCenter. As this replication happens over IP it is important to mention that in order for the solution to work the sites must be on the same network or have connectivity of at least 5MB over a VPN etc, however in order to achieve the best results and depending on how much data is required to be replicated a much higher available bandwidth would be desirable. The initial sync can be reduced by pre-seeding where the data is copied by another means such as storage replication for example or has been replicated previously.

zertoarcvsdx

 

 

As you can see in the image there are 2 VRAs (in red) in each site, one for each ESXi host. The red line indicates the flow of the traffic, from the vmdks in the source storage via the APIs on the host to read the IO. The data is then directed across the network to the alternate sites VRA (which is defined during the creation of the VPG stage) and down to the local storage. This replication is block level host based replication which means that the transfer of data is more manageable.

Some of the main ports are mention in the above diagram, below is a full list of ports used by Zerto and their purpose.

 

zerto-ports

 

The way that the replication works is by the APIs ability to read and not intercept the IO from a VM as it is written, in order to do this Zerto leverages the VAIO, VMware’s APIs for IO filtering. The VAIO was created by VMware to allow vendors access for caching and replicating VMs, it is essentially a framework inserted into the SCSI stack of a VM and allows for the data to be read. This process is show in the below image which shows the process of a VM writing to disk via the SCSI stack. The read box indicates a I/O and the process for that I/O to be written to disk. As you can see the VM which resides on a ESXi host writes data via the SCSI stack on the kernel of the host as the I/O enters the VAIO framework it is directed to the filter which firstly writes the data to its own source datastore but also allows for the third party software to read the I/O and write it to the VRAs memory. The I/O is held in memory where it is referenced against the change block tracking methodology before securely compressing the blocks and replicating to the destination VRA.

 

zertoio

This process allows for the data replication to take place with minimal impact to the network, as the replication is block level and under changed block criteria the replication traffic which is generated is minimal and has no impact to the VM, at the time of the process to create the VM and the VPG all this is determined. Although the process looks laborious to write the I/O’s it happens instantly with no performance impact and regardless of Zerto or any other third party software the process would be the same for each IO in VMware and the time taken would be the same to write any IO, the filter just allows the I/O to be read via the framework. The VRA also handles the compression of the data as mention before replicating it, using the entire LZ compression library to break down the data into bites and send the data in smaller entities to the remote site where they remain in the Journal still compressed. The data remains compressed in the destination site because it obviously saves more but actually doesn’t take any more time to de-compress as part of the process to recover a VM, therefore it is a no brainer.

 

Journaling..

Journaling is a process known in any backup environment, the concept is a file system that keeps track of changes not yet committed and recording the intentions into a journal. In this solution the journal holds the a record of all the compressed data for each replicated VM as far back as that which is selected during the protection process (creating the VPG). The data is held at 5 second intervals and so depending on the configured time i.e. 30 days and the change rate of the server the amount of data can build up. Having said that the data is still compressed and not duplicated due to the change block tracking so the amount of data is significantly reduced.

The journal store holds the bitmap table for the protected machines on the destination so it is able to cross reference an I/O with a VRA or a number of blocks to distinguish if the block already exists. This is also used when there is a site connection issue, when the paired sites are in contact once again the journal’s bitmap will be cross referenced by the blocks held in the source VRAs memory to see which blocks need to be copied and which can be discarded.

 

 

Thank you for reading, soon I will write about the process in which Zerto promotes the disks and the VM on the destination site to failover a protected VM.

 

 

 

 

 

 

Leave a Comment

Your email address will not be published. Required fields are marked *