Reuse Secondary Hardware for Non-Productive SAP HANA Systems with SAP HANA System Replication

[Rohit-Sharma]

In this Article, I am going to explain how we can use Secondary SAP HANA hardware for SAP HANA Non-Productive systems to reduce TCO IT infrastructure.

Let's take an example of SAP HANA productive landscape along with multi-target SAP HANA HA and DR replication setup with 3 nodes.

Here DC1 and DC2 are having High availability setup with replication mode "SYNC" and DC1 and DC3 are having Disaster Recovery setup with replication mode "ASYNC".

In this article ,we'll see how hardware in DC3 can be reused for SAP HANA non-productive systems (in below example ) e.g. if we use hardware in DC3 to operate Non-Productive system then there will no need of separate hardware requirement for Non-Productive system and will be good saving for customer.

HANA 3-tier Replication Setup

When planning to run other systems (SAP HANA Non-Productive or Sandbox Systems) on the secondary system, you need to consider following points:

• The available hardware resources


• The table preload option (preload_column_tables)


• The memory (global_allocation_limit) needed by the secondary system.


• To save memory resources, switch off the preload of tables on the secondary system using global.ini/ [system_replication]-> preload_column_tables=false.


• HANA System Replication requires memory on the secondary instance, even if pre-load is off.

Sizing Guideline to determine Memory needed for the SAP HANA Secondary System with Pre-load ( ON or OFF) options:

The table below describes requirements for each combination of table preload and operation mode:

Operation mode	Load option	Memory needed for the secondary system (global_allocation_limit)
delta_datashipping	Pre-load on	Set the global_allocation_limit to the same value as the memory available on the primary system.
	Pre-load off	minimum 64 GB   or
		(row store size + 20 GB (if this sum is higher)  --> Please refer below section to determine row store size.
Logreplay	Pre-load on	Set GAL to the same value as on the primary
	Pre-load off	size of loaded column tables (in-memory) + row store size +  50 GB -->Please refer below section to determine row store size & loaded column tables (in-memory)
Logreplay_readaccess (HANA 2.0)	Pre-load on	Set the global_allocation_limit to the same value as the memory available on the primary system.
	Pre-load off	Set the global_allocation_limit to the same value as the memory available on the primary system.

Determine row store size : Kindly use following SQL statement to measure row store size .

select host, round (sum(page_size*USED_BLOCK_COUNT)/1024/1024/1024,2) as
"RowStore Size GB" from m_data_volume_page_statistics where page_sizeclass
= '16k-RowStore' group by host;

Determine loaded column tables (in-memory)  : Kindly use following SQL statement to measure loaded column tables (in-memory).

select host, round(sum(memory_size_in_total)/1024/1024/1024) size_GB from m_cs_tables group by host;

 

High Level Steps to enable Secondary SAP HANA Hardware ( DC3) for Non-Productive SAP HANA systems : Please proceed as below:

1. Switch off the preload of tables on the secondary system using global.ini/ [system_replication]-> preload_column_tables=false. It'll save memory requirement to operate DC3 secondary.


2. Calculate Memory needed for the secondary system based upon above table conditions. It'll depend upon each combination of table preload and operation mode which you are using in your replication setup after that set global allocation limit accordingly for DC3 secondary.


3. All resources that are not needed by the secondary system can be used to run further systems ( non-productive ) on the secondary. These resources must be allocated by explicitly setting the global allocation limit.


4. Additional deployments (non-productive systems) on HA/DR server requires additional storage space for log and data volumes for these systems.

Important Consideration :

• If the row store size of the primary system grows during operation, it might become necessary to increase the global_allocation_limit on the secondary system ,will suggest to consider row store tables growth projection matching to projected hardware life.


• RTO and RPO in case of disaster depend on: Network round trip time to DC 3, network bandwidth and if other systems are running on the DR servers .


• If we are running other systems on the DR servers then The takeover process will take longer as no data is preloaded to memory on the secondary system. It'll impact RTO and RPO in case of disaster.


• Logrelay_readaccess requires additional CPU capacity for read access.


• See SAP Note 1999880 for a detailed description on how HANA statistics collected on the Primary HANA instance can help to estimate memory requirements for the Secondary instance.

Important Reference :

You can refer following note and standard SAP HANA replication guide for more details:

• https://help.sap.com/viewer/4e9b18c116aa42fc84c7dbfd02111aba/2.0.05/en-US/afac7100bc6d47729ae8eae32d...


• SAP Note: 1999880 - FAQ: SAP HANA System Replication & 1681092 - Multiple SAP HANA systems (SIDs) on the same underlying server(s)

 

Hope this article will help you to understand how you can use Secondary Hardware for Non-Productive systems to reduce total cost of infrastructure also important considerations & sizing guidelines to achieve this particular use case.

Kindly share feedback or thoughts in a comment or ask questions if any.