SAP HANA Overview: Deployment Options, Use Cases, Scale‑Up/Scale‑Out, TDI, HA and Architecture

SAP, the world’s largest enterprise‑software vendor, offers a suite of applications such as ERP, SRM and BI, while SAP HANA (High‑Performance Analytic Appliance) is its flagship in‑memory database product.

SAP HANA can be deployed as a pre‑configured appliance or in the cloud, providing a revolutionary platform for real‑time analytics and application development by combining data processing, analytical and business‑logic functions entirely in memory, thus overcoming the latency limits of traditional transactional databases.

Hardware partners collaborate with SAP to deliver certified HANA appliances. Deployment options include cloud‑based services (HANA One, SAP HANA Enterprise Cloud) and on‑premise solutions (HANA appliance, B1A, B1H). The following sections highlight key knowledge points for solution design, deployment and implementation.

Typical SAP HANA application scenarios

Business Warehouse on HANA (BWoH) : OLAP workloads such as BW, BPC, BI and BO, using certified BWoH hardware.

Business Suite on HANA (BoH) / S/4HANA : OLTP workloads covering ECC, SRM, CRM, HRM, EWM, Hybris, etc., using certified SoH hardware.

Common SAP system modules

OLTP modules: SAP Business Suite (ECC, SRM, MDM, PI/PO, CRM, HRM, EWM, Hybris).

OLAP modules: SAP Data Warehouse (BW, BPC, BI, FC).

What are B1, SoH and BWoH?

SAP Business One (B1) is a low‑cost, easy‑to‑implement ERP‑style solution for small‑to‑mid‑size enterprises, typically deployed on a two‑node server where the application and database reside on the same hardware.

SoH (SAP Business Suite on HANA) targets OLTP workloads and runs on 4‑, 8‑, 16‑ or 32‑node configurations, usually as a scale‑up single node.

BWoH (SAP Business Warehouse on HANA) serves OLAP workloads and can be deployed on 4‑ or 8‑node machines; depending on data volume, it may use a scale‑up single node or a scale‑out cluster.

Scale‑Up vs. Scale‑Out

Scale‑Up (vertical scaling) adds CPU, memory, etc., within a single server, offering performance advantages, higher resource utilization and potentially lower cost, but it has limits such as uniform hardware capacity in HA scenarios and lower total capacity compared to multi‑node setups.

Scale‑Out (horizontal scaling) distributes the database across multiple nodes, providing strong horizontal scalability for large data volumes, automatic data distribution for SAP NetWeaver BW, and multi‑node fail‑over capabilities, but it incurs network overhead, performance penalties for cross‑node queries, and higher infrastructure costs.

How to find hardware vendor solutions

All SAP‑certified hardware configurations are listed on the SAP certification portal; vendors provide standardized, SAP‑approved configurations.

How to verify a configuration is SAP‑certified

Certification details are available on the SAP certification website (links provided in the original article).

What is TDI?

Tailored Data Center Integration (TDI) is a SAP‑proposed model allowing customers to reuse existing certified servers and storage to build a custom HANA architecture, reducing costs while placing performance responsibility on the customer.

Typical TDI hardware consists of a server (or small machine) for compute and separate storage for data, both of which must be SAP‑certified.

Virtualization support

SAP HANA can be deployed on virtualized platforms such as VMware vSphere and Huawei FusionSphere, provided both the hardware and the virtualization layer are SAP‑certified.

Storage sizing in TDI

Storage capacity is calculated based on the physical RAM of each HANA host: Shared volume = RAM × N × 1, Data volume = RAM × N × 2 (where N is the number of hosts). Log volumes for production should use SSDs; SAS disks are acceptable for development/testing.

When to use HANA clustering

Clustering is currently supported only for Business Warehouse scenarios (BWoH); OLTP workloads (e.g., ERP on HANA) do not support clustering.

HANA high‑availability (HA) options

Two primary HA approaches are Host Auto‑Failover (cluster‑based) and System Replication. SAP recommends native System Replication (primary to secondary) as the preferred HA solution; active‑active configurations are not supported.

Node roles in a HANA cluster

Master node : One active node out of three configured masters, acting as the global transaction coordinator and storing cluster metadata.

Slave node : Caches metadata, performs tasks assigned by the master, and can be configured as Worker or Standby.

Standby node : Takes over when a primary node fails; may exist in multiple copies but does not hold active data under normal operation.

Additional resources

For deeper dives into virtualization, high‑performance computing and related technologies, refer to the linked articles and QR‑code resources provided at the end of the original document.