Hana scale out to scale up migration (2024)

Introduction:

SAP HANA Migration from scale-out to Scale-up architecture, Supported from SAP HANA Database Revision 80 (Support Package Stack SPS08).

Based on customer requirements opt for SAP HANA hardware architecture.

This provides fantastic flexibility – as a customer you can choose the vendor, storage, networking of your choice, and for non-production scenarios, it is possible to build systems that are much more cost-effective. The most important thing though is to get your production hardware correctly provisioned: it can be expensive.

DISCLAIMER

The content of this blog post is provided “AS IS”. This information could contain technical inaccuracies, typographical errors, and out-of-date information. This document may be updated or changed without notice at any time. Use of the information is therefore at your own risk. In no event shall SAP be liable for special, indirect, incidental, or consequential damages resulting from or related to the use of this document.

Overview

The first thing to remember is that HANA systems require a CPU to RAM ratio, which is fixed for production systems, at 256GB/socket for analytic use cases, and 768GB/socket for SAP Business Suite.

Infrastructure preparation: -

A list of all certified and supported hardware can be found in the SAP HANA Hardware Directory athttps://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/index.html

All HWCCT tests of appliances (compute servers) certified with scenarioHANA-HWC-APSU 1.0 or HANA-HWC-APRH 1.0 must use HWCCTofSAP HANA SPS08 or SAP HANA SPS09 or a related SAP HANA revision

All HWCCT tests of appliances (compute servers) certified with scenario HANA-HWC-APSU 1.1 or HANA-HWC-APRH 1.1 must use HWCCTof SAP HANA SPS10 orhigher or a related SAP HANA revision

Setup all Suse Linux parameters based on the below SAP note, make sure to setup parameters based on your hardware details.

2205917 - SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12

Migration strategy and planning

As we are migrating HANA on BW or Business Suite on HANA, need to plan environment support during migration.

Here we always prefer to minimum impact on the current change management strategy, that’s why using a progressive system migration strategy.

Always using alias names for system build instead of a physical name, in this way we have achieved two goals one is safeguarding systems from vulnerabilities and second repointing virtual name DNS to migrated system minimize the impact no interface system and end-users.

Planning: -

• Migration of HANA DB from scale-out to scale-up architecture using Backup & Restore method


• Create the same topology in target DB


• The system built & Migration approach as below
  
  
  
  • Dev à QAS à PPD à PRD
  
  
  
  


• SAP application HA/cluster set up for PPD and PRD system


• SAP DR set up for HANA DB using HSR


• HANA DB HA build on SUSE Linux Enterprise Server pacemaker clusters

Implantation Steps:

Build new landscape with current systems alias name in an isolated environment, BW on HANA or NW on HANA system always migrate by restore mythology instead of SWPM because SWPM is not taking care HANA specific functionality like HANA views, SDA and external configuration.

• Install the target system, the target SAP HANA Database can be of the same or higher revision compared to the source.


• Perform a backup of source SAP HANA Database (Multi-Node)


• Make sure that the statistics server on the target is the same as that of the source either stand-alone or embedded.


• Create the same topology in target HANA DB (Single Hana Box)

Created below table to compare topology difference between source and target,

services that have persistence data only need to create in a target.

Check persistence data by SQL or HANA studio.

SQL command:- SELECT*FROMM_VOLUMES

After comparing with the source system, it is evident that we would need to create additional 2 indexserver, 1 xsengine on the single-node target system.

Create additional index servers by below command:

ALTER SYSTEM ALTERCONFIGURATION('daemon.ini','host',’<hostname>’)SET('indexserver.c','instanceids')='<n>[,<n>+2]' WITH RECONFIGURE

EX :- ALTER SYSTEM ALTER CONFIGURATION ('daemon.ini', 'host', '<DB hostname>') SET('indexserver.c','instanceids') = '40,42' WITH RECONFIGURE;

Create additional XS by below command: -

ALTER SYSTEM ALTERCONFIGURATION('daemon.ini','host',’<hostname>’)SET('xsengine.c','instanceids')='<n>[,<n>+2]' WITH RECONFIGURE

EX:- ALTER SYSTEM ALTER CONFIGURATION ('daemon.ini', 'host', '<DB hostname>') SET('xsengine.c','instanceids') = '44' WITH RECONFIGURE;

Once source and target system services match start retore target DB by source backup.

• Copy the backup files from source system (multi-node) to the target system (single-node)


• Perform recovery using the backup files from the source

Points to Note before starting the recovery:

• 
  
  
  
  • Move or delete available data backups and log backups from the target system.
  
  
  • Select Initialize log area.
  
  
  
  

Once DB recovery completed on target take a full backup and verify the backup catalog.

Post-migration steps

Need to delete all additional services from the target and before deletion performs reorg and data move.

• Mark the indexserver to be removed:
  
  
  
  • callSYS.UPDATE_LANDSCAPE_CONFIGURATION('SET REMOVE','<hostname:port>');
  
  
  
  

In this example,callSYS.UPDATE_LANDSCAPE_CONFIGURATION('SET REMOVE','<DB hostname>:30040')

• Generate the plan for removing the indexserver:
  
  
  
  • callREORG_GENERATE(2,'')
  
  
  
  


• Execute the generated plan:
  
  
  
  • callREORG_EXECUTE(?)
  
  
  
  

Validate data consistency and repoint application to new migrated HANA DB.

backup:-

1. Once the backup team confirms the installation of backing agent, we need to create one soft link as shown below

2.A user needs to be created which needs to have below mentioned roles

1. 
   
   
   
   1. Command:
   
   
   
   

CREATE USER COMMVAULT_USER PASSWORD <SET_YOUR_PASSWORD> NO FORCE_FIRST_PASSWORD_CHANGE;

GRANT BACKUP ADMIN, CATALOG READ, INIFILE ADMIN TO COMMVAULT_USER;

3. In HANA Studio backup catalog setting to be maintained as shown below:

4. Parameter to be configured as below

DR :-

Use below SAP NOTES for HANA DR setup.

Reference Documents: -

1943937 - Hardware Configuration Check Tool - Central Note

1944799 - SAP HANA Guidelines for SLES Operating System Installation

2093572 - SAP HANA Migration from Multi-Node to Single-Node

https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/index.html

2205917 - SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12

Cheers!

Anikesh Jyotishi