17609: Continuous Data Protection Transforms the Game

Transcription

1 17609: Continuous Data Protection Transforms the Game Wednesday, August 12, 2015: 8:30 AM-9:30 AM Southern Hemishere 5 (Walt Disney World Dolhin) Tony Negro - EMC Rebecca Levesque 21 st Century Software

2 About the Seakers Rebecca M. Levesque is Chief Executive Officer of 21st Century Software and resonsible for shaing the comany s roduct strategy and vision. She has over 20 years exerience heling hundreds of comanies establish resiliency and recoverability strategies from any disrutive event. Tony Negro is currently a Cororate Systems Engineer in the Core Technologies Division of EMC Cororation. As a technical resource for VMAX and Mainframe Business Unit, Tony rovides in-deth roduct consulting to customers as well as Field Sales teams worldwide. About this Session Near Continuous Data Protection (CDP) is ossible but alication failover/high availability aroaches cannot guarantee batch data consistency and integrity rotection when disrutive events strike. If an unlanned outage occurs, does it matter whether it s an oerational event or disaster? When minutes count and you have multile coies and intertwined deendencies, how do you know which coy to use? This session rovides insight into what is needed, ossible, and attainable. 2

3 As We Begin Today, Consider This After a trio of high rofile outages, some industry analysts raised the question of whether such outages are inevitable in today s IT environment? Phone comanies used to offer % reliability, which allowed for about five minutes of downtime a year. Today s networks are far less exensive, infinitely more caable and nowhere near as reliable. The NYSE outage lasted about four hours, or nearly 50 years of allowable downtime using the five nines standard. Today s reliability roblems are a reflection of the comlexity and interdeendency of comuter systems, the ace of change, and insufficient organizational and cultural ractices. Information courtesy of Continuity Software 8/17/2015 3

4 Interesting Facts 71% of all Fortune 500 comanies have their core business on the mainframe 23 of the world s to 25 retailers use a mainframe 92% of the to 100 banks use a mainframe 10 out of 10 of the to insurers use a mainframe More than 225 state and local governments worldwide rely on a mainframe 9 of the to 10 global life and health insurance roviders rocess their highvolume transactions on mainframe From Enterrise Systems magazine July /17/2015 4

5 Coies how many? Which one is needed? More storage? Didn t we just buy for the next 3 years? I use built-in backus no one understands my a. Full volume, incrementals, sna, relication we ve got it covered! Comliance, audits, resource constraints does DR have the data? 8/17/2015 5

6 Faster RPO Made Possible through Evolution of Backu Surveys show organizations want a faster recovery oint objective (RPO) and recovery time objective (RTO) from their IT teams. It wasn't until backu roducts evolved to meet those windows that it became ossible. The study indicated that most users exect to recover crucial alications in faster than two hours, while most IT staffers said they cannot deliver recovery sooner than four hours. To meet these tighter RPO and RTO windows requires that secondary data be ositioned in a way that allows the alication to access it faster. Information courtesy of George Crum 8/17/2015 6

7 The State of Backu Organizations are seeking ways to easily, quickly and costeffectively ensure data is aroriately rotected Backu and recovery is one of the oldest and most frequently erformed data center oerations Data rotection aroaches of the ast may no longer suffice in meeting current much less future recovery requirements Adoting new technologies and roducts show an increased willingness to augment or even comletely switch backu/ recovery roviders to meet increasing service-level needs From Gartner Magic Quadrant Enterrise Backu June,

8 Why the gas, what goes wrong? Checkoints of consistent states are used to enable raid recovery to known good states (such as before a atch was alied to an OS, or the last time a database was reorganized) to ensure alication consistency of the data and to minimize the number of log transactions that must be alied. What if you don t have logs and journals batch? Have good data but it is not in sync with other alication deendencies (rile effect) Have too much good data which do I use? Frequent snashots alone do not equate to near CDP - achieving 100% or near-100% availability requires a to-down aroach into engineering availability into the alication, infrastructure and oerating architectures. (Gartner, 2014) 8/17/2015 8

9 Backu Challenges & CDP Definition Continuous data rotection (CDP) is an aroach to recovery that continuously, or nearly continuously, catures and transmits changes to files or blocks of data while journaling these changes. This caability rovides the otion to recover to many more-granular oints in time to minimize data loss, and enables arbitrary recovery oints. Some CDP solutions can be configured to cature data either continuously (true CDP) or at scheduled times (near-cdp). The difference between near-cdp and regular backu is that backu is tyically erformed once a day, whereas near CDP is often done every few minutes or hours, roviding many more recovery otions and minimizing any otential data loss CDP can relace traditional backu, but in most testing scenarios it's only as good as your ability to get backed u data off-site. 8/17/2015 9

10 The Perfect World Customers Transactions ATM Online Commerce Claims Bill Pay Web as Data Data Data Financia l as Customer data Network, As, Servers, Mainframe, Storage Synchronous Relication Asynchronous Relication Fourth Coy Production

11 The Real World Customers Transactions ATM Online Commerce Claims Bill Pay Web as Data Batch data doesn t write until job finishes Data Cross-deendencies on comleted batch jobs become exosure to the business Data Financia l as Customer data Network, As, Servers, Mainframe, Storage Production Synchronous Relication Asynchronous Relication Fourth Coy

12 Batch Deendency Problem From htt:// 12

13 Understanding Data Consistency: The Deendent I/O Concet An alication concet where the start of one write is deendent on the comletion of a revious write A logical deendency, not a time deendency Examles Data base & log Catalogs, Volume Table of Contents Index & data comonents A A A A A A A A A A A A A A A A

14 The Deendent I/O Concet Works great for DBMS across the Enterrise What can be done about logical corrution? What can be done for BATCH cycle? Point-in-time coies (checkoints) 8/17/

15 Today s Gas - Physical vs Logical Existing solution addresses the hysical risk Multile coies continuous and oint in time Planned and Unlanned outage events EVERYTHING gets relicated Even the logical corrutions! Many sites use u to 2 additional full Point in Time (PIT) coies Coy 1: near real time (minutes behind) Coies 2 and 3: new PIT created every 12 hours 24 hours to find corrution U to 24 hours of data loss DC3 Asynchronous DC2 DC1

16 What is needed from a solution? Recovery from loss of data integrity Provides a more granular level of alication recovery from unintended changes to data stemming from Processing error Malicious intent Human error Solutions that focus on the logical Continuous oint in time coies Selectable recovery oints Automation Brings PIT recovery caability to non-database systems Provides alications with recovery caability when not designed-in Provides cross-alication recovery oint 8/17/

17 Secific Requirements from the Array Underlying technologies Easily manage many data coies Reduce imact Target-less SNAPSHOTS Increased agility Multile (~256) Snashots er source Ease of use User-defined name/version number Automatic exiration if desired Sna entire Storage Grou in single command Consistent scale (>20,000 volumes) 8/17/

18 What is needed from Automation side Recovery from loss of data integrity Host automation Execute locally or remotely No Asynchronous RPO imact Restore to Secondary from any snashot Create indeendent DR test coy Frequent creation/deletion of snashots Fast logical corrution recovery Requirements Granularity of minutes Select snashots to LINK by timestam Sace Considerations, monitoring, reorting Legacy systems/alication, batch will not be re-engineered from the to down 8/17/

19 Versioning Snashots with Alication Awareness Alication Table Source Devices JES exit to intelligently tag Snashots on behalf of alication Batch Job Inventory Backu Table Target Devices SNAPSHOT API LINK / UNLINK Snashots Original jobs stes / rocess Host volume Legend Timeline (minutes)

20 Restoration and Simulation Recover to a job or ste level from reviously snaed data Invokes data mover to recover the data necessary to reinitiate comromised job Recovery rocess driven through ISPF interface Simulation of the recovery identifies exosures in the recovery of alication(s) or entire environment Ability to run what if scenarios at any time are critical in a world of SLA s that must be met 20 20

21 Summary When downtime and continuous comuting is required fault-tolerant raid recovery alication environments are needed. With mainframes this includes both transactional and batch rocessing. Alications and databases have advanced transaction recovery features, but batch jobs resent a different roblem. For continuous comuting in mainframe environments continuous rotection of batch rocessing systems can also be required. Possibilities exist to achieve a more granular overall recovery than we know today Lines have blurred between oerational, disaster, or synergy between the next generation controller based snashots and intelligent host based automation is needed to bring near-cdp to mainframe alications 8/17/

22 Thank you! Rebecca Levesque Tony Negro