To Tier or not to Tier

Transcription

1 WHITEPAPERS To Tier or not to Tier Replicating VMware Workloads for Disaster Recovery Chances are, you already have protections in place for the event of a big storm that might threaten your business and its data. You have a cloud backup system for storing your important files, and a disaster recovery blueprint that will help you get those files back and keep your operations up to speed. But that doesn t mean you re 100 percent protected, necessarily you still have to think about downtime and the impact it might have on your business.

2 What are the best practices for Disaster Recovery (DR) and how to build a DR plan, tier (prioritize) applications, and establish recovery points and times for VMware-based workloads? We start by exploring high level business and IT stumbling blocks faced by Virtacore s customers in rationalizing, building, and managing a DR plan more specifically, a robust, cloud-based disaster recovery as a service (DRaaS) plan. Here s a sampling of what new customers tell us: I don t have a DR plan in place today My DR site is end of life and I don t want to reinvest I have a DR plan, but it hasn t been tested regularly It s too costly to justify a second site for my business I m not sure what applications and data I should protect I m not clear on what my recovery points and times need to be I need to meet compliance requirements Disaster recovery is often viewed as an insurance policy for your business and data. CEOs and CFOs don t want to pay too much for it, but like insurance they re glad it s in place when they need it. If a disaster event occurs and you re not properly prepared with a fail-over plan, run book, and application tiers, your business will suffer considerable losses and you may find yourself facing a career changing event. Business disasters come in many forms operational failures, natural disasters, and human events. The chart below highlights the most common causes of such disasters: 1

3 When a disaster occurs, it s clear enough that revenue will suffer. But the same Forrester survey referenced above highlights many other pain points in the chart below: Faced with this reality, we suggest starting at the top of your organization to get operational and financial buy-in from your executive team regarding the need for a disaster recovery plan/solution. A simple starting point to justify the need for DR is the hourly downtime formula: Total Company Revenue divided by Annual Operational Business Hours = Potential Revenue Loss per Hour of Downtime For example, if you have a $50 million annual revenue business that is operational 2,400 hours per year, your hourly loss would equal: $50,000,000 / 2,400 = $20,833 per hour of downtime Using this formula, you can quantify the cost of downtime vs. the cost of a DRaaS solution. And keep in mind that this downtime revenue loss formula captures only a fraction of the total cost, as indicated by the survey results above. (It s also worth noting that some business insurance covers a portion of the financial cost of outages or disasters and related business interruption.) 2

4 Once your team decides it makes sense to protect your business with a DR plan, it s time to dig a bit deeper and start looking at your application stack and determining which apps truly drive your business and financial performance and must stay operational. Every business is unique, but typical critical workloads include SQL, ERP, IIS, Oracle, Financial Services, and Sharepoint. The key questions to ask for each application that could go down are: How would we function? How would our customers function? How would we access systems and recover? What are the other repercussions? Disaster recovery is not a one-size-fits-all solution, and businesses must understand operational and financial challenges and limitations of various solutions. For example, some large file systems with low churn rates are not necessarily good candidates for costly near real-time replication. And some transactional systems require sub-minute or real-time recovery points and times. An intelligent DR architecture takes a contextual approach to solving the problem by breaking up the applications and servers into tiers of priority and proxy tiers of DR technology solutions. This enables each customer to have a flexible approach to DR that leverages the best tools at the best cost for their particular systems and applications. The pyramid diagram below illustrates this approach: At the top level are the short list of applications and systems that should not suffer any data loss. These systems often include directory services, financial transaction systems, and front-facing web-based apps serving external client needs. The recovery point in this tier should be sub-second or real-time. As a result, this tier typically leverages native application-level replication. Such solutions can be complex and often require online or pilot light services at the DR site, making them more expensive to maintain on a day-to-day basis. 3

5 Target applications in the main level are those that can tolerate minimal loss of data in a disaster situation generally, ten minutes or less. These applications are very important to daily business operations and transactional in nature. An organization would normally seek an asynchronous replication solution in this tier, either at the storage level via SAN-based replication or at the hypervisor level using a replication solution that streams I/O as it is being written real-time to the DR site. Solutions in this tier should offer a high level of automation and orchestration to enable near-seamless failover. At the base level, an organization should be targeting lower priority workloads that can be protected with a simple offsite backup copy of the data. These offsite copies are typically produced via backup software, but can also come from storage replicas. This approach would produce a local copy of the data for near line restore capability, while also making an offsite copy available daily at the DR site. The recovery point in this tier should be less than 24 hours. Once you pare back the application stack, you ll clearly see that some apps are more critical to the business that others. Similarly, certain data is more valuable and critical to the business and simply can t be lost, often due to SEC, HIPAA, SOX, or PCI compliance mandates. For example, losing patient information is unacceptable, but losing data entry from your business website may be tolerable for a very limited period of time. In short, you must categorize each application into one of the following three tiers: Tier 1 mission critical Tier 2 critical Tier 3 non-critical Defining application tiers relies on IT and business managers understanding each underlying IT application s assets and how they are used and valued by the business. For example, is the application/data used for CRM, accounting, internal communications, and/or customer facing web apps? And how many users access the applications and when? With this information in hand, you can define for each tier the applicable recovery time and data loss parameters: Recovery Time Objective (RTO) Defined as the acceptable amount of time to restore the function. The RTO must ensure that the Maximum Tolerable Period of Disruption (MTPoD) for each application is not exceeded. Typically, Tier 1 recovery time is 0-2 hours, Tier 2 is 4-24 hours, and Tier 3 is 24+ hours. 4

6 Recovery Point Objective (RPO) Defined as the acceptable latency of data that will not be recovered. The RPO must ensure that the maximum tolerable data loss for each application is not exceeded (for example, can your company afford to lose one day or even one hour of certain data?). Defining data loss parameters requires a business impact analysis (BIA), which differentiates critical/ urgent IT applications from non-critical/non-urgent ones. Critical business applications are those for which disruption is regarded as unacceptable. RPO values are assigned to each critical application, based on the business and/or technical requirements for recovery of the critical application. With executive buy-in, approved budget, application tiers defined, and RPOs/RTOs established, now it s time to find a provider to implement your DRaaS plan (in reality, this provider may have already helped develop your high level DR plan and assign tiers, etc.). We suggest you zone in on: Technology you want enterprise reference architecture and flexibility to help you navigate your unique Tier workloads and RPOs/RTOs (not one size fits all) Value you want a team of problem solvers available and committed to supporting your business and IT team around the clock Price stating the obvious, you want a reasonable, highly competitive price for your disaster recovery insurance Cloud disaster recovery benefits include increased flexibility, better asset utilization, and reduced operational and maintenance costs. If you are force-fitting a physical replication solution for DR of virtualized applications, you re missing out on the key benefits of virtualized DR in the cloud. Protecting mission-critical applications, servers, and databases is not only about copying data. It s about ensuring application recovery, protecting from logical errors, and testing failover regularly to ensure you can fully recover when needed. To learn more about Virtacore s VMware-based DRaaS solutions and expertise, check out our website at We also encourage you to follow us on social media outlets for the latest updates. To request a Solutions Engineer to discuss a solution specific to your needs, please contact us at solutions@virtacore.com. 5