HANA on … you decide

Picture of Matt Lovell
Posted by Matt Lovell

Then and Now:

In 2011, Centiq started deploying HANA solutions from a single hardware vendor, with only 4 different models, 1 supported OS and only one deployment option, Scale Up. Today, there are 1, 386 certified appliances, 38 certified IaaS Platforms, 2 supported Operating Systems and more than 12,000 deployment options.

Starting Out:

A successful HANA deployment depends on understanding the following:

  • HANA’s constraints
  • Your production sizing
  • Your landscape
  • Your SLA’s and security policy requirements
  • Your platform preference
HANA Constraints:
  • Only Linux – Only SLES and RHEL
  • Only certain Intel Xeon and IBM Power CPUs
  • Only certified platforms (Hardware & IaaS)
  • Struct CPU to memory ratios
  • Strict firmware/OS/Driver/Software versions enforcement
Starting the design:

The sizing will instruct the design on the size of the HANA systems being used. The landscape instructs the design what environments are required. The SLA requirements instruct the design’s high availability, disaster recovery and backup features. The security requirements instruct the design on how the systems should be configured. The platform preference informs the design of the desired platform.


The memory requirement is usually at least double the compressed data footprint in HANA. It’s better to grow in to a memory footprint over time than with a snug fit. Very large systems may be restricted to particular hardware vendors or cloud platforms. The size may drive the decision on the platform away from the customer preference.


The landscape requirements are mapped to design. Mapping of landscapes will depend on the target platform. Public cloud and other virtualized should target 1:1 HANA DB per OS. Physical infrastructure systems may deploy MCOS or MDC to reduce cost.

Uptime SLA:

Over 99% will require the HANA service to be highly available. HA for scale up is usually provided by host-level clustering. HANA’s native HA is usually used for scale-out. Introducing HA will have a profound effect on the landscape.

Disaster Recovery:

DR is not necessarily replication. But if low RPO and RTO are required, replication may be necessary. Longer RPO’s and RTO’s could be serviced by a database restore.

Security Policy:

Your security requirements may require additional infrastructure, services or both. HANA supports encryptions of data and log volumes, backups, backend traffic and client traffic, which all need to be specifically configured. HANA’s auditing can be shipped directly to remote syslog servers. If remote auditing is required but no secure syslog service is available, it should be added to the design.

How to deploy HANA successfully:
  • Get a good sizing
  • Understand HANA, its benefits and its constraints
  • Deploy on a platform that fulfills the requirements, don’t choose the platform first!
  • Get a good design
  • Test, monitor and audit before, during and after installation