Hana scale out to scale up migration

 

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: –

HP Hardware details: –   (From HP hardware site)
HPE Superdome X with BL920s Gen9 for SAP HANA TDI compute block using Intel E7-88X0v3 architecture for Scale-Up or Scale-Out Configurations
Server	HPE Superdome X for SAP HANA TDI compute block 18U enclosure / 42U HPE 1075 mm shock intelligent rack 4-8 Two socket server blades, each with 2x FlexLOMs slots, 3x mezzanine slots, and up to 48 DIMM slots. Choice to flex the number of DIMMs per blade (16/32/48) to right-size the SAP HANA workload. For scale up, four to eight BL920s Gen9 8 blades that can be configured in 2/4/8/16- socket partitions, in a number of socket permutations that accommodate mixed workloads and multiple IT tiers. For scale out, up to 48 four blade 8 socket partitions are supported for large in memory analytic workloads. HPE nPartitions (nPars) technology offers electrically isolated hard partitions with 1, 2, 3, 4 or 8 nPars possible that can have mixed workloads, chipsets, and sizes.
Processors	A choice of processors are available in 2/4/8/16-socket configurations: Intel Xeon E7-8880 v3 processor (2.3 GHz/18-core/45MB/150 W) Intel Xeon E7-8890 v3 processor (2.5 GHz/18-core/45MB/165 W)
Memory	Up to 16 processors/288 cores possible Multiple flexible memory sizing Scale up RAM sizes: 8socket- 6/4/3/2TB and 16 socket- 12/8/4 offerings Scale out RAM sizes: 8 socket- 3/2TB offerings Maximum memory: 12TB DDR4 (384 x 32GB DIMMs)

 

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

All HWCCT tests of appliances (compute servers) certified with scenario HANA-HWC-AP SU 1.0 or HANA-HWC-AP RH 1.0 must use HWCCT of SAP HANA SPS08 or SAP HANA SPS09 or a related SAP HANA revision

All HWCCT tests of appliances (compute servers) certified with scenario HANA-HWC-AP SU 1.1 or HANA-HWC-AP RH 1.1 must use HWCCT of SAP HANA SPS10 or higher 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 * FROM M_VOLUMES

Service	Source Active services 1 Coordinator* + 1 Worker* + 1 Stand-by	Target Single Node (No Stand-by)
Nameserver	3	1
Indexserver	3	1
Compileserver	3	1
XSengine	2	1
Preprocessor	3	1
Daemon	3	1

 

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 ALTER CONFIGURATION(‘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 ALTER CONFIGURATION(‘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:
  • call SYS.UPDATE_LANDSCAPE_CONFIGURATION(‘SET REMOVE’,'<hostname:port>’);

In this example, call SYS.UPDATE_LANDSCAPE_CONFIGURATION(‘SET REMOVE’,'<DB hostname>:30040′)

• Generate the plan for removing the indexserver:
  • call REORG_GENERATE(2,”)
• Execute the generated plan:
  • call REORG_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