This checklist will help you to improve the design, migration, implementation, and maintenance of your SAP HANA landscapes on Google Cloud. These tips have been suggested by Google Cloud Support and the Professional Services Organization (PSO) to enable scalable, production-ready enterprise workloads.
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.
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, we recommend that you use Google Cloud Deployment Manager.
- 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:
Certified and Supported SAP HANA Hardware Directory
- 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
Tuning systems with sapconf/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
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).
- Select an SAP-supported OS:
When choosing a persistent disk (PD) type for SAP HANA:
- Use a
zonal SSD persistent disk
to store the
- To learn about the minimum persistent disk size necessary for SAP throughput requirements, see Minimum sizes for SSD-based persistent disks.
- Use either balanced (pd-balanced) or SSD (pd-ssd) persistent disks for shared directories, data, and log volumes.
- Make sure you increase your storage volume sizes to meet your performance needs. Do not use volume sizes that are less than the recommended sizes for your machine type.
To ensure you create volumes sufficiently sized to meet your I/O needs for throughput and input/output operations per second (IOPS), see Storage options.
Use a standard disk for backup if this meets your performance requirements.
For more recommendations, see Persistent disk storage.
- Use a zonal SSD persistent disk to store 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 2GB 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.
To implement the Fast Restart option, see SAP HANA Fast Restart Option in the SAP HANA documentation.
If you deploy your SAP HANA system on Google Cloud by using one of the Cloud Deployment Manager templates that we provide, 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.
- For more information about SAP HANA backup options, see SAP on Google Cloud: Backup strategies and solutions.
- 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, 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.
- To provide protection against unplanned outages (such as hardware failure), we strongly recommend you use OS-based software clustering.
- If you do not use a cluster automation solution (such as Pacemaker), define and test your recovery procedures and playbook.
- When using Pacemaker:
- For the RHEL and SLES operating systems, define a virtual IP address (VIP) that uses Internal TCP/UDP Load Balancing. If you do not use Google-provided templates to set up this configuration, ensure that you reserve this VIP address to avoid it from being reused accidentally.
- Create a configuration that follows the standard guidelines for SLES and RHEL.
- For testing purposes, create a non-production HA system that is equivalent to your production environment.
- When using Live Migration:
- To ensure you've configured adequate cluster failover thresholds, see Testing your availability policies.
- For more information about high availability, see SAP on Google Cloud: High availability.
- 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.
- For more information about disaster recovery, see SAP on Google Cloud: Disaster recovery strategies.