In this part of the blog series about moving seamlessly between SAP HANA hosting types using storage the following data mobility scenarios are explored:
- SAP HANA deployed on bare-metal server(s) (pHANA) being migrated or copied to a virtual machine(vHANA) using VMware Virtual Volumes(vVols)
- SAP HANA deployed on a VMware virtual machine being migrated to bare-metal server(s)
The other posts in this series can be found at these locations :
SAP HANA Data Mobility Part 1 : Introduction
SAP HANA Data Mobility Part 2 : pHANA on-premises migration techniques
SAP HANA Data Mobility Part 3 : pHANA to vHANA and vHANA to pHANA
SAP HANA Data Mobility Part 4 : Hybrid Cloud
With the ability for SAP HANA to be deployed on multiple platforms there arises a question of how instances and databases can be migrated between each efficiently. Some scenarios in which this kind of mobility may be required are :
- Mobility between physical production systems and virtual test, development and quality assurance scenarios.
- Migration of a bare-metal pHANA system to a virtual environment to achieve better total cost of ownership (TCO) , better manageability and improved on demand scalability.
- Migration from a virtual environment to a bare-metal one to account for higher performance and capacity requirements in an SAP HANA environment.
- Migration or duplication from one virtual platform to another (vHANA->vHANA)
In the examples given is possible to use both application consistent and crash consistent storage snapshots. For more information on these concepts see Part 2 : pHANA on-premises migration techniques.
The key to vHANA to pHANA migration with FlashArray is VMware vVols and storage snapshots. More information and insight into the possibilities vVols provides for an SAP HANA environment can be found in the blog post : Configuring SAP HANA Scale Out on VMware with vVols.
The examples in each scenario will use 2 scale up systems :
- pHANA01/Sarah – A bare-metal SAP HANA system
- vHANA01 – A virtual SAP HANA system
Both deployments have an instance “SH1” deployed using the same version of SAP HANA 2.0 (SPS04) , with 3 distinct volumes of the same size mounted at the following locations :
- /hana/shared – An XFS filesystem containing the typical SAP HANA installation path
- /hana/data – An XFS filesystem containing the SAP HANA data volume(s)
- /hana/log – An XFS filesystem containing the SAP HANA transaction logs
Migrating a pHANA system to vHANA using vVols
This kind of migration is known as a P-to-V scenario where a physical system is converted to a virtual one. The instance , SH1 , will move from pHANA01/Sarah to vHANA01. With the instance name being the exact same no system renaming needs to occur .If the instance system ID differed from the source to the target deployment, a rename operation would need to be done.
To begin an SAP HANA instance with the single default tenant is installed on pHANA01/Sarah. There is also an existing instance installed on vHANA01. Some tables have been created on pHANA01 before migrating the instance to vHANA01. Using SAP HANA Studio It can be seen that the pHANA system has around 260GB of data in it and is deployed on a physical system.
Looking at the FlashArray graphical user interface the volumes on FlashArray which correspond to the Data and Log volumes can be identified and are named as follows :
– Data Volume – pHANA01-SAP-HANA-Data
– Log Volume – pHANA01-SAP-HANA-Log
With vVols each virtual disk which is created for a virtual machine is added to a container , called a volume group. When looking at the volume groups on FlashArray the volumes which correspond to the virtual machine can be identified by looking for the VM name.
Looking more deeply into the volume group container for the vHANA01 virtual machine , a number of volumes are present. Identifying virtual disks to FlashArray volumes is discussed at length in this blog by Cody Hosterman. For the purposes of this blog post I have identified that the following volumes correspond to the SAP HANA Data and Log volumes :
SAP HANA Data Volume – vvol-vHANA01-10389c51-vg/Data-89d1331c
SAP HANA Log Volume – vvol-vHANA01-10389c51-vg/Data-24ccaeb3
To begin the migration , shut down the SAP HANA instance on the target vHANA system :
Then look at each of the mounted disks , in this example the virtual volumes will be overwritten and need to be unmounted to avoid data corruption.
To unmount each volume simply use the “umount” command.
At this point it is assumed that either an application consistent or crash consistent storage snapshot has been taken of the SAP HANA volumes. In this example a crash consistent storage snapshot has been taken of the pHANA data and log volumes in a protection group.
Looking at the volume snapshots in the protection group they can either be restored to the parent volume or copied. In this example the storage snapshot will be copied onto the relevant volume group disks.
It’s important to note that the “Copy Snapshot” process will overwrite the existing volumes data. This does not completely destroy the original contents of the volume , instead a volume snapshot is taken of the original volume and placed into the “Destroyed Volume Snapshots” for the volume. The destroyed volume snapshots are eradicated after 24 hours making recovery possible in the event of a mistake.
The prompts displayed when overwriting a volume with a snapshot require that a name be provided for the new volume. An existing volume name can be used which will then overwrite the volume with the snapshot’s data.
To ensure that the correct volume is being overwritten a confirmation will always be shown.
Once the volume has been overwritten the original contents can be seen in the Destroyed Volume Snapshots.
Once all of the required volumes have been overwritten they can be remounted to the filesystem. Important aspects of this process to note are that the volume will retain the same serial number , but the filesystem UUID will change. The change of the filesystem UUID will affect items like mounting by UUID in /etc/fstab.
The point at which all volumes have been remounted the SAP HANA host topology will need to be altered. For a scale up system all that would be affected is the hostname on which the instance would expect to find. For a scale out system only the master nameserver node would need to have the data and log volumes mounted to perform the name change. To make SAP HANA aware that the host topology has changed a terminal session as the <sid>adm user needs to be established. Once established use the hdbnsutil command with -convertTopology to inform the instance of the host name change.
When the host topology has been updated , the SAP HANA instance can be started. After the services have begun it can then be seen that the migration from bare-metal to virtual is complete.
Migrating a vHANA system to pHANA using vVols
Moving from a physical to a virtual system is even easier than moving from a virtual to physical system. It can be done one of two ways :
- Create a storage snapshot of the virtual disks and restore them to either a new or existing volume
- Take the relevant virtual disks attached to a virtual machine and connect them directly to the physical SAP HANA host. The example below is showcasing this example.
Taking the volumes attached via vvols used in the previous example , Migrating a pHANA to a vHANA system using virtual volumes , they have been attached directly to the physical SAP HANA host. The volumes have been unmounted from the filesystem of the virtual machine.
The rescan-scsi-bus.sh utility has been run on the pHANA system with the -a argument , to scan for and add any new devices which may be present.
rescan-scsi-bus.sh -a
Scanning SCSI subsystem for new devices Scanning host 0 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 0 1 6 0 ... ………. ……….. 8 new or changed device(s) found. [1:0:12:5] [1:0:12:6] [1:0:13:5] [1:0:13:6] [5:0:12:5] [5:0:12:6] [5:0:13:5] [5:0:13:6] 0 remapped or resized device(s) found. 0 device(s) removed.
Looking at the volume details on FlashArray for both the log and data volume the serial number can be used to identify which volumes correspond to what is shown to the operating system.
multipath -ll
3624a9370c49a4cb0e2944f440003bbc7 dm-8 PURE,FlashArray size=512G features='0' hwhandler='1 alua' wp=rw `-+- policy='queue-length 0' prio=50 status=active |- 1:0:12:6 sdr 65:16 active ready running |- 1:0:13:6 sdt 65:48 active ready running |- 5:0:12:6 sdv 65:80 active ready running `- 5:0:13:6 sdx 65:112 active ready running 3624a9370c49a4cb0e2944f440003bbc6 dm-7 PURE,FlashArray size=1.0T features='0' hwhandler='1 alua' wp=rw `-+- policy='queue-length 0' prio=50 status=active |- 1:0:13:5 sds 65:32 active ready running |- 1:0:12:5 sdq 65:0 active ready running |- 5:0:12:5 sdu 65:64 active ready running `- 5:0:13:5 sdw 65:96 active ready running
Once the volumes have been identified they can be mounted to the correct location in the filesystem.
After being mounted hdbnsutil needs to be run as the <sid>adm user to inform the instance of the host name change.
In the next part of this series , Part 4 : Hybrid cloud, the methods and concepts discussed in all of the posts in this blog series will be combined to showcase how platform tiering architectures for SAP HANA environments can be created using data mobility functions.