Best Practices of Huawei SAP HANA TDI Solution Using ...

Huawei Enterprise BG, IT Storage Solution Dept

2017-7-31 Version 1.0

Best Practices of Huawei SAP HANA TDI Solution Using

OceanStor Dorado V3

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 2

Best Practices of Huawei SAP HANA TDI Solution Using OceanStor Dorado V3

Contents

1 About This Document .................................................................................................................. 3

1.1 Overview ...................................................................................................................................................................... 3

1.2 Purpose ......................................................................................................................................................................... 3

1.3 Intended Audience ........................................................................................................................................................ 3

1.4 Key Components .......................................................................................................................................................... 3

2 Huawei SAP HANA TDI Solution ............................................................................................ 5

2.1 Scenarios ....................................................................................................................................................................... 5

2.2 Customer Benefits ........................................................................................................................................................ 8

2.3 Feature .......................................................................................................................................................................... 9

2.3.1 Data Loading ............................................................................................................................................................. 9

2.3.2 Data Reduction ........................................................................................................................................................ 10

2.3.3 SAP LaMa Integration ............................................................................................................................................. 12

2.3.4 Data Protection ........................................................................................................................................................ 13

3 Best Practice of Huawei SAP HANA TDI .............................................................................. 18

3.1 Capacity Planning ....................................................................................................................................................... 18

3.2 I/O Features ................................................................................................................................................................ 19

3.3 Scalability ................................................................................................................................................................... 21

3.4 Configuration Reference ............................................................................................................................................. 21

3.5 Typical Scenario Configuration .................................................................................................................................. 23

4 Appendix ...................................................................................................................................... 25

4.1 Reference Documents ................................................................................................................................................. 25



1 About This Document

1.1 Overview

This document describes Huawei SAP HANA TDI Solution Using OceanStor Dorado V3 for

high performance and high availability services.

For more information, see Huawei OceanStor Dorado V3 product documents.

OceanStor Dorado V3

1.2 Purpose

This document helps Huawei partners and customers understand Huawei SAP HANA TDI

solution, which simplifies IT system planning and deployment, lowers TCO, reduces O&M

risks, and streamlines the change process.

1.3 Intended Audience

This document is intended for:

Huawei sales personnel and Huawei customer training personnel who promote Huawei

SAP HANA TDI Solution to customers.

System or storage administrators, customers, and partners

This document provides guidance on how to use Huawei Dorado V3 storage systems in TDI.

1.4 Key Components Huawei OceanStor Dorado V3 enterprise-level all-flash storage

OceanStor Dorado V3, Huawei's new-generation all-flash storage, provides a stable

latency as low as 500 μs and 99.9999% availability and is the first-choice for enterprises

requiring quality storage for critical service systems.

In addition to providing enterprise users with high-performance and efficient storage

services, the OceanStor Dorado6000 V3 storage system supports advanced data backup

and disaster recovery technologies, ensuring secure and smooth operation of data

http://support.huawei.com/enterprise/en/enterprise-storage/oceanstor-dorado5000-v3-pid-21529264

http://support.huawei.com/enterprise/en/enterprise-storage/oceanstor-dorado5000-v3-pid-21529264



services. OceanStor Dorado V3 also offers various methods for easy-to-use management

and convenient local and remote maintenance, remarkably reducing management and

maintenance costs.

SAP HANA in-memory database

SAP HANA is released by SAP in 2011 and applies to in-memory computing and

enterprise-level analysis. It is composed of a memory computing engine and a HANA

modeling tool and combines the functions of databases and application platforms in its

memory. Supporting local and cloud deployment, the SAP HANA high-performance

computing platform is an innovative product powered by an SAP HANA in-memory

database.



2 Huawei SAP HANA TDI Solution

2.1 Scenarios

Basic SAP HANA architecture, involving from all-in-one box to TDI

SAP HANA was launched in 2010 and hit the market in 2011. Since this technology was new

at that time, it was wise to purchase SAP HANA appliance certification hardware that only

contains preinstalled software.

As time passes by, lack of flexibility and reliability of HANA all-in-one boxes cannot meet

requirements of customers' data centers. In 2013, SAP provided the TDI hardware

certification and related solutions to solve these problems.

SAP HANA deployment modes are as follows:

All-in-one box

TDI

Figure 2-1 Comparison between SAP HANA all-in-one box and TDI

Features of all-in-one box:

Servers, networks, storage systems, and operating systems have fixed configurations and

cannot be customized.

Software is preinstalled by the hardware provider.



Features of TDI mode:

Storage systems and servers are not bound and can be purchased separately from

different vendors.

Servers and capacities of storage systems can be adjusted flexibly.

This mode matches with the current management architecture of the data center.

DR backup is implemented based on storage functions.

Existing customer devices are reused.

Compared with the all-in-one box mode, TDI mode is more open and flexible. Customers can

use their existing storage systems for SAP HANA and integrate SAP HANA seamlessly to

current data center operations such as DR, data protection, monitoring, and management,

taking less time for SAP HANA to take effective and reducing risk and cost of SAP HANA.

SAP HANA software deployment mode: Scale-up vs. Scale-out

The SAP HANA TDI solution supports multiple single-node systems (Scale-up) and a cluster

system (Scale-out).

Figure 2-2 Comparison between a single-node SAP HANA HA system and a cluster system

In an environment where multiple single nodes are deployed, an entire HANA database is

deployed on a physical server. Multiple databases are deployed separately for online

transaction processing (OLTP) transaction systems, including SAP Business Suite (ERP, CRM,

SRM). Descriptions about the HA architecture are as follows:

Data of the secondary node is pre-loaded in the memory.

Primary and secondary nodes are worker ones and have independent logs and data. Data

consistency is ensured through System Replication.

In single-node deployment, each HANA node has an independent shared volume.

The primary and secondary nodes work in active-passive mode with a switchover RTO

smaller than 1 minute.

In a cluster, a database is deployed on multiple servers. The system has at least two nodes.

One primary and several secondary nodes function as worker nodes. The system has one or

multiple backup nodes. If a primary or secondary node is faulty, the backup node can detect the fault and automatically change from the backup status to the running status to replace the

Storage

Log0

Data0

Log1

Data1

Shared

Application

HANA

Work

Node0

HANA

Work

Node1

HANA

Standby

Node

!No!Data preloaded...

Switch

...

ABPartition0

CDPartition1

Scale-Out

Scale

-Up

Storage

Log

Data

Application

HANA

Primary

Node

HANA

Secondary

NodeSystem

replication

ABCDABCD

Data preloaded

Log

Data

Shared Shared

Single-node system Distributed cluster



invalid node. Database instances are distributed to one or multiple HANA nodes for parallel

processing, load balance, and HA. Scale-out expansion of a cluster's memory capacity applies

to online analytical processing (OLAP) service load scenarios with large data sets. For

example, BW. Descriptions about the HA architecture are as follows:

Data is distributed to multiple nodes. Query results include results obtained on all nodes.

Each worker node has independent logs and data while a standby node does not have any

log or data and is not a worker node.

In a distributed cluster mode, multiple HANA nodes share a shared volume and file

sharing services are required. Network file system (NFS) is used because HANA only

supports Linux.

If a worker node fails, services are switched over to a standby node and data is loaded

from the storage to the memory of the standby node. The switchover RTO depends on

the time required for loading data to the memory.

Huawei SAP HANA certified storage

All Huawei storage devices certified by SAP are shown as follows:

Figure 2-3 Huawei OceanStor Dorado V3 all-flash storage

Dorado5000 V3 Dorado6000 V3

Figure 2-4 Huawei OceanStor V3 converged storage

For details about Huawei OceanStor V3 converged storage solution, refer to:

Best Practices of Huawei SAP HANA TDI Solution Using OceanStor V3 Converged

Storage

In the SAP official website, you can search for all certified storage systems for SAP HANA

TDI.

https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/enterprise-storage.html




2.2 Customer Benefits

Huawei SAP HANA TDI solution supports deployment of multiple single nodes and a

multi-node cluster and uses certified Huawei storage to provide excellent scalability, high

availability, disaster recovery, and data protection for SAP.

Figure 2-5 Panorama of Huawei SAP HANA TDI solution

Values of Huawei SAP HANA TDI Solution Based-on Dorado V3 storage

Outstanding Performance

High performance of Dorado V3 storage supports flexible service expansion. A

maximum of 32 HANA nodes are supported. This solution allows you to adjust server

and storage capacities flexibly to support rapid growth of enterprise services.

Dorado V3 all-flash storage has optimized data loading capacity and supports database

restart, automatic failover upon a host fault, log backup, database recovery, and table

data loading.

Flexible and Efficient

3:1 global data reduction, decreasing TCO by over 40%.

Integration of Huawei storage plug-in with the SAP LaMa, supporting end-to-end unified

hardware management.

10x faster deployment for development and testing and server upgrade in minutes.

Reliable

Snapshot in seconds without performance compromise achieves continuous data

protection.

Support for local HA, intra-city DR, remote DR solutions, and smooth evolution to the

Geo-Redundant Solution.

Unified data center backup based on storage snapshot has no impact on production

services.



2.3 Feature

2.3.1 Data Loading

Dorado V3 all-flash storage arrays have advantages in scenarios with a high read ratio. Faster

array read accelerates operations such as database restart, automatic host failover, log backup,

database recovery, and table loading. The following table lists the applicable scenarios of the

solution.

Quick HANA startup, reducing system downtime

Capacity expansion for hardware such as CPU, memory, and storage.

Restart after optimization of parameters such as HANA memory allocation.

Storage, server, network, and other hardware failures.

Faster deployment for development and testing to adapt to service changes

Rapid deployment of Huawei Sandbox system

Quick deployment of development, testing, and training systems

Refreshing the testing system database using the production system data

Quick fault switchover for a distributed cluster, reducing downtime

If a worker node in a distributed cluster is faulty, services are switched over to the

standby node.

According to tests, it takes SAP HANA about four minutes to load one TB of data from the

storage to the memory. Dorado V3 has more evident advantages if a data set is large.



During restart of the SAP HANA database, only rows are loaded to the memory and

columns are loaded to the memory through lazy loading after the database is restarted. Therefore, the number and size of rows affect the restart time.

2.3.2 Data Reduction

The deduplication and compression technology of Dorado V3 saves more space than

traditional storage systems.

Inline deduplication

Inline deduplication allows OceanStor Dorado V3 to delete duplicate data online before

writing data to flash media. With this function enabled, data is first cached after entering

the storage system. The background automatically deletes duplicate data before writing

dirty data into the flash media. Deduplication is performed in real time, not after data is

written to the flash media. Deduplication ratio is related to the content of user data. You

can disable deduplication in scenarios requiring high performance and a small

deduplication ratio.

Inline compression

Inline compression compresses data online before writing data to flash media. In

addition, compression is performed after deduplication, ensuring that no duplicate data is

compressed and improving compression efficiency. Compression is performed in real

time and is not handled in post-processing. The overall compression ratio is determined

by the attributes of data sets. The compressed data blocks are stored in arrays.

Compression reduces the amount of data written to SSDs. Compression ratio is related to

the content of user data. You can disable compression in scenarios requiring high

performance.

If any change occurs, memory data of the SAP HANA database is automatically compressed

and the changes are saved permanently in the storage layer. Therefore, data reduction ratio of

SAP HANA databases is smaller than that of traditional databases. Table 2-1 tests data

reduction ratios in three typical application scenarios of SAP HANA databases.

Table 2-1 Comparison of data reduction ratios in three typical application scenarios

Scenario Description Data Reduction Ratio

HANA single node Only one HANA host and no HA node ~1.5:1

HANA HA cluster Two HANA nodes use system replication to

realize HA.

~2.6:1

HANA HA +

development and

testing

Four HANA nodes. Two production nodes

working in HA mode; one node for

development; one node for testing.

~3:1

If SAP applications are deployed on a single HANA database node and no HA node is

available, the storage only provides data and log volumes for the single node. Data reduction

ratio is approximately between 1.5:1 and 1.8:1.



Figure 2-6 Data compression ratio in a single-node scenario

If an HA architecture is deployed for the HANA database, primary and secondary nodes are

both worker nodes and have independent logs and data. System replication is used to ensure

data consistency. One Dorado5000 V3 storage system provides data and log volumes for two

nodes. Data reduction ratio is about 2.6:1.

Figure 2-7 Data compression ratio in an HA scenario



1. Test data is obtained from a demo in the lab and may be different from data collected from a real

scenario.

2. After long-term running, the data reduction ratio may decrease with the growth of user differential

data.

In real applications, a typical SAP application scenario includes production, development, and

testing systems. Production systems work in HA mode. Global deduplication and compression

of Dorado V3 avoid repeated copies of storage data files, reduce occupied space, and do not

affect performance. Data reduction ratio of Dorado V3 is about 3:1, as shown in the following

figure.

Figure 2-8 Global deduplication and compression for HANA HA, testing, and development

2.3.3 SAP LaMa Integration

Huawei has developed a special plug-in, storage service connector (SSC), to integrate with

SAP LaMa for end-to-end and unified management of software and hardware on the SAP and

automatic configuration, increasing the efficiency of system clone, replication, and database

refreshing.

The following functions are provided:

Centralized management: Unified operations and configurations on SAP simplify

management. E2E unified O&M of SAP hardware and software improves efficiency.

Automatic configuration: Automatic running of SAP system clone, replication, and

database update shortens the deployment time of development and testing systems.

Execution scripts can be scheduled to process repeated and time-consuming tasks.

Real-time monitoring: unified management of SAP system monitoring and management

views, visualized job scheduling and O&M, as well as end-to-end detection, monitoring,

and management of SAP and non-SAP applications.

Development

system, 1 TB

memory

Test system,

2 TB memory

Production system,

4 TB memory

Production

system, 4 TB

memoryHA

2.5 TB 3.5 TB 6 TB 6 TB

1.8 TB 2.5 TB 4 TB 4 TB

4.3 TB3.3 TB

6 TB

Periodical data replication

Deduplication and

compression in

LUNs

Global deduplication and

compression between

LUNs

Global deduplication and

compression between

LUNs

1.5:1 1.5:1 1.5:1 1.5:1

1.9:11.3:1

1.3:1

OceanStorDorado V3

3:1 data

reduction

HANA18 TB disk

capacity

6 TB disk

capacity



Figure 2-9 Huawei SAP LaMa integration solution

1. SAP System Clone: used to build a sandbox system or used for migration of systems with the same

SID.

2. SAP System Copy: used to build development and testing systems with different SIDs.

3. SAP System Refresh: used only to refresh testing system data.

2.3.4 Data Protection

Backup and Recovery

To prevent data loss caused by hardware failures, it is necessary to back up SAP service data.

Huawei SAP HANA TDI backup solution includes the following:

File-level backup: writes backup data to the file system of the local storage system.

Backup based on storage-level snapshots: protects data volumes.

Backup based on the Backint interface (a streaming backup interface defined by SAP):

interconnects with third-party centralized backup software.

Table 2-2 shows analysis and comparison of the three backup solutions.

Data/LogData/Log Data/Log Data/Log

OceanStor Dorado V3

SAP Landscape

ManagementInteraction

Monitoring

Storage Services

ConnectorSnapshot and

replication

HTTP, HTTPS

The SOAP interface

initiates clone and

snapshot requirements.

LaMa

SSC

System Copy

DB

Production(SID = PRO)

DB

Sandbox(SID = PRO)

DB

Test(SID = QAS)

DB

Development

(SID = DEV)System

Clone

System Refresh



Table 2-2 SAP HANA backup scenario analysis

Description HANA Studio File-level Backup

Backup Based on Third-Party Software

Backup Based on Storage Snapshots

Solution

overview

Scenario 1. Only SAP services

require independent

backup.

2. No enterprise-level

backup software

3. No strict requirement on

RPO and RTO

1. An enterprise-level backup

platform is needed for

centralized backup of

multiple services.

2. Enterprise-level backup

software such as

CommVault is available for

O&M.

3. Strict requirement on RPO

and RTO

1. This solution supports

rapid backup and

rollback to avoid

misoperations and

logic errors.

2. Backup operations do

not affect services.

3. No backup software is

required.

Advantage 1. HANA provides standard

backup functions and only

requires an NFS storage

system.

2. Simple configurations

enable customers to reuse

existing storage systems.

3. Block-level consistency

check is supported.

1. Flexible configuration. Both

SAP HANA and

CommVault support policy

configuration, backup job

initiation, recovery, query,

and deletion operations.

2. Value-added functions are

provided, including data

encryption and

deduplication.

3. Backup files can be used for

recovery immediately.

1. The solution depends

on snapshots instead

of files. Rapid backup

and recovery have

negligible impact on

storage performance.

2. Optimal TCO.

Snapshots can be used

to formulate a testing

system rapidly.

Disadvantage 1. Backup by copying files

directly. No compression

or other acceleration

functions, wasting disk

space.

2. Performance deteriorates

when a large amount of

1. File-level backup is not as

efficient as snapshot

backup.

2. Additional licenses are

required.

3. Service performance may

be affected greatly in

1. Block-level

consistency check is

not supported.

2. Local backup cannot

avoid failure of an

entire storage system.



Description HANA Studio File-level Backup

Backup Based on Third-Party Software

Backup Based on Storage Snapshots

data exists. extreme cases.

For details about backup solutions, see the following:

Best Practices of Huawei SAP HANA TDI Backup Solution Using HANA Studio

Best Practices of Huawei SAP HANA TDI Backup Solution Using Third Party Software

Best Practices of Huawei SAP HANA TDI Backup Solution Using Storage Snapshot

DR Protection

When deploying the SAP HANA TDI solution, customers create a data copy locally or

remotely to protect key SAP applications and SAP HANA databases from impacts of disasters,

software and hardware faults, and human errors. Huawei SAP HANA TDI solution supports

local HA, intra-city DR, remote DR solutions, and smooth evolution to the Geo-Redundant

Solution. HyperReplication and HyperMetro of Dorado V3 storage provides data protection

for critical SAP services, ensuring high availability and service continuity.

Table 2-3 shows analysis and comparison of the three DR solutions.

Table 2-3 SAP HANA DR scenario analysis

DR Solution

Local DR Solution Same-City DR Solution

Remote DR Solution

Solution

proposal 1. Server system

replication HA

2. Server system

replication +

HyperMetro (RTT

≤ 1 ms)

1. DR for data centers

in the same city,

server system

replication +

HyperMetro (RTT

≤ 1 ms)

2. DR for data centers

in the same city,

HyperReplication

asynchronous

remote replication

(RTT ≤ 10 ms)

1. DR for data centers in

different cities,

HyperReplication

asynchronous remote

replication (RTT ≤

100 ms)

2. This solution can be

upgraded to the

Geo-Redundant

Solution after it is

combined with the

Active-Active Data

Center Solution and

remote replication

solution.

Application

scenario 1. SAP HANA

servers are

deployed in

system replication

1. DR across data

centers in the same

city. RTT ≤ 1 ms.

2. High service

1. Application-level DR

across data centers.

Recommended

network latency is



DR Solution


Remote DR Solution

HA architecture

to improve

reliability.

2. When RTT is ≤ 1

ms, you are

advised to deploy

two HyperMetro

storage systems to

reduce switchover

RTO and improve

system reliability.

continuity requires

end-to-end

hardware HA.

3. This solution

applies to critical

transaction systems

such as ERP and

CRM.

smaller than 10 ms

and does not exceed

100 ms.

2. DR resources are

reused.

3. This solution applies

to critical transaction

systems and is seldom

used for analysis

systems.

Solution

highlight 1. Gateway-free

HyperMetro: I/O

bottlenecks

eliminated,

increasing service

performance by

30%.

2. No data is lost

and services are

not interrupted in

case of a storage

failure (RPO = 0,

RTO = 0).

3. HANA and SAP

application

servers (ERP,

BW, and CRM)

support HA to

avoid single point

of failure (SPOF).

Switchover RTO

is smaller than 1

minute.

4. Smooth evolution

towards the

Active-Passive

Solution and

Geo-Redundant

1. HyperMetro +

end-to-end server

HA, avoiding

SPOF. RPO=0,

RTO ≈ 0,

improving SAP

HANA service

continuity.

2. Gateway-free

design: eliminated

I/O bottlenecks,

improving service

performance by

30%. Fewer

purchased devices

and faults, reducing

CAPEX and

increasing solution

reliability.

3. Further expansion

of the DR solution.

Smooth evolution

to HyperMetro +

heterogeneous

two-site DR, and

Geo-Redundant

Solution

(HyperMetro +

1. Asynchronous remote

replication. Shortest

replication period is 3s

and DR RPO ≈ 0.

2. Create snapshots for

DR volumes and

mount the snapshots to

DR servers. Reuse DR

computing resources

to establish a testing

system, improving

resource usage.

3. Visualized DR

management for

BCManager. One-key

DR drill and recovery

based on customer

service configurations.

4. Concurrent disk

flushing through

BCManager Agent to

ensure data

consistency of

multiple independent

services.

5.

between high-end,



DR Solution


Remote DR Solution

Solution. replication). mid-range, and

entry-level storage, the

first in the industry.

For details about the active-passive DR solution, see the following:

Best Practices of Huawei SAP HANA TDI Active-Passive DR Solution Using BCManager



3 Best Practice of Huawei SAP HANA TDI

The best practice is recommended for deploying SAP HANA production systems on Huawei

Dorado V3 storage systems. This chapter describes storage I/O features, storage capacity

configuration rules, software and hardware planning, and networking after SAP HANA's KPI

standards are met.

3.1 Capacity Planning

The SAP HANA solution requires a disk capacity based on the memory size of HANA nodes

and the database capacity. After customers have determined the memory requirement or

database size, you can access storage capacity requirements according to SAP's recommended

official configuration rules. If the production system is deployed in a HA cluster, the test

system requires half the memory capacity of the production system while the development

system needs a recommended capacity of 512 GB to 1 TB. Adjust the planning based on

actual project requirements. Shared volumes, data volumes, and log volumes are offered by

the storage system. If there is any backup requirement, backup volumes are recommended.

Data volume configuration rules (same for single-node and cluster systems):

− Capacity requirements: one to two times the memory size for each node

− Example:

− 1 TB memory per node ≥ Sizeinstallation ≥ 1 TB or 2 TB LUN created on each node

− Performance requirements: minimum number of SSDs for different quantities of

nodes, see section 3.3 "Scalability".

− Example:

− 8 SSDs for an 8-node system. Adjust disk types based the capacity.

− Configuration confirmation: Compare configuration results generated by calculating

storage capacity and performance, and select the bigger one as the final choice. If the

performance requirement is greater than the capacity requirement, adjust data volume

capacity based on the ratio.

Log volume configuration rules (same for single-node and cluster systems):

− Memory ≤ 512 GB:Sizeredolog = 1/2 x RAM

− Memory > 512 GB:Sizeredolog(min) = 512 GB

Shared volume configuration rules:

− Single-node: Sizeinstallation(single-node) = Min (1 x RAM; 1 TB)



− Cluster: Sizeinstallation(scale-out) = 1 x RAM_of_worker per 4 worker nodes, node memory

size for every 4 nodes in the cluster

Example:

3+1 system, 1 TB per node: Sizeinstallation = 1 x 1 TB = 1 TB






Backup volume configuration rules: The capacity of backup data volumes depends on

the data volume size and backup frequency while the capacity of backup log volumes

depends on the refreshing frequency of a HANA database.

− Sizebackups ≥ Sizedata + Sizeredolog

3.2 I/O Features

In SAP HANA, you need to plan storage and provide the following file system types.

Table 3-1 Storage planning in SAP HANA

File System Description Storage Type

Shared volume The installation directory of the SAP

HANA system is a mandatory parameter in

the installation configuration file.

Used for storing HANA global files and

profiles

Single-node: SAN

Cluster: NAS (provided

by OceanStor V3 or

NFS servers)

Data volume Used for storing data files of SAP HANA

databases

Single-node/Cluster:

SAN

Log volume Used for storing log files of SAP HANA

databases

Backup volume Used for storing backup files of SAP

HANA databases (The files are provided by

backup storage.)

Single-node/Cluster:

NAS (provided by

OceanStor V3 or NFS

servers)

As a global file system, shared volumes have no dedicated performance requirements and are

not affected by I/O performance data. SAP HANA I/O load features involve three parts: data

volumes, log volumes, and backup volumes. Different volumes use different I/O load sizes in

various application scenarios.

Data volumes: SAP HANA uses random I/Os to access data volumes. Data blocks (16

KB or 64 MB) are written to a data volume asynchronously in parallel mode. When the

database is running properly, most I/Os are write operations. Read operations are only

performed during database restarting, cluster failover, or data loading.



Log volumes: SAP HANA delivers sequential I/O data blocks (4 KB or 1 MB) to access

log volumes. One 1 MB buffer zone in the memory is reserved for Redo Log. When the

zone is fulfilled with data, data is written to a log volume asynchronously. If a database

transaction is submitted before the zone becomes full, small I/O data blocks are written

to the file system. Therefore, a low latency is required for small I/Os (4 KB or 16 KB) in

storage devices. Same as data volumes, when the database is running properly, most I/Os

are write operations. Read operations are only performed during database restarting,

cluster failover, log backup, or database recovery.

Backup volumes: SAP HANA uses sequential I/Os to access backup volumes. Data

blocks (512 MB) in data volumes and data blocks (4 KB or 128 MB) in log volumes are

written asynchronously in parallel mode. During database backup, most I/Os of backup

volumes are write operations. A large number of read operations are performed only

during database recovery.

The following table lists storage I/O features in typical SAP HANA scenarios.

Table 3-2 Storage I/O features in SAP HANA scenarios

Scenarios Data Volume Redo Log Volume Backup Storage

Write

transactions

/ WRITE

OLTP – mostly 4 KB

sequential I/O orders;

OLAP – larger I/O order

sizes (up to 1 MB)

/

Savepoint,

Snapshot,

Delta merge

WRITE

4 KB – 64 MB

asynchronous

parallel I/O orders

(amount of data

depends on system

load)

/ /

DB Restart,

Failover,

Takeover

READ

4 KB – 64 MB

asynchronous

parallel I/O orders

(amount of data

depends on

RowStore size)

READ

256 KB asynchronous

I/O orders

/

Column store

table load READ

4 KB – 16 MB

asynchronous

parallel I/O orders

/ /

Data Backup READ

4 KB – 64 MB

asynchronous I/O

orders copied into

buffers of 512 MB

/ WRITE

512 MB sequential

I/O orders

(configurable)

Log Backup / READ

4 KB – 128 MB

WRITE

4 KB – 128 MB



Scenarios Data Volume Redo Log Volume Backup Storage

asynchronous I/O orders

copied into buffers of 128

MB

sequential I/O

orders

Database

Recovery

WRITE

4 KB – 64 MB

asynchronous

parallel I/O orders

READ

256 KB asynchronous

I/O orders

READ

Data backup: 512

MB I/O orders

copied into buffers

of 512 MB

Log backup: 128

MB I/O orders

copied into buffers

of 128 MB

3.3 Scalability

In SAP HANA scenarios, the number of nodes supported by Dorado V3 is decided by the

performance of arrays and planned configuration. The following table lists the maximum

number of HANA worker nodes supported in various specifications.

Table 3-3 Scalable Dorado V3 configuration in SAP HANA

Model Number of Controllers

Maximum Number of HANA Worker Nodes

Number of 8 Gbit/s/16 Gbit/s Fibre Channel Ports

Dorado5000 V3 2 18 (SAS SSDs) 18/12

2 24 (NVMe SSDs) 24/16

Dorado6000 V3 2 18 18/12

4 32 32/20

3.4 Configuration Reference

In principle, Huawei storage can be used to deploy SAP HANA and other applications.

However, if the number of running HANA nodes exceeds half the maximum number of nodes

supported by disk arrays, ensure that the storage arrays are not shared by other applications.

For example, Dorado5000 V3 with dual controllers supports 18 HANA worker nodes. It is

recommended that only 9 to 10 HANA nodes be running to meet performance requirements of

SAP HANA databases.

Table 3-2 shows recommended performance configuration for different storage device

models.



Table 3-4 Dorado5000 V3 (NVMe SSDs) storage configuration reference

Number of Nodes

Memory Number of NVMe SSDs

Disk Domain

Storage Pool

Number of LUNs


1 to 12 1 TB 8 1 1 2 to 24 12/8

16 12 32 20/14

20 16 40 20/14

24 18 48 24/16

Table 3-5 Dorado5000/6000 V3 (SAS SSDs) storage configuration reference

Number of Nodes

Memory Number of SSDs

Disk Domain

Storage Pool

Number of LUNs


1 to 10 1 TB 8 1 1 2 to 20 10/6

14 12 28 14/10

16 16 32 14/10

18 18 36 18/14

22 25 44 22/16

28 30 56 28/22

32 36 64 32/24

1. Recommended capacity configuration: Total capacity = Log volumes + Data volumes + Shared

volumes. Calculate the capacity accurately based on HANA node memory.

2. Log volume capacity = Node memory size/2 (memory < 512 GB); 512 GB or greater (memory ≥

512 GB)

3. Data volume capacity = One to three times node memory size

4. Shared volume capacity for a single node = Min (Node memory size, 1 TB)

Shared volume capacity for a cluster = Node memory size for every four nodes in the cluster

5. For details about calculating the data reduction ratio, see section 2.3.2 "Data Reduction".

6. The LUN number in the above table focuses only on data volumes and log volumes. Adjust

configuration of shared volumes based on actual project situations.



3.5 Typical Scenario Configuration

Typical Configuration for Medium-Scale Applications

One or two sets of SAP ERP and BW service systems are deployed. Each service has test,

development, sandbox, and production systems (HA deployment for production systems).

Figure 3-1 Medium-scale application scenario (4 < Number of nodes ≤ 18)

Typical Configuration

Server: Refer to SAP HANA verified configuration. Each node is configured with one 16

Gbit/s Fibre Channel card.

Storage: Dorado5000 V3 (256 GB cache, 4 x 16 Gbit/s Fibre Channel, 10 x 1.8 TB

SSDs), available capacity of 12 TB after data is compressed and reduced at 3:1 ratio.

Storage switch: 2 x SNS2224 (8 to 24 ports)

Adding Components:

Add disks based on capacity requirements.

Add a SmartIO module each time four host ports are added.

Add a disk enclosure and two SAS cables each time 25 disks are added.

Typical Configuration for Large-Scale Applications

One to N sets of SAP ERP, BW, and other service systems are deployed. Each service has test,

development, sandbox, and production systems (HA deployment for production systems).

Figure 3-2 Large-scale application scenario (18 < Number of nodes ≤ 32)



Typical Configuration

Server: Refer to SAP HANA verified configuration. Each node is configured with one 16

Gbit/s Fibre Channel card.

Storage: 32 nodes, Dorado6000 V3 (four controllers, 512 GB cache per controller, 16 x

16 Gbit/s Fibre Channel, 18 x 3.6 TB SSDs), available capacity of 45 TB after data is

compressed and reduced at 3:1 ratio.

Storage switch: 2 x SNS2248 (8 to 48 ports)

Adding Components:

Add disks based on capacity requirements.

Add a SmartIO module each time four host ports are added.

Add a disk enclosure and two SAS cables each time 25 disks are added.



4 Appendix

4.1 Reference Documents SAP HANA TDI official certification website


Best Practices of Huawei SAP HANA TDI Backup Solution Using HANA Studio

Best Practices of Huawei SAP HANA TDI Backup Solution Using Third Party Software

Best Practices of Huawei SAP HANA TDI Backup Solution Using Storage Snapshot

Best Practices of Huawei SAP HANA TDI Active-Passive DR Solution Using

BCManager

OceanStor Dorado5000 V3&Dorado6000 V3 Storage System Product Documentation


http://support.huawei.com/hedex/hdx.do?docid=EDOC1000141860&lang=zh&idPath=7919749%7C7941815%7C21430818%7C21462743%7C21529264&clientWidth=1639&browseTime=1503729777482


Huawei SAP HANA TDI Solution Best Practice Based on OceanStor Dorado V3

Copyright © Huawei Technologies Co., Ltd. 2017. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.

Trademark Notice

, HUAWEI, and are trademarks or registered trademarks of Huawei Technologies Co., Ltd.

Other trademarks, product, service and company names mentioned are the property of their respective owners.

General Disclaimer

The information in this document may contain predictive statements including,

without limitation, statements regarding the future financial and operating

results, future product portfolio, new technology, etc. There are a number of

factors that could cause actual results and developments to differ materially

from those expressed or implied in the predictive statements. Therefore, such

information is provided for reference purpose only and constitutes neither an

offer nor an acceptance. Huawei may change the information at any time

without notice.

HUAWEI TECHNOLOGIES CO., LTD.

Huawei Industrial Base

Bantian Longgang

Shenzhen 518129, P.R. China

Tel: +86-755-28780808

www.huawei.com

Best Practices of Huawei SAP HANA TDI Solution Using ...

Documents

Transcript of Best Practices of Huawei SAP HANA TDI Solution Using ...