This checklist will help you to improve the design, migration, implementation, and maintenance of your SAP systems on Google Cloud using databases other than SAP HANA.
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.
- We recommend that you do not deploy multiple databases on the same VM in a production environment. Instead, distribute your databases across multiple VMs to isolate resource consumption and avoid contention.
Avoid running other applications on the same VM as the database.
- By using a single VM to run both the database and other
software, both applications share VM resources which can decrease the
performance of the database. Keep in mind:
- Database operations are resource intensive and require compute resource availability based on the benchmark and sizing guides.
- SAP applications are very sensitive to paging and swapping, which can deteriorate the performance and possibly cause the system to go down.
- By using a single VM to run both the database and other
software, both applications share VM resources which can decrease the
performance of the database. Keep in mind:
If you choose to deploy custom or third-party software on the same VM as a database used in an SAP landscape:
- Make sure you deploy this model only in non-production systems (for example, a test system).
- Use hostname aliases for the SAP installations.
- 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-certified Compute Engine VMs might not be available in all locations.
- To protect against zonal failures for SAP landscapes, deploy the databases in multiple zones (especially for VMs that are part of the same HA cluster).
- To protect against regional failures, add disaster recovery sites in other regions.
- When installing databases for SAP, you can use Terraform or Google Cloud Deployment Manager. The Terraform configuration files or Deployment Manager templates that Google Cloud provides install and configure all the required packages necessary to run the database and SAP on Google Cloud. For more information, see the following database deployment guides:
- To select a machine type for your database deployment and workloads, see
SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and VM types or Certified machine types (Google Cloud).- To ensure the 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.
- To select an SAP-supported OS that works on Google Cloud, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and VM types or the Quick reference table (Google Cloud).
Confirm that the OS has recent patches and updates.
If you use SUSE Linux Enterprise Server (SLES) in your landscape, follow these guidelines:
SAP Note 1275776 - Linux: Preparing SLES for SAP environments
Tuning systems with saptune (SUSE documentation)
If you use Red Hat Enterprise Linux (RHEL) in your landscape, follow these guidelines:
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.
When choosing a persistent disk for SAP databases:
- For the highest performance use a Compute Engine
persistent disk that is backed by solid-state drive storage (SSD-based)
to store logs and data (including temporary table spaces). SSD-based
persistent disks include:
- SSD persistent disks: recommended for the
/hana/dataand/hana/logvolumes in most use cases. - Balanced persistent disks: a lower-cost option,
and recommended for the
/hana/sharedvolume when it is not mapped to the same persistent disk as the/hana/dataand/hana/logvolumes. - Extreme persistent disks: provide the highest
performance for the
/hana/dataand/hana/logvolumes. Extreme persistent disks are only available with the larger certified machine types. For more information, see Extreme persistent disks.
- SSD persistent disks: recommended for the
- If high performance is not a requirement, for example when you use a disk for backups, use a Compute Engine standard persistent disk. Standard persistent disks are backed by standard hard disk drives (HDD).
- For more information about persistent disks for non-HANA databases, see:
- For the highest performance use a Compute Engine
persistent disk that is backed by solid-state drive storage (SSD-based)
to store logs and data (including temporary table spaces). SSD-based
persistent disks include:
Test and compare your results against expectations to ensure the landscape meets your disk performance requirements (for benchmarks such as database startup time, backup, volume test, and load test), then document these baselines for future reference.
When using the NetApp Cloud Volumes Service, make sure that NetApp has been certified by your database vendor.
- 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.
- Remember to test your backup and recovery procedures to verify they meet your performance needs.
- For testing purposes, create a non-production HA system that is equivalent to your production environment.
- Test your failover and failback procedures extensively:
- To simulate a Compute Engine live migration and ensure you've configured adequate cluster failover thresholds, see Testing your availability policies.
- 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.
- Establish a monitoring and alerting procedure. Common items to track include system down events, resource utilization (CPU, memory, and disk), database alerts for tables, buffers, log space, and backups. To learn about a useful monitoring tool available in Google Cloud, see Cloud Monitoring.