This checklist will help you to improve the design, migration, implementation, and maintenance of your SAP HANA landscapes on Google Cloud.
As you go through the checklist, take into account your own business needs. If you make choices that differ from what we've recommended, keep track of those differences for later tasks in the checklist.
Checklist
Click on a checklist item to see more information and click the box when you complete a task.
To deploy multiple SAP HANA databases in your landscape:
- Do not run multiple SAP HANA systems on the same host in production systems. Instead, create one VM per each SAP HANA database. For more information, see SAP Note 1681092 - Multiple SAP HANA systems (SIDs) on the same underlying server(s) and SAP HANA Technical Deployment Options.
Create the tenant databases (also known as multitenant database containers [MDC]) that are appropriate for your environment and licensing. For more details, see SAP Note 2096000 - SAP HANA tenant databases - Additional Information.
We recommend that you do not run custom or third-party software on the same VM as an SAP HANA database if this will impact the performance and operations of the SAP HANA database.
By using a single VM to run both the SAP HANA database and other business software, both applications share VM resources which can decrease the performance of the database. Keep in mind that SAP HANA is resource intensive and requires compute resource availability based on the benchmark and sizing guides.
For more information about the SAP HANA landscape design, see SAP HANA Deployment Types.
If you choose to deploy multiple non-production SAP HANA databases on the same VM:
- Use hostname aliases for the different system IDs (SIDs).
- For each installation, use a separate static IP address mapped to an alias hostname.
- To learn which regions and zones support specific Compute Engine VMs, see Available regions and zones. Keep in mind that SAP HANA-certified Compute Engine VMs might not be available in all locations.
- To protect against zonal failures, deploy SAP HANA in multiple zones (especially for VMs that are part of the same SAP HANA HA cluster).
- To protect against regional failures, add disaster recovery sites in other regions.
- To meet the latency requirements for an SAP HANA scale-out system, deploy all nodes of the scale-out system in the same zone.
- When installing SAP HANA, you can use the following automation tools to
deploy SAP workloads on Google Cloud:
- Terraform (recommended): A popular industry application for building, changing, and versioning infrastructure safely and efficiently. To use Terraform and find the appropriate configuration files for your SAP solutions, see Automating SAP deployments on Google Cloud with Terraform.
- Google Cloud Deployment Manager: An application that installs and configures all the required packages necessary to run SAP HANA on Google Cloud. To use Deployment Manager and find the appropriate templates for your SAP solution (including high-availability setup), see Automating SAP deployments on Google Cloud with Deployment Manager.
- To understand how to implement SAP HANA on Google Cloud, see the SAP HANA planning guide.
- To select a machine type for your SAP HANA deployment and workloads,
see the list of
Certified machine types for SAP HANA.
- To confirm that your preferred machine type is available in your preferred region, see Available regions and zones.
- To ensure the capacity needs of your landscape can be fulfilled in the region of your choice (such as capacity planning and reservations), work with your Technical Account Manager or designated Customer Engineer.
- When choosing an operating system (OS):
- Select an SAP-supported OS:
Certified operating systems for SAP HANA (Google Cloud) - Make sure the OS is certified for use on Google Cloud:
Go to Certified and Supported SAP HANA Hardware Directory, click on the required machine type, and then see Operating System. - Confirm that the OS has recent patches and updates:
OS support for SAP HANA on Google Cloud
For example, you don't want to install an outdated 2-year-old image with security issues or other problems. - If you use SUSE Linux Enterprise Server (SLES) in your
landscape, follow these guidelines:
- SAP Note 1275776 - Linux: Preparing SLES for SAP environments
- SAP Note 2205917 - SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12
- SAP Note 2684254 - SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15
- Tuning systems with saptune (SUSE documentation)
- If you use Red Hat Enterprise Linux (RHEL) in your landscape,
follow these guidelines:
- SAP Note 2009879 - SAP HANA Guidelines for Red Hat Enterprise Linux (RHEL) Operating System
- SAP Note 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7
- SAP Note 2777782 - SAP HANA DB: Recommended OS Settings for RHEL 8
- SAP Note 2002167 - Red Hat Enterprise Linux 7.x: Installation and Upgrade
- SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration
- We recommend you use the OS images available on Google Cloud because they meet the certification requirements of SAP, the OS vendor, and Google. However, see Custom OS Images if your landscape has unique requirements that cannot be met with the standard images (such as migrating your existing on-premises images to Google Cloud).
- If you need to set custom environment variables for an SAP HANA system on Linux, see SAP Note 3011163 - How to set Environment Variables for SAP HANA System.
- Select an SAP-supported OS:
- When choosing persistent disk types for SAP HANA:
- Use an SSD-based zonal persistent disk
for the
/hana/data,/hana/log,/hana/shared, and/usr/sapvolumes. The SSD-based Compute Engine persistent disk or Hyperdisk types, which are backed by solid-state disk (SSD) storage, include the following disk types:- SSD persistent disks (
pd-ssd): recommended for the/hana/dataand/hana/logvolumes in most use cases and systems below 1 TB memory size. - Balanced persistent disks (
pd-balanced): a lower-cost option, and recommended for the/hana/sharedand/usr/sapvolumes when they are not mapped to the same persistent disk or Hyperdisk as the/hana/datavolume. It can be used for cost optimization for/hana/dataand/hana/logwith memory sizes 1 TB and above. - Hyperdisk extreme (
hyperdisk-extreme): provides the highest performance for the/hana/dataand/hana/logvolumes. For more information, see About Hyperdisks. - Extreme persistent disks (
pd-extreme): while this disk is certified for use with SAP HANA, we recommend that you use Hyperdisk Extreme instead, which provides greater performance.
- SSD persistent disks (
- Make sure that your SSD-based persistent disks and Hyperdisks are large enough to meet SAP HANA performance requirements. For more information, see Minimum sizes for SSD and balanced persistent disks and Hyperdisks.
- For the optional
/hanabackupvolume, we recommend that you use a standard persistent disk. If you want faster backups, then you can use a balanced persistent disk for the/hanabackupvolume.
- Use an SSD-based zonal persistent disk
for the
- Test and compare your results against expectations to ensure the landscape meets your disk performance requirements (for benchmarks such as HANA startup time, backup, volume test, and load test), then document these baselines for future reference.
- Use a small swap disk of 2 GB for SAP HANA. See SAP Note 1999997 - FAQ: SAP HANA Memory.
- When using the NetApp Cloud Volumes Service, follow the Volume requirements for NetApp Cloud Volumes Service with SAP HANA.
For SAP HANA 2.0 SP04 and later, we recommend the SAP HANA Fast Restart option, especially for Compute Engine memory-optimized machine types, such as the M1, M2, or M3 machine types.
To implement the Fast Restart option, see SAP HANA Fast Restart Option in the SAP HANA documentation.
For more information about configuring the Fast Restart option, see the configuration guide for your Linux distribution:
If you deploy your SAP HANA system on Google Cloud by using one of the Terraform configuration files or Cloud Deployment Manager templates that we provide, then you need to create and mount the TMPFS filesystem after the host VM and the base SAP HANA system are successfully deployed.
- When using the Cloud Storage Backint agent for SAP HANA:
- Use the latest version. See Updating the Backint agent to a new version.
- Adjust performance to meet your needs and perform data backups in parallel. See Multistreaming data backups with the Backint agent.
- Choose a location that is closest to your SAP HANA location, given that Cloud Storage buckets include the region, dual region, and multi-region options.
- Ensure that your choice of storage buckets meets your redundancy needs. Typically, using the multi-region option is best because it provides recoverability if a particular region becomes unavailable.
- If you enable Private Google Access on your subnet, do not route traffic through a private VM (for example, using a NAT gateway or proxy server) because doing so can decrease achievable throughput. For more information, see the Network configuration section of the Configuring Private Google Access guide.
- When you perform backups to a persistent disk:
- You can use any disk type as long as it meets your performance requirements. If standard PD does not provide enough performance for your needs, then try balanced (pd-balanced) or SSD (pd-ssd) instead.
- Know that the SAP HANA landscape requires you to allocate additional bandwidth to each VM instance. SAP HANA uses the extra bandwidth for the overhead and IOPS needed to read and write backup data to disk. As a result, we recommend using SAP HANA Backint or third-party tools that support either streaming or snapshots of the persistent disk volumes.
- Remember to test your backup and recovery procedures regularly to verify they meet your performance and recoverability needs.
For a checklist of best practices for high-availability configurations for SAP HANA on Google Cloud, see High availability for SAP on Google Cloud.
- Test your failover and failback procedures extensively:
- To ensure that your landscape will fail over properly to a new region in the event of a localized disaster, regularly test your disaster recovery procedures.
- To enable successful failover and failback, create an operations playbook and update it as needed.
- To limit the amount of data that should be transferred with each backup, make use of incremental and differential backup strategies by reviewing Delta Backup Types. Consider this against your recovery time objectives.
- Establish a monitoring and alerting procedure. Helpful options available in Google Cloud include Cloud Monitoring and the SAP HANA Monitoring Agent.