High Availability and Disaster Recovery for SAP HANA with SUSE Linux Enterprise Server for SAP Applications

(1)

Uwe Heinz

Product Manager SAP

[email protected]

High Availability and Disaster Recovery for SAP HANA

with SUSE Linux Enterprise Server for SAP

Applications

Fabian Herschel

Senior Architect SAP LinuxLab SUSE SAP Global Alliance [email protected]

(2)

Agenda

SAP HANA typical implementations Outlook for the next 12 – 18 months

Disaster Recovery Capabilities of SAP HANA Automate SAP HANA System Replication

SAPHanaSR - Setup and Implementation SAPHanaSR - Roadmap

Our Community

(3)

Introduction & Overview (SAP and LINUX)

Foundation of Linuxlab

SAP Netweaver

Linux

develpoment plattform

SAP BWA and SAP HANA

SoH and BWonH

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 CeBit

99

and growing ...

SAP supports only : SLES, RHEL and Oracle Linux

15 years

(4)

Joined activities

Events Maintenance

Development

Priority support

bench marks

Gcc optimization

NUMA optimiz ation

KVM/

XEN

SUSE HA

HANA for Linux on

Power

Teched Berlin/Las

Vegas

DSAG/

ASUG

SuseCon

>50 customer

WS NFS

local loopback

SuseLabs conference

Joined support

> 15 years

4 Developer in SAPLinuxlab

harde ning

SLES4SAP

(5)

Joined activities

(6)

High Availability & Disaster Recovery

Customer

http://www.saphana.com/docs/DOC-2010

(7)

High Availability – Disaster Recovery

Overview

Business Continuity

High Availability per Data Center

Disaster recovery between Data Centers

SAP HANA Host Auto-Failover (Scale-Out with Standby)

SAP HANA Storage Replication

SAP HANA System Replication

● Performance Optimized

● Cost Optimized

SAP HANA System Replication

● Performance Optimized

● Cost Optimized

1

2

3

4

(8)

High Availability Options

Scale-Out or Host Auto-Failover 1

(9)

SAP HANA High Availability: Host Auto-Failover

High Availability configuration

•N active servers in one cluster

•M standby server(s) in one cluster

•Shared file system for all servers

Services

•Name and index server on all nodes

•Statistics server (only on one active server)

•Name server active on Standby

Failover

•Server X fails

•Server N+1 reads indexes from shared storage and connects to logical connection of server X

•Storage Connector API ensures remount of necessary disk areas (Note 1900823 - Storage Connector API  Attachments)

Shared Storage SAN Storage

Storage Connector API

Server 1

Server 2

Server 3

Server 4

Server 5

Server 6

Standby Server

(10)

HANA High Availability

Host Auto-Failover (standby)

Different implementation of High Availability by HW partners Using storage solution inside

NFS/cluster fs / reallocating block devices Using internal disk

Name Server

Index Server

Standby Name Server Index Server Name

Server Index Server

Data Disks

Log Disks

Data Disks

Log Disks

Data Disks

Log Disks

GPFS

(11)

High Availability Options

SAP HANA System Replication 2

(12)

SAP HANA High Availability: System Replication

Performance Optimized

Performance optimized option

 Secondary system completely used for the preparation of a possible take-over

 Resources used for data pre-load on Secondary

 Take-overs and Performance Ramp shortened maximally

Data Center 1

OS: DNS, hostnames, virt. IPs

Primary

(active)

Name Server

Index server

Secondary

(active, data pre-loaded)

Name Server

Index server

HA Solution Partner

Clients Application Servers

HA Solution Partner

Transfer by

HANA database

kernel Internal

Disks

Internal Disks

Data Disks

Log Disks

Data Disks

Log Disks

(13)

SAP HANA High Availability: System Replication

Cost Optimized

Cost optimized with

 Operating non-prod systems on Secondary

 Resources freed (no data pre-load) to be offered to one or more non-prod installations

 During take-over the non-prod operation has to be ended

 Take-over performance similar to cold start-up

Data Center 1

Primary

(active)

Name Server

Index server

Secondary

Name Server

Index server

HA Solution Partner

Transfer by

HANA database

kernel Internal

Disks

Data Disks

Log Disks

Internal Disks Data

Disks Log Disks

Data Disks

Log Disks

PRD QA/DEV

QA/DEV running PRD shadow operation

(14)

Disaster Recovery Options

SAP HANA Storage Replication 3

(15)

SAP HANA Disaster Recovery: Storage Replication

Cluster across Data Centers with non-prod on 2^nd site

Arrangement usually offered with a strong part of hardware partners involvement

 Support issues handled by/routed to HW partners

TCO reduction by combined operation with non-prod on Secondary

 Needs another disk stack for non- prod usage load

Cluster management often included and delivered as a whole package

Data Center 2 Data Center 1

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 Solution Partner Storage Mirroring

HA Solution Partner

Log Volume

(16)

Disaster Recovery Options

SAP HANA System Replication 4

(17)

SAP HANA Disaster Recovery: System Replication

Cluster across Data Centers with DB controlled transfer

Performance optimized option

 Faster Take-Over

 Shortened Performance Ramp (seconds to less minutes)

 SYNC & ASYNC possible

Several cluster options

 Some HW Partners offer pre- packaged options

Step-by-Step Implementation Guide (updated recently to SPS8):

 https://scn.sap.com/docs/DOC- 47702

Data Center 2 Data Center 1

OS: Mounts

Log Volume

Primary

(active)

Name Server

Index server

Name Server

Secondary

(active, data pre-loaded)

Name Server

Index server

Name Server

Index server

Name Server

Index server

HA Solution Partner

Log Volume

Log Volume Transfer

by

HANA database

kernel

(18)

How to configure

HANA system replication

(19)

SAP HANA in Data Centers

Video about SAP HANA System Replication

http://www.saphana.com/docs/DOC-4152

https://www.youtube.com/watch?v=oBUiWMjARpc

(20)

System replication using SAP HANA studio

Same SID

Same

Systemnumber

Same number of services

(index,name,…)

(21)

System replication using SAP HANA studio

Complete data backup

(22)

System replication using SAP HANA studio

Apply a logical

systemname e.g. location

(23)

System replication using SAP HANA studio

First stop the secondary site

Apply a logical name e.g. location

(24)

System replication using SAP HANA studio

1. Start the secondary site

2. replication starts using backup and logs

3. Takeover done using SAP HANA Studio (admin)

(25)

High Availability for SAP with SUSE

Around 10 years of experience with High Availability for SAP NetWeaver Systems

Starting around 1 year ago to implement the HANA SR Automation

Solutions are jointly developed between SUSE, SAP, customers and partners in the SAP Linux Lab in Walldorf

(26)

SAP HANA System Replication and

SLES for SAP Applications

resource failover active / active

node 1 node 2

N M

A B

N M

A B

HANA Database

HANA

memory-preload

A B

System Replication

HANA PR1

primary HANA PR1

secondary

(27)

Automate SAP HANA System Replication

Service Level Agreement

SAP HANA System

Replication

SUSE High Availability

Solution

(28)

SUSE Linux Enterprise High Availability Extension Cluster for SAP HANA System Replication

Pacemaker

System Replication

node 1 node 2

SAP HANA PR1

primary

secondary System

PR1 System

PR1 vIP

(29)

Pacemaker

System Replication

node 1 node 2

primary

secondary System

PR1 System

PR1

(30)

Pacemaker

System Replication

node 1 node 2

[primary]

primary System

PR1 System

PR1

vIP

(31)

Direction of the system replication will only be changed if the parameter AUTOMATED_REGISTER is been changed to “true”

Pacemaker

System Replication

node 1 node 2

secondary

primary System

PR1 System

PR1

vIP

(32)

From Concept to Implementation

SAP HANA

Primary SAP HANA

Secondary

vIP

SAPHana

Master/SlaveResource

Master Slave

SAPHanaTopology CloneResource

Clone Clone

suse01 suse02

Cluster Communication

Fencing

(33)

HANA System Replication in HAWK

(34)

SAPHanaSR Delivery

Package SAPHanaSR with two resource agents: SAPHanaTopology and SAPHana

Setup Guide SAPHanaSR HAWK Wizard

and

(35)

Four Steps to Install and Configure

Install SAP HANA

Configure SAP HANA System Replication

Install and initialize SUSE Cluster

Configure SR Automation using HAWK wizard

(36)

SAPHanaSR HAWK Wizard

Technical preview included in the shipping.

(37)

Outlook: SAPHanaSR-monitor

(38)

Internal Testing: Test-Driver with >25K Tests

(39)

The Five Interfaces

HANA Startframework: sapstartsrv/sapcontrol/ HDB (calls, output format “GetProcessList”)

HANA-Topology: landscapeHostConfiguration.py (rc, output format)

SR-Topology: hdbnsutil

(calls, output format “-sr_state--sapcontrol=1”) SAPHostagent: saphostctrl

(call, output format “ListInstances”)

SR-Status: hdbsql(now) / systemReplicationStatus.py (SPS09) (rc, calls, output format)

(40)

Allowed Scenarios (yet)

Two-node clusters

Scale-up (single-box to single-box) HANA system replication Single-tier System Replication ( A → B ), no multi-tier

Preferred site takeover active - there is no other SAP HANA system (like DEV, TST, QAS) on the replicating node that needs to be stopped during takeover (not a technical limit, but requires additional testing)

Both physical and “virtual” SAP host names

(41)

Requirements

Both SAP HANA instances have the same SAP Identifier (SID) and Instance Number

Both cluster nodes in-time sync (ntp)

Both nodes are in the same network segment (layer2) Technical users and host names resolved locally

Distance / Latencies

(42)

Roadmap / Next Steps

Scale-Out ( @A → @B )

- Currently under development - PoC Tests expected in Q1/2015

Multi-tier System Replication – Chain Topology ( A → B → C ) - Currently under testing

- Partner Tests expected in Q4/2014

Single-tier System Replication and DEV / TST ( A → [B] + DEV ) - Cluster configuration already available

- Partner Tests expected in Q4/2014

(43)

Outlook: HANA in a SUSE Linux Enterprise High

Availability Extension Cluster

HANA Multi Node – System Replication / Scale-OUT

swarm 1 swarm 2

N M

A B

N M

A B

HANA Database

HANA

memory-preload

System Replication

HANA PR1

primary HANA PR1

secondary

This scenario is currently in development

A B

resource failover active / active

(44)

Our Community

Developed jointly in the SAP Linux Lab in Walldorf Integration of the solution in partner products

Upstream open-source project

Scoping, discussing and implementing Scale-Out

You are invited to join

our community :-)

Visit our booth or contact us via

[email protected] or [email protected]

(45)

SUSE SAPHanaSR in 3 Facts

Reduces complexity

- provides a wizard for easy configuration with just SID, instance number and IP address

- automates the sr-takeover and IP failover ("bind")

Reduces risk

- includes always a consistent picture of the SAP HANA topology

- provides a choice for automatic registrations and site takeover preference

Increases reliability

- provides short takeover times in special for table preload scenarios - includes the monitoring of the system replication status to increase data consistency

(46)

Thank you.

Find our Best Practices at:

www.suse.com/products/sles-for-sap/resource-library/

(47)

Corporate Headquarters Maxfeldstrasse 5

90409 Nuremberg Germany

+49 911 740 53 0 (Worldwide) www.suse.com

Join us on:

www.opensuse.org

(48)

This work is an unpublished work and contains confidential, proprietary and trade secret information of SUSE.

Access to this work is restricted to SUSE employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of SUSE.

Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.

General Disclaimer

This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. SUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for SUSE products remains at the sole discretion of SUSE. Further, SUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All SUSE marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.