This is the final part of the blog series about moving seamlessly between SAP HANA hosting types using storage where the concepts and scenarios in Part 2 : pHANA on-premises migration techniques and Part 3 : pHANA to vHANA and vHANA to pHANA will be applied to showcase how a truly hybrid cloud environment could look for SAP HANA deployments.
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
Hybrid cloud scenarios refer to environments made up of on-premise infrastructure and systems which at some level interact with private cloud services or a public cloud such as Amazon Web Services or Microsoft Azure. This blog post will focus on the use of SAP HANA in a Public Cloud in a hybrid cloud environment with FlashArray//X on-premise and Cloud Block Store deployed in public cloud.
To explain the lifecycle of migrating the SAP HANA instance between various deployment platforms I will split each concept into a set of “chapters”, building on each as the storyboard progresses.
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.
Chapter 1. The SAP HANA System resides on a bare-metal server and is migrated by taking either an application or crash consistent storage snapshot and then overwriting the VMware virtual machine’s SAP HANA data volume with it. The snapshot is then copied (using the FlashArray user interfaces) to an existing virtual machine SAP HANA data and log volume based on vVols. If the virtual machine storage is based on VMFS it is first migrated to use vVols as a staging scenario before the copy-overwrite process occurs.
Another use of this architecture could be using it to perform a homogeneous system copy between a physical production environment and a test, development or quality assurance .
Chapter 2. The SAP HANA instance will be migrated from the virtual environment to a bare-metal system. To add more complexity to the migration an entirely different storage array is going to be used as the new persistent storage for the SAP HANA instance. Both the source and target arrays are geographically distant from one another.
Before starting the migration the SAP HANA virtual machine needs to be using vVols as the location of its persistent storage. A storage snapshot is taken of the SAP HANA log and data volumes and then replicated to the second FlashArray. Once the snapshot is completely replicated it can be copied to a new or existing volume (overwritten) before starting the SAP HANA instance.
Chapter 3. The SAP HANA Instance is currently located on-premise and to save cost on additional hardware the instance will be copied to a public cloud for non-production use. Examples of non-production use are test, development and quality assurance.
The SAP HANA source instance can be either a physical bare-metal or virtual (using vVols) deployment. The target in this case is a Cloud Block Store instance deployed on public cloud.
A storage snapshot is taken of the log and data volumes on the source. Once the snapshot is taken it is replicated to the relevant Cloud Block Store instance , connected to a Public Cloud virtual machine using iSCSI connectivity. The SAP HANA instance can be recovered and started once all of these steps are complete.
Chapter 4. After completing any test, development or quality assurance work it might be necessary to return the instance and any new data to the on-premise production environment.
This process is the inverse of the steps for Chapter 3. Storage snapshots of the SAP HANA persistence (data and/or log) are taken , replicated to the on-premises FlashArray and restored to either the virtual machine (using vVols) or physical bare-metal system.
This concludes the blog series Moving seamlessly between SAP HANA hosting types using Storage. If you can think of an interesting way in which this architecture can be used which has not been covered here or want to explore how this technology can help your organization, leave a comment or get in touch and request a demo!