SAP - SAP HANA HIGH AVAILABILITY ÇÖZÜMLERİ - SAP Forum 2013

1,100 views

Published on

SAP HANA, müşterilerine basit hatalardan doğal afetlere kadar, karşılaşılabilecek tüm kesinti problemlerine karşı önlem almalarında, uçtan uca alternatifler sunuyor.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,100
On SlideShare
0
From Embeds
0
Number of Embeds
48
Actions
Shares
0
Downloads
68
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

SAP - SAP HANA HIGH AVAILABILITY ÇÖZÜMLERİ - SAP Forum 2013

  1. 1. SAP FORUM İSTANBUL Gelecek Bugün Konuşmacı Adı : Uğur Naciterhan Firma Adı : SAP Türkiye SAP HANA HIGH AVAILABILITY ÇÖZÜMLERİ
  2. 2. © 2013 SAP AG. All rights reserved. 2 Gündem SAP HANA Architecture  Introduction to SAP HANA High Availability & Disaster Recovery  What options are available Backup / Restore  Minimal steps for business continutiy Storage / System Replication  Make use of your second data center  Minimal recovery time Roadmap
  3. 3. SAP HANA Architecture
  4. 4. © 2013 SAP AG. All rights reserved. 4 SAP HANA Appliance
  5. 5. © 2013 SAP AG. All rights reserved. 5 SAP HANA scalability Scales from very small servers to very large clusters Single Server • 2 CPU 128GB to 8 CPU 1TB (Special Layout for Suite On HANA for up to 4 TB per host) • Single SAP HANA deployments for data marts or accelerators • Support for high availability and disaster recovery Scale Out Cluster • 2 to n servers per cluster • Each server is either 4 CPU/512GB or 8 CPU/1TB • Largest certified configuration: 56 servers • Largest tested configuration: 100+ servers • Support for high availability and disaster recovery Cloud Deployment • SAP HANA instances can be deployed to AWS • Limited to developer license • SAP HANA Enterprise Cloud
  6. 6. © 2013 SAP AG. All rights reserved. 6 SAP HANA Database HANA is a Database System and an Appliance Database Management System A database management system (DBMS) is a software package with computer programs that control the creation, maintenance, and use of a database. From: Wikipedia HANA Appliance SAP HANA Database Software Plus well-defined hardware specs  Certain amounts of RAM per Server (128 GB; 256 GB; 512 GB; 1 TB)  Maximum ratio of RAM per CPU Core (16 GB RAM / CPU Core)  Fixed ratio of Data storage size / RAM (Data storage = 3 times RAM)  Fixed ratio of Log storage size / RAM (Log storage = RAM) CPUs Main memory Data Column Row Persistence layer Log Volume Data Volumes
  7. 7. © 2013 SAP AG. All rights reserved. 7 Persistence layer of SAP HANA Database Data storage in SAP HANA Primary persistence of data:  In-Memory  Table contents (data and undo log) Transaction Log for any write process  Information on data changes  Synchronous writing (at commit) Savepoint  Complete file image of database content  Cumulatively extended  Asynchronous, automatic Process SAP HANA Database Main memory Data Persistence layer Automatic savepoints Data changes Log Volume Data Volumes
  8. 8. © 2013 SAP AG. All rights reserved. 8 In-memory computing is secure The SAP in-memory database holds the bulk of its data in memory for maximum performance, but still uses persistent storage to provide a fallback in case of failure. The log is capturing all changes by database transactions (redo logs) Data and undo log information (part of data) are automatically saved to disk at regular savepoints The log is also saved to disk continuously and synchronously after each COMMIT of a database transaction (waiting for end of disk write operation) After a power failure, the database can be restarted like a disk-based database:  System is normally restarted („lazy“ reloading of tables to keep the restart time short)  System returns to its last consistent state (by replaying the redo log since the last savepoint) SAP HANA Persistence: Regular Saving of In-Memory Data to Disk, Restart Savepoint: Data & undo log is written to disk (data area) 1 Continously and after each COMMIT, redo log is written to disk (log area) 2 Power failure 3 Time
  9. 9. SAP HANA High Availability & Disaster Recovery
  10. 10. © 2013 SAP AG. All rights reserved. 10 Continuous availability SAP HANA Continuous Availability Customer Expectation: Planned & Unplanned Planned downtime Unplanneddowntime • Hardware failure / Malfunction including Networks • Software Malfunction / security threat / update • Natural / Man-made disasters • Failure of compliance & operation • Unplanned outages • SAP HANA Revisions & SPSs • Patches for Data Services and SLT • Maintenance Events for OS & Hardware • Custom development & enhancements • Planned outages • ……. Data Center Readiness HANA consumption Extended SAP backend deployments
  11. 11. © 2013 SAP AG. All rights reserved. 11 High Availability – Disaster Recovery Business Continuity High Availability per Data Center Disaster recovery between Data Centers SAP HANA Host Auto-Failover (Scale-Out with Standby) SAP HANA System Replication SAP HANA Storage Replication SAP HANA System Replication
  12. 12. © 2013 SAP AG. All rights reserved. 12 HA & DR Concepts in general RPO RTO operation resumed… time Sync or backup …system operational design & prepare detect recover perf. ramp KPIs: • Recovery Point Objective (RPO) = worst-case data-loss • Recovery Time Objective (RTO) = time to recover from outage *synchronous solution Solution Used for Cost RPO RTO Perf. ramp Backup & Recovery HA & DR $ high high med SAP HANA Host Auto-Failover HA $ 0 med long SAP HANA Storage Replication DR $$ 0* med long SAP HANA System Replication HA & DR $$$ 0* low short
  13. 13. SAP HANA Backup / Restore
  14. 14. © 2013 SAP AG. All rights reserved. 14 Backups in SAP HANA Database Memory>Disk>Backup
  15. 15. © 2013 SAP AG. All rights reserved. 15 Storage System Backup and Recovery Backup-based online database copy  Available since SAP HANA SPS4  SID and hostnames are adapted during the recovery process  Target database is started at the end of the recovery  No impact on in-memory processing on source; executed on persistence level Storage System Source Database online Database backup files Online Database Backup Database Recovery Target Database (copy)
  16. 16. © 2013 SAP AG. All rights reserved. 16 Backup and Recovery New features for database copies SAP HANA database copy from PROD to QA or DEV allows now to change the topology in case of a Scale-out setup on PROD side:  Backups which are produced on scale-out landscapes with n hosts can be recovered to one QA or DEV system.  Purpose is to offer a possibility for a light system copy without the full performance scope like PROD  Ability to work on that copy limited by performance and restricted by tables/partition sizes N  1 PROD QA, DEV or Sandbox
  17. 17. © 2013 SAP AG. All rights reserved. 17 Shared Backup Directory SAP HANA Backup/Recovery Data backup: Single-node and scale-out systems SAP HANA automatically handles the synchronization of backups for all nodes  no special user interaction required What happens internally:  All services with a persistence need to be backed up (e.g. index servers, master name server)  A global, synchronized backup savepoint is written for all these services o All transactions are stopped for a brief moment o Kept until the backup is finished for all services  Data marked in the savepoint is written from the data volume to a backup file o One backup file per service o Written in parallel -> read from different disks (depends on appliance configuration) Backup File Name Server Index Server Savepoint Name Server Index Server Savepoint Master Name Server Index Server Savepoint Data written in parallel from different nodes Savepoint
  18. 18. SAP HANA Scale-out
  19. 19. © 2013 SAP AG. All rights reserved. 19 Scale Out High Availability / Fail-over functionality Failover-configuration for HANA Failover capabilities for individual nodes  <N> active nodes in DB cluster  <M> standby nodes in DB cluster  Common file system for all nodes (in most cases; depends on hardware partner) Failover-Situation Node <X> becomes unavailable Standby node <Y> is activated  Reads tables from common file system (data + log)  Takes over logical connection from node <X> Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Standby Node SharedStorage
  20. 20. © 2013 SAP AG. All rights reserved. 20 In-Memory SAP HANA Database Landscape Persistence Layer LOG DISK DATA DISK LOG DISK DATA DISK LOG DISK DATA DISK LOG DISK DATA DISK LOG DISK DATA DISK *Standby Host: Name Server (active) Index Server (standby) Distributed HANA database even on a single host with shared nothing concept Standby without own persistence
  21. 21. © 2013 SAP AG. All rights reserved. 21 SAP HANA High Availability Minimal Setup for Host Auto-Failover Minimal setup for a Host Auto-Failover (Scale-Out): 2 Servers including one Standby External storage or similar technology necessary which ensures the data provisioning to second node via external data location This setup aims for High Availability not performance scaling or size. Note: Some use cases (e.g. SAP BW powered by HANA) might have different requirements or recommendations for minimal setups (e.g. BW has a defined setup for SAP HANA Scale-Out – SAP note 1637145  attached PDF). Master Name Server Index Server Data Disks Log Disks active standby Index Server Name Server
  22. 22. SAP HANA Replication
  23. 23. © 2013 SAP AG. All rights reserved. 23 SAP HANA Disaster Recovery Different ideas of solutions 1.SAP HANA Storage Replication of disk areas controlled by storage technology of HW partners • First synchronous implementation (available, more in validation, SAP note 1755396) • Afterwards asynchronous implementation planned and in preparation with HW partners 2.SAP HANA System Replication (initial solution): DATA and LOG content is continuously transferred to secondary site under control of SAP HANA database • Fast switch-over times because secondary site has preloaded DATA • First synchronous implementation (available with SAP HANA SPS5, Nov. 29th 2012) • Afterwards asynchronous implementation offered with SAP HANA SPS6 3.SAP HANA System Replication (extended solution): DATA content is only initially transferred to secondary site, afterwards continuous LOG transfer and LOG replay on secondary site • LOG is provided to secondary site on transactional basis (COMMIT) controlled by SAP HANA database (including initial DATA transfer) • Fastest switch-over times, sec. site preloaded and rolled forward on COMMIT basis • Synchronous and asynchronous implementation available with offering
  24. 24. © 2013 SAP AG. All rights reserved. 24 Data Center 2Data Center 1 SAP HANA Disaster Recovery: Storage Replication Cluster across Data Centers OS: Mounts Data Volumes Log Volume OS: DNS, hostnames Primary Name Server Index server Name Server Index server Name Server Index server Secondary (inactive) Name Server Index server Name Server Index server Name Server Index server HASolutionPartner Storage Mirroring Clients Application Servers HASolutionPartner Data Volumes Log Volume Data Volumes Log Volume Data Volumes Log Volume
  25. 25. © 2013 SAP AG. All rights reserved. 25 Data Center 2Data Center 1 SAP HANA Disaster Recovery: Storage Replication Cluster across Data Centers with QA & Dev. on 2nd site (planned) OS: Mounts Data Volumes Log Volume OS: DNS, hostnames Primary Name Server Index server Name Server Index server Name Server Index server Secondary Prod. (inactive), QA&DEV (active) Name Server Index server Name Server Index server Name Server Index server HASolutionPartner Storage Mirroring Clients Application Servers HASolutionPartner Data Volumes Log Volume Data Volumes Log Volume Data Volumes Log Volume Data Volumes Log Volume Data Volumes Log Volume
  26. 26. © 2013 SAP AG. All rights reserved. 26 SAP HANA Disaster Recovery: System Replication Cluster across Data Centers with DB controlled transfer Data Center 2Data Center 1 OS: Mounts Data Volumes Log Volume OS: DNS, hostnames, virt. IPs Primary (active) Name Server Index server Name Server Index server Name Server Index server Secondary (active, data pre-loaded) Name Server Index server Name Server Index server Name Server Index server HASolutionPartner Clients Application Servers HASolutionPartner Data Volumes Log Volume Data Volumes Log Volume Data Volumes Log Volume Transfer by HANA database kernel
  27. 27. © 2013 SAP AG. All rights reserved. 27 SAP HANA Disaster Recovery: System Replication Minimal setup in one Data Center for fast takeovers Data Center 1 OS: DNS, hostnames, virt. IPs Primary (active) Name Server Index server Secondary (active, data pre-loaded) Name Server Index server HASolutionPartner Clients Application Servers HASolutionPartner Transfer by HANA database kernelInternal Disks Internal Disks Data Disks Log Disks Data Disks Log Disks
  28. 28. © 2013 SAP AG. All rights reserved. 28 SAP HANA System Replication - Setup Configuration Steps Walldorf Primary Name Server Index server Name Server Index server Name Server Index server Data Volumes Log Volume Data Volumes Log Volume Rot Secondary Name Server Index server Name Server Index server Name Server Index server Data Volumes Log Volume Data Volumes Log Volume Start with two system on different sets of hosts, possibly different data centers SID, system-number and host topologies are equal Secondary uses additional port range (system-number + 100) Primary stays always online during activation (production not affected) Whole process is initiated by secondary  Stop secondary, primary can stay online  Primary: hdbnsutil -sr_enable --name=WALLDORF Check if an initial data backup exists on primary!  Secondary: hdbnsutil -sr_register --remoteHost=<walldorf_host> --remoteInstance=50 --mode=sync --name=ROT  Secondary: Start system, data and log transfer begins Synchronous mirrored redo log writing Complete data replication
  29. 29. © 2013 SAP AG. All rights reserved. 29 SAP HANA System Replication Replication Modes Synchronous (mode=sync) Primary sends redo log buffers synchronously. The redo log writer waits until it receives an acknowledgement from the secondary. The secondary sends the acknowledgement when it has written the redo log buffer to the redo log volume. Synchronous waits only appear for commits because write transactions in general only wait for redo log writing in case of an own commit . Synchronous In Memory (mode=syncmem) Primary sends redo log buffers synchronously. The redo log writer waits until it receives an acknowledgement from the secondary. The secondary sends the acknowledgement when it has received the redo log buffer without waiting until it’s written to the secondary's redo log volume. Synchronous waits only appear for commits because write transactions in general only wait for redo log writing in case of an own commit . Asynchronous (mode=async) Primary sends redo log buffers asynchronously. It doesn’t wait until the secondary sends an acknowledgement. Secondary guarantees database consistency across all system services. Takeover in secondary can lead to lost changes!
  30. 30. © 2013 SAP AG. All rights reserved. 30 SAP HANA System Replication Takeover Send Takeover command to secondary hdbnsutil -sr_takeover  Secondary goes online, main columns are preloaded as used in the primary Runtime of takeover mainly depends on the size of the row store Walldorf Primary Name Server Index server Name Server Index server Name Server Index server Data Volumes Log Volume Data Volumes Log Volume Rot Primary Name Server Index server Name Server Index server Name Server Index server Data Volumes Log Volume Data Volumes Log Volume _ Clients Switch virtual hostnames / IP-adresses
  31. 31. © 2013 SAP AG. All rights reserved. 31 SAP HANA System Replication Failback after takeover Activate Previous Primary as secondary when DC is back Register Walldorf as secondary Walldorf: hdbnsutil -sr_register --remoteHost=<rot_host> --remoteInstance=<nr> --mode=sync --name=WALLDORF Primary sends a complete persistent data Synchronous mirrored redo log writing Transport complete data Rot Primary Name Server Index server Name Server Index server Name Server Index server Data Volumes Log Volume Data Volumes Log Volume Walldorf Secondary Name Server Index server Name Server Index server Name Server Index server Data Volumes Log Volume Data Volumes Log Volume
  32. 32. © 2013 SAP AG. All rights reserved. 32 Worldwide Data Center Setups Feature timeline with SAP HANA System Replication Campus cluster Metro cluster Geo cluster 1:1 SYNC Since SPS5 Planned for SAP HANA (w/ SPS7 1:n ) 1:1 ASYNC Since SPS6
  33. 33. © 2013 SAP AG. All rights reserved. 33 Worldwide Data Center Setups Support Geo Clusters with System Repl. – Setups possible with B&R now Campus cluster Metro cluster Geo cluster Sync Sync RPO = 0 RTO = < 30 min RPO ≠ 0 RTO ≤ 24 h since SPS5
  34. 34. © 2013 SAP AG. All rights reserved. 34 Worldwide Data Center Setups Multiple Sec. Systems – Chained Setups w/ pure System Repl. (planned) Campus cluster Metro cluster Geo cluster Sync Async Sync Production Local standby Remote standby systems Planned for SAP HANA (w/ SPS7,Cascading Systems) RPO ≠ 0 RTO < 30 min
  35. 35. SAP HANA Roadmap
  36. 36. © 2013 SAP AG. All rights reserved. 36 SAP HANA in Data Centers Roadmap SPS6 (Mid 2013) Planned Beyond Backup & Recovery  Backup LiveCycle Mgmt & Security extensions  Recovery options (n->m) especially for System copy  Incremental Backup(2014)  Named internal Snapshots(2014)  Keep Backup history with topology changes High Availability (Per Data Center) Disaster Recovery (Across Data Center)  System Replication extension • Async & sync transfer option • Near zero downtime maintenance • HW mix • Asymmetric setups  System Replication extension • Zero Downtime maintenance • Backup on shadow instance • Time travel via internal snapshots on secondary to handle logical errors • Cascading systems • Compress log transfer • Time delay option between sites • Basic encryption • Pure Log-based transfer (2014) • Active/Active Operation (2014)  Log Shipping Monitoring, Alerting & Administration  Improved monitoring / SQL Plan Cache / Table and Partition redistribution editor with automation option / More support for 3rd party tools  More 3rd party management tools  Monitoring API (2014) 3rd Party Tooling  Direct streaming to 3rd party backup tools  More 3rd party backup tools Security & Auditing  Extended Auditing / User-Role Mgmt / Authentication / Authorization / Application Security  Extended Auditing  Defined OS installation setup
  37. 37. © 2013 SAP AG. All rights reserved. 37 Useful Links SAP HANA portal page with customer testimonials www.sap.com/hana SAP HANA collaboration space for customers www.saphana.com HANA Technical SCN space http://scn.sap.com/community/developer-center/hana SAP HANA official documentation http://help.sap.com/hana_appliance SAP Education Offerings https://training.sap.com/de/en/curriculum/hana-sap-hana-g-de
  38. 38. Teşekkürler! İletişim Bilgileri: Ad Soyad: Uğur Naciterhan Unvan: Solution Manager Adres: SAP Türkiye Anel İş Merkezi, İstanbul Telefon Numarası: +90 216 633 03 42 Email: ugur.naciterhan@sap.com

×