May 6, 2015 8:13AM
In my last blog, 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 0808 9000247 or firstname.lastname@example.org or fill in the enquiry form
For more information about Zerto 4.0 – http://www.zerto.com/zerto-virtual-replication-4-0/
February 24, 2015 4:14PM
This blog article is the first in a series, ‘Disaster Recovery as a Service (DRaaS)’ which aims to explains the importance in understanding the difference DR & BC, future plan & … In this blog I will focus on DR and how PeaSoup can help organisations to have a DR for their IT environments.
Understanding your DR from your BC
Over the last few months, I have had many discussions on the importance of Disaster Recovery (DR) planning and considerations for the most suitable location. It became apparent that many people are confused between DR and business continuity (BC) and understanding the differences.
Disaster recovery is to recover from a business disaster which will involve downtime of an organization’s IT systems, where the aim of any DR plan to keep the down time as minimum as paramount. Business continuity on the other hand is a solution that does not involve any down time even when there is a disaster. Often this IT architecture is used in large enterprises with 24/7 requirements which can’t afford any downtime and are both complex and costly in nature for most organisations.
Gartner analysts Witty and Scott stated back in 2001 two out of five businesses that experience a disaster go out of business within five years, but DR and BC planning ensures continued viability. In today’s fast paced economy this appears to be more prevalent. What impact does a disaster have on your company? You not only lose revenue, you lose credibility which in the long term can cause more harm for your company. Would you do business with someone who can’t protect their own business?
How can you counteract the fact you have an outage where your staff can not access their datacentre services and receive any orders via web / email / phone etc. A plan to get your essential services up and running as fast as possible or it could result in you losing your business.
Businesses needs to move away from a heavy reliance of traditional backup in order to provide a well-structured business DR plan. Restoration from backup for DR is too time consuming and not in line with today’s data generation. But before I go into today’s DR planning & times, it’s best to explain the impact in terms of potential costs for an outage.
A few years ago, whilst working for a company specialised in DR, I found a formula to calculate the cost of an outage. The formula incorporates traditional backup methods via tape, which is the most widely used method for DR planning.
DR calculation formula:
Costs per incident = (Duration of incident in hours + Working hours x Days since last backup) x ((Hourly tariff employees x Number of employees) + Lost revenue per hour)
For example, assume the following, an incident takes 24 hours and your last full backup is 1 day old. In total there are 75 employees and the average wage is £13 per hour. The revenue per hour is £1000. This would give you the following sum;
Cost per incident = (24 hours + 8 hours x 1 day) x ((£13 ×75 employees) + £1,000)) = £63,200
£63,200 for a day’s outage is a substantial loss and this is just the initial loss (add the loss of new customers and existing customers, fast replacement of any new hardware, software etc for the IT department – you can only imagine the impact this will have on any business!).
With this in mind, are you confident your IT department has the necessary plans and procedures in place for a recovery agreeable with all departments across the business? Do you know the key factors you need to address for your DR plan?
You need to think about the following key factors:
– Your service level agreement (SLA) with your customers / management / departments
– Recovery Time Objective (RTO)
– Recovery Point Objective (RPO)
By addressing these key factors, you will be able to create a robust DR design for your company that is suitable for your business. I shall discuss each one in more detail for you.
SLAs – They are important to define from the outset as the needs of each department in your business may differ. Some departments may have a lower SLA than others, dependent on how reliant they are on IT, for example a Sales department vs a manufacturing department . RTO and RPO are the main discussion points during any DR conversation and they define your SLA and DR architectural design suitable for your business. Let’s look at them in more detail.
RTO – The “Recovery Time Objective” or “RTO”, is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) to avoid unacceptable consequences associated with a break in business continuity.
The “Recovery Time Objective” or “RTO”, is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) to avoid unacceptable consequences associated with a break in business continuity.
I.e. this means the total time to recover your business processes completely, so that the business can continue working as usual. An acceptable RTO is determined by senior management as the more downtime occurring will correlate to a loss of day-to-day revenue generation.
RPO – A “recovery point objective” or “RPO”, is defined by business continuity planning. It is the maximum tolerable period in which data might be lost from an IT Service due to a Major Incident.
A “recovery point objective” or “RPO”, is defined by business continuity planning. It is the maximum tolerable period in which data might be lost from an IT Service due to a Major Incident.
In simpler words, it means the amount of data in hours you will lose as a business, here’s a scenario: you have a backup regime every night starting at 7pm and ending at 10pm. The next day at 3pm an incident occurs, which means you lost all data created between 10 pm and 3pm the next day. In this case you would lose 17 hours’ worth of data and potential revenue.
Every business should create a DR plan for their company, with defined RTO, RPO and SLAs. Ask yourself questions – how much down time can your business afford? How much data loss can you suffer as a business? How much revenue am I willing to lose?
So we have explained the difference between DR and BC and the key factors required for DR planning, the next step it to divide applications into SLA tiers in a hierarchy, in terms of importance. Most companies have different business process / applications that they use for their business, and I always advice companies to create a list of applications and processes and sit down with the department managers and determine the SLA around individual applications.
Also directly involve the Finance director in these conversations, as a budget needs to be set for your DR plan & solution and by creating steering group you be able to generate healthy discussions and obtain ‘buy in’ necessary for creating a realistic budget.
During your SLA assessment, create a simple table so you can get a better understanding of the applications of the business and be able to identify and rank them in terms of importance for each department and to create the design architecture for a DR solution for your company.
Here is an example of an SLA Tiered table with agreed RTO/RPO tiered times
There are no references to any physical or virtual servers in the example as each process/application could use a variety of servers and devices.
Once you have determined your SLAs, RTO and RPO you can address your infrastructure requirements. Start by reviewing your application list and identify how many sit on physical hardware, how many are virtualised and what virtualisation technology is in use etc.
Lastly, where do you want your DR solution to be located? Here are some key questions you need to think about:
– Can we provide DR in-house at another location?
– Can we use the Cloud?
– Where are the Cloud data centres locations?
– What security do we require from a Cloud Service Provider?
– What technology will we require?
– What is our budget?
The next blog in this series will be about PeaSoup’s Zerto offering and you can achieve the lowest RTO and RPO for DR with a virtualised environment.
PeaSoup is offering the best Disaster Recover solution for virtualised environments on the market today using Zerto. PeaSoup uses Zerto to replicate virtual servers and application groups directly into our cloud into a private virtual datacentre which can be fully managed by your own IT or your MSP.
Zerto provides enterprise-class business continuity and disaster recovery (BCDR) solutions for virtualised IT infrastructure & cloud. Zerto won Best of Show at VMworld 2011, a Best of VMworld 2014 award, as well as 2011, 2012, and 2013 Product of the Year Awards because their software, Zerto Virtual Replication, is recognised to be the industry’s most comprehensive hypervisor-based data replication solution for VMware vSphere & Microsoft Hyper-V. Zerto Disaster Recovery solutions replace traditional array-based BCDR that was not built to deal with virtual IT environments.
Witty R.J and Scott D. 2001 ‘Disaster Recovery Plans and Systems Are Essential’ Gartner Information Security Strategies,
February 10, 2015 3:26PM
VMware’s annual Partner Exchange Conference (PEX) took place in San Francisco last week and I was invited to co-speak on ‘Storage as a Service using VMware VSAN’ with Sanjeev Desai from VMware Product Marketing where the new features of VSAN 6.0 were announced for release later in 2015.
This event is a great opportunity to learn about new launches, partnerships and product updates. VMware partners are brought together from across the globe. Key highlights for me were;
– The release of vSphere 6.0 which is providing exciting new features such as long distance vMotion and Fault Tolerance support for virtual machines with 4 vCPU’s
– VSAN 6.0 which will be able to double the cluster size from 32 to 64, 4x more performance, introducing fault tolerant domains across racks and the all flash VSAN. Also new is the support for blade infrastructures!
– Meeting industry peers and have the interaction with VMware senior executives.
The next session of this blog is a summary of my presentation I did at PEX2015, the slides will be made available via VMware Partner portal for PEX2015 attendees or contact PeaSoup at email@example.com for the PeaSoup presentation.
In January 2007, Apple announced the iPhone as the first smart phone of its kind with no key board and 100% touch screen. I was gobsmacked, as this phone not only looked very smart but also provided new functionality so much better than other “smart” phones before. In that time I was using a Compaq iPAQ which was a huge phone with some sort of Windows NT 3.51 look alike OS on it and its usability was rather clunky…
Mr Jobs said, “We are all born with the ultimate pointing device – our fingers – and iPhone uses them to create the most revolutionary user interface since the mouse.” Apple had dared to make a look that was not in their line of business.
Later that year Steve Ballmer commented on the introduction of the Apple iPhone , how stupid it was and why people would never use it, as people needed email access … How wrong was Ballmer… and he was one of many (Blackberry, Psion…) that thought along these lines.
Today we have 1.75 Billion smart phones leaving Microsoft trailing behind in the mobile market. So what’s Apple’s story?
Apple does not just design, develop and sell consumer devices, they sell a lifestyle – one that enriches our everyday lives, such music on demand. They created a new market which is totally commoditized and where everyone is using a smart device. Apple were open for change, they listened to what consumers wanted and created a whole new market. This market is the key driver for datacentre business, today. How many apps are out there? How many are using a cloud platform?
Microsoft as an innovator was not open for change… and in this case they missed the boat…. Which was actually not the first time… Think virtualisation ….
The smart device market and Virtual SAN
Storage is on the verge of the same change seen within the mobile device market. VMware is at the forefront of this change by introducing Virtual SAN. Virtual SAN is built from the ground up for virtual servers, providing a true software defined storage solution with minimal overhead and simplified management. VSAN enables read/write caching using server-side flash. VSAN is built into the VMware hypervisor, optimizing the I/O data path to deliver better performance than a virtual appliance or an external device.
“Physical” does not apply to virtual, this is something we are saying in the industry for the last few years and now we can finally apply this to the storage market. We don’t have to architect our application infrastructure around the storage provider anymore. Consumerization is a key business driver, increasing the demands for storage, impacting IT solutions provided. Monitoring the market and influx of demands is crucial in understanding the requirements for an increase in availability and performance, and less down-time (as possible) whilst allowing for granular growth with the virtual platform.
To grow businesses in line with the increase in consumer rates, flexible solutions need to be implemented which provide reliability, performance and growth rather than large incremental upgrades.
For example, the applications inside the virtual machines will determine the policy set for storage.
PeaSoup CTO Harold Buter speaking at PEX2015
When we started PeaSoup, my partner and I sat down and discussed PeaSoup storage requirements and associated costs. We both have over 20 years’ experience in the industry and we have been selling storage for 15 years. So we knew the biggest challenge we faced would be cash flow, and so we wanted to provide a Cloud solution that did not have a large initial cost from the outset. First of all we knew if we decided to go down the traditional storage route we would have a large capacity array but this would low performance capability. Secondly, our growth model showed the need for a storage solution that could grow linearly with the environment. We didn’t want to create a solution that could not adapt to the growing demands of the environment and require storage controller upgrades increasing risk for further down time.
Virtual SAN was one of the reasons we wanted to start as a cloud services provider, as we could see the potential for our customers. We did our calculations and looked at what CAPEX and OPEX impacts VSAN would have compared to traditional arrays.
On the CAPEX side, rather than buy large storage arrays with smart software to enhance performance and dedicated fibre network, we chose VSAN – yes, VSAN. The hosts cost more than a non VSAN host as they do not need SSD, multiple disks or a raid controller, however the cost per GB is much lower than that using traditional arrays.
Another advantage to using VSAN, we could start relatively small, i.e. not buy a large storage array upfront which would require array upgrades with expansion units. We did not want to create more risks of downtime with cost implications. As most of you know, once you buy the initial storage your expansions would never be at the same discount levels… using Virtual SAN provides linear growth, so we added more data store space in line with the CPU and memory growth. Adding a VSAN node takes a matter of minutes (especially when using auto deploy) and does not have any risks. Secondly using this model made it easy for us to predict when would need new hosts and an operations manager forecasts growth and alarms.
Looking at the OPEX for PeaSoup we decided we needed virtualisation staff rather than virtualisation and storage engineers. Virtualisation engineers require less storage knowledge and can focus on the Virtualisation skills instead.
PeaSoup VSAN is available for service providers under the vCloud Air Network Program (0.08 points per GB per month for the allocated capacity for the hybrid model).
When we compare our operational challenges with the traditional storage arrays you will find the latter more complex, requiring dedicated specialists to maintain both arrays and network. This is because traditional storage solutions are aligned to storage containers i.e. LUN volumes etc. VSAN’s application-centric policy is very simplified and helps us to match the policy to the application.
We wanted a solution that provided VM centric snapshots and not use a solution that snapshots a complete LUN. As you can imagine, in a fully automated environment you don’t want to create a LUN per VM or vAPP which creates more administration work and increases the complexity.
Another challenge is expansion. Previous experience has taught me to check firmware levels of new units when expanding. If the units are newer the production environment requires an upgrade which could have its risks and need advanced planning. But in a fast paced cloud environment there is no time to plan weeks beforehand you need to expand there and then without any risks.
Virtual SAN is great as it provides me with a single datastore that is managed via the vCenter, it is that simple. All the management is completed at vCenter level which means that snapshots and policies are all done from within the same management layer and fully integrates with vCloud Director and vRealize Orchestrator. It means that PeaSoup can simplify the storage solution and spend time and resource on enhancing other services, hence we say PeaSoup | cloud simplified.
To date we have been able to define VM specific policies, for example on reliability and performance, which in the future will be even more improved (IO control is not part of VSAN yet) today we can set the fault tolerance, amount of spindles used and reserve % for flash.
Most cloud outages can be placed in two categories, either network related or storage related. In general, network related issues can be solved pretty quickly if the right people and resources are in place. However storage related issues can have more impact, especially when it’s a fatal error such as a full rebuild, which are very time consuming. For PeaSoup we wanted a solution that allowed fast resolution for any issues occurring on storage layer. In our VSAN design we added an extra host to fail over too, so that customers won’t notice the impact of a host failure.
Additionally with traditional arrays, the solution complexity creates an increased probability of risks of human error over time. Don’t get me wrong, a good designed storage solution should be capable to deal with errors but unqualified staff could be the biggest risk to the stability of the environment. For our environment we wanted a solution that minimizes human error as much as possible.
The beauty of virtual SAN is the scalability and the possibility of a fully automated solution, ie using auto deploy to add new hosts into the cluster – making the no requirement to manually upgrade firmware of controllers, expansion units etc.
Virtual SAN is designed to fail! This is an interesting concept which means there are processes in place created for when a failure occurs and provides an automated solution, for instance to start a VM on a completely separate host when an issues arises on a host. Obviously, you still need to make sure you have the capacity! The policies can be set per VM, you can even choose to have multiple FT points to create more replicas of the virtual disks. This will cost additional storage space which you have to calculate and charge customers! A FT of 1 will have two replicas and a FT of 2 will have three replicas so a VMDK of 50 GB disk uses 100GB with FT1 and 150GB with FT2.
Since VSAN does not use RAID it means that we don’t have the rebuild time. FT ensures that virtual machines don’t have to be rebuilt, ensuring down time is limited to an absolute minimum.
As mentioned previously, scalability is one of the most important features for us, as a cloud provider we need to upgrade when needed, if we get a new customer with a large resource demand, we need to add hosts as quickly as possible for increased CPU, memory, storage capacity and performance. Adding new customers should never implicate storage performance decrease. So we needed a solution with linear scalability without having to cope with large incremental costs.
Note with traditional solutions you can outgrow your array, so you might chose a solution that looked like it fitted the bill when you started, but after a year your controllers can no longer cope with the traffic generated. So you can choose to buy a new larger model, or perform in a place with a controller upgrade which could cause downtime (this is frequently due to human error!) or if upgrading you might need to opt for a different vendor / model with different management tools which require staff needs to learn and adapt.
So to conclude VSAN takes away hosting complexity. It delivers a solution that will grow with the environment – not only increase the processors and memory, but also the capacity and performance of the storage layer. At PeaSoup we can even add additional performance by using larger SSD disks. And with auto deploy you minimize the risk of human error by fully automating the installation of a new host to a cluster.
PeaSoup started in 2014 and was founded on the basis of VSAN released in last year. We spent months laboriously going through the process of due diligence, testing, checking and double checking our solution and we are doing well. As CTO I’ve used many resources to make sure we had the right hardware. In the summer 2014 we built our cloud platform and on boarded a media ISV customer capturing high volumes of raw video data before converting it to mobile video data before exporting across various distribution channels – a very IO intensive, customer happy with performance and services provided.
At the end of the year we concentrated on simplifying our platform further and are currently testing a new portal solution – so watch this space.
2015 we shall go live with the new portal which will provide a single pane view for our customers and partners. The single pane should not only provide vCloud functionality but also backup, usage, billing, disaster recovery and support desk functionality.
We will also improve our service with ‘extreme automation’ – we want to automate as much as possible in order to minimise human error and increase service speed to both customers and partners.
The PeaSoup cloud will constantly adapt to fit new solutions, and we aim to add a new cluster based on vSphere 6.0 in the future to utilise new features such as fault domain on racks which will further increase our reliability. We will add a new tier to our services with flash array. The main feature would be new file systems which will improve snapshot and cloning. This will have a positive and great impact on the platform, especially as backup software uses snapshots.
For further resources on your VSAN journey check out these blogs: www.yellow-brick.com, (Duncan Epping), www.cormachogan.com and www.virtuallyghetto.com (William Lam). These guys provide a lot of very good content! Also I absolutely recommend purchasing Essential Virtual SAN (2014), Hogan C. and Epping D, VMWare Press.
September 2, 2014 1:13PM
Often I got asked why we use Zerto and Veeam in our infrastructure. So hence why I write this blog to explain why we use both products.
Both Zerto and Veeam are excellent products, very easy to use and very consumer friendly, and in the first instance they look like they are similar products. However as many things in life, there are major differences and functionality between the two solutions. In this article we will briefly focus on the Disaster Recovery as this is the point where the two products compete.
Round 1 – Veeam
Veeam has been established since 2006 and since the start they were focused on virtualisation, first in monitoring and soon followed by backup and replication. Veeam changed the backup world by providing an easy method of backing up virtual machines and later by replication virtual machines.
Veeam uses VMware snapshot technology in combination with changed block tracking (CBT) to create a replicate of a virtual machine. During the snapshot, a redo file will be created and all changes during the replication process are written into this file. Once the replication job is finished the redo file will be merged into a live disk file again. The next time the replication job is started only the changes since the last job will be replicated to the replica virtual machine.
Round 2 – Zerto
Zerto is founded 2009 and they also were focused on virtualisation. Zerto’s focus has always been disaster recovery and there product provides one of the best recovery options in the market today. Like Veeam, Zerto strength is in the simplification. Their user interface is integrated virtualisation administrator client and is very easy in use.
Zerto uses a different mechanism for their replication. Zerto will deploy small virtual machines on each physical node. These small virtual machines will capture the data that is written to the host and sends a copy of that data to the replication site. The process is not synchronous but near-synchronous replication. The replication is continuous meaning once set it will replicate a change (using Zerto’s own change tracking technology) as it occurs in the virtual machine.
Round 3 – The difference
The main difference between the two solutions are recovery point objectives (RPO) for business justification and method of replication for technical justification. Both solutions have proven that they are providing best in class for disaster recovery solutions of virtual infrastructures. Obvious there is a pricing difference and this is where the justification comes in. I’ve seen many sites that utilises both solutions to provide a good mix of RTO and RPO. The RTO for both solutions are similar, when a VM is replicated it only takes minutes to boot the virtual machine and off you go. However the RPO is a big difference, Zerto provides seconds and Veeam can do 10 minutes minimum depending on your external links and change rates though. With Veeam most companies uses once a day replication.
Both solutions are the best in the market today for virtualisation DR and it really depends on your business what your requirements are. If you already invested in Veeam for backup and your company has low RPO requirements than Veeam is very viable to use for replication. If you are looking for the best RPO in the market for your virtual machines than Zerto can provide this.
In this case there is no right or wrong of what solution you choose, as often in virtual world, it depends…. Both solutions are winners…
PeaSoup Hosting is using both products, which means we can be used for your company as a replication target (DR-as-a-Service). Our platform runs on VMware vCloud and both Veeam and Zerto are fully vCloud certified. For more information please contact us at firstname.lastname@example.org or call us at 01932 268340
July 17, 2014 6:40AM
In the last blog I went into the main architecture of our cloud using VMware vCloud platform and vSAN. In this article I’ll describe how we protect our infrastructure.
Today I will write about backup of the environment. DR and Backup to our cloud environment will be discussed in later articles. PeaSoup is using Veeam Backup and Replication to backup the customer and the management environment.
We had an architecture dilemma when we started with PeaSoup. Originally we planned to use VMware VDP Appliances while this was the only backup solution on the market that supports vSAN. However, we didn’t want any management servers on our customer cluster, and we did found out during testing, that VDP appliance needs to be installed within the resource cluster. We did look at the big brother of VDP, EMC Avamar, however we did not find this the right solution.
In June Veeam released patch 4 for their Backup and replication v7 product which included support for vSAN. I’ve been working with Veeam for a long time and I really like the simplicity of their solution. Secondly Veeam is fully vCloud supported, meaning we can select organization VDC’s to be backup’ed. We tested Veeam in our cloud using vCloud and vSAN and it really performs very well, both backup and restores were very easy and quick.
The next step was to create a design for the backup environment. As we are using virtual Veeam servers, we decided the best way forward is actually to create a separate cluster for the backup environment. This meant we can utilise different lower cost hardware as we not want to use vSAN as a backup target. The backup cluster uses traditional storage solutions and we are using this purely for backup and disaster recovery targets.
The figure above depicts a logical overview of the architecture with the three clusters we have today.
The cluster is also being used for our backup to cloud using Asigra (which we will describe another time)
Later this year we will upgrade Veeam to version 8 as this will provide repository as a service solution. This is a great option, while we can provide repository services to customers who have Veeam on premise, and want to backup to the cloud or have a backup copy of their jobs stored outside their premises.
June 12, 2014 4:18PM
As CTO I’ve been involved in many technologies in the past, some good, some excellent and some ok ish. This experience of technologies helped us to design our hosting platform. Our main Data Center is in London Dock Lands at the Telecity group. We have 4 independent ISP links going into our racks to have no single point of failure when a line drops or under performs.