By Joshua Stenhouse, Zerto Technical Marketing Manager    

After discussing features, requirements & cross-hypervisor replication in part 1 of our discussion on Zerto from Microsoft Hyper-V, in this second blog post I will cover the installation requirements for Zerto.

Just as Zerto utilizes VMware vCenter for task orchestration and automation in a VMware vSphere environment, it utilizes Microsoft System Center Virtual Machine Manager (SCVMM) in a Microsoft Hyper-V environment. In the below diagram are the pre-install requirements for Zerto in Microsoft Hyper-V:

The management Windows VM is where you install the Zerto Virtual Manager (ZVM) service to manage disaster recovery. One ZVM is required per SCVMM or vCenter server and any number of ZVMs can be linked together for replication, recovery and management.

It is recommended to have 1 SCVMM server or vCenter (if replicating to/from VMware vSphere) per datacenter for disaster recovery. If the SCVMM or vCenter server is unavailable then the ZVM is unable to perform recovery operations, so both management servers should be protected by high availability in a VM.

Following is the architecture for installing Zerto in a Microsoft Hyper-V environment:

To summarize the process in the correct order:

• Install the ZVM service onto the dedicated management VMs provisioned for each SCVMM server, linking it into the SCVMM server for that site with a dedicated service account.
• Pair the ZVMs together so management traffic is replicated to allow selection of a target and source for replication and recovery.
• From the ZVM interface deploy the VRAs onto the Hyper-V hosts, specifying a static IP address for each VRA. The IP address must be able to route to the IP addresses of the target site VRAs. No downtime is required for deploying VRAs and there is no impact to running VMs.
• VMs can now be placed into Virtual Protection Groups for SLA based protection and application centric recovery.

In order to continue replicating and protecting VMs while performing live migrations, each Hyper-V host in a failover cluster than you’re replicating from and to should have VRA deployed.

In my next blog post I will cover creating Virtual Protection Groups to allow the replication and recovery of VMs.

As anyone in the Northeastern US can tell you, there is only one topic on everyone’s mind today. CNN calls Juno “historic”, The New York Times refers to the blizzard approaching, carrying with it two to three feet of snow, as “vast”. Massachusetts Governor Baker declared a state of emergency and an actual travel ban, as opposed to an advisory. Mayor Walsh of Boston announced that city schools will be closed Tuesday and Wednesday. New York Mayor Bill de Blasio, “took the unusual step of ordering all drivers off the streets by 11 p.m. on Monday, a ban that he said covered ‘anything that has to do with leisure or convenience’,” according to the New York Times.

So, what are the dangers to a datacenter during a blizzard? How can these dangers be mitigated in the hours leading to the storm?

According to PSE&G, “While snow by itself doesn’t normally pose a serious problem, heavy snow and strong winds can increase the possibility of downed wires and power outages.” The company’s blizzard handbook also warns that the storm conditions make it difficult for their employees to fix downed lines and outages. This is where danger to employees and datacenters becomes acute – preparing for what can be hours or days of power outages.

Inside the datacenter, power outages are just one danger of severe cold weather. According to this article on datacenterknowledge.com, “Severe cold can cause a data center to operate outside of its specific design perimeters, which adds stress to the system. In addition, if the temperature gets too cold, it becomes difficult to heat any air taken in from the outside. Beyond this, freeze can set in on outdoor equipment, including drain lines, fuel systems that don’t have the appropriate cold-weather additives, HVAC heating coils, cooling towers and humidification units. Frozen HVAC units can begin to leak water, while snow and frost can clog intake vents. If this occurs, it can be difficult for air to circulate and the entire system can shut down.” A regular maintenance schedule is critical to solving these issues – but one simple step you can take is to make sure that you have a special drain for the overflow of water that may leak as the frozen units thaw after the storm.

We also called one of the many IT directors using our disaster recovery software to ask how they prepare for an impending storm of this caliber. According to one IT Director we interviewed, “The safety of our employees is our top priority, so if someone is more comfortable working from home, we want to make sure they are fully enabled. Regarding the datacenter itself, we are providing updated processes for Citrix and VPN to help keep everyone productive AND safe.”

Other Zerto customers fail-over their data so that employees can continue working (remotely) during a storm. In 2012, as Hurricane Sandy approached the East coast, Zerto customer Affigent moved its primary private cloud platform from Reston, VA, which was predicted to be in harm’s way, to a datacenter in Chicago, IL. Actual failover to the Chicago site was performed during lunchtime as the storm approached. Servers were shutdown cleanly, latest changes were replicated and then servers were restarted in the DR site. It took 35 minutes to move and another 20 minutes to fully test all applications that were failed over to the Chicago site. Affigent continued to fully operate without any data loss in the secondary datacenter until the storm passed. Failover does not need to be pre-planned – it can be done, as in the Affigent case – just hours before the storm hits.

Another tip? Communication plans. One of the key factors that all DR specialists rely on during a storm is communication. According to the mass.gov website: “Pay close attention to storm warnings, alerts and updates, and have a plan in place to keep employees informed. Evaluate, update and review your emergency plan, including evacuation routes and communication to employees.”

How can we help? If you are a Zerto customer and have concerns at any time during the storm, our support team is available 24/7. You can find them at http://www.zerto.com/support-services/

For those of you in the Northeast, stay safe and warm!

By Shannon Snowden, Zerto’s Sr. Technical Marketing Architect

We frequently see articles and analysis showing the cost of downtime and how important it is to have a good disaster recovery plan. While downtime is costly to any business, downtime in a healthcare facility can be costly at a completely different level.

By far, the most stressful server migration projects I performed were healthcare-related applications. In my case, we were converting MEDITECH from physical servers to virtual machines and adding new storage arrays to replace end-of-life hardware. What made the migrations so stressful was the knowledge that there was a patient was at the other end whose life could be substantially impacted – not just an email box or some sales guy’s Powerpoint slides. Email and sales presentations are important, but they don’t compare to ensuring the patient treatment tracking data is accurate and available.

At the completion of our migration projects, MEDITECH was highly available, more resilient and was down less since it was running as virtual machines in a cluster. However, they still depended on tape for disaster recovery. The time it takes for restoring from backup tape is unacceptable given there is a better, and far less impactful to the caregivers option.

In fact, not only are Zerto customers no longer depending on backups for a single site disaster, Zerto customers are able to survive and recover even if both the primary and recovery sites are lost, even if one site is VMware-based and the other is Hyper-V. By leveraging Zerto’s Offsite Backup capability, the protection groups of virtual machines are archived to a third or even a fourth site, such as a cloud service provider or AWS, and can be recovered to any Zerto Virtual Manager.

Because of our proven track record of successfully protecting data and growing supported platform flexibility, we are seeing unprecedented interest from healthcare providers. They know they need to be able to do better than restoring from backups in case of a disaster. Being able to restore from a complete site disaster in minutes instead of hours is compelling, and recovering the applications and patient data from a two-site disaster is too important to ignore.

In an upcoming Webinar, we have a compelling Case Study that discusses how Zerto is protecting Allscripts and positions Liverpool Heart and Chest Hospital to have very little downtime, even if they have a major outage at one of their sites.

Valentine’s Day is this weekend and we wanted to help you get into “that loving feeling” with some old school poetry. We have gone Shakespearean and put together a sonnet dedicated to our love of Disaster Recovery (DR).

We hope you enjoy reading it as much as we enjoyed writing it!

Shall I compare thee to a case of beer?
You are more lovely and more refreshing.
Rough winds do shake the datacenter sphere,
But I have my DR plan protecting.

How I can find the many minutes to tell;
Recalling each time of thunder, rain and wind,
Knowing with BC/DR it will be well
Enjoying my beer whilst wearing a grin

As I look now on this datacenter
The care for it is solely in my hands
Protecting it shant be an adventure
Or I might find myself getting canned

So long as men can breathe or eyes can see,
So my love to DR, I give appreciation to thee.

The below infographic outlines the dangers of disasters and downtime to your datacenter, and ultimately your business, as well as how quickly business typically recover, why testing is important, and much more information. Take a look at our Disaster Recovery as a Service (DRaaS) infographic and learn how this might be the right solution for your environment.

The data for this infographic was collected by Zerto and had 125 survey participants.

By Joshua Stenhouse, Zerto Technical Marketing Manager    

Following Part 1 and Part 2 of the Zerto for Microsoft Hyper-V Series, In Part 3 I will cover replicating and protecting VMs in a Microsoft Hyper-V environment using Zerto 4.0.

All VMs that require replicating and protecting in Zerto need to be configured in a Virtual Protection Group (VPG). The VMs are then replicated and recovered on a per VPG basis. A VPG has to contain at least one VM and a VM can only exist in one VPG at a time.

VPGs are typically built on a per-application basis so that multi-VM applications can be recovered or tested together. The VPG maintains the write-order fidelity of changes across all of the VMs in the VPG, ensuring they are all recovered to the exact same point in time. This in conjunction with the Zerto journal based protection allows recovery of the entire application from any point in time, with increments every few seconds, up to 5 days in the past.

Creating a VPG in Zerto 4.0 is now a 6 step process as shown below:

Pre-seeding can be configured on a per vDisk basis which means Zerto will only synchronize the changes between the disks rather than replicating an entire copy of the disk to the target site.

Configuring the networking allows the VMNics to be connected to different vSwitches and for the IP and/or MAC address to be automatically changed as part of a move, failover or failover test operation.

Zerto 4.0 also introduces a new workflow for VPG creation that brings with it the following enhancements:

• Bulk editing of storage configurations for vDisks allowing the quick configuration of individual disks in VMs to any different target storage configuration
• Bulk editing of network configurations for VMnics allowing the quick configuration of individual VMnics in VMs to different port groups and specifying different IP addresses for reconfiguration
• Import and export of IP addresses for re-ip addressing

These 3 enhancements together make Zerto extremely easy to deploy and manage in large VM environments.

Once the VPG is in a protected state, be it after an initial-sync or pre-seeding operation, Zerto will then start protecting the VMs as shown below:

Any changes you make to the protected VMs after initial VPG configuration are replicated also, such changes include:

• Live migrations between hosts
• Storage live migrations
• Adding, removing or resizing vDisks
• Adding or removing VMnics
• Changing the VM CPU or RAM specification

As Zerto is fully virtual aware it doesn’t need constant maintenance to support the day to day changes that happen in your Microsoft Hyper-V environment.

This concludes my blog post on VPG configuration, replication and recovery in Microsoft Hyper-V environments. In my next post I will cover cross-hypervisor replication.

Guest Post by Zerto Cloud Service Provider Green House Data

It’s true that planning for an emergency situation can be difficult and time consuming, but failing to prepare can be disastrous for your company. Whenever an organization experiences IT downtime, production stops…and revenue takes a major hit.

To simplify disaster recovery and rest easy knowing that business systems and data will be there when they need them, many small to midsized companies are evaluating disaster recovery as a service (DRaaS). This fully managed solution is a great alternative for companies that lack the expertise or necessary staff to provision, configure, and regularly test their systems to meet recovery goals.

In order for disaster recovery to succeed, you must select a provider that has your interests in mind and can fully protect your data according to your organization’s specific requirements. Here are three steps to choosing a provider and set up a recovery plan that will keep your computer systems working so you can avoid downtime.

Objectives & Resources

There are some details that you need to take into consideration when comparing different DRaaS providers:

• What are their replication options?
• What does their recovery environment look like?
• Do they offer testing?
• Do they have multiple data centers in strategically placed locations?

Your objectives for this plan are crucial as well. Think about what your company must achieve by implementing a DR plan. What are the critical parts of your infrastructure that are needed for daily business operations? Knowing why you are doing this can help pinpoint where to start and what parts of your infrastructure need more concentration.

You need to keep in mind your RPO (Recovery Point Objective) and RTO (Recovery Time Objective) needs. How far back do you need to go in order for normal operations to resume in the event of a system, network, or application failure? You probably don’t need e-mails from five years ago, but you do need documents from last week. What is the tolerable length of time for a system, network, or application to be unavailable? If your company has not established RTO or RPO, a DRaaS provider should be able to assist in determining these.

Support is a big factor as well. If something were to go wrong, does the provider offer 24/7/365 technical support? Are their technicians properly trained and certified? What is their guaranteed response time to critical issues? These factors should be addressed in the Service Level Agreement from each potential provider, which will detail the acceptable downtime of their own systems, the availability of staff, and more, with compensation offered if they do not meet the agreement.

Setting Up Your Disaster Recovery

When you’ve settled on a provider, you need to setup and test your DR. If you’ve picked a fully managed solution, like DRaaS, your new partner can do this for you. If not, you should know what their process is and what software will be required for compatibility issues.

You may also want to know how long the migration is going to take, the amount of potential downtime that may occur, and if there is any risk of data corruption, or missed or lost data.

Different DR tools have different configuration settings and may or may not integrate with your environment by default. It’s wise to set up automated failover with continuous replication, but that can also increase bandwidth and storage fees. Some software does automatically integrate with virtualization management tools like vCenter or vSphere, so you can set up fast, automated, recovery with groups of virtual machines.

Having a DR plan is good, but examining each step of it to make sure everything is in working order is a must. Make sure your DRaaS provider offers routine testing of all stages of your DR plan to ensure that your data will be recovered, your critical applications will be restored, and your business operations can continue as normal.

Failover

Should an outage occur, systems will failover to standby equipment that seamlessly takes over so your business will experience little, if any downtime. You will need to know your requirements for the failover process and testing, and if the provider already has a pre-defined failover policy.

A service provider can help set up automated failover, which will periodically check in to see if your infrastructure is live and switch over network settings, power up your backup virtual machines, and make sure your employees never miss a beat.

Put careful consideration into the DR provider you choose in terms of their long-term availability and capabilities, to ensure their performance is at the level your company needs in order to avoid major issues if the failover process is delayed.

Green House Data takes disaster recovery planning very seriously, and with facilities located in some of the safest areas in the country, severe weather or seismic events are of slight concern. Green House Data provides cost-effective custom solutions from traditional DR to DRaaS, concentrating on faster replication, improved recovery time, and configurability.

By Jennifer Gill, Director of Global Product Marketing

In the wake of this past winter’s weather events across the US, many IT organizations are wondering, will they be ready if an outage occurs? However, what these same teams don’t realize – is they should really be considering this on a daily basis. “Disasters” are not caused only by weather – hardware failures and upgrades are actually the more common culprits. Do you have hardware on which you perform upgrades? Well, then you are a candidate for a disaster!

Since a dedicated DR site can be expensive for many organizations, hybrid cloud and Disaster Recovery-as-a-Service (DRaaS) are more and more common, and with good reason. Replacing the costs of a secondary site (hardware, software, power, cooling and maintenance etc.) with a predictable monthly cost is a very attractive option.

DRaaS is also very fast! With a credit card and a virtual server environment, you can complete the most critical step in the process – replicating a copy of your data somewhere else. I can’t take credit for the crispness of this message, but I can point you who did. Jason Buffington, Senior Research Analyst at ESG provided this valuable insight and more, see here. As he correctly states, you might not have your whole plan in place – but you will complete the most critical step – replicating your data somewhere else!!

So, why should you consider DRaaS?

• Well, we already discussed the cost model. It can be cheaper for your environment, depending on the SLAs you require. The costs are also predictable.
• DRaaS can help with geographical diversity. If your DR site is across the street, this could be a problem. You can find a cloud provider who has something far away – providing increased confidence in your DR plan.
• Do you want to use cloud providers for other things? DRaaS is a great way to evaluate a cloud provider. The replication and ongoing testing is more interactive than Backup-as-a-service. It enables you to more rigorously test the cloud provider’s environment. As you build confidence, you may want to think about partnering with the cloud provider on other initiatives.
• DRaaS providers do this every day, so they are knowledgeable with how to get environments online quickly and can help you avoid common mistakes, plus they effectively serve as additional resources that are focused on your datacenter recovery.

DRaaS isn’t some “new” thing that only the most bleeding-edge companies are doing; it is on pace to be a $5.7 billion market in about 3 years. It is an option which deserves serious consideration. Check out our Zerto Cloud Ecosystem to learn more:

Guest Post by Dante Orsini, SVP Business Development, iland

Disaster Recovery-as-a-Service (DRaaS) enables an organization to failover applications and workloads to a cloud environment as its secondary, operational site, in the event of a disaster, whatever the nature of the disaster.

Why use a cloud environment for disaster recovery?

When downtime occurs, business continuity remains an expectation held by customers, partners and senior executives alike. Consequently the pressure is on for IT departments to protect an entity’s data and ensure employees, and other authorized parties, have access during a disaster event. Today, if you don’t have a solution for business continuity, it’s likely your competitors will.

One of the most compelling aspects of DRaaS is that you don’t need to own the technology, buy the hardware, or train personnel for your secondary site. DRaaS is typically on a subscription basis, so it becomes an operating expense rather than a capital expense. It’s also more cost effective because you pay for resources when you failover to the cloud. Failing over to a cloud enables the organization to continue operations much quicker than with traditional DR.

A customer’s core business is not one of storing data. That’s not a revenue-generating item and customers typically don’t have the technical capacity, in-house expertise or the time for it. They do, however, want the safety, security and peace of mind that a second site is ready to go, should an emergency situation arise..

What types of businesses are best served by DRaaS?

At iland we serve customers of all sizes across a range of industries. Companies approach us for a variety of reasons, but primarily it’s because they’ve undertaken a risk assessment and have a realistic understanding of what could happen if operations are compromised. Sometimes they’ve had a disaster near miss, or they’ve experienced a disaster and may not survive another one.

It’s important to note that no two DR plans are the same, so we tailor our DRaaS solutions according to each customer’s specific needs. Where one business is fine if customers can’t access data for a few hours or days, another will be fine only if customers can access data within a few minutes or less. For organizations that require 24/7 system availability, DRaaS is an attractive risk management option. Likewise, for customers that operate within regulated industries, a disaster recovery plan is typically a requirement for compliance reasons e.g. HIPAA, PCI DSS etc. Thus, many of these entities are turning to cloud-based DR as a more cost-effective and efficient way to protect applications and achieve business continuity.

How is DRaaS deployed in the event of a disaster?

iland provides many DRaaS options, including real-time replication using Zerto that enables a secondary site to take over at the push of a button. That kind of speed is usually important for organizations with public-facing sites or e-commerce businesses. We also have less immediate plans for those that don’t need such speedy failovers.

Customers have the option of iland managing their secondary site or they can self-manage it through iland’s award-winning ECS portal. Zerto is integrated into the portal, making failover to iland’s cloud environment just one click away.

However their DR plan is configured, customers know it ahead of time – including how to deploy the solution and access the site in the event of a disaster.

What are the risks or downside to DRaaS?

For companies used to doing everything themselves, it can be a challenge to shift their DR plan to a third party vendor. Doing that requires a solid working relationship, a good fit and complete trust in the cloud vendor. We believe cloud providers are, and should be, held to a higher standard – we maintain our own internal data sets and compliance-driven testing policies. At the end of the day, we are in the business of protecting our customers’ data and keeping it safe. Some organizations are skeptical about cloud, so we do encourage organizations to look closely at the background of any potential cloud vendor and the certifications they hold. What you don’t want is a provider that’s a fly-by-night operation with a couple of servers in a closet.

Some companies see the cost of DR as an unnecessary expense, but if you carefully consider the value of business continuity, retaining customers, saving transactions and protecting data, it’s a small price to pay in comparison. In fact, many companies see it as another, equally necessary form of insurance.

What else needs to be considered in the decision to adopt DRaaS?

Keep in mind that backup and disaster recovery are two different services. Sometimes we have customers tell us a backup vendor said that all they needed to do was to get their backed-up data to a secondary site,but it’s not that simple. Unless you have a plan you can test and a means to validate that everything works, you won’t have the confidence that a failover will be successful. While iland does provide backup services, it’s a DR plan that’s necessary for safeguarding an organization’s assets.

iland provides a DR Planning and Assessment Service that assists organizations with their DR planning. Whether you need to protect legacy applications on physical equipment, virtualized applications or even systems you operate in other clouds, iland brings over nine years of experience helping customers implement DR plans. Contact us at info@iland.com .

By Andrew Martin, Director of Asia Pacific & Japan

In the last two years I have seen transformations in channel dynamics that are more fundamental than anything I have seen in the previous twenty. Whilst I am not naive enough to believe that perfect channel dynamics ever existed anywhere; it has long been the case that vendors choose their route to market, either direct or via partners, and to a large extent they stick with the approach they have selected. System Integrators, for the most part, know which vendors they will have to compete with and which vendors they can expect to support them. Based on this, the channel has been able to build strong businesses based on domain expertise, product supply and, not to mention, value added services.

Everything as a Service, also known as XaaS, cloud computing and mobility are all impacting the channel dynamic in a way that in my experience has never happened before. As an example, in the “old days” (which are not so long ago) when Microsoft ended support for a server operating system this led to tangible channel opportunity for server upgrade projects. Today the focus for Microsoft is to encourage customers with unsupported server operating systems to upgrade directly onto Azure. As Azure is cloud based, the channel’s line on fulfillment is much more blurred than in the days of hardware and software supply, therefore a cloud upgrade is no longer an obvious “channel play”.

The bottom line is that the way IT is consumed has changed forever, and the way vendors go to market is transforming at a rapid rate. The net effect is that the channel ecosystem is going to have to adapt and reassess how they add value or become irrelevant. In the last six months, I have had more conversations than I can count with owners of resellers and system integrators that have run successful businesses for years but are finding that their traditional markets are drying up. The challenge they face is that the successful reseller business model that has worked for years is no longer sustainable, nor is it as relevant to buyers as it once was. Organisations are consuming and purchasing IT differently, because of this, the channel needs to review and change some of their go to market strategies in order to exploit the new world of opportunity that is before us.

Certain things still hold true, a reseller than can add value to IT no matter how it is consumed, will still gain the trust of the people and organisations they sell to. The key is to embrace the change that cloud and software-defined IT has caused, develop expertise in these areas and find new suppliers and solutions that are “born” in this new era of computing.

As an example, on the surface Zerto is just another replication company, but when you look deeper the technology has been developed for a new era of computing. Zerto takes a virtual or software defined view of the world and, in doing so, is fanning the flames of opportunity for resellers and systems integrators once again.

In the old days resellers developed skills in a product like backup; they did so in the knowledge that the built-in backup on the windows server operating system did not meet customer needs. Today the landscape has changed but the challenges still remain the same. Users are building virtualised IT infrastructures that leverage new consumption methods like XaaS, however these new methods still need a supporting cast of add on functions and products. In line with these changes, the supporting cast of specialist vendors is also evolving rapidly.

Zerto is one of the new supporting cast members, solving similar challenges but built for the new era we find ourselves in today. We provide a technology that has been built in a way that allows our partners to offer value add in a virtualised and/or cloud based world. In addition, companies like Zerto, who have developed solutions for today and into the future, understand that routes to market need to be accommodating and flexible in order to facilitate partner engagement.

One of the keys to successful change for the channel community is to search for the new breed of “born in the software defined era” vendors that have built products and solutions that are relevant to today’s ways of consuming IT. Advice for partners is to seek out vendors who are hungry for partnerships with companies looking to embrace the rapid change that is upon us and provide services that give genuine value so that you stay relevant to your customer’s ever-changing business needs.

For the channel, I believe this new breed of vendor is the future and the good news is that there are many more, including Zerto, who are forging a new path in this new era of IT.

By Joshua Stenhouse, Zerto Technical Marketing Manager

In disaster recovery terminology the term Recovery Point Objective, often abbreviated to RPO, is a widely used term. However, it is seldom fully understood in terms of being able to explain it easily and quantify the impact it has on a recovery scenario.

Put simply;

“The Recovery Point Objective is the point in time you can recover to in the event of a disaster”

Put into context this means that if you have a disaster, such as a database corruption, power outage, SAN failure or user error that ceases production operations then you will lose all of the data up until the achieved RPO. If you have an RPO of 4 hours on your critical applications then this means you would lose 4 hours of data, as 4 hours ago is the last point in time to which you can recover.

The cost of just 1 hour of lost data for any size business can be a significant amount and as you scale upwards this becomes an even larger impact. If we take a sample organization with a turnover of $100m you can see the potential impact:

Of course this is a very simplistic calculation of the annual revenue divided by number of days in a year and then hours in a day, but any attempt to be more exact would be a vast complicated exercise in coming to an answer of “I don’t know”. The reason being that it is impossible to know when a disaster will strike and over what time period the data loss will occur. You could be lucky and have a disaster out of working hours and lose no data, but this assumes you even have the concept of “out of working hours” in your organization, which many in this day and age do not. Or you could be really unlucky and have a disaster at peak usage during your busiest period, and of the 2 it always seems to be the latter!

Due to the importance of RPO on data loss, it is recommended to agree on an acceptable and achievable RPO on a per application basis with all of the relevant business units and owners. Once this has been done you might have a basic SLA such as the below:

• CRM System – 1 hour RPO
• Finance System – 1 hour RPO
• Email – 2 hour RPO
• File Servers – 4 hour RPO
• Directory Service – 8 hour RPO
• Print Servers – 24 hour RPO
• Development Servers – 24 hour RPO

If you have implemented a BC/DR technology to deliver the above RPOs by replicating on a schedule, as defined by the SLA, you may think you are covered, but you could be wrong.

The reason being is that you would always be “red lining” your achieved RPO to your SLA. By which I mean that by replicating on an hourly basis with perhaps a SAN based snapshot, the best you will ever do is meet the SLA. However, if there is a huge amount of data change you might start to miss that SLA and not to able to recover to a point acceptable to the business.

This is why you should always aim to achieve the lowest RPO possible, then configure alerts to warn if you are in danger of the achieved RPO getting close to your defined SLA. In order to ensure low priority applications don’t impact the RPO on high priority applications, a priority and Quality of Service (QoS) setting should be applied to individual replication streams. This ensures they are prioritized accordingly in the circumstances of high IO and/or low bandwidth.

By applying QoS you can ensure that any available bandwidth is used to maintain a consistently low RPO across all of your applications, yet if the bandwidth becomes constrained only the high priority applications continue to maintain the low RPO.

I hope this has given you a good insight on the subject of RPO and you can now use this knowledge to help you define your BC/DR strategy and SLAs.

Earlier this week,  I was elated to see an article I wrote published on cnet, about my colleague, Jennifer Gill, taking charge after being mistaken for a booth babe at a tech tradeshow. She created buttons that say, “I am not a booth babe. Ask me a question!” The response was overwhelmingly positive, with dozens of tweets and shares of the article and a groundswell of support for the idea. It was trending as the most popular cnet article for two days.

We’ve clearly struck a chord. A  number of people visited the website we created – iamnotaboothbabe.com – ordered buttons and asked to help distribute the pins at RSA and other upcoming shows. The article came just days after RSA conference organizers chose to set a dress code for the event this year – specifically to companies who employ “booth babes.”  According to the article:

All Expo staff are expected to dress in business and/or business casual attire. Exhibitors should ensure that the attire of all staff they deploy at their booth (whether the exhibitor’s direct employees or their contractors) be considered appropriate in a professional environment.

NYMag reported on the trend as well, asking, “Could this be the end of the booth babe trend?”

We hope so. Women in tech has been the topic of much conversation in recent weeks.  We’re hoping that it becomes common knowledge at tradeshows that company employees – all of them – are there to answer questions because they know and understand their company’s products.

“But I know a change’s gonna come, oh yes it will.” We’re glad to be able to play a small part.

Guest Post by Rob Selby, Lead Technical Design Architect, Adapt

A robust Disaster Recovery (DR) capability is mandatory for most businesses today – especially where IT is part of the workflow critical to continued operations or revenue generation. Software as a Service (SaaS) applications may mitigate risk by placing the responsibility for availability firmly with the service provider. However for those applications hosted either on-premise or with a partner, it pays to consider their ongoing business continuity needs.

Assessing Disaster Recovery tool options

Fortunately, the tools that make DR possible today have become much easier to install, configure and manage, removing some of the implementation costs. The almost ubiquitous virtualisation of workloads has also further simplified the process, removing vendor lock-in to expensive proprietary tools and giving customers access to much more choice and flexibility.

This increased choice and flexibility has fundamentally changed the traditional commercial considerations of providing DR. Businesses used to be reluctant to sink a large amount of Capex into what is essentially an insurance policy that you sincerely hope you will never have to invoke. The flexibility of the tools and the increased maturity of application level replication techniques has led to a large increase in the number of managed service providers offering a DR service that can be consumed under an Opex model, delivered with only a small internal resource investment.

What We Use

Adapt’s Recovery as a Service (RaaS) is built on Zerto replication software, with the target being a dedicated cloud environment within Adapt’s data centres.

The RaaS offering can be delivered on an Opex only commercial model, so really is that insurance policy – you are paying to have capacity available in the event of a disaster, but not to maintain that full capacity sitting there under normal operation. RaaS provides a high level of flexibility to customers, enabling them to scale the service in line with their business at a small incremental cost.

Implementing DR is simply a phone call to the Adapt support desk where, if necessary, the process of initiating and reconfiguring the virtual machines (VMs) starts. As standard with Zerto, the recovery point can be as low as a few seconds and the recovery time merely a factor of the number of VMs being protected. Once the VMs are powered up, the reconfiguration and quality assurance testing begins.

Customer Case Point

A potential customer approached Adapt with a requirement to provide a more comprehensive disaster recovery solution. Their current setup consisted of a fully virtualised primary infrastructure, hosted in a shared data centre and a secondary infrastructure hosted onsite in their head office with the hardware halfway depreciated.

The IT organisation understood the goals they needed to achieve and the corresponding service levels their business required. They understood that expanding their existing infrastructure wasn’t cost effective and would detract from the level of service they currently provided. The requirements had been set and the applications grouped into tiers of criticality, with the focus of the first phase on the tier one applications and inter-dependencies.

The solution proposed by Adapt was for the customer to provide an MPLS network tail into our RaaS platform. The base Zerto infrastructure was set up on the customer’s primary site and paired with Adapt’s RaaS platform – enabling tier one applications (consisting of just under 20 virtual machines) to be replicated and configured into the appropriate Virtual Protection Groups. The customer’s network provider managed the WAN component to allow network failover, meaning the virtual machines wouldn’t need reconfiguration when DR was activated.

Our customer was fully protected from Day 1, without having to spend any Capex, or invest months of internal resource in DR configuration, leaving the business exposed in other areas. The customer now only pays for the resource reservation of what they use, offering far greater value for money against the previous solution.

That business now has the flexibility to add in tier 2 and 3 applications, when they are ready, via a simple change request and an uplift in the reservation fee to account for the additional resources. For the customer, this is a win-win situation as all the pain of sizing DR and sinking large sums into hardware is negated, with the added bonus of vastly reducing the time, complexity and resource requirements to stand up the service.

A daunting & costly job?

Creating a DR solution for your business can seem daunting and can potentially leave a big hole in the IT budget. However with the latest tools and service offerings available, that doesn’t need to be the case.

If your business doesn’t have DR in place for your mission critical services, the mentioned use case shows it needn’t be a costly, Capex heavy project.

Is it time to review your current DR capabilities? Do the capabilities you have in place match your business continuity plans and equally importantly – are you getting the best bang for your DR buck?

Guest Post by Diana Nolting , Marketing Content Strategist, Bluelock

If you want to know what the future of IT looks like, you don’t need a crystal ball. You just need to chat with Jeff Ton, CIO and SVP of Corporate Connectivity at Goodwill Industries of Central Indiana.

Just a few weeks ago Ton took what he called, “a seismic shift forward in the way technology is delivered for my organization.”

By following a three-step process to get his IT team out of the business of managing the daily details of infrastructure Ton was able to focus his team on business-impacting strategic initiatives that not only impacted revenue, but positioned his team as a true partner within the larger business.

That seismic shift wasn’t an overnight change. It was the culmination of five years of work determined to bring more pronounced value to the business with the IT team and transition an 80-year old business to 100% cloud-based. Ton led a strategic journey that began as many do, with transitioning some applications to a SaaS model, starting by getting out of the business of managing email servers and leveraging Google mail.

Step two on the journey was to implement Recovery-as-a-Service (RaaS) through managed cloud hosting and recovery provider Bluelock, whose RaaS solution includes Zerto-replication.

“2014 (plus the first 10 days of 2015) saw the completion three major steps on this journey,” explains Ton in his blog, Amplify Your Value – A Seismic Shift Forward.
“The year started with our implementation of Recovery-as-a-Service (RaaS), modernizing our disaster recovery processes and providing a Recovery Time Objective (RTO) of under two hours and a Recovery Point Objective (RPO) of…get this…THIRTY SECONDS! (Insert legal disclaimer here “our experience may not match your actual results SLA’s do apply”). Too good to be true? We’ve done it!”

Ton continued his journey in late 2014 and early 2015 by migrating all of their production, test servers and data storage to Bluelock as well.

“What does our company gain from these efforts?” Ton asks. “In short, agility and elasticity.”

But, why read our words when you can read his story exactly as he experienced it in his words.

Read here for Ton’s full blog which details the benefits of managed cloud hosting, RaaS and shows you how your organization amplify their value to the business, too.

By Shannon Snowden, Zerto’s Sr. Technical Marketing Architect

What a great event! HIMSS 2015 in Chicago was full of compelling ideas, products and services that are completely healthcare IT focused.

(Photo Caption: Shannon Snowden, Zerto ‘s Sr. Technical Marketing Architect , presenting on Disaster Recovery for Electronic Protected Health Information

From the beginning of the show, until the last day, we had discussions with IT leaders – Directors, VPs and CIOs – at the Zerto booth, that were backed by a great sense of urgency to find a functional disaster recovery solution. They are tired of cobbling together solutions from different vendors to do disaster recovery.

Healthcare leaders are looking for a better way to protect their applications with a staff that is too busy already. I had a conversation with a hospital CTO that had no less than four different solutions for DR and he wasn’t happy with any of them.

None of the traditional solutions really allow for a relatively painless recovery for important applications like Epic, Cerner and McKesson from a disaster, even within their own subset of what they were protecting. So he had layers of inefficient solutions that actually compound the complexity and extend any outage, much less a full site disaster. In fact, he wasn’t sure exactly how a site-wide recovery would be performed because he had never tested the layers all together, but he was sure it would be painful, take way too long to perform, and wasn’t really repeatable.

I found the conversations had four common thematic pain points that Zerto addresses. The DR solution needs to be:

• Intuitive – Easy to configure, update and support.
• Powerful – Healthcare applications like Epic, McKesson and Cerner house some of the most important data that IT supports regardless of industry.
• Flexible – No matter what hardware you have or even if you decide to go to the cloud, your DR solution should support it natively.
• Reliable – The data must be quickly recoverable from any type of disaster and with as little end-user interaction as possible.

Until Zerto Virtual Replication (ZVR) came along a few years ago, these requirements really couldn’t be met or the solutions simply were too expensive. ZVR makes it clean and simple.

ZVR has changed that to where all of the ideal solution points are exactly the pain points ZVR addresses.

• Intuitive – ZVR installs in less than an hour and is easy to upgrade and administer from a friendly, intuitive interface.
• Powerful – Organizations running ZVR often have recovery point objects (RPOs) measured in the seconds. It’s not unusual at all to see a 10 second RPO. ZVR’s continuous data protection and 5 day point in time journal allows for the fastest recovery times (RTOs) in the industry. Many production Zerto customers know exactly how long it takes to fail over a single application or their entire datacenter.
• Flexible – ZVR is hardware agnostic and with version 4.0, ZVR is hypervisor agnostic by adding support for Hyper-V. Zerto also allows you to expand into the public clouds by supporting AWS as a target site.
• Reliable – Zerto is known for “just working” and doing what we say it does. Our customers have great confidence that when they need to failover, they can. With our non-disruptive testing capability, you can be sure that when you hit the red button, you can recover.

There were many amazing technologies at HIMSS that elevate the quality of healthcare and I count Zerto Virtual Replication amongst them. The ability to recover and entire data center, in a matter of minutes, from a disaster is too important with the data that is being protected in healthcare data centers.

Try Zerto Virtual Replication for yourself! We have free trials and are not disruptive to your production environment to test.

By Joshua Stenhouse, Zerto Technical Marketing Manager

In the final blog post of this series ( Part 1, Part 2, Part 3) on Zerto 4.0 support for Microsoft Hyper-V series I will cover cross–hypervisor replication for Microsoft Hyper-V and VMware vSphere.

In order to describe the processes involved with cross-hypervisor replication I am going to use the below example from my demo lab. In the lab I have 2 datacentres, Boston and London, each with a VMware vSphere and Microsoft Hyper-V environment and I have 4 Virtual Protection Groups (VPGs) replicating as per:

In the above configuration I have the 4 multi-VM applications that each consist of a database VM, file server VM and web front-end VM that together form my CRM application. They are set to replicate and recover as follows:

• CRMApp1 VPG replicating from Microsoft Hyper-V to Microsoft Hyper-V
• CRMApp2 VPG replicating from Microsoft Hyper-V to VMware vSphere
• CRMApp3 VPG replicating from VMware vSphere to VMware vSphere
• CRMApp4 VPG replicating from VMware vSphere to Microsoft Hyper-V

For the CRMApp1 and CRMApp3 VPGs as they are replicating within the same hypervisor then no conversion is required and the VM is kept exactly as is.

Microsoft Hyper-V to VMware vSphere Conversion

For CRMApp2 it is replicating from Microsoft Hyper-V to VMware vSphere and so requires conversion. Zerto replicates the data at the block level, from the source VHD, or VHDX disks, directly to VMDKs in the target VMware vSphere hypervisor. Zerto then simply replicates any changes, as they occur, continuously from the source disk and inserts them in the target disk format using our Virtual Replication Appliance (VRA) technology, it doesn’t matter that the underlying virtual disk is a different type. This means that there is no delay waiting for a disk format conversion when migrating or recovering the VM between the hypervisors, therefore maintaining a Recovery Time Objective (RTO) of just minutes.

When a move, failover, or failover test, is initiated from Microsoft Hyper-V to VMware vSphere ESXi Zerto follows the below process:

• A new VM is created in ESXi at the highest VM hardware version support for the target host
• Target VMDKs are attached to the new VM
• VMnics are added as E1000 adapters and by default are configured with the same IP and MAC address, unless a new IP and/or MAC address has been configured in the VPG
• The target VM is booted with the same name, disk layout, CPU and RAM configuration
• The process is reversed when failing back

This process does not currently include the installation of VMware tools. It is therefore recommended to install VMware tools in advance in order to maintain a low RTO. As the installation of VMware tools requires the VM to be running in VMware vSphere, the VMs should be migrated to the target VMware vSphere hypervisor out of working hours, the tools installed and the VM rebooted, then migrated back to the source Microsoft Hyper-V hypervisor. After migrating back the VMtools service will simply sit in an idle state ready for recovery in the VMware vSphere environment.

VMware vSphere to Microsoft Hyper-V Conversion

For CRMApp4 it is replicating from VMware vSphere to Microsoft Hyper-V. Zerto replicates the block level changes continuously from the source VMDK disks to target VHD or VHDX disks upon initial sync or pre-seeding.

When a move, failover or failover test is initiated from VMware vSphere ESXi to Microsoft Hyper-V Zerto follows the below process:

• A new VM is created in Hyper-V either as Gen1 or Gen2 depending on the supported configuration
• Target VHDs (if Gen1) or VHDXs (if Gen2) attached to the new VM
• VMNics are added and by default are configured with the same IP and MAC address, unless a new IP and/or MAC address has been configured in the VPG
• The target VM is booted with the same name, disk layout, CPU and RAM configuration
• The process is reversed when failing back

It should be noted that this process does not include the installation of host integration tools. If the guest OS is Windows Server 2012 then they are installed by default and no action is required. For any other OS you should perform the same process as is for installing VMware tools in advance by migrating, installing, rebooting and then migrating the VMs back to VMware to minimise the RTO.

Failover Testing

The cross-hypervisor replication in Zerto fully supports failover testing with no impact in production, or break in the replication. Thanks to this, I cannot recommend this feature enough to anybody replicating between hypervisors. You can use it to see how the VMs and guest OS behave in the target hypervisor without any impact, and then plan the steps needed to resolve the issues in advance of a migration or disaster recovery scenario.

This concludes my blog post series on Hyper-V support. I hope you enjoyed reading it and are looking forward to trying out our Hyper-V and cross-hypervisor replication support soon.

4 Things You Need to Know about Zerto Virtual Replication 4.0

It’s not every day that you get to announce a milestone release in a product that has been shipping for several years, but that’s what we’re doing with Zerto Virtual Replication 4.0.

Zerto, the standard for business continuity and disaster recovery for virtualized workloads is once again raising the bar. Here are the 4 main things you need to know about Zerto Virtual Replication 4.0.

The Zerto Cloud Continuity Platform

Imagine being able to determine your data protection solution by selecting two things:

• The service level uptime expectations of the application
• The costs associated with meeting the service level

Simplifying the choices to the essentials and creating a platform that can support it empowers the entire organization to focus on the business and innovation, not disasters. That is the Zerto Cloud Continuity Platform vision.

In a fully realized Cloud Continuity Platform model, there is no consideration of the infrastructure that it takes to meet the actual data protection requirements or any business requirements. It shouldn’t matter if the infrastructure includes an all on-premise, public cloud, or a hybrid solution to meet the requirements. The infrastructure should be able to handle it, and it should be easy to install and manage.

ZVR will be able to federate replication and failover orchestration on them all. We think this is the only realistic way to address the ever-increasing complexity.

Service offerings from private, public, SaaS and PaaS providers will continue to expand and new, interesting technologies such as containerization will always be emerging. The Zerto Cloud Continuity Platform will federate them all to a single logical data protection solution.

It is an exciting vision of what data protection can achieve when it is built upon the replication and orchestration capability of ZVR.

If you have a hypervisor in one datacenter that doesn’t match the hardware or hypervisor in another datacenter, it won’t matter you can still use it. If the cloud makes sense as either the source or target for your data protection design – use it.

For migrations, ZVR 4.0 offers options that you simply didn’t have before. With the non-disruptive testing capability, you can perfect the migration steps well before the actual downtime occurs. This makes for the shortest outages possible.

In ZVR version 4.0, we take the first steps in fulfilling the vision by introducing two new supported platforms and a completely new interface to manage it all.

ZVR 4.0 UI: The new face of data protection

Giving you the ability to perform complex replication and complete failover orchestration while keeping an intuitive management interface is in our DNA. But we wanted to provide even more capability from the UI to make it as easy as possible to manage the disparate DR platforms underneath.

We’ve taken years of feedback from large production customers, paired it with our ubiquitous infrastructure goals of the Cloud Continuity Platform and created a completely refactored user interface.

The first thing that greets you is a dashboard with all of your critical information in one view. Key Performance Indicators are right in front of you for quick analysis. Both real-time and historic information are the dashboard and the VPG status is shown as a green, yellow or red heat map of health. All of the creation tasks are now wizard-driven for easier administration.

The new UI is based on HTML5, so you have even more choices of what device you can use to manage your data protection.

Hypervisor Agnostic: ZVR now supports Microsoft Hyper-V

ZVR 4.0 adds Microsoft Hyper-V support. This includes cross-hypervisor replication between a Microsoft Hyper-V and a VMware vSphere site. This is one of the milestone additions in capability because it is the first step in ZVR being hypervisor agnostic as well as hardware agnostic.

Deployment and management is remarkably similar to what you experience in a VMware-only deployment. In fact, you won’t really know the difference between hypervisors in the Zerto UI. It looks, performs and is managed exactly the same. You may find yourself opening the System Center Virtual Machine Manager (SCVMM) to ensure the VMs were actually failing over to Hyper-V and not vSphere.

Of course, crossing hypervisors comes with some additional things to know about drivers and guest operating systems behavior when failing over. Zerto has made that information readily accessible and makes easier to deploy mixed hypervisor solution.

Support for Microsoft Hyper-V helps you reduce costs by leveraging already owned Hyper-V licenses for DR or for test and development. Zerto makes the conversion of the workload from the Hyper-V environment to the VMware production environment as simple as point and click.

DR to the Public Cloud: ZVR supports Amazon Web Services (AWS) as the recovery site with ZVR for AWS 1.0

ZVR now allows you to use AWS as the target site for your DR. Since this is our first public cloud offering, we wanted to highlight that point, so we gave it a 1.0 version number.

You will be able to mix your on premise protection with a public cloud for certain applications that may not need the aggressive RTO and RPOs that on premise solutions offer.

You don’t have to settle for less; ZVR brings our award-winning enterprise class replication and orchestration performance abilities to AWS too. RPOs are measured in seconds and you will see RTOs faster than any other solution.

Along with DR, there are several uses for on premise to AWS including:

• Test/Development to reduce costs
• Eliminate cost of DR site with an OPEX line item
• Migrate to AWS to eliminate hardware maintenance and obtain on demand resources

If you are familiar with the ZVR architecture, the graphic below should look very familiar. Going to AWS shouldn’t mean you have to use different methodologies and tools to use it. With ZVR 4.0, you don’t.

The deployment on the on-premise side is exactly the same as it always has been, plus you can use Hyper-V on the source side as well. In fact, it can be paired with other non-AWS sites at the same time. The virtual machines are placed in to virtual protection groups and the VMs are all protected and have write-order fidelity between them. We still have the 5-day point in time journal for AWS recoveries as well to keep it the same as an on-premise solution.

Try it now!

With all the new features and options, if you haven’t tried ZVR 4.0, we make it really easy.

Zerto Virtual Replication 4.0 is here and the excitement, both here at Zerto and outside the company, is buzzing. User are talking about the new features including: protecting, replicating, and migrating data between VMware vSphere and Microsoft Hyper-V hypervisors, as well as across private, hybrid and public cloud environments including Amazon Web Services (AWS).

You have heard what we are Zerto have to say about the 4.0 release, but we wanted to share with you what others in the industry are saying.

PeaSoup: CTO Blog – DR in the Cloud using Zerto 4.0 (part 2 of 2)

Vladan Seget ESX Virtualization: Zerto Virtual Replication 4 Released

Viktorious Virtualization and Cloud Management: Zerto announces Zerto Virtual Replication 4.0

The IT Hollow: Zerto 4 – To Amazon and Beyond

Settlersoman A Settler in the SDDC World: Zerto Virtual Replication 4.0: Architecture overview and features.

VMblog.com Virtualization Technology News and Information: Zerto Announces General Availability of Zerto Virtual Replication Version 4.0

CloudExpo Blog: Zerto Virtual Replication 4.0 Released

By Joshua Stenhouse, Zerto Technical Marketing Manager

In disaster recovery the term Recovery Time Objective (RTO) can be simply be defined as:

“The time that it takes to recover data and applications”

This means that in the event of a disaster, such as a system wide virus, a user error deleting production data, or a key hardware failure, the RTO is the time it will take to recover from this disaster and have the data and applications back online and running in your recovery site.

The cost of the downtime associated with waiting for applications and data to be recovered can result in significant loss in revenue and productivity, as your business may have no applications available in order to continue generating revenue. In even the smallest of organizations this can be a significant figure and below is an example for a company with a turnover of $100m:

In this example you can see the potential revenue impact is a significant amount and this is the most basic of calculations of the annual revenue, divided by days in the year and hours in the day. The actual figure can be significantly worse if the disaster occurs in working hours. Additionally, this calculation doesn’t even attempt to quantify the impact on customers, brand identity, market perception, suppliers and share price which can increase the impact exponentially.

It is therefore important for any organization to try and attain the lowest possible RTO in order to minimise the impact of a disaster in a timely manner if and when required. Your RTO should be defined on a per application basis in order to prioritize the recovery of certain applications, in advance of others, depending on their level of criticality. This has the added benefit of ensuring that revenue generating applications are recovered first and ensuring that theIT staff focus on these before anything else.. An example RTO SLA could be:

• CRM System – 4 hour RTO
• Finance System – 4 hour RTO
• Email – 4 hour RTO
• File Servers – 4 hour RTO
• Directory Service – 2 hour RTO
• Print Servers – 24 hour RTO
• Dev Servers – 24 hour RTO

Achieving the above RTOs with any BC/DR technology is not as easy as it first seems.Just registering and powering on Virtual Machines (VMs) is not your true RTO and nor should it be the RTO that you communicate as an achievable SLA to the business.

Registering and Powering on a VM is the simplest part of any recovery operation. The most complex and time consuming part is:

• Reconfiguring the VMs to run in the recovery site( such as MAC and IP address changes).
• Restoring from a working point in time where data is consistent.
• Finally ensuring all of the applications can communicate with each other and that they are up and running.

All of this should be done before communicating to the business that the application is back online and ready to use. The time that this whole process takes is your actual RTO and is the one that should be defined in your SLA.

By utilizing a BC/DR technology that can automate the process of registering, powering on VMs in the correct order and automatically reconfiguring IP and MAC addresses, you are going to give yourself the best shot and maintaining a low RTO. If this technology also allows you to try specific points in time, then rollback to a previous point in time, if the first recovery does not work, then you are ensuring recovery is not a “one shot” thing but rather a process.

In order to benchmark your RTO and tweak your BC/DR plan to minimize the time, testing is a must. By testing your plan with a BC/DR technology that allows for testing with no downtime in production, or break in the replication, you can perform a testduring working hours to ensure that: first of all you are able recover, then you can run through the recovery operation multiple times to get your RTO as low as possible.

I hope this has given you a good insight into RTO and the things you should take into consideration when applying RTO SLAs to your applications, and how you prove they are achievable.