Sie sind auf Seite 1von 35

ITM216

Deployment Options with Business Continuity for


SAP HANA (HA and DR) (update 1.11.2016)
Tomas KROJZL, SAP HANA Distinguished Engineer, SAP Mentor
SAP HANA
Distinguished
Engineers
© 2016 IBM Corporation
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.

SAP HANA 2
Distinguished
Engineers
© 2016 IBM Corporation
Agenda

• Introduction into Business Continuity


• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

SAP HANA 3
Distinguished
Engineers
© 2016 IBM Corporation
Availability Considerations
Unplanned Downtime
• Availability can be measured on different
(outages) levels in the stack
Planned Downtime ? • It can include planned downtime
(maintenances)
(maintenances) or can be based only on
unplanned downtime (outages)
Business Process Business Process Level
• Period against which the availability is
Application
e.g. SAP NetWeaver
Application Level measured (monthly versus yearly) –
important if “mean time between failures”
SAP HANA Database Level (MTBF) is more than one month
Operating System
SUSE Linux Enterprise Server for SAP Operating System Level
Red Hat Enterprise Linux for SAP HANA Availability % 99% 99.5% 99.8% 99.9%

Internal Storage
Downtime per year 3.65 day 1.83 days 17.5 hour 8.76 hour
Server HW Infrastructure Level
Network Subsystem
Downtime per month 7.20 hour 3.60 hour 86.2 min 43.8 min

SAP HANA 4
Distinguished
Engineers
© 2016 IBM Corporation
Important Business Continuity KPIs
Recovery Time Objective (RTO)
• Maximum targeted duration of time within which
business process must be restored after disruption
• Can include investigation time, recovery time itself,
testing and communication to the users

Recovery
Backup
Backup

Recovery Point Objective (RPO)


“Data Loss Period” “Outage Duration”
• Maximum targeted time period in which data might
Recovery Period Recovery Time be lost as a result of disruption
Objective (RPO) Objective (RTO) • Only loss of committed transactions is taken into
is saying how much data is saying how fast you can
can be lost during recovery recover from an outage account (loss of incomplete transactions is not taken
into account)

SAP HANA 5
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA Business Continuity
Availability (incl. High Availability) Disaster Recovery

• Protection against single server failure • Protection against Data Center failure
• Hardware failure (e.g. CPU failure) • Natural disasters (e.g. floods, earthquakes)
• Software malfunction (e.g. OS crash) • Man made disasters (e.g. riots, terrorism)

• Typically inside same location • Typically against other location


• Goal is to stay close to the rest of the • Goal is to move whole customer landscape to
customer landscape (bandwidth, latency) new location (Data Center)
• Different requirements on “safe distance” (next
city versus different continent)

SAP HANA 6
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA Business Continuity
Availability Techniques Disaster Recovery Techniques

• SAP HANA Host Auto-Failover • Passive Spare (Backup/Restore)


• Approach based on +1 node (might be up to +3) • Backups must be replicated across both sites
• Additional nodes CANNOT be used for non-prod
• SAP HANA System Replication
• SAP HANA System Replication
• Storage Replication
• Additional compatible environment required
• Continuous replication of data between storage
• Additional nodes CAN be used for non-prod subsystem on primary and secondary side
• Failover can be automated for single-node

• VMware High Availability (Infrastructure Level)

SAP HANA 7
Distinguished
Engineers
© 2016 IBM Corporation
Agenda

• Introduction into Business Continuity


• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

SAP HANA 8
Distinguished
Engineers
© 2016 IBM Corporation
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-
Node 01 Node 02 by node
(active) (stand-by) • Data is written only to active node
SAP HANA SAP HANA
• SQL query will retrieve data from active
instance instance node

DB
L

SAP HANA 9
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA Host Auto-Failover for SAP HANA Single-node
• Active node will fail (data-set is not
available anymore)

Node 01 Node 02
(crashed)
(active) (stand-by)

SAP HANA SAP HANA


instance instance

DB
L

SAP HANA 10
Distinguished
Engineers
© 2016 IBM Corporation
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)
Node 01 Node 02 • SQL query can again retrieve data from
(crashed)
(active) (active)
(stand-by) new active node
SAP HANA SAP HANA
instance instance

DB
L

SAP HANA 10
Distinguished
Engineers
© 2016 IBM Corporation
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-
Node 01 Node 02 Node 03 Node 04 by node
(active) (active) (active) (stand-by) • Data is distributed into pre-defined
SAP HANA SAP HANA SAP HANA SAP HANA
locations (shared nothing architecture)
instance instance instance instance • SQL query will retrieve data from all
nodes in parallel
DB DB DB
L L L

SAP HANA 11
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA Host Auto-Failover for SAP HANA Scale-out
• One node will fail (data-set is not
complete anymore)

Node 01 Node 02 Node 03 Node 04


(active) (crashed)
(active) (active) (stand-by)

SAP HANA SAP HANA SAP HANA SAP HANA


instance instance instance instance

DB DB DB
L L L

SAP HANA 12
Distinguished
Engineers
© 2016 IBM Corporation
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)
Node 01 Node 02 Node 03 Node 04 • SQL query can again retrieve data from
(active) (crashed)
(active) (active) (stand-by)
(active) all nodes in parallel
SAP HANA SAP HANA SAP HANA SAP HANA
instance instance instance instance • Multiple stand-by nodes are allowed but
not common
DB DB DB
• One stand-by node is serving as fail-over
L L L target for any of the worker nodes – no
data preloading possible

SAP HANA 12
Distinguished
Engineers
© 2016 IBM Corporation
Agenda

• Introduction into Business Continuity


• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

SAP HANA 13
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA System Replication for SAP HANA Single-node
Node A1 Node A2 • SAP HANA System Replication needs
(active) (stand-by)
additional “compatible” environment
SAP HANA SAP HANA
instance instance • During System Replication each primary
worker node is paired with one dedicated
DB
L node on secondary side

Node B1 Node B2
(replicating) (stand-by)
SAP HANA SAP HANA
instance instance

DB
L

SAP HANA 14
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA System Replication for SAP HANA Single-node
Node A1 Node A2 • SAP HANA System Replication needs
(active) (stand-by)
additional “compatible” environment
SAP HANA SAP HANA
instance instance • During System Replication each primary
worker node is paired with one dedicated
DB
L node on secondary side
• Stand-by node is not required on
secondary side
Node B1 • When data is written on primary node
(replicating)
then related change is replicated to
SAP HANA
instance
secondary node
• This replication is performed on
DB
L
database level

SAP HANA 14
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA System Replication for SAP HANA Scale-out
Node A1 Node A2 Node A3 Node A4 • SAP HANA System Replication needs
(active) (active) (active) (stand-by)
additional “compatible” environment
SAP HANA SAP HANA SAP HANA SAP HANA
instance instance instance instance • During System Replication each primary
worker node is paired with one dedicated
DB DB DB
L L L node on secondary side

Node B1 Node B2 Node B3 Node B4


(replicating) (replicating) (replicating) (stand-by)
SAP HANA SAP HANA SAP HANA SAP HANA
instance instance instance instance

DB DB DB
L L L

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

SAP HANA 15
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA System Replication - Advantages
Node A1 Node A2 • Main advantages of SAP HANA System
(active) (stand-by)
Replication approach:
SAP HANA SAP HANA
instance instance

DB
L

Node B1
(replicating)
SAP HANA
instance

DB
L

SAP HANA 16
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA System Replication - Advantages
Node A1 Node A2 • Main advantages of SAP HANA System
(active) (stand-by)
Replication approach:
SAP HANA SAP HANA
instance instance • Secondary side can be “disconnected” to serve
different purpose – for example:
DB
L • Specialized testing
• Fast Back-out plan in case of failed change
• Near Zero Downtime Database Upgrades

Node B1
(active)
SAP HANA
instance

DB
L

SAP HANA 16
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA System Replication - Advantages
Node A1 Node A2 • Main advantages of SAP HANA System
(active) (stand-by)
Replication approach:
SAP HANA SAP HANA
instance instance • Secondary side can be “disconnected” to serve
different purpose – for example:
DB
L • Specialized testing
• Fast Back-out plan in case of failed change
• Near Zero Downtime Database Upgrades

Node B1 • Non-production can be hosted on secondary


(repl./active)
(replicating) side – must be stopped in case of failover
SAP HANA
Non-prod.
SAP HANA
• Protection against disk corruptions
instance
• Can be used in various scenarios –
DB DB including Disaster Recovery or DB copy
L L

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

Synchronous Primary side is blocked


RPO = 0
with full sync until secondary reconnects

SAP HANA 17
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA System Replication – Operation Modes
Delta Data Shipping Mode Log Replay Mode (SP11+)
• Same layout of data across pages • Same information but different layout
• Full compatibility across features • Reduced network traffic
• More free resources on secondary side • Reduced takeover time
for non-productive system • Base for planned active-active setup
Shipment types: Shipment types:

Node A1 Full Data Node B1 Node A1 Full Data Node B1


(active) (replicating) (active) (replicating)
Delta Data
DB DB DB DB
L L L L
Log Entries Log Entries

Storage Storage Storage Storage

SAP HANA 18
Distinguished
Engineers
© 2016 IBM Corporation
SAP HANA Multitier System Replication
Node A Node B Node C • Only supported scenario (today) - three
SAP HANA databases in “pipeline”
(active) (replicating) (replicating)

SAP HANA SAP HANA SAP HANA


instance instance instance
topology (A » B » C)
• Supported for both single-node and
DB DB DB
L L L

scale-out deployment options


A»B B»C Version Use Case (example) • Only listed combinations of replication
SYNC SYNC SP12+ Local solution for fast failover
combined with DR to nearby modes are possible
SYNC SYNCMEM SP12+
SYNCMEM SYNC SP11+
location.
• Combinations of operation modes
SYNCMEM SYNCMEM SP12+
(Delta Data Shipping and Log Replay)
SYNC ASYNC SP07+ Local solution for fast failover are not supported
combined with DR to distant
SYNCMEM ASYNC SP07+ location.
ASYNC ASYNC SP11+ Multi-level DR solution.

SAP HANA 19
Distinguished
Engineers
© 2016 IBM Corporation
Agenda

• Introduction into Business Continuity


• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

SAP HANA 20
Distinguished
Engineers
© 2016 IBM Corporation
Availability / High Availability - Comparison

Can passive HW
Can decrease

host non-prod
complexity
Protection against planned Cost implications

Operation

Approach
downtime Relative Typical
High Availability scenarios
Failure Failure RTO RPO
HW OS Single- Scale- Single- Scale-
of one of all DB
failure Failure node out node out
DB node nodes
SAP HANA Host Auto-Failover HW, OS
Y Y Y N N low N+1 medium medium medium 0 N
(one stand-by node) only
SAP HANA System Replication very
Y Y Y Y Y Y low N+N medium high 0 Y (*1)
(synchronous) - manual failover high
SAP HANA System Replication very
Y Y Y Y Y (*2) Y (*2) medium N+N medium high 0 Y/N (*4)
(synchronous) - automated failover low (*3)
VMware High Availability Infra.
Y partial N N HW only HW only low low low medium 0 n/a
(Infrastructure Level option) option

(*1) Non-productive system will be stopped in case of failover, separate storage for non-productive system is required
(*2) Special treatment is required to prevent cluster to takeover during maintenance
(*3) Very low only in case of “Log Replay Mode” (“HotStandby” setup) – otherwise low
(*4) Non-productive system is supported only in single-node (scale-up) scenario

SAP HANA 21
Distinguished
Engineers
© 2016 IBM Corporation
Disaster Recovery - Comparison

Can passive
Checked for Operation Cost Relative
Disaster Recovery scenarios Approach Typical RPO HW host
consistency complexity implications RTO
non-prod
Passive Spare (Backup/Restore) -
Y low N+N medium high hours Y (*1)
preinstalled
SAP HANA System replication
Y low N+N medium low 0 Y (*1)
(synchronous)
SAP HANA System replication seconds /
Y low N+N medium low Y (*1)
(asynchronous) minutes
Storage Replication
N low N+N medium low 0 Y (*1)
(synchronous) - preinstalled
Storage Replication seconds /
N low N+N medium low Y (*1)
(asynchronous) - preinstalled minutes

(*1) Non-productive system will be stopped in case of failover, separate storage for non-productive system is required

SAP HANA 22
Distinguished
Engineers
© 2016 IBM Corporation
Agenda

• Introduction into Business Continuity


• SAP HANA Host Auto-Failover
• SAP HANA System Replication
• Comparison of Individual Options
• Typical Deployment Options

SAP HANA 23
Distinguished
Engineers
© 2016 IBM Corporation
Business Continuity – Typical Deployment Options (Single-node)
automatic Additional combinations of replication modes are possible:
(HANA native) (note the network latency dependencies) Legend:
active sby Also referred as A»B B»C Version
“Single-node Mandatory Component
P P SYNC SYNC SP12+
HA cluster”
SYNC SYNCMEM SP12+ Optional Component
SYNCMEM SYNC SP11+ synchronous
synchronous SYNCMEM SYNCMEM SP12+ P Production Node
automatic
manual SYNC ASYNC SP07+ active active
active sby active stand-by (Pacemaker Quality Node
Q
SYNCMEM ASYNC SP07+ P cluster or P’
P P P’ Q P’ Q ASYNC ASYNC SP11+ 3rd party SW)
D Development Node
SAP HANA System
synchronous
asynchronous Replication Flow
automatic
manual active (Pacemaker active
active sby active stand-by
cluster or
P P’ Q
P P P’ Q P’ Q 3rd party SW)

synchronous asynchronous
synchronous asynchronous
automatic manual
manual manual active (Pacemaker active active
active sby active stand-by active stand-by
cluster or
P P’ P’’
P P P’ Q P’ Q P’’ D P’’ D 3rd party SW)

Location 1 Location 2 Location 3 Location 1 Location 2 Location 3


(low latency) (high latency) (low latency) (high latency)

SAP HANA 24
Distinguished
Engineers
© 2016 IBM Corporation
Business Continuity – Typical Deployment Options (Scale-out)
automatic
(HANA native) Additional combinations of replication modes are possible:
(note the network latency dependencies) Legend:
active
active
active sby Also referred as A»B B»C Version
“Scale-out Mandatory Component
P P SYNC SYNC SP12+
cluster with HA”
SYNC SYNCMEM SP12+ Optional Component
synchronous SYNCMEM SYNC SP11+ synchronous
SYNCMEM SYNCMEM SP12+ P Production Node
active
active manual active
active SYNC ASYNC SP07+ active
active active
active
active sby active stand-by active sby active sby Q Quality Node
SYNCMEM ASYNC SP07+
P P P’ Q P’ Q P P P’ P’
ASYNC ASYNC SP11+ mm D Development Node

asynchronous automatic SAP HANA System


(Pacemaker Replication Flow
active manual active cluster or
active
active sby active
active stand-by 3rd party SW)
P P P’ Q P’ Q

synchronous asynchronous

active
active manual active
active manual active
active
active sby active stand-by active stand-by
P P P’ Q P’ Q P’’ D P’’ D

Location 1 Location 2 Location 3 Location 1 Location 2 Location 3


(low latency) (high latency) (low latency) (high latency)

SAP HANA 25
Distinguished
Engineers
© 2016 IBM Corporation
Additional Materials (1/3)
• How to Perform System Replication for SAP HANA • SAP Note 1999880 - FAQ: SAP HANA System Replication
https://scn.sap.com/docs/DOC-47702 https://launchpad.support.sap.com/#/notes/1999880/E

• FAQ: High Availability for SAP HANA • SAP Note 2303243 - SAP HANA Multitier System Replication –
https://scn.sap.com/docs/DOC-66702 supported replication modes between sites
https://launchpad.support.sap.com/#/notes/2303243/E
• Introduction: High Availability for SAP HANA
https://scn.sap.com/docs/DOC-65585 • SAP HANA Distinguished Engineer (HDE) Webinar: Overview
of SAP HANA On-Premise Deployment Options (replay)
• High Availability for SAP HANA https://scn.sap.com/community/hana-in-
https://help.sap.com/saphelp_hanaplatform/helpdata/en/6d/252d memory/blog/2016/05/25/sap-hana-distinguished-engineer-hde-
b7cdd044d19ad85b46e6c294a4/content.htm webinar-overview-of-sap-hana-on-premise-deployment-options

• High Availability and Disaster Recovery with the SAP HANA • SAP HANA Distinguished Engineer (HDE) Webinar: Overview
Platform of SAP HANA On-Premise Deployment Options
https://open.sap.com/courses/hshd1 https://www.slideshare.net/TomasKrojzl/sap-hana-distinguished-
engineer-hde-webinar-overview-of-sap-hana-onpremise-
deployment-options

SAP HANA 26
Distinguished
Engineers
© 2016 IBM Corporation
Additional Materials (2/3)
• SAP on SUSE • SAPHanaSR-ScaleOut: Automating SAP HANA System
https://scn.sap.com/docs/DOC-49204 Replication for Scale-Out Installations with SLES for SAP
Applications
• Best Practices for Mission-Critical SAP Applications https://www.suse.com/communities/blog/saphanasr-scaleout-
https://www.suse.com/products/sles-for-sap/resource- automating-sap-hana-system-replication-scale-installations-sles-
library/sap-best-practices sap-applications

• Automate SAP HANA System Replication with SLES for SAP • SAP HANA System Replication Automation (HanaSR) for
Applications HANA Scale-Out now officially available with SLES for SAP 12
https://scn.sap.com/docs/DOC-56278 SP2
https://www.suse.com/communities/blog/sap-hana-system-
• How to Set Up SAPHanaSR in the Cost Optimized SAP HANA replication-automation-hanasr-hana-scale-now-officially-
SR Scenario - Part I available-sles-sap-12-sp2
https://scn.sap.com/docs/DOC-65899

• How to Set Up SAPHanaSR in the Cost Optimized SAP HANA


SR Scenario - Part II
https://scn.sap.com/docs/DOC-68633

SAP HANA 27
Distinguished
Engineers
© 2016 IBM Corporation
Additional Materials (3/3)
• SAP HANA System Replication simplified
https://www.slideshare.net/snoopy1710/sap-hana-system-
replication-simplified

• 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

• Automated SAP HANA System Replication with Pacemaker on


RHEL Setup Guide
https://access.redhat.com/articles/1466063

SAP HANA 28
Distinguished
Engineers
© 2016 IBM Corporation
Thank You! Tomas KROJZL
SAP HANA Architect,
Technicka 2995/21
616 00 Brno
SAP HANA Distinguished Czech Republic
Engineer,
Mobile: +420-731-435-817
SAP Mentor
tomas_krojzl@cz.ibm.com
IBM Innovation Center
Central Europe Twitter: @krojzl

Feedback
Please complete your session evaluation.

SAP HANA 29
Distinguished
Engineers
© 2016 IBM Corporation

Das könnte Ihnen auch gefallen