saphighavailability-130926061652-phpapp01

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


SAP HANA Appliance


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


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

http://en.wikipedia.org/wiki/Database

http://en.wikipedia.org/wiki/Database_management_system


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


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


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


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


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


Backups in SAP HANA Database

Memory>Disk>Backup


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)


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


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


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


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


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

https://service.sap.com/sap/support/notes/1637145

SAP HANA Replication


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

https://service.sap.com/sap/support/notes/1755396


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



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


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


SAP HANA Disaster Recovery: System Replication Cluster across Data Centers with DB controlled transfer


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


HA

Solu

tion P

art

ner

Data

Volumes

Log

Volume

Data

Volumes

Log

Volume

Data

Volumes

Log

Volume

Transfer

by

HANA

database

kernel


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


HA

Solu

tion P

art

ner

Transfer

by

HANA

database

kernel Internal

Disks

Internal

Disks

Data

Disks

Log

Disks

Data

Disks

Log

Disks


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


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!


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


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


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


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


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


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


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

http://www.sap.com/hana

http://www.saphana.com/

http://www.saphana.com/


















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: [email protected]

saphighavailability-130926061652-phpapp01

Documents