Deployment Models: Scale-Up vs. Scale-Out & Hardware Architecture

Comprehensive analysis of SAP HANA physical deployment architectures, comparing single-node multi-socket Scale-Up with multi-node clustered Scale-Out topologies, TDI vs Appliance, and S/4HANA vs BW sizing restrictions.

IntermediateFundamentals~12 min studyHANA 2.0 (All SPS)

Core Learning Objectives

  • 1.Compare Scale-Up and Scale-Out architectures, use cases, and limitations.
  • 2.Understand the SAP certified hardware appliance model versus Tailored Datacenter Integration (TDI).
  • 3.Learn SAP sizing restrictions (e.g. S/4HANA Business Suite scale-up mandates vs BW multi-node scale-out).
  • 4.Analyze inter-node interconnect requirements (10GbE / 40GbE / InfiniBand).
Prerequisites:hana-fundamentals-overview

Definition & Architectural Rationale

Technical Definition:

Scale-Up (Vertical Scaling) adds more CPUs, sockets, and RAM to a single physical server chassis. Scale-Out (Horizontal Scaling) distributes the database across multiple physical worker nodes connected by a low-latency interconnect with shared or distributed storage.

Why this component exists:

Very large database landscapes (e.g. SAP BW/4HANA enterprise warehouses exceeding 20-50 TB) surpass the RAM capacity of standard enterprise servers. Understanding the operational and architectural trade-offs between Scale-Up and Scale-Out is crucial for system design and high availability.

Internal Working & Mechanics

1. Scale-Up Architecture: - All services (nameserver, indexserver, compileserver) execute on a single physical host with multi-socket NUMA architecture (e.g., 4-socket or 8-socket Intel Xeon / IBM Power systems with 3 TB to 24 TB RAM). - Zero network overhead for cross-table joins; all memory pointers are local. - SAP S/4HANA (OLTP / ERP) is strongly recommended and traditionally required by SAP PAM to be deployed on Scale-Up systems to avoid distributed lock overhead. 2. Scale-Out Architecture: - Composed of: 1 Master Host (Active Name Server + Index Server), multiple Worker Hosts (Index Servers holding partitioned table slices), and optional Standby Hosts (N+M High Availability). - Inter-Node Communication: High-speed low-latency network (InfiniBand or 40/100 GbE) is mandatory. Cross-node queries require intermediate result set shipping across nodes. - Common for SAP BW, BW/4HANA, and massive Big Data analytical repositories. - Requires Table Distribution & Hash/Range Partitioning across worker nodes.

Architecture Flow Diagram

Mermaid DiagramDeployment Models: Scale-Up vs. Scale-Out & Hardware Architecture
Architectural Flow: Scale-Up hosts the entire database inside one massive hardware chassis without network transit. Scale-Out splits tables across multiple worker nodes coordinated by the Master Name Server, with standby nodes providing automated host auto-failover.

Production SQL Diagnostics

Inspect Scale-Out Topology, Host Roles, and Failover GroupSafe (Read-Only)

Displays all physical hosts in the cluster, active roles (worker/standby), and cluster status.

SystemDB
Privileges: CATALOG READ
Target Engine: HANA 2.0 (All SPS)
SELECT HOST, PORT, SERVICE_NAME, PROCESS_ID, COORDINATOR_TYPE, SQL_PORT FROM SYS.M_SERVICES WHERE SERVICE_NAME IN ('nameserver', 'indexserver') ORDER BY HOST, SERVICE_NAME;

Key Diagnostic Columns

HOST:Hostname of the node
COORDINATOR_TYPE:MASTER, SLAVE, or STANDBY
SERVICE_NAME:Running process role

Expected Diagnostic Output

HOST     | PORT  | SERVICE_NAME | PROCESS_ID | COORDINATOR_TYPE | SQL_PORT
--------------------------------------------------------------------------
hana01   | 30001 | nameserver   | 18450      | MASTER           | 0
hana01   | 30003 | indexserver  | 18510      | MASTER           | 30015
hana02   | 30003 | indexserver  | 14102      | SLAVE            | 30015
hana03   | 30003 | indexserver  | 12050      | STANDBY          | 0
DBA Interpretation: hana01 is the active Master Coordinator, hana02 is an active Worker (Slave) holding data partitions, and hana03 is an idle Standby host configured for automatic host failover.
Next Diagnostic Action: Check M_LANDSCAPE_HOST_CONFIGURATION to ensure all hosts have INDEXSERVER_ACTUAL_ROLE matching ASSIGNED_ROLE.

Production Best Practices & Operational Risks

Mandatory Best Practices

  • Always keep S/4HANA production systems on Scale-Up unless explicit SAP architecture exemption is granted.
  • For Scale-Out, ensure storage is configured with STONITH (Shoot The Other Node In The Head) fencing to prevent split-brain filesystem corruption during host failover.

Senior DBA Interview Mastery

3–5 Year Experience Target

Official Documentation & SAP Notes

SAP HANA TDI FAQ Overview

DBA Study Notes & Lab Observations