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 V2.5, January 2015 Contents Legal Disclaimer ..................................................................................................................................3 Change history ....................................................................................................................................3 1 Introduction ................................................................................................................................4 Conceptual Storage Layout .............................................................................................................4 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 .................................................................................................8 Disk Space Required for Exports ..................................................................................................9 2 High Availability ..........................................................................................................................9 Failure Recovery: Host Auto-Failover...............................................................................................9 Failure Detection and Failover....................................................................................................... 10 File Access and Fencing ................................................................................................................. 10 Non-shared Storage .................................................................................................................. 10 Shared Storage with Shared File Systems .................................................................................. 11 Disaster Recovery Approaches ...................................................................................................... 12 Backups..................................................................................................................................... 12 Storage Replication ................................................................................................................... 13 System Replication .................................................................................................................... 14 3 Performance ............................................................................................................................. 15 Scenarios ...................................................................................................................................... 15 I/O Patterns .................................................................................................................................. 17 I/O Sizing ...................................................................................................................................... 17 4 Summary................................................................................................................................... 19 5 Acknowledgements ................................................................................................................... 19 6 Terminology Appendix .............................................................................................................. 20 7 References ................................................................................................................................ 21 © 2015 SAP SE page 2/21 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. 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. 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 2015 SAP SE. All rights reserved. Change history Version Date Description 1.9 June 2013 Initial release 2.0 November 2013 Added Storage Sizing section Added Performance Section 2.1 December 2013 Improved information about IO fencing with NFS based shared storages 2.2 May 2014 Updated sizing formulas Minor fixes 2.3 July 2014 Minor fixes 2.4 October 2014 Updated Sizing chapter: New formula for redo log sizing 2.5 January 2015 Updated Sizing chapter: Distinguish total memory and net data size on disk © 2015 SAP SE page 3/21 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: x 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 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. x Backups. Regularly scheduled backups are written to storage in configurable block sizes up to 64 MB. x 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. x Redo Log. To ensure the recovery of the database with zero data loss in case of faults, SAP 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. ConceptualStorageLayout 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). 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. © 2015 SAP SE page 4/21 / (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