Business Insurance FOR YOUR HANA DATABASE

Transcription

1 Insurance FOR YOUR HANA DATABASE Why It Pays to Invest in for SAP HANA January 2016 LET S GO

2 3 4 : The Challenge of Protecting Large Databases Universal Unique to HANA 8 Traditional Backups HANA System Replication Storage Replication 9 : You Can Count On 10 of for SAP HANA : Now Has HANA-Specific Best Practices 2 Copyright 2015 Corporation. All rights reserved. Published in the USA.

3 for SAP HANA October Two Organizations today face datacenter disasters caused by a range of factors: human error, hardware and software glitches, natural disasters, hackers, and more. When disaster strikes, an organization is measured by its ability to resume operations quickly, seamlessly, and with the minimum amount of data loss. Responding quickly can make the difference between Disaster strikes, the organization is measured being featured on the national news and being able to Disaster strikes, the organization is measured by its ability to by resume its operations ability to quickly, resume operations quickly. conduct business as usual. Two PROTECTING LARGE DATABASES Because of this, having a valid carbon copy of the entire information infrastructure ready and waiting to take over business processing, consistently, across many complex interdependencies is essential. This means establishing and meeting the acceptable level of lost data (the desired recovery point objective, or RPO), the recovery time objective (RTO), and the service level agreement (SLA). Five In this paper, we talk about the challenges of protecting large databases when disaster strikes. We discuss how best to protect the entire business landscape of interconnected business systems. Then we explore the unique challenges of protecting a SAP HANA database. We introduce your options for recovering a HANA database. And we explain why with its capability to minimize data losses as well as business restart and recovery times is the best data protection solution for your business. Five DISASTER STRIKES Disaster Strikes for SAP HANA October protecting large databases You need to the entire business when disaster strikes. landscape of interconnected systems. 3 Copyright 2015 Corporation. All rights reserved. Published in the USA.

4 Two : The Challenge of Protecting Large Databases continuity is essential for today s businesses. But problems and outages happen. The vast majority of unplanned outages Two are caused by either human error or mechanical failure, according to the Uptime Institute (see Figure 1). 1 When these events occur, the cost of downtime is becoming increasingly expensive. A Ponemon study of U.S. Five datacenters found that the average cost of an unplanned datacenter outage was slightly more than $474,000 per hour ($7,900 per minute). 2 This is a 41% increase from the $336,000 per hour ($5,600 per minute) it was in 2010, when Ponemon first started assessing downtime costs. 3 According to IDC, the numbers are even more staggering for industries with large transaction volumes. A brokerage firm loses $6 million to $7 million an hour while a credit card processor loses $2 million to $3 million an hour (see Figure 2). 4 for SAP HANA October The Cause of Unplanned Outages FIGURE 1: Cause of outages. Source: Uptime Institute IT EQUIPMENT FAILURE for SAP HANA October Average Cost of Downtime FIGURE Even 2: if Average your cost company of downtime survives per industry. a disaster, the costs are staggering: Even if your company survives a disaster, the costs are staggering: eg: UPS SYSTEM FAILURE (BATTERY) ACCIDENTAL / HUMAN ERROR WATER, HEAT OR CRAC FAILURE WEATHER RELATED GENERATOR FAILURE OTHER 29% 24% 15% 12% 10% 05% 05% 88% HUMAN & MECHANICAL 12% WEATHER RELATED Brokerage $6M-$7M / hour Home Shopping $100K / hour Five Universal Unique to HANA Banking $5-$6M / hour Pay Per View $1-$2M / hour (up to $50M for fights) Credit Card $2M-$3M / hour Catalog Sales $100K / hour Package Shipping $30K / hour Tele-ticket $70K / hour Airline Reservations $1M / hour ATM Fees $20K / hour Source: Disaster Recovery Journal 1 Jason Weckworth (Uptime Institute). Data Center Outages, Incidents, and Industry Transparency Yevgeniy Sverdlik (Datacenter Dynamics). minute of data center downtime costs US$7,900 on average. December 2, Ibid. 4 Pete Manca (Disaster Recovery Journal). The Future of Disaster Recovery as a Service. September 25, Copyright 2015 Corporation. All rights reserved. Published in the USA.

5 Universal Unique to HANA Because of this, protecting data is an absolute business necessity. Yet that is challenging, given that enterprise data is growing 40% to 50% annually, according to IDC. At the same time, IT budgets are relatively flat, at just 2.5% growth, meaning you must do more with less. This is especially the case in the era of Big Data and SAP HANA. Currently, there are many thousands of HANA installations worldwide. That number is growing. Although still a small percentage of SAP s total installed base, HANA deployments have more than doubled in the past 12 months. And this rate of growth is expected to accelerate since SAP has for SAP HANA October 2015 announced that all SAP systems in the future will run on the HANA in-memory platform. It s not a question of if organizations will move to HANA, it s one of when. Two Universal Two Two Two THE COST OF SPACE In many ways, the data-protection challenges How facing many SAP The Production cost of space Systems/Modules do THE COST OF SPACE THE COST OF SPACE HANA users are the same as for any other your kind of company large run? Five database. Five Five Answer THE VALUE OF THE DATA For starters, databases are getting larger every day. THE VALUE OF THE DATA The value of the data THE VALUE OF THE DATA Over the past decade, three trends have driven major Five The cost cost of space of versus space the value versus of the data the has value decreased of significantly The cost of space versus the value of the data has decreased significantly increases in average database size (see Figure 3). the data has decreased significantly. The cost of space versus the value of the data has decreased significantly Don t Know In other words, the cost of keeping data online is cheap, the value of that data is now very high, and both the sizes of companies and their data 4 needs or less have grown exponentially. For example, it s not unusual Companies now value data as a critical business asset for today s online transaction processing (OLTP) or Companies now now value data value as a data critical business as a critical asset Companies now value data as a critical business asset operational data store (ODS) databases to reach 800 business assett 5 to 9 gigabytes (GB). In particular, SAP and PeopleSoft enterprise resource planning (ERP) databases routinely exceed 400 GB. 10 to 14 The size of these systems mean that traditional data backup methods aren t adequate any longer. 15 or more Traditional data backup methods require you to restore 100 percent of the data. Outages when they occur therefore last longer than before because it takes so long to restore the data. Restore times that were adequate years ago before databases were so large are no longer practical. Restores from backup for any growing database do and will outgrow any static business SLAs for recovery over time. Many organizations have outgrown their restore SLAs already, but are not even aware of the issue until a restore is required. Then there s the interdependencies of many different applications both SAP and non-sap sending and receiving data from each other to support complex business transactions. According to an customer survey, 72 percent of organizations have five or more production SAP systems, and 20 percent have 15 or more (see Figure 4). for SAP HANA October for SAP HANA October for SAP HANA October FIGURE 3: Protecting Large Databases Companies have merged into large multinational entities have merged into large multinational entities Companies have merged have into merged large multinational into large entities multinational entities FIGURE 4: Number of Production SAP Systems Organizations Have Response Percent 8.4% 19.3% 37.3% 14.5% 20.5% Don t Know 4 or less 5 to 9 10 to or more 5 Copyright 2015 Corporation. All rights reserved. Published in the USA.

6 FIGURE 5: How many SAP production systems/modules does your company run? Today s Large SAP Landscape Universal Unique to HANA FIGURE 5: RTO and RPO expectations 6 Copyright 2015 Corporation. All rights reserved. Published in the USA.

7 Additionally, service-level agreements (SLAs) are becoming more stringent as businesses are increasingly intolerant of downtime. for SAP HANA A full October 90 percent 2015 of enterprises want recovery 04time objectives (RTOs) of four hours or less (see Figure 6). (The RTO is the time it takes for a business to resume operations after an outage.) Organizations are also shrinking their recovery point objectives (RPO) or the maximum What targeted are time that you data business can be lost an expectations outage as well. for remote recovery for mission critical databases? FIGURE 6: RTO and RPO expectations What are your business expectations for remote recovery for mission critical databases? 35% 30% 25% 20% 15% RTO RPO 10% 5% 0% Zero Loss Seconds Two Minutes Minutes Under 4 Under 12 (1 to 30) (31 to 60) hours hours Source: 2015 SAP Global Solutions Marketing Customers Survey for SAP HANA October Over 12 hours What s more, disaster recovery (DR) compliance and auditing mandates are also putting an increasingly heavy burden on organizations. es have to regularly perform DR tests, and they need to be able to do this without impacting Five production systems or any business recovery SLAs. for SAP HANA October Universal Unique to HANA Two Unique to HANA Additionally, two data protection challenges are unique to HANA. First, on scale-out HANA databases, each Five replicated node needs to be updated in the same order across the nodes as the source. If that isn t achieved, the database will crash upon restart. This is obviously a major issue when doing data restores on HANA. Scale-Out On scale-out hana databases, each replicated node needs to be updated in the same order across the nodes as the source or upon restart it will crash. This is obviously a major issue when doing data restores on hana. Scale-Out Scale-Out On scale-out hana databases, each replicated node needs to be updated in the same order across the nodes as the source or upon restart it will crash. This is obviously a major issue when doing data restores on hana. Second, because HANA is a newer techno- logy, SAP is continually issuing patches and updates. Organizations can find it difficult to keep current with these patches and updates while keeping important production systems running. Because A HANA case is in a point: newer In technology, December SAP 2015, is continually SAP issuing patches and updates more than for more mature released its eleventh support package stack (SPS11) systems which since first can shipping be difficult HANA to stay in current And with there while is a continuous stream of HANA patch releases and keeping SAP OSS important fixes production being released systems by running. SAP. A case in point: in june 2015, SAP released its tenth support package stack (sps10) since first shipping HANA in And there is a continuous stream of HANA patch releases and SAP oss fixes being released by SAP. Because HANA is a newer technology, SAP is continually 7 Copyright 2015 Corporation. All rights issuing reserved. patches Published and updates more in the USA. than for more mature systems which can be difficult to stay current with while keeping important production systems running. A case in

8 Five for SAP HANA October for SAP HANA October 2015 TRADITIONAL BACKUPS WHITE PAPER Two Two Traditional backups can be used to protect the primary HANA database against a storage failure. You have three choices when it comes to protecting your SAP HANA databases: Traditional backup HANA System Replication TRADITIONAL BACKUPS Traditional backups can be used to protect the primary HANA database ag storage failure. Traditional backup Five Five Storage Replication Each HANA solution System enables Replication different RPOs, RTOs, and SLAs. HANA System Replication Traditional Backups Traditional backups can be used to protect the primary HANA database against a failure. But they have numerous drawbacks when it comes to backing up HANA databases. For example, RPOs and RTOs can be very long. The RPO depends on the frequency in which the customer does HANA backups and saves backup logs, which can range from minutes to hours to more than a day. The recover time using a backup strategy can also be multiple hours because a HANA Storage backup Replication needs to be restored to disk, often from slow tape, and from there Storage a subset Replication of data has to be read into HANA memory before the database is available. Because full restores are needed, as databases get larger, the recovery time/rto gets longer. In addition, with traditional backup solutions, backups are only good for single databases. There s no syncing or consistency with other, interrelated databases after rolling failures. So recovering your databases individually doesn t mean your business recovers in a cross-database and businessconsistent form. Quite the contrary, in fact you ll have to spend significant time getting the various databases back to a business-consistent state with everything in sync. HANA Data Protection Traditional Backups HANA System Replication Storage Replication Finally, in an effort to reduce restore times and handle local disasters, organizations often have the complexity and cost of having to produce both onsite and offsite backup copies when using a traditional data backup solution. HANA System Replication HANA System Replication is an application-based disaster recovery solution it is built into HANA so there are no added costs where a secondary standby HANA system is configured as an exact copy of the active primary system. Data is continuously sent from the source database to the copy much as with storage replication. The advantage to this is the price point HANA System Replication is included with HANA and both the business data loss and recover time for the one database can be low. Plus, it s relatively easy to implement. But there are also serious deficiencies with this method. It supports SAP HANA only, and doesn t work with other SAP or non-sap databases that may feed data to HANA or get data from HANA. There s no consistency between HANA databases or other databases in the federation. And when testing at the DR site, the replication may have to be suspended, risking production SLAs during this window. 8 Copyright 2015 Corporation. All rights reserved. Published in the USA.

9 HANA Data Protection Traditional Backups HANA System Replication Storage Replication Storage Replication Storage replication solutions in HANA tailored datacenter integration (TDI) deployments provide a convenient method to protect HANA against a site failure. The HANA Production Site#1 is replicated to a Replica Site #2 with special journals to allow for operational recovery even with data-corruption use cases. By replicating your critical business data outside the server, you free up compute resources for other critical database and application processing. This improves performance and lowers server costs. In addition, you get short RTOs because the database is already restored in the secondary copy at the target site. No copy from backup to the HANA storage is needed. Of all the storage replication solutions in the market, is the best in fact, it s the only solution to deploy with SAP HANA with any point-in-time granularity across multiple applications and databases. And with Recover Point, you get more than just an exact copy of your data for disaster recovery. If that copy has been corrupted in any way, you also get operational recovery and can roll the data back with just the changes prior to the corruption much more quickly than with any other solution. is the best and only solution to provide a reliable safety net for all your integrated databases both traditional and new SAP HANA in-memory ones across storage platforms. : You Can Count On is an enterprise-scale solution designed to protect application data on heterogeneous SAN-attached servers and storage arrays. runs on a dedicated appliance and combines industry-leading continuous data protection technology with a bandwidth-efficient, no-data-loss replication technology, allowing it to protect data both locally and remotely for any point-in-time recovery. dramatically improves application protection and recovery times compared to traditional host and array snapshots. is capable of replicating the production copy to up to four different copies at up to four different sites. Now validated for SAP HANA, is a long-time tried-and-true SAP protection tool. It has more than 10,000 deployments worldwide not just SAP systems, but also SQL, SharePoint, Meditech, and others and has accumulated more than 150 million run hours offering more than five 9s system uptime. protects an exabyte of data worldwide. allows you to optimize both RTO and RPO for both SAP HANA and non-hana databases as well as databases from other vendors by ensuring instant access to data for DR, operational recovery, and disaster-recovery testing. also includes bookmark capabilities allowing for a rollback of changes to support all SAP database changes and corruption rollbacks, among other things. delivers a point-in-time image that is business consistent across the multitude of business application environment with no impact to RTO, RPO, and SLAs. Additionally, if you are required by corporate or industry mandates to do regular business DR and continuity testing, allows you to continue doing business replication and testing at the same time. HANA System Replication cannot do this. Typical Topologies for for SAP HANA Continuous data protection Only one copy on the same site as production copy. Continuous remote protection Only one copy on a different site than production copy. Concurrent local and remote protection Two copies, one on the same site as production copy and the other copy on another site. 9 Copyright 2015 Corporation. All rights reserved. Published in the USA.

10 Two WHITE PAPER Five Table of of for SAP HANA of for SAP HANA YOU GET MANY BENEFITS FROM DEPLOYING RECOVERPOINT FOR SAP HANA. AMONG THEM: You get many benefits from deploying for SAP HANA. Among them: SAP non-sap HANA October ormance rpoint s data compression hronous network bandwidth is improving performance. Get consistent business recovery by Get consistent business recovery Reduce and simplify minimizing RPO your RTO and RPO needs across databases that have Reduce and simplify your RTO and RPO needs complex data interdependencies. across databases that have complex data interdependencies. Achieve data business continuity between dependent SAP and non-sap applications works with non-sap Achieve data as well business as other continuity SAP systems between than HANA. Because dependent SAP and non-sap applications all data is synced, your business doesn t hiccup after an works with non-sap as well as outage, other SAP no systems matter than how HANA. extensive Because that all outage data is or how many is synced, interdependent your business links doesn t are hiccup necessary after to an keep the data outage, no matter how extensive that outage is business consistent. or how many interdependent links are necessary to keep the data business consistent. Recover to any point in time enables you to achieve a business-consistent recovery even after you Recover to any point in time make a copy of corrupted data. You do this via journal enables you to achieve a technology. It delivers a DVR-like rollback-in-time capability business-consistent recovery even after you make a to copy whatever of corrupted point data. in time You you do this select typically via journal just seconds technology. before It delivers data a corruption DVR-like rollback-in-time or loss occurred. Without capability to whatever point in time you select typically you just could seconds spend before days data or corruption even weeks to back up or loss to the occurred. point before Without the bad data. you With could, it s spend days or even weeks to back up to the point a matter of seconds. before the bad data. With, it s a matter of seconds. Improve performance Because of s data compression capabilities, asynchronous network bandwidth is eased. Offloading compute for replication frees CPU cycles to service the application, significantly improving performance. Journaling: Gets You To the Exact Point in Time uses a journal-based implementation to hold the point-intime information of all changes made to the protected data. Its replication policy enables a short RPO via journal technology that delivers a DVRlike rollback-in-time capability. You get to any selected point in time just seconds before a data corruption or loss occurred, and can quickly reverse the error. EX by integrating into existing d protection using existing esses. Because you can use ss all your systems, including line workflows with reliable and es, also reducing OPEX. You can by replicating data onto than the production system tically better SLAs than if you nal restores from backups, king true landscape recovery ind s you to simplify DR testing your production SLAs, so you DR preparation is up to the task. Lower TCO You can reduce OPEX by integrating into existing -based protection using existing expertise and processes. Because you can use across all your systems, including HANA, you streamline workflows with reliable and repeatable processes, also reducing OPEX. You can then reduce CAPEX by replicating data onto lower-cost storage than the production system has. Improve SLAs You can get dramatically better SLAs than if you depend on traditional restores from backups, especially when taking true landscape recovery into consideration. Get peace of mind allows you to simplify DR testing without impacting your production SLAs, so you always know your DR preparation is up to the task. 10 Copyright 2015 Corporation. All rights reserved. Published in the USA.

11 Single and federated database local and remote recovery Fast restore from source failures Fast restore from data corruptions Federated landscape DR testing without loss of SLAs : Now Has HANA-Specific Best Practices Whether needing fast recovery from large single databases or needing fast business-consistent recovery from two or more interdependent mission-critical databases, is for you. now offers the same SAP-proven reliable platform at the software and hardware layer for the SAP HANA database that it has always provided for traditional databases. It enables complete DR and business continuity for mission-critical environments, including scale-up and scaleout in-memory SAP HANA database. And because has validated for SAP HANA as a proven configuration, you now get key HANA-specific best practices from the engineering team. This allows you to add HANA as another -supported database, and enables you to use the same great features and leverage your investment in the same long-time consistency that provides for your other databases. If you have deployed or are considering deploying HANA in your SAP landscape, contact your sales representative today to see how can improve your business recovery needs. Don t forget to ask them how SAP runs better on. For More Information Please Visit: Tailored Data Center Integration Resource Center: Everything SAP at : 11 Copyright 2015 Corporation. All rights reserved. Published in the USA.