SAP HANA Sizing

The concept of T-shirt sizes for SAP HANA

SAP defined so-called T-shirt sizes for SAP HANA to both simplify the sizing and to limit the number of hardware configurations to support, thus reducing complexity. SAP’s hardware partners provide configurations for SAP HANA according to one or more of these T-shirt sizes. Table 3-1 lists the T-shirt sizes for SAP HANA.

 In addition to the T-shirt sizes listed in Table 3-1, you might come across the T-shirt size XL, which denotes a scale-out configuration for SAP HANA.

The T-shirt sizes S+ and M+ denote upgradable versions of the S and M sizes:

§  S+ delivers capacity equivalent to S, but the hardware is upgradable to an M size.

§  M+ delivers capacity equivalent to M, but the hardware is upgradable to an L size.

These T-shirt sizes are used when relevant growth of the data size is expected.

Sizing approach

The sizing of SAP HANA depends on the scenario in which SAP HANA is used. We discuss these scenarios here:

§  SAP HANA in a side-car data mart approach, used for business intelligence or new applications

§  SAP HANA as the database for a SAP NetWeaver Business Warehouse 7.30 SP5, as described in 3.3.2, “SAP HANA as a database for SAP NetWeaver BW”

The sizing methodology for SAP HANA is described in detail in SAP Note 15149663 (SAP HANA in a side-car approach) and SAP Note 1637145 (SAP HANA as the database for SAP BW). The the following sections provide a brief overview of sizing for SAP HANA in a sidecar approach.

Sizing the RAM needed

Sizing an SAP HANA system is mainly based on the amount of data to be loaded into the SAP HANA database, because this determines the amount of main memory (or RAM) needed in an SAP HANA system. To size the RAM, the following steps have to be performed:

1. Determine the information that has to be transferred (either by replication or extraction) to the SAP HANA database. Note that typically customers will only select a sub-set of information from their ERP or CRM database, so this has to be done at the table level. The sizing methodology is based on uncompressed source data size, so in case compression is used in the source database, this has to be taken into account as well. The information required for this step can be acquired with database tools. SAP Note 1514966 contains a script supporting this process for several database systems, for example, DB2 LUW and Oracle. The current size of all the tables (without DB indexes) storing the required information in the source database is denoted as A.

2. Although the compression ratio achieved by SAP HANA can vary depending on the data distribution, a working assumption is that, in general, a compression factor of 7 can

be achieved:

B = ( A / 7 )

B is the amount of RAM required to store the data in the SAP HANA database.

3. Only 50% of the total RAM should be used for the in-memory database. The other 50% is needed for temporary objects (for example, intermediate results), the operating system, and application code:

C = B * 2

C is the total amount of RAM required.

The total amount of RAM should be rounded up to the next T-shirt configuration size, table above.

Sizing the disks

The capacity of the disks is based on the total amount of RAM. As described in 2.1.2, “Data persistence” on page 9, there are two types of storage in SAP HANA:

§   Diskpersistence

The persistence layer writes snapshots of the database in HANA to disk in regular intervals. These are usually written to an array of SAS drives4. The capacity for this storage is calculated based on the total amount of RAM:

Diskpersistence = 4 * C

§   Disklog

This contains the database logs, written to flash technology storage devices, that is, SSDs or PCIe Flash adapters. The capacity for this storage is calculated based on the total amount of RAM:

Disklog = 1 * C

The certified hardware configurations already take these rules into account, so there is no need to perform this disk sizing. However, we still include it here for your understanding.

Sizing the CPUs

A CPU sizing only has to be performed in addition to the memory sizing if a massive amount of users working on a relatively small amount of data is expected. Choose the T-shirt configuration size that satisfies both the memory and CPU requirements.

The CPU sizing is user-based. The SAP HANA system has to support 300 SAPS for each concurrently active user. The servers used for the IBM Systems Solution for SAP HANA support about 60 - 65 concurrently active users per CPU, depending on the server model.

Selecting a T-shirt size

According to the sizing results, select a SAP HANA T-shirt size that satisfies the sizing requirements in terms of main memory, and possibly CPU capabilities. For example, a sizing result of 400 GB for the main memory (C) suggests a T-shirt size of M.

The sizing methodology described above is valid for SAP HANA in a side-car approach. Other use cases might require another sizing methodology, for example, for SAP HANA as the database for an SAP BW system. Also, SAP HANA is constantly being optimized, which might affect the sizing methodology. Consult SAP documentation regarding other use cases and up-to-date sizing information.

In addition to the sizing methodologies described in SAP Notes, SAP provides sizing support for SAP HANA in SAP Quick Sizer. SAP Quick Sizer is an online sizing tool that supports most of the SAP solutions available. For SAP HANA it supports sizing for these:

Ø  Standalone SAP HANA system, implementing the sizing algorithms described in SAP Note 1514966 (which we described above)

Ø  SAP HANA as the database for a SAP BW system, implementing the sizing algorithms described in SAP Note 1637145

Ø  Special sizing support for the SAP HANA Rapid Deployment solutions

Ø   

The SAP Quick Sizer is accessible online at: http://service.sap.com/quicksizer5

Note: The sizing approach described here is simplified and can only provide a rough idea of the sizing process for the actual sizing for SAP HANA. Consult the SAP sizing documentation for SAP HANA when performing

SAP HANA software licensing

As described in 3.2, “SAP HANA delivery model” on page 17, SAP HANA has an appliance-like delivery model. However, while the hardware partners deliver the infrastructure, including operating system and middleware, the license for the SAP HANA software has to be obtained directly from SAP. Figure 3-8 shows an overview over the licensing structure.

 
 The SAP HANA software is available in these editions:

Ø  SAP HANA platform edition

This is the basic edition containing the software stack needed to use SAP HANA as a database, including the SAP HANA database, SAP HANA Studio for data modeling and administration, the SAP HANA clients, and software infrastructure components. The software stack comes with the hardware provided by the hardware partners, whereas the license has to be obtained from SAP.

Ø  SAP HANA enterprise edition

The SAP HANA enterprise edition extends the SAP HANA platform edition with the software licenses needed for SAP LT replication or ETL-based replication.

Ø  SAP HANA extended enterprise edition

SAP HANA extended enterprise edition extends the SAP HANA platform edition with the software licenses needed for log-based replication with the Sybase Replication server.

As above figure suggests, additional licenses for SAP BusinesObjects BI tools might be needed

to get a complete SAP HANA-based solution.

The SAP HANA licenses are based on the amount of main memory for SAP HANA. The smallest licensable memory size is 64 GB, increasing in steps of 64 GB. The hardware might provide up to double the amount of main memory than licensed.