Checklist for SAP HANA on Google Cloud

This checklist helps 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.

  • 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 don't 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:

When choosing disk types for SAP HANA:

  • Use an SSD-based Persistent Disk or Hyperdisk. SSD-based Persistent Disk and Hyperdisk types that are certified by SAP for use with SAP HANA include the following:

    • SSD-based Persistent Disk types: Balanced (pd-balanced), Performance or SSD (pd-ssd), and Extreme (pd-extreme)

      • These disk types provide cost-effective and reliable block storage.
      • Performance (SSD) Persistent Disk (pd-ssd) provides higher performance than Balanced Persistent Disk (pd-balanced).
      • Use Balanced Persistent Disk as the recommended disk for hosting the following for VM instances:
        • VM boot volume.
        • The /usr/sap volume.
        • The /hana/shared volume, if you're hosting it on its own disk.
        • The /hanabackup volume, if you save your backups to a disk. If you want to reduce the backup costs, then you can use a Standard HDD Persistent Disk (pd-standard). Balanced Persistent Disk provides faster backups than Standard HDD Persistent Disk. While selecting the disk, make sure that your VM type supports the disk type.
      • Balanced and Performance (SSD) Persistent Disk support PD Async Replication. You can use this feature for cross-region active-passive disaster recovery. For more information, see Disaster recovery using PD Async Replication.
      • While Extreme Persistent Disk (pd-extreme) is certified for use with SAP HANA, we recommend that you instead use Hyperdisk Extreme (hyperdisk-extreme), which provides greater performance. If you want to use Extreme Persistent Disk, then make sure to provision the disks in accordance with the information in Minimum sizes for SSD-based Persistent Disk and Hyperdisk volumes.
    • Hyperdisk types: Hyperdisk Extreme (hyperdisk-extreme) and Hyperdisk Balanced (hyperdisk-balanced)

      • Hyperdisk Extreme provides higher maximum IOPS and throughput options than SSD-based Persistent Disk types.
      • For a list of the machine types that support Hyperdisk Extreme and Hyperdisk Balanced, see Machine type support.
      • Use Hyperdisk Balanced as the recommended disk for hosting the following for Compute Engine bare metal instances such as X4:
        • The boot disk.
        • The /usr/sap volume.
        • The /hana/shared volume, if you're hosting it on its own disk.
        • The /hanabackup volume, if you save your backups to a disk.
      • For Hyperdisk Extreme, you select the performance you need by provisioning IOPS, which also determines your throughput. For more information, see Throughput.
      • For Hyperdisk Balanced, you select the performance you need by provisioning IOPS and throughput. For more information, see About IOPS and throughput provisioning for Hyperdisk.
      • You can use Hyperdisk Extreme for the /hana/data and /hana/log volumes when you require the highest performance.
      • To enable the best performance from Hyperdisk Extreme for SAP HANA, update your SAP HANA system properties as recommended in Hyperdisk Extreme performance.
  • Make sure that your SSD-based Persistent Disk and Hyperdisk volumes are large enough to meet SAP HANA performance requirements. For more information, see Minimum sizes for SSD-based Persistent Disk and Hyperdisk volumes.
  • 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 Google Cloud NetApp Volumes, follow the Volume requirements for NetApp Volumes 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 Backint feature of Google Cloud's Agent for SAP:
    • Use version 3.6 (latest) of Google Cloud's Agent for SAP. For instructions to update to it, see Update Google Cloud's Agent for SAP.
    • Adjust performance to meet your needs and perform data backups in parallel. See Multistreaming data backups with Google Cloud's Agent for SAP.
    • While creating the Cloud Storage buckets, choose a location that is closest to your SAP HANA location. Also, 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. For more information, see Storing backups in Cloud Storage buckets.
    • If you enable Private Google Access on your subnet, then don't 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 or Hyperdisk volume:
    • You can use any disk type as long as it meets your performance requirements. If Standard Persistent Disk does not provide enough performance for your needs, then try Balanced Persistent Disk 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 or Hyperdisk volumes.
  • Remember to test your backup and recovery procedures regularly to verify that 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 metrics collection feature of version 2.0 or later of Google Cloud's Agent for SAP.
To automate continuous validation checks for your SAP HANA workloads that run on Google Cloud, use Workload Manager. Workload Manager allows you to automatically scan and evaluate your SAP HANA workloads against best practices to improve their quality, performance, and reliability.