OpenSAP Suse3-Pc Week 1 All Slides

Week 1: Planning an SAP HANA SR HA Deployment
Unit 1: Overview of the SAP HANA architecture

Overview of the SAP HANA architecture
Overview of SAP HANA
• SAP HANA is a database and a platform

• The SAP HANA database component stores the data in
memory
o This eliminates I/O bottlenecks
o Data is persisted to disk at regular intervals
• The data in memory is compressed
• Everything is calculated on-demand
open.sap.com Slide 2
SAP HANA database terminology
• Host
o The hardware and operating environment on which the SAP HANA
database runs
− The host provides all the required resources and services such
as CPU, memory, network, and storage
• System
o A system is one or more instances with the same SAP system ID
and instance number
o The term system is interchangeable with the term SAP HANA
database
o An SAP HANA system with more than one instance is distributed
over several hosts
SAP HANA database terminology
• Instance
o A set of SAP HANA system components installed on one host are
called an instance
• SAP HANA <SID>
o The SAP HANA <SID> is the name of the SAP HANA system
o The <SID> is assigned during the installation
o The <SID> is unique throughout an organization
o The <SID> consists of exactly three alphanumeric characters
− Only uppercase letters are allowed
− The first character must be a letter
SAP HANA is a “multitenant database container system”
• A single SAP HANA system can host multiple

databases
• A database lives in what is referred to as a “container”
within the SAP HANA system
o The container enables complete isolation of a database
from any other databases in an SAP HANA system
• SAP HANA 2.0 SPS01 and above is installed as a
multiple database container system
• A minimal SAP HANA system contains:
o System database
− Only one system database is required for an SAP HANA
system
o One tenant database
Identifying a database
• The SAP HANA system is identified using a system identifier

o SID
• An SAP HANA database is identified using two pieces of
information
o SID
o Database name
SAP HANA deployment options
• SAP HANA can be deployed in either of the following

configurations:
o Scale Up
o Scale Out
• Scale Up
o When more capacity is required, add more hardware to the
existing host
o Limited by factors including the hosts CPU capacity, memory
capacity, and IO throughput
Scale Up
• Scale Out
o When more capacity is required, add more systems
Scale Out
Information sources
• In this course we will focus on the deployment of SAP

HANA with system replication, performance optimized, in
a scale up configuration
• SUSE product and best practices documentation is
available from
o www.suse.com/documentation
• This training material is based on the SUSE Best Practice
Document:
o SAP HANA System Replication Scale-Up Performance
Optimized Scenario
− The latest version of this document is available from the
SUSE documentation web site
• The cluster nodes in the demonstrations are running
SLES for SAP Applications 15 SP2
Thank You!
Contact Information:
open@sap.com
Unit 2: Native SAP HANA HA features
Native SAP HANA HA features
Fault tolerance and high availability
• Fault tolerance aims to eliminate all single points of failure

o Eliminating all single point of failure can be very costly
• High availability
o Accept some downtime
− Reduces the implementation costs
o Aim to recover quickly
− For example, a 20 second delay during the recovery process
may be acceptable
• Implementing high availability for SAP HANA is a
combination of:
o SLE High Availability
− The HA extension is included with a SLES for SAP Applications
subscription
o SAP HANA's native fault tolerance features
o Fault tolerant hardware components
Assessing single points of failure
• Providing a completely fault-tolerant system is expensive

• The key to achieving fault tolerance is to eliminate all single
points of failure
• Assess everything:
o Power
o Hardware
o Networking
o Data centers
o .....
• Put fault tolerance in place where the cost vs return is
acceptable
o e.g. dual PSU in a server
Overview of the available SAP HANA native HA features
• SAP HANA includes several native high availability features

• These SAP HANA features are:
o Service auto-restart
o SAP HANA auto-restart
o Host auto-failover
− Only available when using a scale out configuration
o SAP HANA system replication
• These native SAP HANA features reduce the time to recover
from a failure
• A fully automated HA solution cannot be provided using only
the SAP HANA HA features
• To fully automate an HA solution for SAP HANA requires the
specialized components provided in SLES for SAP
Applications
Native SAP HANA HA features – service auto-restart
• Service auto-restart use case:

o Local software failure
• Local faults such as software failures can often be
handled using the same hardware
• A simple first step is to restart the failed service on the
same server
o Advantages:
− SAP HANA provides this function at no cost
− No loss of database integrity
o Disadvantage:
− Transactions not committed to the logs are lost
− May take some time to recover
• The SAP HANA auto-restart watchdog provides this
function
o This service is provided by the SAP HANA daemon
• In a clustered environment be aware failing SAP HANA
over to a node with SAP HANA active on it can lead to a
much faster recovery than restarting SAP HANA on the
same node
Native SAP HANA HA features – SAP HANA auto-restart
• When the system hosting SAP HANA is started, SAP HANA

will automatically startup
• Use cases:
o After a power failure
o Powering on the server after a shutdown
• When power returns after a power failure the SAP HANA
database system automatically performs a startup and
recovery
• Configuration required:
o SAP HANA database system is configured with auto-restart mode
on
• In a clustered environment SAP HANA is under cluster
control, therefore we do not want auto-restart enabled
Native SAP HANA HA features – system replication
• SAP HANA system replication – SAP HANA SR

• SR is provided with SAP HANA at no extra cost
• Consists of a primary and a secondary system
• The primary and secondary systems can be:
o In the same data center
o In remote data centers
• The secondary can be either passive or active
o Passive – Client requests are not accepted
o Active – Read-only client requests are accepted
Native SAP HANA HA features – system replication
• System replication modes:

o Synchronous in-memory (SYNCMEM)
− The secondary system sends an acknowledgment back to the
primary system as soon as the data is received in memory
o Synchronous (SYNC)
− The secondary system sends an acknowledgment back to the
primary system as soon as the data is received and persisted to
the log volumes on disk
o Asynchronous (ASYNC)
− The primary system sends redo log buffers to the secondary
system asynchronously. The primary does not wait for
confirmation from the secondary system
• The SYNC mode is used when configuring SAP HANA SR
scale up performance optimized on SLES for SAP
Applications with HA
Native SAP HANA HA features – operation modes
• There are three operation modes for SAP HANA system

replication:
o Delta Data Shipping
− System replication where delta data is transferred in addition to
continuous log transfer
− Default delta log transfer interval = 10 minutes
o Continuous Log Replay
− The transferred redo log is continuously replayed at the
secondary site
o Continuous Log Replay with Active/Active
− This is the same as the Continuous Log Replay option but read
only access for clients is permitted
• Continuous Log Replay is used when deploying SAP HANA SR
on SLES for SAP Applications with HA
SAP HANA system replication – how it works
• On the primary:
o SAP HANA makes updates in RAM on the
primary
o The updates are written to the
transaction log
o At the next savepoint, the data is
written to disk
• On the Secondary:
o When the primary makes updates in
RAM they are synchronously written to
the secondary
o The updates are written to the
transaction log
o At the next savepoint, the data is
written to the disk
• Result: The SAP HANA databases on
the primary and secondary are
synchronized
Thank You!
open@sap.com
Unit 3: SAP HANA Deployment Options
SAP HANA deployment scenarios
• This training is focused on deploying SAP HANA with

system replication, scale up in a performance-optimized
scenario
• This deployment scenario is not the only deployment
scenario, and in this unit we will make you aware of other
available scale up deployment scenarios
• Important: SUSE may have a supported HA solution for the
following deployment scenarios, but you must check the
SUSE Best Practices document for the particular
deployment scenario that suites your requirements
SAP HANA SR with HA deployment configurations
• The following deployment configurations are available in a

scale up deployment:
o Performance-optimized
o Cost-optimized
o Multi-tier chain topology
o Multi-tier multiple-target topology
Overview of the performance-optimized deployment scenario
• SAP HANA with system replication

• The secondary system is dedicated
• SAP HANA data is pre-loaded into memory on the secondary
• Advantages:
o Fully automated failover with SLE HA can be configured
o Fast recovery from the failure of the primary
− The data is already in memory on the secondary
• Disadvantages:
o Higher cost because secondary system is dedicated and is only
used when a failover occurs
• The performance-optimized deployment enables a fully
automated HA solution for SAP HANA to be deployed using
SLES for SAP Applications
Overview of the cost-optimized deployment scenario
• SAP HANA with system replication

• The secondary system is not dedicated
• SAP HANA data is not pre-loaded into memory on the
secondary
o SAP HANA therefore does not require memory for loading the
data
− Data preload must be turned off
o SAP HANA memory size configuration is adapted for this scenario
• SAP HANA is running on the secondary system in an SR
configuration but only persists the logs and data to
persistent storage
• Other software can be run on the system, for example, an
Oracle development system
Overview of the cost-optimized deployment scenario
• Advantage:
o Lower cost because the secondary system can be used for other
purposes, e.g. testing or QA
• Disadvantage:
o Slow recovery because running services need to be stopped, SAP
HANA started, and then there is a delay while the SAP HANA data
loads into memory
The failover process – performance vs cost-optimized
• Performance-optimized
o The detection of a failure and the failover process can be fully
automated with SLE HA
• Cost-optimized
o The detection of a failure and the failover process is manual
therefore the failover process cannot be automated with SLE HA
o When failover is required:
− First the failover requirement must be detected, this is a
manual process
− Any non-SAP HANA services hosted on the secondary must be
stopped, for example, an Oracle development system
− The SAP HANA memory must be reconfigured to use all the
available memory
− The data must be loaded into memory; this can take an
extended period of time
Multi-tier chain topology
• SAP HANA with synchronous system replication from the

primary to the secondary
• Add a third node with asynchronous system replication from
the secondary to the third node
• The SLE HA cluster only handles the primary and the first
secondary system
Multi-tier multiple-target topology
• SAP HANA with synchronous system replication from the

primary to the secondary
• Add a third node with asynchronous system replication from
the primary to the third node
• The SLE HA cluster only handles the primary and the
secondary system that are using synchronous
replication between them for SR
Thank You!
open@sap.com
Unit 4: Planning the Required Infrastructure
Planning the required infrastructure
Setting the context for the plan
• What are we aiming to achieve?

o Deploy SAP HANA scale up performance optimized with system
replication on SLES for SAP Applications with High Availability
• To support SAP HANA SR with HA there are some
prerequisites
• This training material follows the SUSE best practice
document:
o SAP HANA System Replication Scale-Up - Performance Optimized
Scenario
Planning – cluster components
• The best practice document this training is based on

has been tested and certified on a two-node cluster
o Three nodes can be deployed but the third node is only used
as a decision maker for fencing
− For example, if using diskless SBD
o The third node must not run any SAP HANA resources
• A valid STONITH method must be defined
• Both nodes are on the same layer-two network
segment
• Name resolution is available locally to each cluster
node
• Time synchronization is configured and active
• The Linux users and group required by SAP HANA are
defined locally on each cluster node
o Each user must have the same UID on each node
o The group must have the same GID on each node
Planning – SAP HANA components
• Cluster nodes hosted in geographically remote data centers

must match the requirements of SLE HA extension
recommendations
• Both primary and secondary SAP HANA instances must have
the same SID (SAP identifier)
• Configure AUTOMATED_REGISTER=<"true | false">
o If "true" the previously failed primary is automatically registered
as a secondary to the running primary
o If "false" the previously failed primary must be manually
registered as a secondary to the running primary
• SAP HANA auto-restart must be disabled
o The SAP HANA instance will be under cluster control
− SAP HANA must not be managed by systemd or sapstartsrv
Multi-tenant SAP HANA databases and HA
• Multi-tenant databases are supported using HA

• The SAP HANA RDBMS is treated as a single system by HA
o Therefore, it includes all database containers in a single HA
solution
• With an MDC implementation cluster, failover decisions are
based on the complete RDBMS
o Individual containers are not assessed during the failover decision
process
• Designing test procedures for MDC systems with HA requires
careful planning
Overview of sizing for SAP HANA
• Sizing SAP HANA is a complex process and requires the

skills of an experienced SAP consultant
• The key components to consider when sizing SAP
HANA include:
o Memory
o Storage
o CPU
o Network
• A good place to start is:
• https://www.sap.com/about/benchmark/sizing.quick-
sizer.html#quick-sizer
SAP HANA network planning
• SAP HANA network requirements need to be assessed on a

case-by-case basis
• Always refer to SAP documentation for the latest best
practice configuration options
o https://www.sap.com/documents/2016/08/1cd2c2fb-807c-0010-
82c7-eda71af511fa.html
• Communication is over the following logical network zones:
o Client
o Internal
o Storage
Logical network zones for SAP HANA
• The client zone includes:

o SQL clients running on SAP application servers
o Browser applications
− Using HTTP/S
o Data sources
− For example, BI
• The internal zone includes:
o The communication between hosts in a distributed SAP HANA
o system
− This would be a scale out scenario; this training is focused on
− a scale up scenario
o The communication used by SAP HANA system replication
• The storage zone:
o SAP HANA persists the data and transaction log data to persistent
storage
o If storage is on the SAN, the SAN infrastructure must be planned
o Storage can be local to an SAP HANA node
Thank You!
open@sap.com
Unit 5: Deploying the required infrastructure
Deploying the required infrastructure
Demonstration – Deploy the Required Infrastructure
• The infrastructure has been deployed and in this

demonstration we will take a tour of that infrastructure
o This module contains useful reference material for later units
• The services systems networking, repository and hosts file
configuration will be viewed
• The storage systems network configuration and iscsi targets
will be viewed
• The networking configuration and storage
available on node01 will be viewed
• The networking configuration and storage available
on node02 will be viewed
• The network configuration on the nfs system will be viewed
o The SAP HANA installation archive file has been previously
downloaded and copied onto a file system on the nfs system
Demonstration Summary – Deploy the Required Infrastructure
• The infrastructure has been deployed and in this

demonstration we went on a tour of the infrastructure that
has been deployed
o This module will be a useful reference module if you need to
check the configuration during later units
• The networking, repository and hosts file configuration for
the services system was viewed
o The services system provides access to the repositories required
by the systems related to the cluster
• The storage system was checked
o There were many local disks available
o All the disks except the disk containing the operating system are
shared using iscsi
• The storage systems network configuration was viewed and

was found to be on the following networks 192.168.17.0,
10.10.11.0, 10.10.12.0 and 10.10.13.0
• The iscsi devices were then listed
o There are 6 devices on the 192.168.17.0 network and the other 3

devices are each on their own 10.10.x.0 network
• The networking configuration on node01 was checked

• The locally available storage was viewed
o Some of the devices are iscsi targets
o Some of the iscsi targets are shared with node02 and some are
only local to node01
• The networking configuration on node02 was checked
• The locally available storage was viewed
o Some of the devices are iscsi targets
o Some of the iscsi targets are shared with node01 and some are
only local to node02
• The network configuration on the nfs system was viewed
• The SAP HANA installation archive file has been previously
download and copied onto a file system on the nfs system
• The status of the nfs service was checked and found to be
not running
o The nfs service will be configured in a later unit
Demonstration System Networking Reference
Thank You!
open@sap.com

OpenSAP Suse3-Pc Week 1 All Slides

Uploaded by

Document Information

Original Description:

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 Suse3-Pc Week 1 All Slides

Uploaded by

Copyright:

Available Formats

Week 1: Planning an SAP HANA SR HA Deployment

Unit 1: Overview of the SAP HANA architecture

• SAP HANA is a database and a platform

• A single SAP HANA system can host multiple

• The SAP HANA system is identified using a system identifier

• SAP HANA can be deployed in either of the following

• In this course we will focus on the deployment of SAP

• Fault tolerance aims to eliminate all single points of failure

• Providing a completely fault-tolerant system is expensive

• SAP HANA includes several native high availability features

• Service auto-restart use case:

• When the system hosting SAP HANA is started, SAP HANA

• SAP HANA system replication – SAP HANA SR

• System replication modes:

• There are three operation modes for SAP HANA system

• This training is focused on deploying SAP HANA with

• The following deployment configurations are available in a

• SAP HANA with system replication

• SAP HANA with system replication

• SAP HANA with synchronous system replication from the

• SAP HANA with synchronous system replication from the

• What are we aiming to achieve?

• The best practice document this training is based on

• Cluster nodes hosted in geographically remote data centers

• Multi-tenant databases are supported using HA

• Sizing SAP HANA is a complex process and requires the

• SAP HANA network requirements need to be assessed on a

• The client zone includes:

• The infrastructure has been deployed and in this

• The infrastructure has been deployed and in this

• The storage systems network configuration was viewed and

o There are 6 devices on the 192.168.17.0 network and the other 3

• The networking configuration on node01 was checked

You might also like