This checklist helps 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, then 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 Compute Engine VM instance in a production environment. Instead, distribute your databases across multiple VM instances to isolate resource consumption and avoid contention.
Avoid running other applications on the same VM instance as the database.
- By using a single VM instance to run both the database and other
software, both applications share the VM resources, which can decrease the
performance of the database. Keep in mind the following:
- 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 instance to run both the database and other
software, both applications share the VM resources, which can decrease the
performance of the database. Keep in mind the following:
If you choose to deploy any custom or third-party software on the same VM instance as a database used in an SAP landscape, then:
- 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 high-availability (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's 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 Compute Engine machine type for your database deployment and workloads, see
SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and
Google Cloud machine types
or
Certified machine types
(Google Cloud).
- To ensure that the needs of your landscape, such as capacity planning and reservations, can be fulfilled in the region of your choice, 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 Google Cloud machine 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, then 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, then follow these guidelines:
We recommend that you use the OS images provided by Google Cloud because they meet the certification requirements of SAP, the OS vendor, and Google. However, if your landscape has unique requirements that cannot be met with the standard images, then see Custom OS Images.
When choosing a persistent disk for SAP with other 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. The available
SSD-based persistent disk types are SSD Persistent Disk (
pd-ssd), Balanced Persistent Disk (pd-balanced), and Extreme Persistent Disk (pd-extreme). - If high performance is not a requirement, for example when you use a
disk for backups, then use a Compute Engine Standard Persistent
Disk (
pd-standard). 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. The available
SSD-based persistent disk types are SSD Persistent Disk (
Test and compare your results against expectations to ensure that the landscape meets your disk performance requirements for benchmarks such as database startup time, backup, volume test, and load test. After comparing, 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 use a persistent disk for backups, consider the following:
- You can use any disk type as long as it meets your performance
requirements. If a Standard Persistent Disk (
pd-standard) does not provide enough performance for your needs, then use a Balanced (pd-balanced) or SSD Persistent Disk (pd-ssd). - Remember to test your backup and recovery procedures to verify that they meet your performance needs.
- You can use any disk type as long as it meets your performance
requirements. If a Standard Persistent Disk (
- For testing purposes, create a non-production HA system that is equivalent to your production environment.
- Test your failover and failback procedures extensively as follows:
- To simulate a Compute Engine live migration and ensure that you've configured adequate cluster failover thresholds, see Testing your availability policies.
- To ensure that your landscape fails 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.