Preparing Your Technical Landscape

for an SAP HANA Installation

Dr. Bjarne Berg

COMERIT
Copyright 2014
Wellesley Information Services, Inc.
All rights reserved.

In This Session
This session examines, in detail:

The most critical sizing, integration and performance factors you

must address when adopting SAP HANA.

Trends amongst hardware vendors for virtualization, cloud, and

hosted systems, including options, requirements, and costs
associated with network, backup, and application servers

How the SAP HANA database uses persistent storage to provide

a fallback, and how fault tolerance, disaster recovery, and highavailability can be setup for your SAP HANA implementation
2

What Well Cover

Hardware Sizing, Planning, and The Cloud

Top 10 Lessons Learned from SAP HANA Implementations
Landscape Deployment Planning
Backup
High Availability
Wrap-up

Hardware Options 2014 Onward

Example: IBM 3850 X6

Hardware Options 2014 Onward

These systems are based on Intel's E7 IvyBridge processors with
15 cores per processor (the old had only 10).

UPDATE: Hitachi Servers and Dell (R920) are now also available

Cloud Options 2014 Onward

Support Packages

As of 2014, SAP introduced the idea of production verified revisions to provide indepth testing of all service packs for SAP HANA

Based on the planned releases over the next 24 months, customers should adjust their
plans for service packs accordingly
8

Sizing Overview
Depending on the software components there are several sizing
options:
BW system for HANA

1.

BusinessSuite System for HANA

2.
.
.
.

3.

QuickSizer New implementation only, not migrations

BW Automated Sizing tool in the Migration Cockpit
Rule of Thumb
T-Shirt Sizing

QuickSizer for BusinessSuite on HANA

Automated Sizing tool
Vendor Tools

Standalone HANA System

SAP QuickSizer for HANA

There are three versions of the tool for each version of SAP HANA
The QuickSizer for the
Business Suite allows you to
size for specific modules

The second
QuickSizer version
is for SAP HANA
on SAP NetWeaver
BW

The last is for those who want

to use SAP HANA as a
standalone platform for inmemory data (i.e., using SAP
Data Services to load data to)

SAPs QuickSizer for SAP HANA is available at

http://service.sap.com/quicksizer.

10

SAP QuickSizer for New BW HANA Implementations

If youre using planning in
SAP NetWeaver BW, enter
the info here. The fields
marked with * are mandatory.
For H-PLAN-1, enter the
maximum concurrent users
in the USERS field. The S.T.
and E.T. fields are the start
and end times for the
processing.

Enter the estimated number of information consumers (H-BWINFO), business users (H-BW-BUSI.), and experts (H-BW-EXPER).
SAP suggests a ratio of 71%, 26%, and 3% for each user group,
but you can enter your own mix if you have better estimates.

By entering this type of

information, youll get
estimates of loads on the
SAP HANA system by time
periods at the end of the
sizing exercise.
11

SAP QuickSizer for New BW HANA Implementations (cont.)

Enter the InfoCube and DSO
information. The max number
of dimensions (DIM) you can
enter for the InfoCube is 13.
The three fixed dimensions of
BW are already included, so
just enter the free dimensions.
The field KEYF. refers to the
number of key figures in the
fact table of your InfoCube,
while the field COM. is the
estimated compression.

In the INITIAL LOAD field, you enter the number of records in

the existing InfoCube, and in the PERIOD. UPLD field, you enter
the number of records you estimate will be loaded periodically.

If you dont have better

estimates, a rate of 5 may
serve for the initial sizing
before you refine the
estimates with your hardware
vendor.
12

SAP QuickSizer for HANA Output

This SAP HANA

sizing example
calls for 1.6TB of
memory.

In this case, SAP HANA for BW will deploy the master data, ABAP
system tables, and row store data on the master node. The other
connected server node(s) will contain the InfoCubes and DSOs.

13

HANA Sizing Tool for Existing BW Implementations

To increase speed, you can suppress
analysis tables with less than 1 MB size.

SAP has released an updated tool that

generates a report significantly better for
sizing SAP BW than using the QuickSizer. This
tool should be used by all existing BW
implementations for sizing (QuickSizer is only
for new implementations).
This program takes into consideration existing
database, table types, and includes the effects
of non-active data on the HANA system.

The higher precision you run the estimate

at, the longer the program is going to run.

With 12 parallel processors and 10TB database,

it is not unusual to see 30-70 minutes runtime

14

SAP BW on HANA Automated Sizing Tool

Since timeouts are common when
running the sizing program, you can
temporarily change the parameter in
rdisp/max_wprun_time to 0 in BW
transaction RZ11. Finally, you estimate
the growth for the system as a
percentage, or as absolute growth.
The output is stored in the file you
specified and the file can now be
emailed to hardware vendors for sizing
input and hardware selection.

This program is referenced in SAP Notes 1909597 and 1736976 on the Service Marketplace15

Sizing for BusinessSuite on HANA

SAP has created a program for sizing HANA for BusinessSuite:

This should be used for all

HANA migration projects of
ERP/ECC/BusinessSuite

16

Sizing for BusinessSuite on HANA

Some Vendors have also created their own sizing programs, that also include
hardware prices.

17

QuickSizer for BusinessSuite on HANA

For New BusinessSuite implementations you can use QuickSizer

and send the results to SAP for further processing

18

QuickSizer for BusinessSuite on HANA

This is the input screen where you
enter the number of expected
transaction by module. You are also
asked to enter estimated changes
and new records as well as operating
times of your system

Here you get the size in SAPS as well

as memory and disk requirements

19

Sizing a Standalone HANA System - Output

This is the input screen

Here you get the size in

SAPS as well as
memory and disk
requirements
20

Rule-of-Thumb Approach to Sizing HANA Memory

Memory can be estimated by taking the current system size and running the
programs in get_size.zip in SAP Note 1637145 to get row and column store sizes
for your system

Memory = 50GB +
[ (rowstore tables footprint / 1.5) +
(colstore tables footprint * 2 / 4) ] * Existing DB Compression

The 50GB is for HANA services and caches. The 1.5 is the compression expected
for rowstore tables and the 4 is the compression expected for column store tables.
The 2-factor refers to the space needed for runtime objects and temporary result
sets in HANA. Finally, the term existing DB compression is to account for any
compression already done in your system (if any).

Remember, these are quick rules of thumb, so dont rely

on it for finalized budgeting and hardware purchases

21

Rule-of-Thumb Approach to Sizing HANA Disk

The next item you need is disk space, which can be estimated by the
following:
Disk for persistence layer = 4 Memory
Disk for the log = 1 Memory

In this example, you need 4 x 710GB disk for the persistence layer
and about 710GB for the logs. This equals around 3.5TB (dont worry,
disk space of this size is now almost cheap).

The persistence layer is the disk that keeps the system secure and
provides for redundancy if there are any memory failures, so its
important not to underestimate this.
Remember, these are quick rules of thumb, so dont rely
on it for finalized budgeting and hardware purchases

22

Rule-of-Thumb Approach to Sizing HANA CPU

The CPUs are based on the number of cores that you include.
For example, 10 core CPUs now exist (depending on when you
bought your system).
CPU = 0.2 CPU cores per active user

If you have a single node with 4 x 10 cores, you will have 40

cores and can handle 200 active users on that hardware node,
and quite a larger number of named users.

Remember, these are quick rules of thumb, so dont rely

on it for finalized budgeting and hardware purchases

23

A T-Shirt Model for Sizing HANA on BW

A T-shirt model is a quick
way to get some basic ideas
on what a system may look
like
While very inaccurate for
sizing, it provides basic
information for those just
starting to consider SAP
HANA

The number of processors are largely driven by the number of users and usage
patterns. Serious consideration should be made before buying hardware.
24

Summary of HANA Sizing Approaches

Approach

Quality of Estimate

Effort Required

T-Shirt Sizing
Sort of OK
Very Low
Rule of Thumb
Better
Low
SAP QuickSizer
Much better (new implementations only) High
Sizing for programs Excellent (for existing BW systems) Moderate/Low

Work with your preferred vendor before ordering your hardware or

finalizing your budgets
SAP Note 1736976 (ABAP report to help with BW on HANA Sizing)
SAP Note 1909597 (SAP NetWeaver BW Migration Cockpit for SAP HANA)
SAP Note 1729988 (SAP BW Checklist for Migration),
SAP Note 11855041 (Sizing the Master node)
25

What Well Cover

Hardware Sizing, Planning, and The Cloud

Top 10 Lessons Learned from SAP HANA Implementations
Landscape Deployment Planning
Backup
High Availability
Wrap-up

26

1. Lessons Learned: Buy Hardware Early

1.

The typical lead time for the basic HANA

appliances is as little as 4-8 weeks

2.

However, for large scale environments, or multinode environments, the lead times can sometimes
be as long as 10-14 weeks

3.

This is particularly true for virtualized systems

managed by a third-party who has to set them up,
configure backup, and learn the new technology
Get a small team on site early for planning, budgeting, and
sizing; and hold off staffing all team members from the
business until you get a confirmed hardware delivery date
27

2. Lessons Learned: Get the Right Team Members

1.

While there are many with basic certifications in

HANA, the pool of qualified experienced resources
is limited

2.

Great HANA resources are most likely working on

another project already

3.

So, if you want the best, be prepared to give your

implementation partner several weeks lead time
Do you want who is available or who should be
available on your project? Be prepared to give your
implementation partner longer lead times than usual.
28

3. Lessons Learned: Include Training for your Staff

1.

There are a lot of myths and beliefs about HANA

that you have to address early

2.

Before you start the project, make sure your

implementation partner has a formal written training
plan on how they will provide knowledge transfer

3.

Include your support staff and Basis people in all

project discussions from the first planning session
Many are fearful of a new technology and are unsure how this will change their
work. You should provide real demos and workshops early so that everyone
knows what is happening and how HANA will change their day-to-day jobs.
29

4. Lessons Learned: Hardware Sizing Should Include Growth

1.

Some customers forget that sizing would be for 3

years out and not based on current system size
alone

2.

You should have a sizing estimate that includes new

projects, data growth, and data retention policies, as
well as periodic scheduled clean up activities

Funding for hardware is sometimes easier in a project mode,

and many companies plan for 30-50% more capacity as part
of the initial rollout if they can afford it

30

5. Lessons Learned: Master-Node Size

1.

Some hardware vendors want to maximize the number

of processes available to the users. They can do this
by using multiple smaller nodes with many processors
in each.

2.

The drawback is that all of your row and master data

stores may not fit on the small node as you grow.

Pay very careful attention to the row-stores sizes and the

master data growth when buying hardware. You dont
want to have to upgrade shortly after go-live.
31

6. Lessons Learned: Create an Ecosystem of Experts

1.

Having access to the best and brightest within

SAP, consulting firms, and industry experts is
key when issues or questions arise

2.

These people are very busy and are often

engaged on many projects as supporters

Formally assign a team of 2-3 experts to come in and meet with your
team a few times during the project planning and execution. Make sure
these project advisors are hands-on and that they can act as technical
go-to resources for your team if questions arise.

32

7. Lessons Learned: Think BIG

1.

A HANA implementation should not be treated as a

replacement project. It is an enabler

2.

Plan ahead on what you are going to do with the

new technology, e.g., mobile, forecasting,
planning, BI dashboards, customer and vendor
facing analytics, market basket analysis,
stratification, data visualization, etc.

Early in the project create a 2-3 year strategic plan that demonstrates
to the leadership what you are going to do with this new technology.
Present it as new capabilities not just how fast it is
33

8. Lessons Learned: Plan for Reporting and System Consolidation

1.

After go-live you should have planned for how

you are going to migrate all reporting and
management analytics on to HANA and away from
datamarts and standalone expensive systems that are
not integrated into the long-term vision

2.

You will most likely have to do some selling to

your fellow employees and be prepared to give them
free access to your HANA system
HANA is not just for BW or Business Suite. It is an enterprise
platform for integrated analytical and data processing. You can give
developers access to your system and they can build their own Agile
marts inside HANA, even if they dont want to use BW.

34

9. Lessons Learned: Near-Line Storage Can Save Millions

1.

Removing data that is not needed on a daily basis from

your system and placing it on near-line storage instead
of in-memory can save you millions.

2.

In one project a customer took his system from 112TB to

38TB by simply moving data to near-line storage (NLS)

3.

An Asian firm took a 3.8TB BW system to only 900GB

after cleanup and an NLS implementation

There are many NLS solutions available that can save you big bucks by
reducing the need for multi-node, multi-terabyte HANA systems. Take a serious
look at SAP IQ solution for NLS. It is tightly linked with HANA already.
35

10. Lessons Learned: Save Money with MCOD and MCOS

1.

You may not need separate hardware for sandbox and development
environments

2.

Using Multiple Components One Database (MCOD) and/ or Multiple

components One System (MCOS) you can simplify the number of hardware
environments you need
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)

SAP NetWeaver BW on SAP HANA

SAP Finance and Controlling Accelerator for the material ledger
ERP operational reporting with SAP HANA
SAP Finance and Controlling Accelerator: Production Cost Planning
SAP Rapid Marts
SAP COPA Accelerator
SAP Operational Process Intelligence
SAP Cash Forecasting
SAP Application Accelerator / Suite Accelerator
Smart Meter Analytics

In addition to custom developed datamarts, all items above can

run in an MCOD setup (see SAP Note 1666670 for more details)

36

What Well Cover

Hardware Sizing, Planning, and The Cloud

Top 10 Lessons Learned from SAP HANA Implementations
Hardware Trends
Landscape Deployment Planning
Backup
High Availability
Wrap-up

37

Landscape Deployment Planning

Virtualization

MCOS
MCOD
Co-Deployment

Technical

Deployment
Scenario

HANA DBs

Multiple

Multiple

One

One

DB Schema

Multiple

Multiple

Multiple

One

Availability

Supported for
DEV & QA
systems

Supported for
DEV & QA
systems

Defined by:
White List
1661202 for BW
White List
1826100 for Suite

Business Suite
components
SCM and/or
SCM codeployed with
ERP
38

Landscape Deployment Planning - Virtualization (on premise)

Share hardware resources for multiple Suite systems and HANA instances with
virtualization techniques. Virtualization technology separates multiple OS images
each containing one HANA DB.
n x Virtualized Appliances
n x HANA DB
n x DB Schema
n x Applications

Strengths

Only one HANA system needed

Resource mgmt per virtual instance possible (RAM, CPU, Storage)
Easy scalability
Different Server Level Agreements per virtual machine possible
Independent deployment & maintenance per instance (OS, HANA)

Weaknesses
Performance impact
Virtualization overhead

39

Landscape Deployment Planning

One database schema per database

Separate virtual machine and OS
Separate SAP HANA databases per SAP system
Shared hardware and storage
Currently supports VMware vSphere 5.1

Usage Scenarios
Non-production systems
Single-node SAP HANA databases up to 1 TB

See SAP note 1788665.

40

Multiple Components One System (MCOS)

Share hardware for HANA among multiple Suite system to reduce TCO

1 x Appliance
n x HANA DB
n x DB Schema
n x Applications

Strengths
Only one HANA system and one OS required
HANA software can be individually maintained per DB instance
Dedicated memory assignment per instance

Weaknesses
Shared HANA hardware risk of performance issues since no dedicated CPU
assignment per instance
No separate Service Level Agreements on database level

SAP currently does not support MCOS configuration on a production system (note 1681092).

41

Multiple Components One Database (MCOD)

Provides the ability to install several components independently on a single database.

1 x Appliance
1 x HANA DB
n x DB Schema
n x Applications

Strengths
Versatility through components and only one HANA instance necessary
Cross schema reporting supported and separate upgrades possible
Different operating systems and databases
Highest scalability possible

Weaknesses
Maintaining different operating systems and databases
Shared HANA software version and maintenance processes
Risk of performance issues - lack of resource management capabilities
Complex high availability solutions
Synchronizing backup and restore
42

Multiple Components One Database (MCOD)

Multiple database schemas per database

Shared SAP HANA database
Dedicated application servers per application
Shared hardware, OS and storage pool

Usage Scenarios
Non-production systems
Production systems for applications on whitelists and custom data marts
Not multiple BW production systems

See SAP notes:

1661202 HANA MCOD scenario whitelist
1826100 SoH MCOD scenario whitelist
1666670 BW specific considerations

43

Classical Technical Co-Deployment

Appliance approach for optimal performance.
No additional system required and a reduction of operations effort
Cross application reporting possible

1 x Appliance
1 x HANA DB
1 x DB Schema
Strengths 1 x Application (e.g. ERP, CRM, or BW)
Coordinated start-stop functionality
Reduced operation exertion for DB/OS/Backup/Basis
Multiple application servers can be shared
Simplified application landscape setup, deployment, and maintenance
Option to scale out into separate deployment
Reduced TCO on application level

Weaknesses
Restrictive enhancement package dependencies
Application specific middleware (CIF, BDOC) still being used. Not yet available for CRM.

44

Landscape Deployment Planning

Classical Technical Co-Deployment
One SAP HANA database and one database schema
One AS ABAP application server/SID
Available for SRM and SCM as ERP add-on

Usage Scenarios
Production and non-production systems
Can be combined with Virtualization or MCOS

45

What Well Cover

Hardware Sizing, Planning, and The Cloud

Top 10 Lessons Learned from SAP HANA Implementations
Hardware Trends
Landscape Deployment Planning
Backup
High Availability
Wrap-up

46

Backup
Supports synchronous backup between production system and
backup storage
Alerts can be setup to monitor whether backups are being done as
expected
Two primary methods of backing up:
Traditional File
BACKINT API for third party vendors

47

Backup

There are 4 basepath options for traditional file backups in HANA

Basepath data backup Standard backups to external mount point

Basepath data volumes Permanent location for data volumes
Basepath log backup External mount point for logs segment to be copied
Basepath log volumes Permanent location for log volumes

IBM offers a backup management solution

called Tivoli Storage Manager
SAP provides a script in SAP Note 1651055 to
help clean up log files
Many backup features are now automated
including removal of log segments after backup

These basepath options are available in the Configuration tab in HANA Studio

48

Standby Systems and Backup Monitoring

It is possible to keep a warm standby system that is ready to come
online in the event of a failure
Hosts can also be on standby in the event of host issues
HANA includes a service auto-start that restarts any service that may fail
Alerts can be set to monitor
If the backups are being successful
inside the admin console under the
Alerts tab

Standby host can provide

fault-tolerance recovery

49

What Well Cover

Hardware Sizing, Planning, and The Cloud

Top 10 Lessons Learned from SAP HANA Implementations
Hardware Trends
Landscape Deployment Planning
Backup
High Availability
Wrap-up

50

High Availability (HA)

SAP HANA supports HA and recovery measures ranging

from faults and software errors, to disasters that decommission an entire data center

HA can be achieved by eliminating single points of failure (fault tolerance)

Providing the ability to rapidly resume operations after a system outage with minimal
business loss (fault resilience).

The SAP HANA database provides several features in support of high availability, one
of which is service auto-restart

In the event of a failure or an intentional intervention by an administrator that

disables one of the SAP HANA services, the SAP HANA service auto-restart function
automatically detects the failure and restarts the stopped service process
The number of standby servers defined during installation cannot
subsequently be reduced. Standby servers can be added after installation.

51

High Availability
Additional SAP HANA appliances used in standby mode for failover
Capability to assign up to three master servers as the name server (one
is selected as the active server)
Active server assigned master index server
If active master name server fails, the systems restores itself to
available standby master

High Availability is a set of techniques, engineering practices and

design principles for Business Continuity

52

Scale out High Availability

High Availability Configuration
N active servers in one cluster
M standby server(s) in one cluster
Shared file system for all servers

Failover
Server X fails
Server N+1 reads indexes from shared storage and
connects to logical connection of server X

Source: SAP AG 2014

SAP HANA cold standby host

Standby host is kept ready for the event that a

failover situation occurs during production operation
Standby host is not used for database processing
All the database processes run on the standby host,
but they are idle and do not allow SQL connections
Source: SAP AG 2014

53

What Well Cover

Hardware Sizing, Planning, and The Cloud

Top 10 Lessons Learned from SAP HANA Implementations
Hardware Trends
Landscape Deployment Planning
Backup
High Availability
Wrap-up

54

7 Key Points to Take Home

There are programs to do pre-readiness checks for an ERP and BW

system for migration to HANA

A BW Migration Cockpit is now available to assist in the tasks

While one is more common, there are actually four possible approaches
to the HANA migration project

There are currently seven different certified HANA vendors and many
options for small, medium, and large systems Make sure you get a
competitive bid

Budgeting should include HANA training and system cleanup, as well as

support staff required or reorganized

Most HANA projects can be done in a matter of weeks

Only extremely large systems may require 4-7 months

55

Where to Find More Information

https://www.sap-press.com/sap-hana_3687
Dr. Bjarne Berg and Penny Silvia, SAP HANA: An Introduction (3rd
edition) SAP PRESS, 2014).
www.saphana.com/welcome
SAPs main page for all SAP HANA-related information
www.saphana.com/community/try
SAP HANA demos
http://scn.sap.com/community/netweaver-bw-hana
SAP NetWeaver BW Powered by SAP HANA Community

56

Your Turn!

How to contact me:

Dr. Berg
bberg@comerit.com
57

Disclaimer
SAP, R/3, mySAP, mySAP.com, SAP NetWeaver, Duet, PartnerEdge, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product
and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by
SAP.

58