saphighavailability-130926061652-phpapp01
Post on 19-Jul-2016
5 Views
Preview:
DESCRIPTION
Transcript
SAP FORUM İSTANBUL Gelecek Bugün
Konuşmacı Adı : Uğur Naciterhan
Firma Adı : SAP Türkiye
SAP HANA HIGH AVAILABILITY ÇÖZÜMLERİ
© 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
SAP HANA Architecture
© 2013 SAP AG. All rights reserved. 4
SAP HANA Appliance
© 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
© 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
© 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
© 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
SAP HANA High Availability & Disaster Recovery
© 2013 SAP AG. All rights reserved. 10
Continuous
availability
SAP HANA Continuous Availability Customer Expectation: Planned & Unplanned
Planned downtime
Unpla
nned d
ow
ntim
e
• 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
© 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
© 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
SAP HANA Backup / Restore
© 2013 SAP AG. All rights reserved. 14
Backups in SAP HANA Database
Memory>Disk>Backup
© 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)
© 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
© 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
SAP HANA Scale-out
© 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
Sh
are
d S
tora
ge
© 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
© 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
SAP HANA Replication
© 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
© 2013 SAP AG. All rights reserved. 24
Data Center 2 Data 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
HA
Solu
tion P
art
ner
Sto
rage
Mirro
ring
Clients Application Servers
HA
Solu
tion P
art
ner
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
© 2013 SAP AG. All rights reserved. 25
Data Center 2 Data 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
HA
Solu
tion P
art
ner
Sto
rage
Mirro
ring
Clients Application Servers
HA
Solu
tion P
art
ner
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
© 2013 SAP AG. All rights reserved. 26
SAP HANA Disaster Recovery: System Replication Cluster across Data Centers with DB controlled transfer
Data Center 2 Data 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
HA
Solu
tion P
art
ner
Clients Application Servers
HA
Solu
tion P
art
ner
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Data
Volumes
Log
Volume
Transfer
by
HANA
database
kernel
© 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
HA
Solu
tion P
art
ner
Clients Application Servers
HA
Solu
tion P
art
ner
Transfer
by
HANA
database
kernel Internal
Disks
Internal
Disks
Data
Disks
Log
Disks
Data
Disks
Log
Disks
© 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
© 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!
© 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
© 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
© 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
© 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
© 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
SAP HANA Roadmap
© 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
© 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
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
top related