Migrating SAP HANA to the Cloud: AWS, Azure, and GCP
What Is SAP HANA?
SAP HANA is an in-memory system for managing relational databases. Because HANA is based on a columnar structure, and stores all data in memory, data can be retrieved with very high performance compared to traditional RDBMS systems. SAP HANA is commonly used for next generation applications, business intelligence, and analytics.
HANA lets you perform advanced analysis directly in the database, without requiring third party tools – including spatial data processing, predictive analysis and stream processing. You can also perform the ETL (extract, transform, and load) function when transferring data between databases within SAP HANA.
In this article we show how to migrate SAP HANA to one of the top three cloud provides – Amazon Web Services, Microsoft Azure, and Google Cloud Platform. This offloads infrastructure management tasks from your internal team, and provides added benefits like pay-per-use cost models, scalability, high availability, and disaster recovery.
SAP HANA on Azure
The extensive partnership between Microsoft and SAP enables you to run and fully support SAP HANA in the Microsoft Azure cloud, including development, testing and production scenarios.
SAP HANA certified TDI
Azure SAP dedicates virtual machines and bare metal servers on which you can run SAP HANA. These are part of a larger SAP-certified environment, including servers, storage components, and network configuration. This is known as the Tailored Datacenter Integration (TDI).
The SAP application layer on Azure
SAP HANA applications run on the SAP application layer (the VM layer). In each SAP HANA unit, you can deploy compute and memory resources ranging from 36 Intel processors with total memory of 786 GB, to 480 Intel processors with 24 TB of memory. These resources are dedicated to your user account in the SAP TDI environment on Azure.
The Azure HANA VM includes several services, including load balancing, clustering, Active Directory, and the HANA database instance itself. The VM can be accessed in the Azure cloud and also on-premises, using a dedicated network connection.
SAP HANA on AWS
Amazon Web Service (AWS) provides a set of cloud infrastructure services that make SAP HANA highly available, fault tolerant and cost effective. By deploying HANA in the AWS cloud, you can take full advantage of the flexibility and security of the AWS ecosystem.
Running SAP HANA on AWS instead of in your local data center makes application management easier. First, on AWS, users only manage their SAP applications. Physical infrastructure is owned and operated by AWS.
In addition, with AWS, users only pay for actual use. This means that you can rent equipment and pay by the hour. SAP HANA can bill you by the hour instead of purchasing the license and hardware resources upfront. In addition, AWS supports bring your own license (BYOL) for SAP, which can further reduce costs.
SAP HANA on AWS supports two main architectures.
Single-AZ, single-node architecture
This option configures a single EC2 instance to host SAP HANA using Amazon EBS storage and an operating system of your choice. For improved security, configure a VPC with public and private subnets, and place the SAP HANA server in the private subnet with no direct Internet access. You can manually install SAP HANA Studio on a Windows Server instance available on the public subnet, and access it using SSH.
Multi-AZ (HA), single-node architecture
Using this option, you provision two EC2 instances in private subnets in two different availability zones, with Amazon EBS storage. The architecture is based on the SLES High Availability Extension (HAE), which is part of the SAP SLES operating system. There are two main scenarios for a high availability implementation of SAP HANA:
- Performance optimization – the primary and secondary nodes are the same size, with synchronous replication mode using SAP HANA System Replication (HSR), configuring the secondary node to preload data tables.
- Cost optimization – the secondary node can be used for production and non-production jobs. In case of failure on the production node, you must stop running non-production workloads on the secondary node, to provide resources for the production environment. This requires configuring synchronous replication, but with table preloading disabled on the secondary node.
SAP HANA on Google Cloud
Google Cloud maintains a long-term partnership with SAP and provides SAP-certified infrastructure for products including SAP HANA, SAP HANA Enterprise Cloud, SAP S/4HANA Cloud, and SAP Ariba.
When you deploy SAP HANA to Google Cloud Platform (GCP), you deploy it to a virtual machine running on Compute Engine. Persistent storage is provided via managed persistent disks mounted on the Compute Engine VMs, which provide redundancy and high performance.
SAP HANA on Google Cloud supports two main architectures.
The SAP HANA virtual machine does not have a public IP address and is not accessible from external networks. Instead, the deployment uses a NAT bastion host to access HANA via a deployment of SAP HANA Studio, which is in the same subnet as the HANA database.
The multi-host architecture is especially useful when using HANA for OLAP workloads, as it can scale out and distribute load across multiple hosts.
This architecture consists of one master, multiple workers, and one or more standby hosts (optional, supports automated failover and disaster recovery for the SAP HANA hosts). Hosts are connected to a fast network that supports data transfer with speeds up to 16 Gbps.
This article covered three options for migrating SAP HANA to major cloud providers. Through tight partnerships between SAP and the leading cloud vendors, you can achieve a smooth migration, and ensure SAP HANA is running on SAP-certified hardware, while enjoying all the benefits of the public cloud. Wishing you a successful migration!