India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP HANA Architecture on Cloud: Scale-Up, Scale-Out, Tenants and NSE
SAP HANA architecture is the set of database-level design choices that decide how HANA uses memory, storage and hosts: scale-up or scale-out, tenant layout, data tiering with Native Storage Extension, restart behaviour and replication topology. NTSPL designs these for S/4HANA and BW/4HANA on cloud so memory, cost and recovery targets hold as data grows.
Delivered on
In scope
Why HANA Design, Not Instance Size, Sets SAP Cloud Cost and Recovery Time
HANA keeps its column store in memory, so every architectural mistake turns into either a bigger instance or a slower restart. A BW system that keeps seven years of sales history hot, an S/4HANA tenant sharing a host with a test tenant, or a scale-out landscape built only because on-prem appliances were limited to 2 TB: each of these drives the next certified instance size, which on cloud can double the monthly bill. Restart time after a host event can stretch to 40 minutes on a large instance if nothing is done about memory loading.
NTSPL designs HANA from table-level evidence. We read M_CS_TABLES and M_SERVICE_MEMORY to see what is hot, warm and never queried, model the effect of Native Storage Extension and archiving on memory, and only then choose scale-up or scale-out and the instance class. Restart behaviour, tenant isolation and HANA system replication operation modes are decided in the same design, so HA and DR teams inherit a database that is built to replicate.
Symptoms That Call for a HANA Architecture Redesign
Signals you need SAP HANA Architecture
- HANA used memory has grown more than 25 percent a year and the next growth step forces a larger certified instance.
- A BW on HANA or BW/4HANA system runs scale-out on four or more nodes because on-prem appliances were memory-limited.
- HANA restart after maintenance takes over 20 minutes and pushes past the agreed patch window.
- Multiple tenants or SIDs share one HANA host and a test workload has slowed production at least once.
- Over 30 percent of column-store memory belongs to tables or partitions not read in the past 12 months.
When to choose something else
- The workload is ECC on Oracle or SQL Server with no HANA move planned; HANA design starts when the target database is decided.
- The issue is slow ABAP reports or poor custom SQL rather than memory or topology; a code and query performance review is the better fit.
- You need cluster and failover build work for an already-designed HANA; that is SAP high availability.
HANA Design Domains Covered in an NTSPL Engagement
Memory profile and growth model
Hot, warm and cold split by table and partition from HANA monitoring views, with a three-year growth model and the instance boundary each scenario hits.
Scale-up versus scale-out
Decision for each HANA database based on memory, BW or S/4 workload type, certified shapes available in the target Indian region and operational complexity.
Data tiering
Native Storage Extension candidates, archiving with SAP ILM or SARA, and partitioning for large tables such as ACDOCA, MATDOC and BW ADSOs.
Tenant and host layout
Which databases share a host, tenant isolation settings and resource limits so non-production cannot starve production.
Restart and replication design
Fast Restart option use, HANA system replication mode and operation mode, and preload settings for secondary sites.
HANA Memory Tiering and Replication Topology for Cloud
HANA Memory Tiering and System Replication Topology
Hot column-store data stays in memory on a certified scale-up host, warm partitions are paged from disk through Native Storage Extension, and cold data is archived out of the database. The primary replicates to a zonal secondary for HA and to an asynchronous tier-three secondary in another Indian region for DR.
Select any component
HANA Memory Tiering and System Replication Topology: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Certified HANA Shapes and Storage on Each Hyperscaler
AWS offers certified scale-up shapes up to very large memory sizes, so NTSPL usually consolidates on-prem scale-out S/4 into scale-up, keeping scale-out only for large BW systems.
On Azure, scale-out HANA typically uses Azure NetApp Files for shared volumes and standby nodes; for scale-up, Premium SSD v2 gives independently sized IOPS and throughput per HANA volume.
Google Cloud's X4 instances extend scale-up to very large memory sizes, which often removes the need for BW scale-out; Hyperdisk lets throughput be tuned per HANA volume.
HANA Design Choices with Thresholds
Scale-up or scale-out
Choose scale-up for S/4HANA whenever a certified shape covers three years of forecast memory with 20 percent headroom; S/4 scale-out adds partitioning and cross-node join cost with little benefit. For BW/4HANA above roughly 6 TB with heavy parallel loading, scale-out on 1+n nodes remains valid. Always check the certified shapes actually offered in the chosen Indian region.
Native Storage Extension adoption
Adopt NSE when warm data exceeds 15 percent of column-store memory and access is mostly range scans on old partitions. Start with the buffer cache at about 10 percent of warm data size and adjust from hit-ratio monitoring. Avoid NSE for tables with frequent random reads such as open items; they belong in memory.
Tenant layout
Put one production tenant per HANA host. Non-production tenants can share a host if each tenant has an explicit allocation limit and CPU affinity where needed. Never place quality and production tenants on the same host: an upgrade test in quality can force an unplanned restart of production.
Replication operation mode
Use logreplay for zonal HA, which keeps the secondary close to current state for takeovers in minutes. Consider logreplay_readaccess when reporting can offload to the secondary and licences allow it. For a DR tier three, async mode avoids slowing commits on the primary; size the network for peak log generation, typically measured during month-end close.
Evidence-Led HANA Design in Five Steps
Memory and table profiling
Collect column-store size, access statistics and growth by table and partition from production HANA or the sizing report.
Tiering and archiving model
Model NSE, partitioning and archiving options with memory savings and functional impact signed off by process owners.
Topology and instance selection
Decide scale-up or scale-out per database, tenant layout and certified instance in the target region.
Restart and replication design
Specify Fast Restart, HSR modes, preload and network bandwidth for replication.
Design validation on a copy
Apply NSE and partitioning on a production-sized copy, measure memory and query response, and adjust before production.
What you receive
HANA Health Measures We Design Against
| KPI | Typical target |
|---|---|
| Peak used memory as share of global allocation limit | Below 80 percent at month-end |
| HANA restart time after planned maintenance | Under 10 minutes with Fast Restart on large instances |
| Memory released by tiering and archiving | Typically 20 to 40 percent of column store |
| NSE buffer cache hit ratio | Above 95 percent |
HANA Design Errors That Cost Memory or Uptime
| Risk | How NTSPL prevents it |
|---|---|
| Tables moved to NSE are still read randomly and queries slow down | NTSPL tests NSE candidates on a production-sized copy with replayed workload before change and keeps a rollback script per table. |
| Archiving is blocked by audit or business requirements late in the project | Retention rules are agreed with the CFO and statutory auditors before modelling savings, including GST and Companies Act record periods. |
| Replication bandwidth is sized on average log rate and lags at month-end | Bandwidth is sized on peak log generation measured during close and verified with a replication lag test before go-live. |
HANA Native Storage Extension or data archiving: which reduces cloud HANA cost more?
Archiving reduces cost more, because archived data leaves HANA entirely and no longer counts toward memory or backup size. But archiving needs functional sign-off, archive objects per process and a way for users to read archived documents, which takes months to agree. NSE is faster to implement and keeps data queryable in HANA, but it still occupies disk and some buffer memory. NTSPL's guidance is to apply NSE first for quick memory relief on old partitions in large tables, then run archiving as a programme for closed fiscal years once retention rules are agreed with finance and auditors.
Key facts: SAP HANA Architecture
SAP HANA Architecture in Practice
2 SAP HANA Architecture scenarios, from Aluminium extrusions and Bearings maker, plus related platform case studies.
Aluminium extruder avoids a HANA instance upgrade by moving 1.1 TB to NSE
Bearings maker consolidates a 4-node BW scale-out into one HANA host
Auto-ancillary maker converts ECC to S/4HANA on AWS inside a 48-hour downtime window
API manufacturer moves a GxP-validated SAP landscape to Azure without re-validation delays
SAP HANA Architecture: Frequently Asked Questions
How much does a HANA architecture engagement cost?
For one S/4HANA and one BW database, effort is usually 20 to 35 consultant-days over five to six weeks. Validation on a production-sized copy adds cloud cost for a few days, which NTSPL schedules to minimize run time.
Do we need scale-out HANA on cloud?
Usually not for S/4HANA. Cloud providers offer certified scale-up shapes far larger than most Indian S/4 databases, so scale-up is simpler. Scale-out stays relevant for large BW/4HANA systems or databases that exceed the largest shape in your chosen region.
Does HANA data stay in India with this design?
Yes. Primary, zonal secondary and DR tier three can all sit in Indian regions, and archives go to object storage in the same regions. That supports DPDP Act 2023 data mapping and keeps evidence simple for RBI, SEBI or IRDAI regulated entities.
Will NSE affect user response times?
For correctly chosen warm data, users rarely notice. Queries on old periods may take slightly longer because pages load from disk. NTSPL tests response times on representative reports before and after the change and only moves tables where impact stays inside agreed limits.
Can BW and S/4HANA share a HANA host?
Technically yes, as separate tenants, but NTSPL does not recommend it for production. BW loads and S/4 transactions peak at different times and compete for memory and CPU. Separate hosts make sizing, patching and replication simpler.
How often should HANA design be revisited?
Review memory profile and tiering quarterly and topology yearly, or after any acquisition, new plant or company-code rollout. Growth that is not reviewed usually appears as a sudden instance upgrade request.