This slide deck was used to present SAP TechEd 2019 session called "Deployment Options with Business Continuity for SAP HANA (HA and DR)"

1. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
CAA232
Deployment Options with Business Continuity for
SAP HANA (HA and DR)(update 23.8.2019)
Tomas KROJZL, SAP HANA Distinguished Engineer, SAP Mentor

2. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
2
Disclaimer
This presentation is based on official IBM and SAP information however it is not
representing official position of IBM nor SAP and does not contain statements about
future direction. Content of this presentation is based on personal view and
experience of presenter and cannot be associated with IBM or SAP corporations.
This document is provided without a warranty of any kind, either express or implied,
including but not limited to, the implied warranties of merchantability, fitness for a
particular purpose, or non-infringement. IBM nor SAP assumes no responsibility for
content of this document.

3. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Agenda
3
• Introduction into Business Continuity
• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

4. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
SAP HANA Business Continuity
• Protection against single server failure
• Hardware failure (e.g. CPU failure)
• Software malfunction (e.g. OS crash)
• Availability Zone failure
• Typically inside same location
• Goal is to stay close to the rest of the
customer landscape (bandwidth, latency)
4
• Protection against Region failure
• Natural disasters (e.g. floods, earthquakes)
• Man made disasters (e.g. riots, terrorism)
• Typically against other location
• Goal is to move whole customer landscape to
new location (Data Center)
• Different requirements on “safe distance” (next
city versus different continent)
Availability (incl. High Availability) Disaster Recovery

5. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
SAP HANA Business Continuity
• SAP HANA Host Auto-Failover
• Approach based on +1 node (might be up to +3)
• Additional nodes CANNOT be used for non-prod
• SAP HANA System Replication
• Additional compatible environment required
• Additional nodes CAN be used for non-prod
• Failover can be automated
• VMware High Availability (Infrastructure Level)
5
• Passive Spare (Backup/Restore)
• Backups must be replicated across both sites
• SAP HANA System Replication
• Storage Replication
• Continuous replication of data between storage
subsystem on primary and secondary side
Availability Techniques Disaster Recovery Techniques

6. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Agenda
6
• Introduction into Business Continuity
• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

7. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
7
SAP HANA Host Auto-Failover for SAP HANA Single-node
• Each SAP HANA node represents running
instance
• Only active node is having own data and log
files
• There are no data and log files on stand-by
node
• Data is written only to active node
• SQL query will retrieve data from active node
Node 01
(active)
Node 02
(stand-by)
DB
L
SAP HANA
instance
SAP HANA
instance

8. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Node 02
(stand-by)
Node 01
(active)
Node 02
(active)
Node 01
(crashed)
SAP HANA
instance
SAP HANA
instance
8
SAP HANA Host Auto-Failover for SAP HANA Single-node
• Active node will fail (data-set is not available
anymore)
• Stand-by node will take over data and log
files of failed node and will replace it (data-
set is available again)
• SQL query can again retrieve data from new
active node
SAP HANA
instance
DB
L

9. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
9
SAP HANA Host Auto-Failover for SAP HANA Scale-out
• Each SAP HANA node represents running
instance
• Each active node is having own data and log
files
• There are no data and log files on stand-by
node
• Data is distributed into pre-defined locations
(shared nothing architecture)
• SQL query will retrieve data from all nodes in
parallel
Node 02
(active)
SAP HANA
instance
Node 01
(active)
Node 03
(active)
Node 04
(stand-by)
DB
L
DB
L
DB
L
SAP HANA
instance
SAP HANA
instance
SAP HANA
instance

10. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Node 02
(active)
SAP HANA
instance
Node 02
(crashed)
SAP HANA
instance
10
SAP HANA Host Auto-Failover for SAP HANA Scale-out
• One node will fail (data-set is not complete
anymore)
• Stand-by node will take over data and log
files of failed node and will replace it (data-
set is complete again)
• SQL query can again retrieve data from all
nodes in parallel
• Multiple stand-by nodes are allowed but not
common
• One stand-by node is serving as fail-over
target for any of the worker nodes – no data
preloading possible
• No support for multiple Availability Zones
Node 01
(active)
Node 03
(active)
Node 04
(stand-by)
Node 04
(active)
DB
L
DB
L
SAP HANA
instance
SAP HANA
instance
SAP HANA
instance
DB
L

11. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Agenda
11
• Introduction into Business Continuity
• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

12. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Node B1
(replicating)
SAP HANA
instance
12
SAP HANA System Replication for SAP HANA Single-node
• SAP HANA System Replication needs
additional “compatible” environment
• During System Replication primary worker
node is paired with dedicated node on
secondary side
• Stand-by node is not required on secondary
side
• When data is written on primary node then
related change is replicated to secondary
node
• This replication is performed on SAP HANA
database level (infrastructure agnostic)
• All tenant databases are replicated –
takeover of single tenant is not possible
Node A2
(stand-by)
SAP HANA
instance
Node A1
(active)
SAP HANA
instance
DB
L
DB
L

13. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Node B3
(replicating)
Node B1
(replicating)
Node B2
(replicating)
SAP HANA
instance
SAP HANA
instance
SAP HANA
instance
13
SAP HANA System Replication for SAP HANA Scale-out
• SAP HANA System Replication needs
additional “compatible” environment
• During System Replication each primary
worker node is paired with one dedicated
node on secondary side
• Stand-by node is not required on secondary
side
• When data is written on primary node then
related change is replicated to secondary
node
• This replication is performed on SAP HANA
database level (infrastructure agnostic)
• All tenant databases are replicated –
takeover of single tenant is not possible
Node A4
(stand-by)
SAP HANA
instance
Node A3
(active)
SAP HANA
instance
DB
L
Node A1
(active)
SAP HANA
instance
DB
L
Node A2
(active)
SAP HANA
instance
DB
L
DB
L
DB
L
DB
L

14. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
14
SAP HANA System Replication – Details of Replication Cycle
• Data Modification Event will persist log
update to local storage and in parallel will
send log entry to secondary system
• Local storage write is impacted by Storage
Latency
• In case of Synchronous Replication Mode
operation needs to wait for secondary system
to confirm
• Secondary system persists log update to
secondary storage and will confirm back to
primary system
• Primary system will report that Data
Modification Event was completedNode A1
(active)
SAP HANA
instance
DB
L
Node B1
(replicating)
SAP HANA
instance
DB
L
Network Latency
Impact (twice)
Data Modification Event
(insert, update, delete, etc.)
Storage
Latency
Impact
Storage
Latency
Impact

15. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
15
SAP HANA System Replication – Replication Modes
• Replication process is having three important
milestones
• Four different replication modes are available
• Synchronous modes are sensitive to network
latency therefore can be used only across
small distance
• Full sync mode will stop operation on primary
system in case that secondary system is not
reachable
Note: If network connection is too slow and the
Asynchronous replication buffer is running full
then even Asynchronous Replication Mode can
have performance impact on primary system.
3. Secondary system persists
the information (I/O impact)
2. Secondary system receives
the information (network impact)
1. Primary system sends
the information
Asynchronous RPO > 0
Synchronous
in-memory RPO ~ 0
Synchronous RPO = 0
Synchronous
with full sync
RPO = 0
No impact
Primary side is blocked
until secondary reconnects
Primary side may be
blocked until time-out
Impact in case that connection
between systems is lost

16. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Storage
SAP HANA System Replication – Delta Data Shipping Mode
• Initial “Full Data” transfer will
synchronize both databases
• All log entries are immediately
replicated to secondary
database to be stored on disk
(not applied to database)
• Periodically all data changes
are replicated to secondary
database
• Resync option is dependent on
Data Retention configuration
16
L L
Full Data
DBDB
Log Entries
Delta Data
Primary Database Secondary Database
Parameters:
• datashipping_snapshot_max_retention_time
[ minutes ], default: 300

17. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
L
Storage
SAP HANA System Replication – Delta Data Shipping Mode
• Smaller memory footprint on
secondary server (no in-
memory operations)
• Either pre-loading can be
activated or additional non-
productive system can be
hosted on same server
• Longer recovery / takeover
times (need to apply log
entries since last delta)
• Increased network traffic
between systems (data
changes are sent twice)
17
Full Data
L Log Entries
DB
Delta Data
Primary Database Secondary Database
DB

18. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
SAP HANA System Replication – Log Replay Mode
• Initial “Full Data” transfer will
synchronize both databases
• All log entries are immediately
replicated to secondary
database
• Log changes on secondary are
applied asynchronously
Note: Data changes might be stored
in different database pages
• Resync option is dependent on
Log Retention configuration
18
L L
Full Data
DBDB
Log Entries
Primary Database Secondary Database
Parameters:
• enable_log_retention [ auto | on | off | force_on_takeover ], default: auto
• logshipping_max_retention_size [ size in MB ], default: 1048576 (1TB)

19. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
SAP HANA System Replication – Log Replay Mode
• Minimal recovery / takeover
times (data is fully loaded into
memory)
• Reduced network traffic
between systems (data
changes are sent once)
• Protection against logical
persistence corruptions
• Higher memory footprint on
secondary server (memory for
data processing)
• No support for history tables
• HANA 1.0 rev < 122.14
• HANA 2.0 rev < 10
(SAP Note 2480889)
19
Full Data
DB
L
Log Entries
Primary Database Secondary Database
L
DB
Operation Mode SAP HANA Version Primary Database Secondary Database
logreplay HANA 1.0 SP11+ Read / Write Not Accessible
logreplay_readaccess HANA 2.0 Read / Write Read Only (no backups)

20. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
SAP HANA System Replication – Log Replay Read Access Mode
• Two virtual IP addresses
• Delayed access to data on
secondary – ability to
configure “lag threshold”
• Read access on secondary is
possible only if (1) same
version as primary and if (2)
connection to primary is active
• Two connection types for
Applications:
• Explicit connection to
secondary database
• Implicit HINT-based routing
20
Full Data
DB
L
Log Entries
Primary
Database
Secondary
Database
L
DB
Application
SAP HANA Client Library
Application
Server
Sec.
IP
Pri.
IP

21. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
SAP HANA System Replication – Secondary Time Travel
• Only for Log Replay or Log
Replay Read Access Modes
• Secondary Database can be
configured to make periodic
“Time Travel Snapshots"
Note: Snapshots contain only
modified data pages.
• These snapshots are kept on
secondary database for
defined time travel period
• All Log Entries since oldest
snapshot are also retained
21
L L
Full Data
DBDB
Log Entries
Primary Database Secondary Database
Parameters:
• timetravel_max_retention_time [ minutes ], default: 0 (disabled)
• timetravel_snapshot_creation_interval [ minutes ], default: 1440 (1 day)
• timetravel_logreplay_mode [ auto | manual ], default: auto

22. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
L L
SAP HANA System Replication – Secondary Time Travel
• Secondary Database is
stopped
• Time Travel is activated –
based on specified timestamp
appropriate snapshot is used
• Log entries are processed up
to the requested timestamp
• Secondary database can be
opened in online mode (as
active database) or in read-
only mode (log replay is on
hold)
22
Full Data
Primary Database Secondary Database
Commands:
• hdbnsutil -sr_timetravel --startTime=<startTime>
• hdbnsutil -sr_timetravel --startTime=<startTime> --startMode=replicate
DB
Log Entries
DB

23. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
SAP HANA Multi-tier System Replication (up to SAP HANA 2.0 SPS02)
A » B B » C Version Use Case (example)
SYNC SYNC SP12+ Local solution for fast failover
combined with DR to nearby
location.SYNC SYNCMEM SP12+
SYNCMEM SYNC SP11+
SYNCMEM SYNCMEM SP12+
SYNC ASYNC SP07+ Local solution for fast failover
combined with DR to distant
location.SYNCMEM ASYNC SP07+
ASYNC ASYNC SP11+ Multi-level DR solution.
23
• Three SAP HANA databases in “pipeline”
topology (A » B » C)
• Supported for both single-node and scale-out
deployment options
• Only listed combinations of replication modes
are possible (up to SAP HANA 2.0 SPS02)
• Combinations of operation modes (Delta Data
Shipping and Log Replay) are not supported
• Log Replay Read Access Mode is valid only for
(A » B) – subsequent replication mode (B » C)
must be Log Replay Mode
Node A
(active)
SAP HANA
instance
DB
L
Node B
(replicating)
SAP HANA
instance
DB
L
Node C
(replicating)
SAP HANA
instance
DB
L

24. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
SAP HANA Multi-target System Replication (SAP HANA 2.0 SPS03+)
24
• Multiple secondary systems can be configured
(A » B, A » C » D)
• Supported for both single-node and scale-out
deployment options
• Different combinations of replication modes are
possible
• Combinations of operation modes (Delta Data
Shipping and Log Replay) are not supported
• Log Replay Read Access Mode can be
configured for multiple secondary systems
(however only one can use hint based access)
• Log Replay Read Access Mode is valid only for
first tier (A » B, A » C) – subsequent replication
mode (C » D) must be Log Replay Mode
Node A
(active)
SAP HANA
instance
DB
L
Node B
(replicating)
SAP HANA
instance
DB
L
Node C
(replicating)
SAP HANA
instance
DB
L
Node D
(replicating)
SAP HANA
instance
DB
L
SYNC SYNC
ASYNC

25. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Node B1
(replicating)
SAP HANA
instance
Node A2
(stand-by)
SAP HANA
instance
25
SAP HANA System Replication – Advantages
• Secondary side can be “disconnected” to serve
different purpose – for example:
• Fast Back-out plan in case of failed change
• Near Zero Downtime Database Upgrades
• Secondary Time Travel
• Non-production can be hosted on secondary side
(operation mode Delta Data Shipping) but must be
stopped in case of failover
• Protection against physical disk corruptions
• Support for multiple Availability Zone concept
• Can be used in various scenarios – including Disaster
Recovery or DB copy
Node A1
(active)
SAP HANA
instance
DB
L
Node B1
(repl./active)
DB
L
DB
L
Non-prod.
SAP HANA

26. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Agenda
26
• Introduction into Business Continuity
• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

27. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Availability / High Availability - Comparison
27
atment is required to prevent cluster to takeover during maintenance
nly in case of “Log Replay Mode” or “Delta Data Shipping Mode with active pre-loading” – otherwise medium
ctive system is supported only in case of “Delta Data Shipping Mode with disabled pre-loading”
ctive system will be stopped in case of failover, separate storage for non-productive system is required
ctive system is supported only in single-node (scale-up) scenario
Can decrease
planned
downtime
Single-
node
Scale-
out
HW, OS
only
N
Y Y
Y (*1) Y (*1)
HW only HW only
Protection against
HW
failure
OS
Failure
Failure
of one
DB node
Failure
of all DB
nodes
Y Y Y N
Y Y Y Y
Y Y Y Y
Y partial N N
Operation
complexity
low
low
medium
low
Cost implications
Single-
node
Scale-
out
medium medium
medium high
medium high
low low
Relative
RTO
Typical
RPO
medium 0
very
high
0
very
low (*2)
0
medium 0
CanpassiveHW
hostnon-prod
N
Y (*3)
Y/N
(*3,4)
n/a
High Availability scenarios
ApproachSAP HANA Host Auto-Failover
(one stand-by node)
N+1
SAP HANA System Replication
(synchronous) - manual failover
N+N
SAP HANA System Replication
(synchronous) - automated failover
N+N
VMware High Availability
(Infrastructure Level option)
Infra.
option

28. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Disaster Recovery - Comparison
28
(*1) Non-productive system will be stopped in case of failover, separate storage for non-productive system is required
(*2) Non-productive system is supported only in case of “Delta Data Shipping Mode with disabled pre-loading”
Disaster Recovery scenarios Approach
Passive Spare (Backup/Restore) -
preinstalled
N+N
SAP HANA System replication
(synchronous)
N+N
SAP HANA System replication
(asynchronous)
N+N
Storage Replication
(synchronous) - preinstalled
N+N
Storage Replication
(asynchronous) - preinstalled
N+N
Checked for
consistency
Y
Y
Y
N
N
Can passive
HW host
non-prod
Y (*1)
Y (*1,2)
Y (*1,2)
Y (*1)
Y (*1)
Relative
RTO
Typical RPO
high hours
low 0
low
seconds /
minutes
low 0
low
seconds /
minutes
Cost
implications
medium
medium
medium
medium
medium
Operation
complexity
low
low
low
low
low

29. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Agenda
29
• Introduction into Business Continuity
• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

30. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Business Continuity – Typical Deployment Options (Single-node)
30
active
P’
active
P
synchronous
automatic
(Pacemaker
cluster or
3rd party SW)
active
P’ Q
active
P
synchronous
automatic
(Pacemaker
cluster or
3rd
party SW)
active
P’’
active
P’
asynchronous
active
P
synchronous
automatic
(Pacemaker
cluster or
3rd party SW)
manual
Location 1 Location 2
(low latency)
Location 3
(high latency)
Location 1 Location 2
(low latency)
Location 3
(high latency)
active
P’’ D
stand-by
P’’ D
active stand-by
P’ Q P’ Q
asynchronous
active sby
P P
synchronous
manual manual
active stand-by
P’ Q P’ Q
active sby
P P
synchronous
manual
active sby
P P
automatic
(HANA native)
Also referred as
“Single-node
HA cluster”
active
P’ Q
stand-by
P’ Q
asynchronous
active sby
P P
manual
Mandatory Component
P
Q
D
Optional Component
Production Node
Quality Node
Development Node
Legend:
SAP HANA System
Replication Flow

31. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Location 1 Location 2
(low latency)
Location 3
(high latency)
Business Continuity – Typical Deployment Options (Scale-out)
31
Location 1 Location 2
(low latency)
Location 3
(high latency)
activeactive activeactive active stand-by
Q P’ Q
active sby
P
manual
synchronous
P P’
activeactive activeactive active
Q
stand-by
P’ Q
active sby
P
manual
asynchronous
P P’
activeactiveactive sby
P P
automatic
(HANA native)
Also referred as
“Scale-out
cluster with HA”
active activeactive active activeactiveactive
D
stand-by
P’’ D
active stand-by
Q P’ Q
active sby
P
manual manual
asynchronoussynchronous
P’’P’P
Mandatory Component
P
Q
D
Optional Component
Production Node
Quality Node
Development Node
Legend:
SAP HANA System
Replication Flow
activeactive activeactive active sby
P’
active sby
P
automatic
(Pacemaker
cluster or
3rd party SW)
synchronous
P P’
mm

32. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Additional Materials (1/3)
• SAP HANA - Host Auto-Failover
https://scn.sap.com/docs/DOC-62494
• How to Perform System Replication for SAP HANA
https://www.sap.com/documents/2016/06/0ec37684-7a7c-0010-
82c7-eda71af511fa.html (SAP HANA 2.0 SPS00)
• FAQ: High Availability for SAP HANA
https://scn.sap.com/docs/DOC-66702
• Introduction: High Availability for SAP HANA
https://scn.sap.com/docs/DOC-65585
• High Availability for SAP HANA (Administration Guide)
https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd
56/2.0.04/en-US/6d252db7cdd044d19ad85b46e6c294a4.html
• SAP HANA System Replication Guide
https://help.sap.com/viewer/4e9b18c116aa42fc84c7dbfd02111a
ba/2.0.04/en-US/afac7100bc6d47729ae8eae32da5fdec.html
32
• High Availability and Disaster Recovery with the SAP HANA
https://open.sap.com/courses/hshd1
• SAP Note 1999880 - FAQ: SAP HANA System Replication
https://launchpad.support.sap.com/#/notes/1999880/E
• SAP Note 2303243 - SAP HANA Multitier System Replication –
supported replication modes between sites
https://launchpad.support.sap.com/#/notes/2303243/E
• SAP TechEd 2018 - SAP HANA Deployment Options (29.8.2018)
https://www.slideshare.net/TomasKrojzl/sap-teched-2018-sap-
hana-deployment-options-166545426
• SAP TechEd 2019 - Deployment Options with Business
Continuity for SAP HANA (HA and DR) (23.8.2019)
https://www.slideshare.net/TomasKrojzl/sap-teched-2019-
deployment-options-with-business-continuity-for-sap-hana

33. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Additional Materials (2/3)
• SAP on SUSE
https://scn.sap.com/docs/DOC-49204
• Best Practices for Mission-Critical SAP Applications
https://www.suse.com/documentation/sles-for-sap-
12/#bestpractice
• Automate SAP HANA System Replication with SLES for SAP
Applications
https://scn.sap.com/docs/DOC-56278
• SAP HANA SR Performance Optimized Scenario
https://www.suse.com/media/white-
paper/suse_linux_enterprise_server_for_sap_applications_12_s
p1.pdf
• SAP HANA SR Cost Optimized Scenario
https://www.suse.com/media/white-
paper/sap_hana_sr_cost_optimized_scenario_12_sp1.pdf
33
• SAP HANA System Replication Scale-Out - Performance
Optimized Scenario
https://www.suse.com/documentation/suse-best-
practices/pdfdoc/SLES4SAP-hana-scaleOut-PerfOpt-
12/SLES4SAP-hana-scaleOut-PerfOpt-12.pdf
• SAPHanaSR-ScaleOut: Automating SAP HANA System
Replication for Scale-Out Installations with SLES for SAP
Applications
https://www.suse.com/communities/blog/saphanasr-scaleout-
automating-sap-hana-system-replication-scale-installations-sles-
sap-applications
• SAP HANA System Replication Automation (HanaSR) for
HANA Scale-Out now officially available with SLES for SAP 12
SP2
https://www.suse.com/communities/blog/sap-hana-system-
replication-automation-hanasr-hana-scale-now-officially-
available-sles-sap-12-sp2
• SAP HANA Scale-Out System replication - SUSECon
https://www.susecon.com/doc/2015/sessions/TUT19921.pdf

34. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
Additional Materials (3/3)
• SAP on Red Hat
https://scn.sap.com/docs/DOC-37811
• Technical Resources for SAP HANA on Red Hat
https://scn.sap.com/docs/DOC-37812
• Supported HA Scenarios for SAP HANA, SAP S/4HANA, and
SAP Netweaver
https://access.redhat.com/articles/4079981
• Automated SAP HANA System Replication in Scale-Up in
pacemaker cluster
https://access.redhat.com/articles/3004101
• Configure SAP HANA System Replication in Pacemaker on
Amazon Web Services
https://access.redhat.com/articles/3569621
34
• Support Policies for RHEL High Availability Clusters -
Management of SAP HANA in a Cluster
https://access.redhat.com/articles/3397471
• Be Prepared for Using Pacemaker Cluster for SAP HANA – Part
1: Basics
https://blogs.sap.com/2017/11/19/be-prepared-for-using-
pacemaker-cluster-for-sap-hana-part-1-basics
• Be Prepared for Using Pacemaker Cluster for SAP HANA – Part
2: Failure of Both Nodes
https://blogs.sap.com/2017/11/19/be-prepared-for-using-
pacemaker-cluster-for-sap-hana-part-2-failure-of-both-nodes

35. © 2019 IBM Corporation
SAP HANA
Distinguished
Engineers
35
Tomas KROJZL
SAP HANA Architect,
SAP HANA Distinguished
Engineer,
SAP Mentor
IBM Innovation Center
Central Europe
Technicka 2995/21
616 00 Brno
Czech Republic
Mobile: +420-731-435-817
tomas_krojzl@cz.ibm.com
Twitter: @krojzl
Thank You!
Feedback
Please complete a session evaluation for this session!