Redpaper. A Disaster Recovery. Solution Selection Methodology. Front cover. ibm.com/redbooks. Learn and apply a Disaster Recovery

Transcription

1 Front cover A Disaster Recovery Solution Selection Methodology Learn and apply a Disaster Recovery Solution Selection Methodology How to find the right Disaster Recovery solution Working with IBM TotalStorage products Cathy Warrick John Sing ibm.com/redbooks Redpaper

2

3 International Technical Support Organization A Disaster Recovery Solution Selection Methodology February 2004

4 Note: Before using this information and the product it supports, read the information in Notices on page v. First Edition (February 2004) This edition applies to the gamut of IBM TotalStorage products. Copyright International Business Machines Corporation All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Notices v Trademarks vi Preface vii The team that wrote this Redpaper vii Become a published author vii Comments welcome viii Chapter 1. Disaster Recovery Solution Selection Methodology The challenge in selecting Disaster Recovery solutions The nature of Disaster Recovery solutions The tiers of Disaster Recovery Blending tiers into an optimized solution Using tiers as a communication tool to senior management and others The use of tiers in this Redpaper Disaster Recovery Solution Selection Methodology tutorial Flowchart of the methodology Intended usage and limitations of the methodology Hourglass concept in Disaster Recovery Solution Methodology Steps in the Disaster Recovery Solution Selection Methodology Value of the Disaster Recovery Solution Selection Methodology Step D: Turn over identified solutions to detailed evaluation team Updating the methodology as technology advances An example: Using the DR Solution Selection Methodology Step A: Ask specific questions in a specific order Step B: Use level of outage and Tier/RTO to identify RTO solution subset Step C: Eliminate non-solutions Step D: Turn over identified preliminary solutions to evaluation team Summary Chapter 2. Sample scenarios Scenario 1: An efficient 24-hour recovery Step A: Client requirements Step B: Level of outage and Tier/RTO to identify RTO solution subset Step C: Eliminate non-solutions Scenario 2: A long distance recovery at Tier Step A: Client requirements Step B: Level of outage and Tier/RTO to identify RTO solution subset Step C: Eliminate non-solutions Scenario 3: Enterprise long distance recovery at Tier Step A: Client requirements Step B: Level of outage and Tier/RTO to identify RTO solution subset Step C: Eliminate non-solutions Appendix A. Disaster Recovery Solution Selection Methodology matrixes Starter set of business requirement questions Disaster Recovery Solution Matrix Notes on the Solution Matrix cells Eliminate non-solutions matrixes Copyright IBM Corp All rights reserved. iii

6 Tier 7 Planned Outage Tier 7 Unplanned Outage Tier 7 Transaction Integrity Tier 6 Planned Outage Tier 6 Unplanned Outage Tier 6 Transaction Integrity Tier 5 Planned Outage Tier 5 Unplanned Outage Tier 5 Transaction Integrity Tiers 4 and 3 Planned Outage Tier 4 Unplanned Outage Tier 4 Transaction Integrity Tier 3 Unplanned Outage Tier 3 Transaction Integrity Tiers 2 and 1 Planned Outage Tiers 2 and 1 Unplanned Outage Tiers 2 and 1 Transaction Integrity Additional business requirements questions Justifying business continuance to the business Business requirements questions for detailed evaluation team Related publications IBM Redbooks How to get IBM Redbooks Help from IBM Index iv A Disaster Recovery Solution Selection Methodology

7 Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. references in this information to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Copyright IBM Corp All rights reserved. v

8 Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: FlashCopy Redbooks(logo) AIX AS/400 DB2 Enterprise Storage Server ESCON ^ FICON GDPS HyperSwap ibm.com IBM OS/390 OS/400 pseries Redbooks RS/6000 S/390 Tivoli TotalStorage z/os zseries The following terms are trademarks of other companies: Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others. vi A Disaster Recovery Solution Selection Methodology

9 Preface This Redpaper will help you design a Disaster Recovery solution and presents a Disaster Recovery Solution Selection Methodology to assist in this process. The team that wrote this Redpaper This Redpaper was produced by a team of specialists from around the world working at the International Technical Support Organization, San Jose Center. Cathy Warrick is a Project Leader at the International Technical Support Organization, San Jose Center. Before joining the ITSO, she worked in the IBM Storage Field Education group, managing the Technical Leadership Program John Sing is a Senior Consultant with IBM Systems Group Business Continuance Strategy and Planning, helping to plan and integrate IBM TotalStorage products into the overall IBM Business Continuance strategy and product portfolio. He started in the Disaster Recovery arena in 1994 while on assignment to IBM Hong Kong S.A.R. of China and IBM China. In 1998, John joined the Enterprise Storage Server (ESS) Planning team for PPRC, XRC, and FlashCopy ; in 2000, John became the Marketing Manager for ESS Copy Services, and in mid-2002, joined the Systems Group. John has been with IBM for 22 years. Thanks to the following people for their contributions to this project: Rainer Eisele, SVA GmbH, an IBM Business Partner Ray Pratts, Mark III System, an IBM Business Partner Ulrich Walter, IBM Ian R. Wright, IBM Become a published author Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or clients. Your efforts will help increase product acceptance and client satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html Copyright IBM Corp All rights reserved. vii

10 Comments welcome Your comments are important to us! We want our papers to be as helpful as possible. Send us your comments about this Redpaper or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an Internet note to: Mail your comments to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California viii A Disaster Recovery Solution Selection Methodology

11 1 Chapter 1. Disaster Recovery Solution Selection Methodology There are a wide variety of IBM TotalStorage Disaster Recovery technologies and solutions. Each are very powerful in their own way, and each has their own unique characteristics. How can we select the optimum combination of solutions? How do we organize and manage all these valid Disaster Recovery technologies? These questions have vexed Disaster Recovery solution designers for a long time. Developing the skill to perform this selection function effectively was often time consuming and incomplete. It can be difficult to transfer these skills to other colleagues. In this Redpaper, we offer a suggested Disaster Recovery Solution Selection Methodology that is designed to provide assistance to this problem. The intent of our methodology is to allow us to navigate the seemingly endless permutations of Disaster Recovery technology quickly and efficiently, and to identify initial preliminary, valid, cost-justified solutions. This methodology is not designed to replace in-depth skills. It is meant as a guideline and a framework. Proper application of this methodology can significantly reduce the effort and time required to identify proper solutions, and therefore accelerate the selection cycle. For more information about this methodology, see the redbook IBM TotalStorage Solutions for Disaster Recovery, SG Copyright IBM Corp All rights reserved. 1

12 1.1 The challenge in selecting Disaster Recovery solutions From an IT infrastructure standpoint, there are a large variety of valid Disaster Recovery products. The fundamental challenge is to select the optimum blend of all these Disaster Recovery products and technologies. The common problem in the past has been a tendency to view the Disaster Recovery solution as individual product technologies and piece parts; see Figure 1-1. Instead, Disaster Recovery solutions need to be viewed as a whole, integrated multiproduct solution. In this chapter we propose a Disaster Recovery Solution Selection Methodology that can be used to sort, summarize, and organize the various business requirements in a methodical way. Then, we methodically use those business requirements to efficiently identify a proper and valid subset of Disaster Recovery technologies to address the requirements. Each vendor and product area tends to build separate pieces of the solution Insufficient interlocking of the different areas Business Continuance and Disaster Recovery need to be seen as an integrated product solution Many valid technologies, but how to choose among them? Figure 1-1 Historical challenges in selecting Disaster Recovery solutions The nature of Disaster Recovery solutions To combine and properly select among multiple products, disciplines, and skills to effect a successful IT Disaster Recovery solution, we first observe that we can categorize all valid Disaster Recovery IT technologies into five component domains: Servers Storage Software and automation Networking and physical infrastructure Skills and services required to implement and operate the above All IT infrastructure necessary to support the Disaster Recovery solution can be inserted into one of these five components; see Figure 1-2 on page 3. 2 A Disaster Recovery Solution Selection Methodology

13 The Solution: True Nature of Disaster Recovery xseries pseries iseries Solaris HP-UX WinNT/2000 zseries xseries pseries iseries Solaris HP-UX WinNT/2000 Operating System Applications Operations Staff zseries Data Network Staff Applications Staff Management Control A comprehensive approach with the five IT component areas results in a solution: Telecom Network Physical Facilities 1. Servers 2. Storage 3. Software and Automation 4. Networking (includes Physical Infrastructure) 5. Skills and Services Provide all five to assure: "On Time, On Budget, On Demand" Figure 1-2 The five components These five categories provide a framework to organize the various component evaluation skills that will be needed. Gathering the proper mix of evaluation skills together facilitates an effective comparison, contrast, and blending of all five product component areas to arrive at an optimum solution. 1.2 The tiers of Disaster Recovery The concept of tiers is a common method used in today s best practices for Disaster Recovery solution design. The concept of tiers is powerful and central to our selection methodology, because the tiers concept recognizes that for a given client Recovery Time Objective (RTO), all Disaster Recovery products and technologies can be sorted into a RTO solution subset that addresses that particular RTO range. By categorizing Disaster Recovery technology into the various tiers, we have the capability to more easily match our desired RTO time with the optimum set of technologies. The reason for multiple tiers is that as the RTO time decreases, the optimum Disaster Recovery technologies for RTO must change. For any given RTO, there are always a particular set of optimum price/performance Disaster Recovery technologies. The tiers concept is flexible. As products and functions change and improve over time, the Tiers chart only needs to be updated by the addition of that new technology into the appropriate tier and RTO. The Tiers chart, shown in Figure 1-3 on page 4, gives a generalized view of some of today s IBM Disaster Recovery technologies by tier. As the recovery time becomes shorter, then Chapter 1. Disaster Recovery Solution Selection Methodology 3

14 more aggressive Disaster Recovery technologies must be applied to achieve that RTO (carrying with them their associated increase in value and capital cost). Tiers of Disaster Recovery Best Disaster Recovery practice is blend tiers of solutions in order to maximize application coverage at lowest possible cost. One size, one technology, or one methodology doesn't fit all applications. Value Tier 7 - Highly automated, business wide, integrated solution (Example: GDPS/PPRC/VTS P2P, AIX HACMP/PPRC, OS/400 HABP... minutes to hours data recreation up to 24 hours data recreation hours data recreation 15 Min. 1-4 Hr Hr Hr Hr.. 24 Hr.. Days Figure 1-3 Tiers of Disaster Recovery Tier 6 - Storage mirroring (example: XRC, PPRC, VTS Peer to Peer) Tier 5 - Software two site, two phase commit (transaction integrity) Tier 4 - Batch/Online database shadowing & journaling, Point in Time disk copy (FlashCopy), TSM-DRM Tier 3 - Electronic Vaulting, TSM**, Tape Tier 2 - PTAM, Hot Site, TSM** Tier 1 - PTAM* Recovery Time Tiers based on SHARE definitions Zero or near zero data recreation Applications with low tolerance to outage Applications somewhat tolerant to outage Applications very tolerant to outage *PTAM = Pickup Truck Access Method with Tape **TSM = Tivoli Storage Manager *** = Geographically Dispersed Parallel Sysplex The concept and shape of the Tiers chart continues to apply even as the scale of the application or applications changes. Large scale applications will tend to move the curve to the right, and small scale applications will tend to move the curve to the left. But in both cases, the general relationship of the various tiers and Disaster Recovery technologies to each other remains the same. Finally, although some Disaster Recovery technologies fit into multiple tiers, clearly there is not one Disaster Recovery technology that can be optimized for all the tiers. Of course, your technical staff can and should, when appropriate, create a specific version of the Tiers chart for your particular environment. After the staff agrees on what tier or tiers and corresponding RTO a solution delivers for your enterprise, then Disaster Recovery technical evaluation and comparisons are much easier, and the technology alternatives can be tracked and organized in relation to each other. Although the technology within the tiers has obviously changed through time, the concept continues to be as valid today as when it was first described by the U.S. SHARE user group in Blending tiers into an optimized solution Best practices today in designing a Disaster Recovery solution is to further use the tiers concept to derive a blended Disaster Recovery solution for the entire enterprise. The most common result, from an enterprise standpoint, is a strategic architecture of three tiers in a blended Disaster Recovery solution. Three tiers generally appear as an optimum number, 4 A Disaster Recovery Solution Selection Methodology

15 because at the enterprise level, two tiers generally are insufficiently optimized (in other words, overkill at some point and underkill at others), and four tiers are more complex, but generally do not provide enough additional strategic benefit. To use the tiers to derive a blended, optimized enterprise Disaster Recovery architecture, we suggest the following steps: 1. Categorize the business' entire set of applications into three bands: Low tolerance to outage, Somewhat tolerant to outage, and Very tolerant to outage. Of course, although some applications that are not in and of themselves critical, they do feed the critical applications. Therefore, those applications would need to be included in the higher tier. 2. Within each band, there are tiers. The individual tiers represent the major Disaster Recovery technology choices for that band. It is not necessary to use all the tiers, and of course, it is not necessary to use all the technologies. 3. After we have segmented the applications (as best we can) into the three bands, we usually select one best strategic Disaster Recovery methodology for that band. The contents of the tiers are the candidate technologies from which the strategic methodology is chosen. A blended architecture optimizes and maps the varying application recovery time requirements with an appropriate technology at an optimized cost. The net resulting blended tier Disaster Recovery architecture provides the best possible application coverage for the minimum cost Using tiers as a communication tool to senior management and others The concept of tiers is also very useful as a communication tool regarding Disaster Recovery solution recommendations to others in the department, and especially to senior management. The tier concept is simple enough that non-technical personnel can see the end result of technical evaluations in a straightforward fashion. Senior management does not need to understand the technology that is inside the tier; but they can clearly see the Recovery Time Objective and the associated cost versus RTO trade-off. This ability to communicate the bottom line allows senior management to understand the recommendation, the trade-offs, and therefore make a decision quickly and efficiently. Because of the clarity of the decision alternatives, it can be more likely that management understands the choices and reaches decisions more quickly. This clarity of the choices and the associated financial cost should result in a higher likelihood of adequate funding for the Disaster Recovery project The use of tiers in this Redpaper We categorized the product information in this Redpaper by tiers. You will easily be able to recognize what tier or tiers any given technology is likely to be in, and in this way, be able to categorize where a particular Disaster Recovery tool and solution can be used in your environment. In Figure 1-4 on page 6 is a partial summary list of the many IBM technologies that will be categorized in this Redpaper. Chapter 1. Disaster Recovery Solution Selection Methodology 5

16 IBM eserver / TotalStorage Disaster Recovery Portfolio of Tools Applications Servers Site 1 Primary disk Common Timers Clustering Facilities Clustering Facilities Site 2 Mirrored disk Applications Servers eserver zseries: #2: Data Integrity Geographically Dispersed Parallel Sysplex (GDPS) - Tier 7 pseries: AIX/HACMP (High Availability Clustered Multi-Processors) with PRRC - (Tier 7) iseries: High Availability Business Partner software: Vision, Lakeview, DataMirror (Tier 7) xseries: X-Architecture, Blades (Tier 6) IBM TotalStorage ESS PPRC (Tier 6) ESS XRC (Tier 6) #1: Byte Movers Virtual Tape Server Peer to Peer (Tier 6) FAStT, SAN Volume Ctlr Mirroring (Tier 6) ESS, FAStT, SAN Volume Controller FlashCopy (Tier 4) 3590, 3592, LTO tape (Tier 1,2,3,4) Storage software (Tier 1,2,3,4) Software and Automation DB2, IMS, CICS, WebSphere (Tier 5) WebSphere, MQ (Tier 5) Tivoli Storage Manager (Tier 2,3,4) IGS, Business Partner Services #3: Transaction Integrity Networking and Infrastructure IBM Global Services, IBM Business Partners, IBM Networking Partners Figure 1-4 Portfolio of tools 1.4 Disaster Recovery Solution Selection Methodology tutorial So let's now go into detail about using this methodology. The following sections provide a tutorial and examples of using this methodology to more efficiently identify and select the Disaster Recovery technology that best fits your IT environment Flowchart of the methodology The Disaster Recovery Solution Selection Methodology is designed to provide a clear, understandable, flexible, and repeatable method to efficiently subset, organize, and select initial preliminary Disaster Recovery solution recommendations from the wide, possible portfolio of technologies. In Figure 1-5 on page 7 is a flowchart of our suggested methodology. 6 A Disaster Recovery Solution Selection Methodology

17 Flow of Disaster Recovery Solution Selection Methodology We need to be online 24x7 The Tiers of Disaster Recovery DR solution matrix Detailed DR solution description table CEO Hmm... That means Oracle and SAP must be recovered Risk Analysis results BIA / RTO RPO Analysis results Define the Tier level for each application Identify DR solution subset from DR solution matrix Eliminate DR solutions that do not apply to all requirements Valid preliminary candidate solution Business Requirements CO Figure 1-5 Flow of the Disaster Recovery Solution Selection Methodology Detailed Evaluation Team Note that the prerequisite to entering the methodology is having already performed and reached organizational agreement on the business requirements: Risk analysis, Business Impact Analysis, application segmentation, and associated Recovery Time Objectives and Recovery Point Objectives. The Disaster Recovery Solution Selection Methodology is designed to: Provide a methodology to quickly and repeatedly identify valid initial configuration options, which is intended to accelerate determining the final solution. Enforce asking of correct business and IT requirements questions for a proper Disaster Recovery configuration. Provide a convergence discussion methodology for the multiple products and IT disciplines that must make up an integrated Disaster Recovery solution. Be easily extendable as products and technologies evolve. Capture basic expert Disaster Recovery intellectual capital in a teachable, repeatable way, and provide a framework to consistently propagate these basic skills to a worldwide audience, remote or local Intended usage and limitations of the methodology The Disaster Recovery Solution Selection Methodology is intended to be used early in the selection cycle to establish a generalized vision of what are the requirements and what kinds of solutions and Disaster Recovery technologies to start investigating to solve any particular set of Disaster Recovery requirements. See Figure 1-6 on page 8. Chapter 1. Disaster Recovery Solution Selection Methodology 7

18 Intended Use of DR Solution Selection Methodology CEO We need to be online 24x7 Hmm... That means Oracle and SAP must be recovered CIO Promote asking of proper initial questions and collection of proper information The planning and evaluation cycle Evaluate the business environment Develop business strategy and initiatives Recognize needs Evaluate Options DR Solution Selection Methodology select Solution Option Resolve concerns and decide Detailed Evaluation Team Implement solution and evaluate success Identification of valid initial solution technologies and possibilities Turn over identified subset of possible solutions to evaluation team for detailed investigation and selection Figure 1-6 Intended use of Disaster Recovery Selection Methodology It is important to note what the Disaster Recovery Solution Selection Methodology cannot do: Not intended to replace detailed solution recommendation configuration assistance. Not intended to replace in-depth technical validation. Not intended to replace detailed design and implementation skills and services. The detailed evaluation team will perform those functions. The Disaster Recovery Solution Selection Methodology is not intended to be a perfect decision tree. Rather, it is a framework for efficiently organizing multiple Disaster Recovery technologies, and more quickly identifying the proper possible solutions for any given client set of requirements Hourglass concept in Disaster Recovery Solution Methodology The Disaster Recovery Solution Selection Methodology uses the following hourglass concept in its methodology. The hourglass concept allows us to organize and minimize the information that we need to gather in order to arrive at a valid solution, see Figure 1-7 on page 9. 8 A Disaster Recovery Solution Selection Methodology

19 Disaster Recovery Solution Selection Methodology: "Hourglass" Concept Start here Pick proper subset Solution 1 Solution 2 Solution 3 Solution 1a... Figure 1-7 Hourglass concept Solution 3a... A. Ask Specific Questions in Specific Order Ask proper high-level questions Application, platform, RTO, Distance, Connectivity, RPO, Vendor... Order of questions: Designed to eliminate many non-qualifying solutions up front Document answers B. Use RTO to pick appropriate solution subset Organize solutions by Tiers (creates RTO subset) C. From among subset, use question answers to eliminate non-solutions Apply answers gathered previously D. Turn over remaining valid solutions to detailed evaluation team As appropropriate, can then expand each solution to multiple flavors, tailoring for the client's exact needs 'Above the Neck' 'At the Neck' 'Below the Neck' By segmenting the asking of questions into this hourglass concept and these three categories, it becomes possible to efficiently subset the nearly endless permutations of possible Disaster Recovery technology combinations and solutions into a manageable, methodical process Steps in the Disaster Recovery Solution Selection Methodology Let s step through the concepts: Steps A through D. Step A: Ask specific questions in a specific order A series of business Disaster Recovery requirements questions is asked, in a specific order. With these questions, the basic environment, infrastructure, and desired recovery times for the Disaster Recovery solution are established. Below, we suggest a basic starter set of specific questions. Some of the questions will require the business line to answer them in their Risk and Business Impact Analysis. Other questions are for the Operations staff to answer from their knowledge of the IT infrastructure. Starter set of business requirements questions: 1. What is the application or applications that need to be recovered? 2. On what platform or platforms does it run? 3. What is the desired Recovery Time Objective? 4. What is the distance between the recovery sites (if there is one)? 5. What is the form of connectivity or infrastructure transport that will be used to transport the data to the recovery site? How much bandwidth is that? 6. What are the specific hardware and software configurations that need to be recovered? 7. What is the Recovery Point Objective? Chapter 1. Disaster Recovery Solution Selection Methodology 9

20 8. What is the amount of data that needs to be recovered? 9. What is the desired level of recovery (Planned/Unplanned/Transaction Integrity)? 10.Who will design the solution? 11.Who will implement the solution? These are not all the possible questions, of course, but they are a valid starting point. You can see additional questions in Appendix A, Disaster Recovery Solution Selection Methodology matrixes on page 29. Note that the specific order of the questions is by intent, designed to eliminate non-solutions even as we are performing the information gathering phase. The questions and how they are used in our hourglass concept are shown in the following chart in Figure 1-8. Step A: Ask Specific Questions in a Specific Order Step A: Start here, gather answers to proper questions 1. What applications or databases to recover? 2. What platform? (z, p, i, x and Windows, Linux, heterogeneous open, heterogeneous z+open) 3. What is desired Recovery Time Objective (RTO)? 4. What is distance between the sites? (if there are two sites) 5. What is the connectivity, infrastructure, and bandwidth between sites? 6. What are the specific h/w equipment(s) that needs to be recovered? 'Above the Neck' Step B: Identify proper possible solution subset 7. What is the Level of Recovery? - Planned Outage - Unplanned Outage - Transaction Integrity 'At the Neck' Step C: Eliminate non-solutions 8. What is the Recovery Point Objective? 9. What is the amount of data to be recovered (in GB or TB)? 10. Who will design the solution? (IGS, BP, client) 11. Who will implement the solution? (IGS, BP, client) 'Below the Neck' 12. Remaining solutions are valid choices to give to detailed evaluation team Figure 1-8 Step A: Ask specific questions in a specific order The questions above the neck of the hourglass define the basic business and IT requirements. It is essential that these basic questions be answered fully, because a lack of any of these answers means that it is not possible to properly evaluate what subset of solutions are the ones we should investigate. In this way, the methodology enforces the collection of proper business and infrastructure requirements before proceeding. We must assure that the answers to these questions have gained consensus from the enterprise s management, business lines, application staff, in addition to the IT operations staff. 10 A Disaster Recovery Solution Selection Methodology

21 Step B: Use Tier/RTO and Level of Recovery to identify solution subset We now are ready to identify the preliminary candidate solutions. To do that, let s review one final concept: the Level of Recovery (which is defined below). Note that each level builds on the previous level. The reason for the three levels, is to accommodate the fact that Disaster Recovery technology and solutions used will vary for Planned Outages versus Unplanned Outages versus Transaction Integrity. Planned Outage: The solution is required only to facilitate Planned Outages or data migrations. Unplanned Outage recovery is not necessary. Unplanned Outage: The solution is required, at the hardware and data integrity level, to facilitate Unplanned Outage recovery. It implies that Planned Outage support is also available in this solution. This level of recovery does not perform Transaction Integrity recovery at the application or database level. Transaction Integrity: The solution is required to provide Unplanned Outage recovery at the application and database Transaction Integrity level. This level relies on an underlying assumption that hardware level Planned Outage and Unplanned Outage support is also available. Having identified the appropriate Level of Recovery, and in combination with the RTO, we now reference the Solution Matrix in Appendix A, Disaster Recovery Solution Selection Methodology matrixes on page 29. An extract of the full Solution Matrix is shown for illustration purposes in Figure 1-9. Take the identified Level of Recovery and RTO answers, and look into the Solution Matrix chart. You ll immediately identify the intersect of the Level of Recovery with the RTO/Tier. At the intersect, in the contents of the intersection cell, are the initial candidate Disaster Recovery solutions for this particular RTO. Step B: Use Level of Outage and Tier/RTO to identify RTO Solution Subset B1. Use RTO, recovery level to select subset... Tier 7 Tier 6 Tier 4 RTO and Tiers tells me my "RTO Solution Subset" Planned Outages Unplanned Outages Transaction Integrity GDPS/PPRC GDPS/XRC PPRC, PPRC-XD XRC, GDPS Storage Mgr, ercmf, etc.. IMS RSR, Oracle, DB2-specific... PPRC-XD Point in Time FlashCopy, VTS Peer to Peer DB2-specific 'At the Neck' Disaster Recovery Solution Matrix (extract for illustration purposes) Figure 1-9 Step B: Identify candidate RTO solutions using tabular Tiers chart, RTO, and Level of Recovery Chapter 1. Disaster Recovery Solution Selection Methodology 11

22 In the illustration in Figure 1-9 on page 11, the identified preliminary candidate solutions are XRC, GDPS Storage Manager, and ercmf. Step C: Eliminate non-solutions Now that we have identified the preliminary candidate Disaster Recovery solutions, we eliminate non-solutions by applying the other answers gathered in Step A to the candidate solutions. For the solutions in this paper, we supply a starter set of the eliminate non-solutions in Appendix A, Disaster Recovery Solution Selection Methodology matrixes on page 29. An extract from that table is shown in Figure Step C: Eliminate Non-Solutions B1. Use RTO, recovery level to select subset... Tier 7 Tier 6 Tier 4 PPRC, PPRC-XD PPRC-XD Planned Outages Unplanned Outages Transaction Integrity GDPS/PPRC GDPS/XRC XRC, GDPS Storage Mgr, ercmf, etc.. IMS RSR, Oracle, DB2-specific... Point in Time FlashCopy, VTS Peer to Peer DB2-specific Lookup... My Questions and Answers eliminate non-solutions C. Use 'answers' to eliminate non-solutions XRC GDPS Storage Manager PPRC Platform zseries only zseries and z + Open heterogeneous ermcf Open Systems only... Distance any distance... < 103 km < 103 km Recovery Time 2-4 hours 1-4 hours 1-4 hours Objective Connectivity... ESCON ESCON ESCON Recovery Point few seconds to zero data loss zero data loss Objective few minutes Valid Option? No Yes No 'Below the Neck' Figure 1-10 Step C: Eliminate non-solutions Step D. Turn over Identified solutions to detailed evaluation team By applying the answers from Step A, on topics such as distance and non-support of platforms, those candidate solutions that do not apply will be eliminated. It is normal to have multiple possible solutions after we complete Step C. Whatever Disaster Recovery candidate solution or solutions remain after this pass through Step C are therefore a valid Disaster Recovery candidate solutions. Here we have completed our methodology Value of the Disaster Recovery Solution Selection Methodology As simple as this sounds, this process of quickly identifying proper candidate Disaster Recovery solutions for a given set of requirements is of significant value. 12 A Disaster Recovery Solution Selection Methodology

23 Much less time and skill is necessary to reach this preliminary solution identification in the evaluation cycle than would otherwise be experienced. This methodology can manage the preliminary evaluation phase more consistently and repeatedly, and can be easily taught to others. This methodology also supports our current best Disaster Recovery practices of segmenting the Disaster Recovery architecture into three blended tiers (and therefore three tiers of solutions). To identify the solutions for the other bands of solutions, you would simply re-run the methodology, and give the lower RTO Level of Recovery for those lower bands and applications; you would find the corresponding candidate solution technologies in the appropriate (lower) RTO solution subset cells Step D: Turn over identified solutions to detailed evaluation team Having identified a preliminary set of valid candidate Disaster Recovery solutions and technologies, we turn over this set of candidate solutions to a skilled evaluation team, made up of members qualified to contrast and compare the identified solutions in detail. The valid identified candidate solutions also dictate what mix of skills will be necessary on the evaluation team. The evaluation team will in all likelihood need to further configure the candidate solutions into more detailed configurations to complete the evaluation. This is also normal. In the end, that team will still make the final decision as to which of the identified options (or the blend of them) is the one that should be selected Updating the methodology as technology advances This methodology is flexible. Because of the table-driven format, as technology changes, only the contents of the Tiers chart will change; the methodology itself need not change. In particular, as Disaster Recovery technology is created or enhanced and results in an improvement of its tier of Disaster Recovery capability, this methodology simply: Adds the new technology to the appropriate RTO/Tier cell. Adds that solution as a column to the Eliminate Non-Solutions table. In most cases, the questions being asked in either Step A or Step B will not need to change. 1.5 An example: Using the DR Solution Selection Methodology To illustrate the use of the Disaster Recovery (DR) Solution Selection Methodology in practice, here is an example. Further examples are shown in Chapter 2, Sample scenarios on page Step A: Ask specific questions in a specific order The first step in any Disaster Recovery solution evaluation is to gather the appropriate business and IT infrastructure requirements by working within your organization to reach agreement on the following questions. Let us suppose that the answers to our starter set of Disaster Recovery Solution Selection Methodology questions turn out to be as follows: 1. What is the application or applications that need to be recovered? Heterogeneous Chapter 1. Disaster Recovery Solution Selection Methodology 13

24 2. On what platform or platforms does it run? zseries 3. What is the desired Recovery Time Objective? 3 hours 4. What is the distance between the recovery sites (if there is one)? 35 km 5. What is the form of connectivity or infrastructure transport that will be used to transport the data to the recovery site? How much bandwidth is that? ESCON, DWDM, bandwidth = 50 MB/sec 6. What are the specific vendor hardware and software configurations that need to be recovered? IBM ESS 7. What is the Recovery Point Objective? Near zero data loss 8. What is the amount of data that needs to be recovered? 4 TB 9. What is the desired level of recovery (Planned/Unplanned/Transaction Integrity)? Unplanned Integrity 10.Who will design the solution? To be determined 11.Who will implement the solution? To be determined After this information is obtained, we proceed to Step B Step B: Use level of outage and Tier/RTO to identify RTO solution subset We now apply our Tier/RTO and Level of Recovery to our Solution Matrix, a simplified version for illustration purposes is shown in Figure 1-11 on page 15. A full version of this table is in Appendix A, Disaster Recovery Solution Selection Methodology matrixes on page 29. Unplanned Level of Recovery Recovery Time Objective = Three hours 14 A Disaster Recovery Solution Selection Methodology

25 RTO ===> Description Planned Outage/ data migrations - byte movers Unplanned Outage D iaster R ecovery, adds data integrity to byte m overs Database and application Transaction Integrity - adds Transaction Integrity to Unplanned Outage data integrity Generally near continuous to 2 hours Highly automated integrated h/w s/w failover GDPS/PPRC, GDPS/XRC, AIX HACMP-XD with ESS PPRC, W indows GeoDistance DB2 with GDPS/PPRC Figure 1-11 IBM TotalStorage Disaster Recovery Solution Matrix By intersecting the Tier 6 RTO column with the Unplanned Outage row, we find that the preliminary candidate recommendations in our simplified table would be: XRC GDPS Storage Manager with PPRC ercmf Step C: Eliminate non-solutions , 3 2, 1 Generally 1 to 6 Generally 4 to 8 G enerally > 24 hours hours hours Storage and Server mirroring PPRC, PPRC-XD, XRC, VTS Peer to Peer XRC, GDPS Storage Manager with PPRC, ercmf S/W and database transaction integrity SAP, Oracle, DB2, SQL Server remote replication Generally Tier 4: 6-12 hours; Tier 3: hours H ot site, D isk PiT copy, Tivolio Storage Manager-DRM, fast tape FlashCopy, PPRC-XD, VTS Peer to Peer, Tivoli Storage Manager, tape Tier 4: VTS Peer to Peer, FlashCopy, FlashCopy Migration Manager, PPRC-XD, ercmf with PPRC-XD. Tier 3: FlashCopy, Tivoli Storage Manager, tape Tier 3: MS SQL Server database cluster with physical tape transport Backup software, tape Tivoli Storage Manager, tape Tivoli Storage Manager, tape We now use the information gathered in Step A for Step C: Eliminate non-solutions. We examine the Step C: Eliminate Non-Solutions table for this Tier 6 Unplanned Outages for which a starter set is supplied in Appendix A, Disaster Recovery Solution Selection Methodology matrixes on page 29. A simplified version of the Eliminate Non-Solutions table for the Tier 6 Unplanned Outage chart is shown in Figure 1-12 on page 16. Chapter 1. Disaster Recovery Solution Selection Methodology 15

26 Solution XRC GDPS Storage M anager with PPRC ercm F Platform zseries zseries, Hetereogeneous in c lu d in g z S e rie s Distance <40 km, km, >103 km < 40 km, km Connectivity ESCON, FICON ESCON, Fibre Channel Vendor (1) Vendor (2) RPO XRCcom pliant z/o S subsystem z/os subsystem Few seconds to fe w m in u te s PPRCc o m p lia n t subsystem Sam e vendor as PPRC subsystem Near zero Figure 1-12 Tier 6 Unplanned Outage Eliminate Non-Solutions table pseries, Linux, Sun, HP, M icrosoft W indows, Heterogeneous (open) <40 km, km ESCON, Fibre Channel IB M As we apply the different criteria sequentially from top to bottom, we find that: 1. Because the platform is IBM Sserver zseries, we can eliminate ercmf because that does not support zseries. 2. From a distance of 35 km, all remaining solutions qualify. 3. From a connectivity standpoint of ESCON, all remaining solutions qualify. 4. From a vendor hardware standpoint for site 1 of IBM ESS, all solutions qualify. 5. From a vendor hardware standpoint for site 2 of IBM ESS, all solutions qualify. 6. From a RPO standpoint of near zero, only GDPS Storage Manager with PPRC qualifies. Therefore, we see that after applying the answers to the identified candidates and eliminating non-solutions, this is the valid preliminary candidate solution: GDPS Storage Manager with ESS PPRC The methodology can often result in more than one possible solution. This is normal. IB M A m t o f D a ta Near zero Step D: Turn over identified preliminary solutions to evaluation team We would now turn over this solution or solutions to the detailed evaluation team in Step D. In all cases, whether we have identified one or multiple possible solutions, the detailed evaluation team step is necessary to validate this preliminary set of identified solutions, as well as accommodate a large variety of environment-specific considerations. As stated earlier, the methodology is not intended to be a perfect decision tree. This completes the methodology example. For additional examples, see the Chapter 2, Sample scenarios on page 19, in which a series of typical client Disaster Recovery requirements are distilled through this methodology, and a preliminary solution is identified. 16 A Disaster Recovery Solution Selection Methodology

27 1.6 Summary This methodology is meant as a framework and an organizational pattern for the efficient preliminary identification of proper Disaster Recovery solutions. This methodology is adaptable as technology or environment changes by updating the tables and questions used. It provides a consistent, teachable, repeatable method of locating the proper preliminary Disaster Recovery solutions. This methodology is not meant as a substitute for Disaster Recovery skill and experience, nor is it possible for the methodology to be a perfect decision tree. Although there clearly will be ambiguous circumstances (for which knowledgeable Disaster Recovery experts will be required), the methodology still provides for the collection of the proper Disaster Recovery business requirements information. In this way, the methodology provides an efficient process by which the initial preliminary Disaster Recovery solution selection can be consistently performed. In the end, this methodology should assist you in mentally organizing and using the information in this Redpaper, as well as navigating any Disaster Recovery technology evaluation process. Chapter 1. Disaster Recovery Solution Selection Methodology 17