Disaster Recovery in the Cloud (part 1), I wrote about why companies should adopt DR plans. This blog article is about the service PeaSoup is offering to its customers and applies to other Zerto cloud providers.
PeaSoup offers DRaaS using Zerto, we find this is the best and easiest to use virtual aware disaster recovery software on the market. This week Zerto announced its new release 4.0 of their software and I’ve been testing this new release for the last month in preparation for this blog where I will discuss the latest release 4.0 and cover some of the exciting new features that comes with this new version. Also I’ve created videos to accompany this blog which you can find the bottom of this post.
The main features of using PeaSoup with Zerto 4.0;
– Easy to implement
– RPO of seconds, RTO of minutes
– Cross hypervisor replication
– Storage and hardware agnostic
– NO snapshots involved
– Non-disruptive testing
– Journal based CDP
– Ability to create consistency groups using VPG
– Upfront re-IP your servers
– Reduced complexity
– Replicated servers to the PeaSoup DR platform based in Tier3 datacentre
The new features of Zerto 4.0 are:
– New user interface, based around HTML5 and no more Adobe Flash
– Cross hypervisor support
– Sizing improvements for large environments
– Security Enhancements
– vSphere 6.0 support
PeaSoup platform is built around VMware vCloud SDDC stack in a Tier 3 datacentre in London Docklands. More information about our architecture can be found here.
Zerto is very easy to implement in your current environment, the following requirements are needed for DRaaS setup to PeaSoup:
– One Windows 2008R2 / 2012 Standard server for the Zerto Virtual Manager (ZVM)
– Virtual Replication Adapter (VRA) per ESXi / Hyper-V Host
– vCenter / SCVMM must be available
– Site to site VPN to your PeaSoup vCloud Organization firewall
– Firewall rules to allow traffic
The figure below displays the components used in a typical DRaaS environment using Zerto and PeaSoup;
– VPG – Virtual Protection Groups – Group of protected virtual machines providing the ability to protect an application that run on multiple virtual machines and disks to replicate as a single unit
– Zerto Virtual Manager (ZVM) – The ZVM integrates with your vCenter or SCVMM server as it needs to understand where a virtual machine resides i.e.on which host and what storage location.
– Virtual Replication Adapter (VRA) – The VRA will capture the data that is written for the protected virtual machines to the hypervisor level and replicates it to the DR site.
– Zerto Cloud Connector – Installed per customer to route traffic in a secure manner between customer organization and cloud replication network
– Zerto Self Service Portal – Portal service to provide overview and ability to perform failover test and live failovers
The ZVM installation itself takes 5 to 10 minutes after which you will need to pair your ZVM with the PeaSoup cloud. With version 4.0 you can select an external SQL database for the ZVM server, when used in large environments this is highly recommended to use.
Once paired, you will be able to provision the VRA’s to the hosts. Each host will have a dedicated VRA. The reason why each host needs a VRA is that Zerto is virtual aware, this means that in a virtual environment virtual machines are moved between hosts and datastores, the ZVM communicates with the vCenter/SCVMM server to know where the virtual machine is located (i.e. what host / datastore), and instruct the VRA’s to capture the data for that VM if it sits on that VRA’s host. New in version 4.0 is that you are now able to set the memory allocation, by default it is 3GB but you can assign less or more memory depending on your environment. (Maximum is 16GB). The VRA in version 4.0 is also further hardened, features like ICMP and cron are either not installed or are turned off by default, devices that are not required are removed in the /etc/securetty file and the sysctl.conf is now been configured in such way that it won’t accept packets that have their route through the network specified by the sender.
Once the VRA’s are installed, Virtual Protection Groups (VPG) can be configured. These are protection groups that provide consistent point in time checkpoints for all virtual machines in that particular VPG. This is important when using an application that uses multiple virtual machines (for instance a web front end server with a database backend server). During the creation of VPG you set the SLA for that VPG, PeaSoup provides a default VPG however a customer can define higher and lower priority sets for their VPG’s. Secondly you can set the parameters for DR such as WAN compression, pre and post fail-over scripts, DR IP addresses, what vCloud Org network to use for testing and for live Fail-overs. When configured the VPG will be created and the initial seed will start.
The idea is to configure this all upfront and test it so when a disaster happens you can focus on getting the services up as quickly as possible and not trying to get everything working by try and error..
Once the VPG is fully replicated you will be able to monitor the SLA on the dashboard, and start your first DR test.
With the PeaSoup DRaaS offering, customers are able to test their DR anytime they like. Testing is a feature to allow customers to test their DR without any intrusion of their on premise production environment. Replication during testing will continue as usual.
In the above figure, we show you a DR testing scenario, to start a test, make sure the “test” failover option is selected, when you select live, the bottom part of the screen will turn red. Important to notice is that when selecting live failover that down time will occur! When the test is selected a new vApp in the vCloud environment will be created call [VPG name] – testing recovery. All the virtual machines in a VPG will be deployed into this newly created vApp. You can than start testing your virtual machines. When done you can select the stop button. All changes made in the testing environment during the test will be gone after the test stopped. When the test failover button is selected, you will get a wizard that guides you through your test.
– Select VPG you would like to test
– Execution parameters
– And failover test.
At the execution parameters you can select your checkpoint (latest, VSS or manually created checkpoint to recover from) Once set, the vApp are created inside the customer organization at the PeaSoup cloud.
Inside vCloud you are able to check you new vApp and gain access to the consoles of those virtual machines.
Once everything is tested you are able to stop the test and provide a test result plus notes
In this next part we will describe the live failover. Please note that if you like to test with a live failover that down time is involved, please plan carefully before starting this process!
There are two scenario’s to start your failover
1) If the live environment is partly not available, but you still have access to your vCenter or SCVMM server and your ZVM server. You can start the failover from the ZVM server.
2) If there is no access to the live site at all, you can login into ZSSP with your credentials provided by PeaSoup.
Live Failover (and failback) can be started by selecting the live option next to the failover button, the bottom part of the screen will turn red to warn you that you are about to start a failover. Again a wizard appears, but this time the execution parameters is slightly different from the test failover one.
This time you are able to set the commit, to shutdown the gracefully the virtual machine on premise, and to reverse protect the VPG.
Once all set you can start the failover. The option VM shutdown is for those situations that production environment is still reachable, or failback, or if you like to test the live failover. If VM shutdown is selected “Yes”, the virtual machines in that VPG will be shutdown gracefully, if set to no, the virtual machines will be powered off. When reversed protection is selected, Zerto will setup the VPG to protect at cloud environment and replicate to your on premise location. Obviously this only works when your environment is still available. If the environment is not available, you can always create recreate the VPG later.
Failback procedure is exactly the same as the failover procedure, please make sure to plan your failback, as down time is involved. Lastly I would like to cover one very cool new feature, which is that you can protect hyper-v virtual machines and replicate these to a VMware vCloud environment. I’ve been testing this in our environment and will have a short video of this coming out soon. Below you see a screenshot of hyper-v environment VPG setup to a vCloud environment.
Lastly I would like to cover one very cool new feature, which is that you can protect hyper-v virtual machines and replicate these to a VMware vCloud environment. I’ve been testing this in our environment and will have a short video of this coming out soon. Below you see a screenshot of hyper-v environment VPG setup to a vCloud environment.
During the test I’ve successfully tested and performed failover of the Hyper-V environment to the PeaSoup vCloud environment.
I’ve created a demonstration video in which I will cover the following;
If you would like to know more about our services, or you would like to sign up for a trial please contact our sales department 01932 450 400 or firstname.lastname@example.org