Technical Articles
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:-
- 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
-
- 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
Thanks Anikesh for this elaborate blog! Really helpful...
-Jyoti
This blog explains steps very clearly to perform the migration from multi node to single node.
Thank you for sharing this helpful information.
Regards,
Vishal
Hi Anikesh,
Thanks for sharing the information.
Could you clarify the below :
1) what would be the evidence to conclude the scale out to scale up migration is successful?
2) Should the source and target data base sizes same if we do backup and recovery method?
Hello Naresh,
Please check below for my answers.
1) what would be the evidence to conclude the scale out to scale up migration is successful?
Once you have done with all migration, We can check consistency by performing 2 steps.
backup consistency by hdbbackupcheck (Application should be down during full backup)
after removing all additional services check data consistency by generation pre and post-control reports check.
Please referer 1977584 note to check the consistency.
2) Should the source and target data base sizes same if we do backup and recovery method?
Database size should not be the same in HANA scale-out to scale-up migration, As we are performing reorg after service removal.
Thanks,
Anikesh
Hi Anikesh Jyotishi
I think you forgot some steps.
step to delete index server after call REORG_EXECUTE(?).
Step to delete xsengine.
A second redistrubution documented in sap note 2093572 - SAP HANA Migration from Multi-Node to Single-Node