openSAP hshd1 Week2 All Slides PDF

Week 2 Unit 1:
System Replication
System Replication
Overview (1)
System Replication:
Alternative, high availability solution for
SAP HANA platform, providing an extremely short
RTO
Compatible with all SAP HANA hardware partner
solutions
Employs an "N+N" approach, with a secondary
standby system. Secondary system has the same
number of active nodes as the active, primary system
2016 SAP SE or an SAP affiliate company. All rights reserved.
Primary System
Secondary System
Public
System Replication
Overview (2)
System Replication:
The instances in the secondary system operate in live
replication mode.
In this mode, all secondary system services constantly
communicate with their primary counterparts.
System replication replicates data and persists
data/logs, and finally loads data to memory.
The logs and data can be compressed before shipping.
The secondary system does not accept requests or

queries.
Primary System
Secondary System
Public
System Replication
Replication mode Options (1)
1. Synchronous in-memory (default): The primary
system commits the transaction after it receives a
reply confirming that the log was received by the
secondary system, but before it has been persisted.
Primary
Secondary
STOP
Transaction
2. Synchronous with full sync: This option means that

the log write is successful when the log buffer has
been written to the log file of the primary and the
secondary instance.
Data
Log
Data
Log
Synchronous with full SYNC operation
Public
System Replication
Replication mode Options (2)
3. Synchronous: The primary system does not commit
a transaction until it receives confirmation that the log
has been persisted in the secondary system.
4. Asynchronous: The primary system sends redo log

buffers to the secondary system asynchronously. The
primary system commits a transaction when it has
been written to the log file of the primary system and
sent to the secondary system through the network.
Primary
Secondary
Transaction
Data
Log
Data
Log
ASYNC operation
Public
System Replication
Operation mode Options
Depending on the system replication configuration,
there are two operation modes available:
1. Delta data shipping: In this operation mode the
secondary system persists but does not immediately
replay the received logs.
2. Logreplay (available from SPS11): With this
operation mode configured, the received log entries
are replayed immediately in the secondary system.
The takeover time is reduced significantly because
the log no longer has to be replayed.
Secondary
Primary
SAP HANA
Delta Data
SAP HANA
Log
Public
System Replication
Minimal setup in one data center for fast takeovers
Clients
Application Servers
Primary
Secondary
(active)
(active, data preloaded)
Name Server
Transfer
by
Index Server
Index Server
SAP HANA
database
kernel
Internal
Disks
Data
Disks
Name Server
Log
Disks
Internal
Disks
Data
Disks
HA Solution Partner
HA Solution Partner
Data Center 1
OS: DNS, hostnames, virt. IPs
Log
Disks
Public
System Replication
Cluster across data centers with DB controlled transfer
Application Servers
HA Solution Partner
Data Center 1
Data Center 2
Primary
(active)
Name Name Name
Server Server Server
Index Index Index
OS: Mounts
Secondary
Transfer
by
SAP HANA
database
kernel
(active, data preloaded)

Name Name Name
Index Index Index
Data
Volumes
Data
Volumes
Data
Volumes
Data
Volumes
Log
Volumes
Log
Volumes
Log
Volumes
Log
Volumes
HA Solution Partner
Clients
Public
System Replication
Cluster across data centers with QA & DEV on second site
Clients
Application Servers
Primary
(active)
Name Name Name
Index Index Index
OS: Mounts
HA Solution Partner
HA Solution Partner
Data Center 1
Data Center 2
Secondary
Transfer
by
SAP HANA
database
kernel
(active,PRD
data pre-loaded)
shadow
Name Name Name
operation
Index QA/DEV
Name Name
Server Server
runningServer
Data
Volumes
Data
Volumes
Data
Volumes
Data
Volumes
Data
Volumes
Data
Volumes
Log
Volumes
Log
Volumes
Log
Volumes
Log
Volumes
Log
Volumes
Log
Volumes
PRD
QA/DEV
Public
System Replication
SAP HANA multitenant database containers
SAP HANA Multitenant Database Containers:
SAP HANA system replication can be used to replicate
the whole system.
The replication process treats the complete collection
of tenant containers as one.
Primary and secondary systems must be identical at
the time of system replication setup, including tenant
databases.
Replication of a single tenant to an individual location is
not possible.
Primary
Secondary
SystemDB
SystemDB
TenantDB1
Delta Data
TenantDB2
TenantDB n
MDC
TenantDB1
TenantDB2
Log
TenantDB n
MDC
Public
10
Thank you
Contact information:
open@sap.com

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate
company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its
affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and
services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as
constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop
or release any functionality mentioned therein. This document, or any related presentation, and SAP SEs or its affiliated companies strategy and possible future
developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time
for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forwardlooking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place
undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.
Public
12
Week 2 Unit 2: Continuous Log

Replay Replication
Continuous Log Replay Replication

Overview
Continuous log replay (pure log-based transfer)
Automatic Initial Data Load
Redo log is processed immediately on secondary

(commit-based)
New operation mode logreplay
Primary
No more delta-data transfer necessary
SAP
HANA
Reduced takeover times
Network traffic significantly reduced

Automatic initial data transfer still supported
Log
Secondary
SAP
HANA
Client
r/w
Continuous Log replication is the foundation for

active/active operations (planned beyond SP11)
Delta
Data
r/o
Primary
Secondary
SAP
HANA
SAP
HANA
Log
Public

Configuration (1)
Only a few steps are necessary to
configure SAP HANA system replication:
SAP HANA studio

Prim.
Create an initial data backup (native or storage

snapshot)
Enable primary system for system replication

Register secondary
Sec.
New option in operation mode: logreplay

Start secondary
Public

Configuration (2)
Command line tool hdbnsutil
First initial data backup
SAP HANA studio

Prim.
Enable primary
hdbnsutil sr_enable ...
Jump to secondary and register
Sec.
hdbnsutil sr_register
replicationMode=[sync|syncmem|async]
operationMode=[delta_datashipping|logrepl
ay]...
Start secondary
Public

New parameters (1)
logshipping_max_retention_size <> 0
(soft limit)
In a disconnect situation, the log segments are not reused until the max size limit is reached. In a log full
situation, they are reused
This prevents system standstill on the primary site due
to too many log segments that are held for syncing the
secondary site
This way, the primary is kept running with the drawback
that the secondary can no longer sync and has to be
reinitialized with a data shipping
New
New
Default: 1TB
Public

New parameters (2)
logshipping_max_retention_size = 0
(hard limit)
Log segments required for secondary syncing are not
re-used and a log full results in system standstill on the
primary site until log writing can continue
Here, syncing the secondary has priority over standstill
on the primary
When the log full has been resolved (on the primary or
secondary site), transaction processing can continue
New
New
Public

Data retention vs. log retention
Data Retention (delta data shipping)
Log Retention (log replay)
After reconnect or failback, the

primary sends incremental data, if
the last snapshot is still available
After reconnect or failback, the

primary sends an incremental log, if
the enable_log_retention
parameter is on
How long the last snapshot that

was sent to the secondary is kept
depends on the parameter value of
datashipping_snapshot_max_ret
ention_time (default: 120 minutes)
Otherwise, a full set of data is

shipped
logshipping_max_retention_size
defines the maximum amount of log

segments that are kept on the
primary side for syncing a
secondary system, i.e. that are not
re-used (default 1 TB)
Primary
Delta
Data
Secondary
SAP
HANA
SAP
HANA
Log
Data
Log
Data
Log
Primary
Secondary
SAP
HANA
SAP
HANA
Log
Log segments will not be freed while

the secondary is disconnected
Data
Log
Log
Data
Public
Log

Zero Downtime takeover procedure SAP NetWeaver ABAP stack
Evolving from near Zero Downtime Maintenance, as
of SPS07, SAP HANA offers Zero Downtime
Maintenance:
SAP NetWeaver
ABAP Server
Based on connectivity suspend feature of the SAP

NetWeaver ABAP stack (SAP Note 1913302)
DBSL
DBSL of the database interface decouples transaction

management between ABAP and SAP HANA database
Decoupling keeps the transaction on the ABAP layer alive
and allows components (software versions) to be changed
on the layers below on the secondary (shadow) SAP HANA
instance
Software
Upgrade
Order
SAP HANA Version
Walldorf
Primary
Data
Volumes
Name
Server
Name
Server
Name
Server
Index
Server
Index
Server
Index
Server
Log
Volume
Data
Volumes
Log
Volume
SAP HANA Version +1

Rot
Sync/Async
mirrored
Secondary
redo log writing
Transport
incremental data
Data
Volumes
Name
Server
Name
Server
Name
Server
Index
Server
Index
Server
Index
Server
Log
Volume
Public
Data
Volumes
Log
Volume

Zero Downtime takeover procedure Planned
SAP NetWeaver
ABAP Server
DBSL
Cluster Manager
(e.g. SUSE
Cluster)
Software
Upgrade
Order
SAP HANA Version

Walldorf
Primary
Log
DBSL
Connectivity
Suspend
SAP HANA Version +1 SAP HANA Version

Sync/Async mirrored
redo log writing
Rot
Walldorf
Secondary
Primary
Sync/Async mirrored
redo log writing
Rot
Walldorf
Secondary
Primary
Log
Data
Log
Virtual
IP
3. Re-initiate
SAP HANA Version +1 SAP

SAP HANA
HANA Version
Version +1
Transport
incremental data
Data
Cluster Manager
(e.g. SUSE
Cluster)
1. Update
2. Reconfigure
Takeover
Transport
incremental data
Data
SAP NetWeaver
ABAP Server
DBSL
Virtual
IP
SAP NetWeaver
ABAP Server
SAP HANA Version +1
Sync/Async mirrored
redo log writing
Rot
Secondary
Transport
incremental data
Data
Log
Data
Log
Data
Public
Log

Zero Downtime takeover procedure Unplanned
DNS Virtual
Hostname
DNS Virtual
Hostname
DNS Virtual
Hostname
SAP NetWeaver
ABAP Server
SAP NetWeaver
ABAP Server
DBSL
DBSL
Cluster Manager
(e.g. SUSE
Cluster)
Cluster Manager
(e.g. SUSE
Cluster)
Virtual
IP
Takeover
Virtual
IP
Walldorf
Primary
Sync/Async mirrored
redo log writing
Rot
Walldorf
Secondary
Primary
Transport
incremental data
Data
Log
SAP NetWeaver
ABAP Server
Sync/Async mirrored
redo log writing
1. Rebuild
2. Reconfigure
Rot
Walldorf
Secondary
Secondary
Transport
incremental data
Data
Log
Data
Log
DBSL
Virtual
IP
3.Re-initiate
Sync/Async mirrored
redo log writing
Rot
Primary
Transport
incremental data
Data
Log
Data
Log
Data
Public
Log
10
Thank you
open@sap.com

Public
12
Week 2 Unit 3: Host Auto-Failover/ScaleOut, Storage Replication
Host Auto-Failover/Scale-Out, Storage Replication
Server 3
Name
server
Server 4
Name
server
Server 5
Name
server
Server 6
Name
server
Standby Server
Minimalistic setup for only HA:

Name
server
Name
server
SAN Storage
Name
server
Server 1
Standby Server
SAN
The resulting cluster is managed by the name service inside

SAP HANA
SAP HANA regularly checks the cluster members are still
active
In case of problems, the system initiates a fully automated
takeover to the standby hardware
Together with the switched mounts/disks, the identity of the
failing cluster member is moved to the standby hardware
Server 2
Public
Storage
Host auto-failover
Name
server
Shared Storage
Scale to a setup larger than one host

Offer an easy HA option by having one or more hosts as
spare/standby
Server 1
Storage
Connector
API
Scale-out clusters address two problems:
Name
server
Storage Connector API
Scale-out with host auto-failover

Storage for persistent data
Fiber Channel Storage using SAN

Non-shared SAN storage
attached via Fiber Channel for
SAP HANA data and log volumes
and shared NFS/NAS storage for
SAP HANA binaries
Shared-nothing architecture with

cluster file systems
Shared storage infrastructure using
cluster file system with local disks
Network attached storage
using NFS
Public

Host auto-failover (1)
Host Auto-Failover:
Host auto-failover is a local "N+m" (m is often 1)
fault recovery solution.
It is used as a supplemental or alternative
measure to the system replication solution.
One (or more) standby hosts are added to an
SAP HANA system and configured to work in
standby mode.
Host auto-failover before failure
Public

Host Auto-Failover:
When an active (worker) host fails, a standby
host automatically takes its place.
Since the standby host may take over operation
from any of the primary hosts, it needs access to
all the database volumes.
This is accomplished by a shared networked
storage server, by using a distributed file system.
Host auto-failover after recovery
Public

Host Auto-Failover:
In order to recover connections from SAP HANA

clients that were configured to reach the original
host, and need to be "diverted" to the standby
host after host auto-failover, there are a couple of
approaches available:
http load balancer (HLB)
Network base approach (IP or DNS)
SQL/MDX database clients
Public

Host Auto-Failover:
SAP HANA host auto-failover uses a
combination of heartbeat and fencing
capabilities
1. Heartbeat: The following types of heartbeats
are used to check if another host is active as
master before starting the current host as
master or performing a failover.
TCP communication-based heartbeats:
a) Ping from name server to name server with
SAP HANA internal communication protocol
b) Ping from name server to hdbdaemon with
SAP HANA internal communication protocol
Worker
(Master candidate 2)
Master
Standby
Rewrites single
random strings
repeatedly
Checks for
changes
.lck
Tries to become new master
Located in
shared storage
for SAP HANA
binaries
Check
name server locks
.lck is still changing

original master still
alive
If
Public

2. Fencing: I/O fencing ensures that the other
side no longer accesses the data or log
storage.
The SAP HANA storage connector API allows
usage of different types of storage and network
architecture to ensure proper I/O fencing:
SAN storage: SAP HANA Fiber Channel
storage connector using SCSI-3 persistent
reservations (SCSI-3 PGR)
NFSv3: used without file locking, but with a
storage connector provided by certified
storage vendors
NFSv4 or cluster file systems like GPFS:
using file locks
Worker
Master
Standby
Rewrites single
random strings
repeatedly
Checks for
changes
.lck
Located in
shared storage
for SAP HANA
binaries
Check
name server locks

alive
If
Public

Host Auto-Failover:
One dangerous scenario that may occur with
host auto-failover is referred to as split-brain.
Master name server is the only entity to make a
failover decision
Network errors between master candidates and
master name server can cause split-brain
situations
As long as the randomly written string in file
nameserver.lck is changing, master is still alive
Worker
Master
Standby
Rewrites single
random strings
repeatedly
Checks for
changes
.lck
Located in
shared storage
for SAP HANA
binaries
Check
name server locks

alive
If
Public

Storage replication
Storage Replication:
Storage level replication prevents the potential
loss of data from the time of the last backup to
the time of the failure and provide continuous
replication of all persisted data:
It delivers a backup of the volumes or file system
to a remote networked storage system.
The locally persisted transaction log has been
replicated remotely via synchronous storage
replication.
Primary System
Replicated Storage
Synchronous storage replication can be used

only when the distance between the primary and
backup site is no more than 100 km
Public
10

Storage replication Cluster across data centers
Application Servers
Data Center 2
Primary
Secondary
(inactive)
Name Name Name

Index Index Index
OS: Mounts
Data
Volumes
Data
Volumes
Log
Volumes
Log
Volumes
Name Name Name

Index Index Index
Storage
Mirroring
HA Solution Partner
Data Center 1
OS: DNS, hostnames
Data
Volumes
Data
Volumes
Log
Volumes
Log
Volumes
HA Solution Partner
Clients
Public
11

Cluster across data centers with QA & DEV on second site
Application Servers
Data Center 2
Secondary
Primary
PROD (inactive)
QA & DEV (active)
Name Name Name
Index Index Index
Name Name Name

Index Index Index
OS: Mounts
Data
Volumes
Data
Volumes
Log
Volumes
Log
Volumes
Storage
Mirroring
HA Solution Partner
Data Center 1
OS: DNS, hostnames
HA Solution Partner
Clients
Data
Volumes
Data
Volumes
Data
Volumes
Data
Volumes
Log
Volumes
Log
Volumes
Log
Volumes
Log
Volumes
Public
12
Thank you
open@sap.com

Public
14

openSAP hshd1 Week2 All Slides PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

openSAP hshd1 Week2 All Slides PDF

Uploaded by

Copyright:

Available Formats

Week 2 Unit 1:

2016 SAP SE or an SAP affiliate company. All rights reserved.

The secondary system does not accept requests or

2016 SAP SE or an SAP affiliate company. All rights reserved.

2. Synchronous with full sync: This option means that

Synchronous with full SYNC operation

2016 SAP SE or an SAP affiliate company. All rights reserved.

4. Asynchronous: The primary system sends redo log

2016 SAP SE or an SAP affiliate company. All rights reserved.

2016 SAP SE or an SAP affiliate company. All rights reserved.

(active, data preloaded)

2016 SAP SE or an SAP affiliate company. All rights reserved.

(active, data preloaded)

2016 SAP SE or an SAP affiliate company. All rights reserved.

2016 SAP SE or an SAP affiliate company. All rights reserved.

2016 SAP SE or an SAP affiliate company. All rights reserved.

2016 SAP SE or an SAP affiliate company. All rights reserved.

2016 SAP SE or an SAP affiliate company. All rights reserved.

Week 2 Unit 2: Continuous Log

Continuous Log Replay Replication

Automatic Initial Data Load

Redo log is processed immediately on secondary

No more delta-data transfer necessary

Reduced takeover times

Network traffic significantly reduced

2016 SAP SE or an SAP affiliate company. All rights reserved.

Continuous Log replication is the foundation for

Continuous Log Replay Replication

SAP HANA studio

Create an initial data backup (native or storage

Enable primary system for system replication

New option in operation mode: logreplay

2016 SAP SE or an SAP affiliate company. All rights reserved.

Continuous Log Replay Replication

SAP HANA studio

Jump to secondary and register

2016 SAP SE or an SAP affiliate company. All rights reserved.

Continuous Log Replay Replication

2016 SAP SE or an SAP affiliate company. All rights reserved.

Continuous Log Replay Replication

2016 SAP SE or an SAP affiliate company. All rights reserved.

Continuous Log Replay Replication

Log Retention (log replay)

After reconnect or failback, the

After reconnect or failback, the

How long the last snapshot that

Otherwise, a full set of data is

defines the maximum amount of log

Log segments will not be freed while

2016 SAP SE or an SAP affiliate company. All rights reserved.

Continuous Log Replay Replication

Based on connectivity suspend feature of the SAP

DBSL of the database interface decouples transaction

2016 SAP SE or an SAP affiliate company. All rights reserved.

SAP HANA Version +1

Continuous Log Replay Replication

SAP HANA Version

SAP HANA Version +1 SAP HANA Version

2016 SAP SE or an SAP affiliate company. All rights reserved.

SAP HANA Version +1 SAP

SAP HANA Version +1

Continuous Log Replay Replication

2016 SAP SE or an SAP affiliate company. All rights reserved.