SAP HANA TDI - Storage Requirements

1 SAP hana . Storage Requirements As an in-memory database, SAP hana uses Storage devices to save a copy of the data, for the purpose of startup and fault recovery without data loss. The choice of the specific Storage technology is driven by various Requirements like size, performance and high availability. This paper discusses the SAP hana Storage Requirements . _____. SAP hana Development Team , February 2016. Contents Legal Disclaimer .. 3. Change history .. 3. 1 Introduction .. 4. Conceptual Storage Layout .. 4. Physical Separation of Data and Log Volumes .. 6. Sizing .. 6. Disk Space Required for the Data Volume .. 7. Disk Space Required for the Log Volume .. 7. Disk Space Required for SAP hana Installation .. 8. Disk Space Required for Backups.

2 9. Disk Space Required for Exports .. 10. 2 High Availability .. 10. Failure Recovery: Host Auto-Failover .. 10. Failure Detection and Failover .. 11. File Access and Fencing .. 11. Non-shared 11. Shared Storage with Shared File Systems .. 12. Disaster Recovery Approaches .. 14. 14. Storage Replication .. 14. System Replication .. 15. 3 Performance .. 16. Scenarios .. 16. I/O Patterns .. 18. I/O 18. 4 20. 5 Acknowledgements .. 20. 6 Terminology Appendix .. 21. 7 References .. 22. 2016 SAP SE page 2/22. Legal Disclaimer THIS DOCUMENT IS PROVIDED FOR INFORMATION PURPOSES ONLY AND DOES NOT MODIFY THE TERMS OF ANY AGREEMENT. THE CONENT OF THIS. DOCUMENT IS SUBJECT TO CHANGE AND NO THIRD PARTY MAY LAY LEGAL CLAIM TO THE CONTENT OF THIS DOCUMENT.

3 IT IS CLASSIFIED AS CUSTOMER . AND MAY ONLY BE SHARED WITH A THIRD PARTY IN VIEW OF AN ALREADY EXISTING OR FUTURE BUSINESS CONNECTION WITH SAP. IF THERE IS NO SUCH. BUSINESS CONNECTION IN PLACE OR INTENDED AND YOU HAVE RECEIVED THIS DOCUMENT, WE STRONGLY REQUEST THAT YOU KEEP THE CONTENTS. CONFIDENTIAL AND DELETE AND DESTROY ANY ELECTRONIC OR PAPER COPIES OF THIS DOCUMENT. THIS DOCUMENT SHALL NOT BE FORWARDED TO ANY. OTHER PARTY THAN THE ORIGINALLY PROJECTED ADDRESSEE. This document outlines our general product direction and should not be relied on in making a purchase decision. This document is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to develop or release any functionality mentioned in this document.

4 This document and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice. This document is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this document and shall have no liability for damages of any kind that may result from the use of these materials, except if such damages were caused by SAP. intentionally or grossly negligent. Copyright 2016 SAP SE. All rights reserved. Change history Version Date Description June 2013 Initial release November 2013 Added Storage Sizing section Added Performance Section December 2013 Improved information about IO fencing with NFS based shared storages May 2014 Updated sizing formulas Minor fixes July 2014 Minor fixes October 2014 Updated Sizing chapter: New formula for redo log sizing January 2015 Updated Sizing chapter: Distinguish total memory and net data size on disk March 2015 Updated Sizing chapter: New recommendations for sizing of / hana /shared February 2016 Added chapter: Physical separation of data and log volumes 2016 SAP SE page 3/22.

5 1 Introduction SAP hana is an in-memory database which stores and processes the bulk of its data in memory. Additionally it provides protection against data loss by saving the data in persistent Storage locations. For setting up a SAP hana system, the Storage layer must fulfill several Requirements . This paper discusses the different Requirements and common design options for the Storage subsystem. Especially when using high availability and disaster tolerance features, care must be taken on planning the persistent space. SAP hana uses Storage for several purposes: The SAP hana installation. This directory tree contains the run-time binaries, installation scripts and other support scripts. In addition, this directory tree contains the SAP hana .

6 Configuration files, and is also the default location for storing trace files and profiles. On distributed systems, it is created on each of the hosts. Backups. Regularly scheduled backups are written to Storage in configurable block sizes up to 64 MB. Data. SAP hana persists a copy of the in-memory data, by writing changed data in the form of so-called savepoint blocks to free file positions, using I/O operations from 4 KB to 16 MB. (up to 64 MB when considering super blocks) depending on the data usage type and number of free blocks. Each SAP hana service (process) separately writes to its own savepoint files, every five minutes by default. Redo Log. To ensure the recovery of the database with zero data loss in case of faults, SAP.

7 hana records each transaction in the form of a so-called redo log entry. Each SAP hana . service separately writes its own redo-log files. Typical block-write sizes range from 4KB to 1MB. Each service of a distributed (multi-host) SAP hana system manages its persistence independently. Logically, this is a shared-nothing approach. Conceptual Storage Layout The following illustration shows the recommended structure of a SAP hana installation, showing a distributed SAP hana system (named H36) with n=2 hosts. Following figure represents the file system structure of a SAP hana setup. For the plain Linux installation 10 GB of disk size is recommended the Storage size Requirements of a SAP hana . installation are expressed as a function of the host memory size (see Sizing).

8 Additionally, at least 50. GB must be provided for the /usr/sap location in the system as this is the place where other SAP. software that supports SAP hana will be installed. It is possible to join this location with the Linux installation. 2016 SAP SE page 4/22. / (root). Linux /usr/sap / hana 10GB 50GB data log shared H36 H36 H36. mnt00001 mnt00002 mnt00001 mnt00002. hdb00001 hdb00005 hdb00001 hdb00005. hdb00002 hdb00002. hdb00003 hdb00003. hdb00004 hdb00004. When installing SAP hana on a host, you specify where to place the installation binaries (by default: / hana /shared/<sid>, where sid is the instance identifier of the SAP hana installation), as well as the destination for the data and log files. In the case of a simple, single-host installation of SAP hana , the directory layout to support these different Storage usages is correspondingly simple, and the installation defaults are often adequate.

9 It is possible to use plain attached Storage devices1, such as SCSI hard drives, SSDs or SANs. However, the Storage device considerations change once one considers the need for backups, and other failure recovery measures. For instance, it may be desirable to direct the backups of all the instances of a distributed system onto a single Storage device. And as we shall see, local failure recovery (host auto-failover) requires the ability to share the same files between multiple hosts. Thus, in most cases, the preferred Storage solution involves separate, externally attached Storage subsystem devices that are capable of providing dynamic mount-points for the different hosts, according to the overall landscape. This is further discussed in the section on High Availability.

10 In terms of Storage performance, both write and read operations need to be considered. Raw write speed is important to keep up with the volume of write operations represented by the Savepoint persistence and backups. Write latency (the time it takes to complete the writing of a redo log record) is equally critical, since transactions are not completed until they have been persisted. Read speed is obviously important for a rapid startup of the database as well as in failover situations where a SAP hana host takes over the persistence of another host, in particular with very large data sizes. Data is also read during regular operations, if rarely-used tables are unloaded, and only loaded on use. Again the faster the media the less wait time.