Best Practices of Huawei SAP HANA TDI Solution Using OceanStor Dorado V3. Huawei Enterprise BG, IT Storage Solution Dept Version 1.

Best Practices of Huawei SAP HANA TDI Solution Using OceanStor Dorado V3 Huawei Enterprise BG, IT Storage Solution Dept 2017-7-31 Version 1.0

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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2

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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 3

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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 4

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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 5

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 Single-node system Distributed cluster Application Application HANA ABCD Primary Node System replication HANA ABCD Data preloaded Secondary Node HANA AB Partition0 Work Node0 HANA CD Partition1 Work Node1 HANA!No!... Data preloaded Standby Node Scale-Up Shared Log Data Log Data Storage Shared Scale-Out Log0 Data0 Switch Log1 Data1 Storage... Shared 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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 6

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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 7

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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 8

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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 9

2.3.2 Data Reduction 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. 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 HANA HA + development and testing Two HANA nodes use system replication to realize HA. Four HANA nodes. Two production nodes working in HA mode; one node for development; one node for testing. ~2.6:1 ~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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 10

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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 11

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 HANA Development system, 1 TB memory Test system, 2 TB memory Production system, 4 TB memory Production system, 4 TB memory HA 2.5 TB 3.5 TB 6 TB 6 TB 18 TB disk capacity Deduplication and compression in LUNs Global deduplication and compression between LUNs 1.8 TB 2.5 TB 4 TB 4 TB 3.3 TB Periodical data replication 1.5:1 1.5:1 1.5:1 1.5:1 1.3:1 1.9:1 4.3 TB 3:1 data reduction Global deduplication and compression between LUNs 1.3:1 6 TB OceanStorDorado V3 6 TB disk capacity 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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 12

Figure 2-9 Huawei SAP LaMa integration solution Production (SID = PRO) DB System Clone System Copy Sandbox (SID = PRO) DB System Refresh Test (SID = QAS) DB Development (SID = DEV) DB Interaction Monitoring LaMa SAP Landscape Management The SOAP interface initiates clone and snapshot requirements. SSC Data/Log Data/Log Data/Log Data/Log Snapshot and replication HTTP, HTTPS Storage Services Connector OceanStor Dorado V3 2.3.4 Data Protection Backup and Recovery 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. 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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 13

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 1. An enterprise-level backup 1. This solution supports require independent platform is needed for rapid backup and backup. centralized backup of rollback to avoid 2. No enterprise-level backup software multiple services. 2. Enterprise-level backup misoperations and logic errors. 3. No strict requirement on RPO and RTO software such as CommVault is available for O&M. 2. Backup operations do not affect services. 3. No backup software is 3. Strict requirement on RPO required. and RTO Advantage 1. HANA provides standard 1. Flexible configuration. Both 1. The solution depends backup functions and only SAP HANA and on snapshots instead requires an NFS storage CommVault support policy of files. Rapid backup system. configuration, backup job and recovery have 2. Simple configurations enable customers to reuse initiation, recovery, query, and deletion operations. negligible impact on storage performance. existing storage systems. 2. Value-added functions are 2. Optimal TCO. 3. Block-level consistency check is supported. provided, including data encryption and deduplication. Snapshots can be used to formulate a testing system rapidly. 3. Backup files can be used for recovery immediately. Disadvantage 1. Backup by copying files 1. File-level backup is not as 1. Block-level directly. No compression efficient as snapshot consistency check is or other acceleration backup. not supported. functions, wasting disk space. 2. Additional licenses are required. 2. Local backup cannot avoid failure of an 2. Performance deteriorates when a large amount of 3. Service performance may be affected greatly in entire storage system. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 14

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 1. DR for data centers in the same city, 1. DR for data centers in different cities, 2. Server system replication + HyperMetro (RTT 1 ms) server system replication + HyperMetro (RTT 1 ms) HyperReplication asynchronous remote replication (RTT 100 ms) 2. DR for data centers 2. This solution can be in the same city, upgraded to the HyperReplication Geo-Redundant asynchronous Solution after it is remote replication combined with the (RTT 10 ms) Active-Active Data Center Solution and remote replication solution. Application scenario 1. SAP HANA servers are 1. DR across data centers in the same 1. Application-level DR across data centers. deployed in city. RTT 1 ms. Recommended system replication 2. High service network latency is Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 15

DR Solution Local DR Solution Same-City DR Solution Remote DR Solution HA architecture continuity requires smaller than 10 ms to improve end-to-end and does not exceed reliability. hardware HA. 100 ms. 2. When RTT is 1 3. This solution 2. DR resources are ms, you are applies to critical reused. advised to deploy two HyperMetro storage systems to reduce switchover RTO and improve system reliability. transaction systems such as ERP and CRM. 3. This solution applies to critical transaction systems and is seldom used for analysis systems. Solution highlight 1. Gateway-free HyperMetro: I/O 1. HyperMetro + end-to-end server 1. Asynchronous remote replication. Shortest bottlenecks HA, avoiding replication period is 3s eliminated, SPOF. RPO=0, and DR RPO 0. increasing service performance by 30%. 2. No data is lost RTO 0, improving SAP HANA service continuity. 2. Create snapshots for DR volumes and mount the snapshots to DR servers. Reuse DR and services are 2. Gateway-free computing resources not interrupted in design: eliminated to establish a testing case of a storage I/O bottlenecks, system, improving failure (RPO = 0, improving service resource usage. 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 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 + 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, Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 16

DR Solution Local DR Solution Same-City 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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 17

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 Size installation 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:Size redolog = 1/2 x RAM Memory > 512 GB:Size redolog(min) = 512 GB Shared volume configuration rules: Single-node: Size installation(single-node) = Min (1 x RAM; 1 TB) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 18

Cluster: Size installation(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: Size installation = 1 x 1 TB = 1 TB 4+1 system, 1 TB per node: Size installation = 1 x 1 TB = 1 TB 5+1 system, 1 TB per node: Size installation = 2 x 1 TB = 2 TB 6+1 system, 1 TB per node: Size installation = 2 x 1 TB = 2 TB 9+1 system, 1 TB per node: Size installation = 3 x 1 TB = 3 TB 12+1 system, 1 TB per node: Size installation = 3 x 1 TB = 3 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. Size backups Size data + Size redolog 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 Data volume Log volume Backup 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 Used for storing data files of SAP HANA databases Used for storing log files of SAP HANA databases Used for storing backup files of SAP HANA databases (The files are provided by backup storage.) Single-node: SAN Cluster: NAS (provided by OceanStor V3 or NFS servers) Single-node/Cluster: SAN 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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 19

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, READ READ / Failover, Takeover 4 KB 64 MB asynchronous parallel I/O orders (amount of data depends on RowStore size) 256 KB asynchronous I/O orders Column store table load Data Backup READ 4 KB 16 MB asynchronous parallel I/O orders 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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 20

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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 21

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 Number of 8 Gbit/s/16 Gbit/s Fibre Channel Ports 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 Number of 8 Gbit/s/16 Gbit/s Fibre Channel Ports 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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 22

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) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 23

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. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 24

4 Appendix 4.1 Reference Documents SAP HANA TDI official certification website https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enen/enterprise-storage.html 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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 25

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 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 26