Workload Manager best practices for SAP

Google Cloud's Agent for SAP is required for SAP support on any VM that runs an SAP system.

To receive support from SAP and Google Cloud for SAP HANA on a Compute Engine VM, you must use an Operating System version that is certified by SAP and Google Cloud for use with SAP HANA.

To receive support from SAP and Google Cloud for SAP HANA on a Compute Engine custom VM, you must use a custom VM type that is certified by SAP and Google Cloud for use with SAP HANA.

For performance reasons, the SAP HANA /hana/data and /hana/log volumes must be mapped to the same type of SSD-based persistent disk. You can map both volumes to the same single persistent disk or, if the same persistent disk type is used for each, you can map each volume to a separate persistent disk.

To receive support from SAP and Google Cloud for SAP HANA on a Compute Engine VM, you must use a VM type that is certified by SAP and Google Cloud for use with SAP HANA.

To receive support from SAP and Google Cloud for SAP NetWeaver on a Compute Engine VM, you must use an operating system version that is certified by SAP and Google Cloud for use with SAP NetWeaver.

For block storage, SAP HANA requires a minimum throughput of 400 MB per second. If you are using SSD or balanced persistent disks, use the minimum size for that persistent disk type to provide the necessary throughput. If you are using extreme persistent disks, provision a minimum of 20,000 IOPS.

In a Linux Pacemaker high-availability cluster for SAP on Google Cloud, the Corosync join parameter must be configured correctly to conform to Google Cloud best practices.

In a Linux Pacemaker high-availability cluster for SAP on Google Cloud, to avoid message flooding between cluster nodes during token processing, set the Corosync max_messages parameter to a value of 20.

In a Linux Pacemaker high-availability cluster for SAP on Google Cloud, set the Corosync parameter token_retransmits_before_loss_const to a value of 10 or more to conform to Google Cloud best practices.

In a Linux Pacemaker high-availability cluster for SAP on Google Cloud, set the value of the Corosync token parameter to the recommended timeout value of 20000 to conform to the Google Cloud best practice for failure detection.

In a Linux Pacemaker high-availability cluster for SAP on Google Cloud, set the value of the Corosync transport protocol as appropriate for your Operating System. For Red Hat systems of version 8 and later, the parameter should be set to knet. For other supported Operating Systems, a value of udpu is expected.

• For RHEL, see HA cluster configuration guide for SAP HANA on RHEL.
• For SLES, see HA cluster configuration guide for SAP HANA on SLES.

In a Linux Pacemaker high-availability cluster for SAP on Google Cloud, the default value of the consensus parameter is set to 1.2 times the value of the token parameter. It is recommended not to modify this value. If you change the default value, make sure that it is at least 1.2 times the token value.

To avoid fence race conditions in Linux Pacemaker high-availability clusters for SAP, the pcmk_delay_max parameter must be specified with a value of 30 or greater in the definition of the fencing resource.

The definition of the SAP HANA resource in a Linux Pacemaker HA cluster contains a timeout value for the stop, start, promote, and demote operations. For Linux Pacemaker HA clusters for SAP on Google Cloud, we recommend a value of at least 3600 for each operation.

• For RHEL, see HA cluster configuration guide for SAP HANA on RHEL.
• For SLES, see HA cluster configuration guide for SAP HANA on SLES.

To migrate the SAP HANA resource to a new cluster node in the event of a failure in a Linux Pacemaker high-availability cluster, the SAP HANA resource definition must specify the migration-threshold parameter with the recommended value of 5000. This parameter determines the number of errors before a failover occurs and marks the cluster node as ineligible to host the SAP HANA resource.

• For RHEL, see HA cluster configuration guide for SAP HANA on RHEL.
• For SLES, see HA cluster configuration guide for SAP HANA on SLES.

A Linux Pacemaker HA cluster contains a location preference constraint that has been set on one or more resources. For Linux Pacemaker HA clusters for SAP on Google Cloud, we recommend removing the location preference to avoid situations where the clustering software attempts to set resources with a specific node affinity, such as when a resource is manually moved between nodes in the cluster.

• For RHEL, see Managing Cluster Resources.
• For SLES, see Manual resource migration.

To allow a Linux Pacemaker high-availability cluster configuration to monitor and manage its application resources, the cluster nodes that host those resources must not be in the maintenance mode.

• For RHEL, see Performing cluster maintenance.
• For SLES, see Enable and disable maintenance mode in a High Availability Cluster.

A Linux Pacemaker HA cluster contains a SAP HANA topology resource that includes a monitor operation, which has an interval value and a timeout value. For Linux Pacemaker HA clusters for SAP on Google Cloud, we recommend a value between 10 and 60 seconds for the interval, and a value of 600 seconds for the timeout.

• For RHEL, see Create the SAPHanaTopology resource.
• For SLES, see Create the SAPHanaTopology primitive resource.

To ensure that the VM restarts automatically in the event of a failure, enable the Compute Engine automatic restart policy for any VM that is running an SAP workload.

Compute Engine includes functionality based on Intel's Memory RAS that can significantly reduce the impact of all memory errors that would otherwise cause VM crashes. When combined with SAP HANA's fast restart capability (available since HANA 2.0 SP04), SAP HANA systems are able to recover from such failure events. This configuration is recommended on all Memory Optimized virtual machine families.

To prevent any platform maintenance events from stopping or restarting a VM that is running SAP workloads, the onHostMaintenance parameter for the VM must be set to the recommended option MIGRATE.

In a SAP HANA high-availability configuration the system replication hook provided by the Operating System vendor has not been implemented. This may lead to incorrect reporting of the replication state of SAP HANA System Replication to Linux Pacemaker clusters.

• For RHEL, see Enable the SAP HANA HA/DR provider hook.
• For SLES, see Enable the SAP HANA HA/DR provider hook.

To ensure resiliency of an SAP HANA high-availability configuration, the primary and secondary nodes must exist in different zones in the same region.

To receive support from SAP and Google Cloud for SAP NetWeaver on a Compute Engine custom VM, you must use a custom VM type that is certified by SAP and Google Cloud for use with SAP NetWeaver.

To receive support from SAP and Google Cloud for SAP NetWeaver on a Compute Engine VM, you must use a VM type that is certified by SAP and Google Cloud for use with SAP NetWeaver.

Encryption protects backups from unauthorized access by encrypting the backup data before it is transferred to the backup location. This means that even if an unauthorized user gains access to the backup data, they cannot read it without the decryption key. This is applicable for both file-based backups and backups created using third-party backup tools. We recommend that you enable backup encryption in the SAP HANA system.

At least one user or role has the DEVELOPMENT privilege in the production database. Google Cloud recommends that you have no users with this privilege.

The force_first_password_change parameter in SAP HANA specifies whether users are required to change their password after they are created. We recommend that you enable force_first_password_change parameter.

At least one user has the SAP_INTERNAL_HANA_SUPPORT role. This is an internal role that enables low level access to data. It should only be assigned to administrator or support at the request of SAP Development and during an active SAP support request.

Password reuse is a common security vulnerability. The last_used_passwords parameter in SAP HANA prevents users from reusing their most recent passwords. The parameter specifies the number of past passwords that a user is not allowed to use when changing their current password. We recommend that you set last_used_passwords to 5 or higher.

Encryption protects SAP HANA logs from unauthorized access. One way to do this is to encrypt the logs at the operating system level. SAP HANA also supports encryption in the persistence layer, which can provide additional security. Recommendation is to encrypt log volumes.

The maximum_invalid_connect_attempts parameter in SAP HANA specifies the maximum number of failed login attempts; the user is locked as soon as this number is reached. We recommend that you set maximum_invalid_connect_attempts to 6 or higher.

The maximum_password_lifetime parameter in SAP HANA specifies the number of days after which a user's password expires. The parameter enforces security measures to change the user password periodically. Recommendation is to set maximum_password_lifetime parameter to 182 or lower.

The initial password is only meant to serve a temporary purpose. The maximum_unused_initial_password_lifetime parameter in SAP HANA specifies the number of days for which the initial password or any password set by a user administrator for a user is valid. Recommendation is to set maximum_unused_initial_password_lifetime to 7 or lower.

The maximum_unused_productive_password_lifetime parameter in SAP HANA specifies the number of days after which a password expires if the user has not logged in. It helps in reducing the risk of compromised accounts due to prolonged inactivity of the user account. We recommend that you set maximum_unused_productive_password_lifetime to 365 or lower.

The minimal_password_length parameter in SAP HANA specifies the minimum number of characters that a password must contain.

The minimum_password_lifetime parameter in SAP HANA specifies the minimum number of days that must elapse before a user can change their password.

Checks the number of days before a password is due to expire that the user receives notification.

The password_layout parameter in SAP HANA specifies the character types that the password must contain; at least one character of each selected character type is required.

The password_lock_time parameter in SAP HANA specifies the number of minutes for which a user is locked after the maximum number of failed login attempts. Recommendation is to set password_lock_time to 1440 or higher.

We recommend that you protect SAP HANA data from unauthorized access. One way to do this is to encrypt the data at the operating system level. SAP HANA also supports encryption in the persistence layer, which can provide additional security. We recommend that you encrypt data volumes.

CVE-2019-0357 is a vulnerability that allows database users with administrator privileges to run operating system commands as root on particular SAP HANA versions.

At least one user has the DEBUG or ATTACH DEBUGGER privilege in the system. We recommend not to have users with this privilege.

System replication is configured with allowed_sender when the listen interface is .global.

Data and log compression can be used for the initial full data shipping, the subsequential delta data shipping, as well as for the continuous log shipping. Data and log compression can be configured to reduce the amount of traffic between systems, especially over long distances (for example, when using the ASYNC replication mode).

If system replication is disconnected during a full data shipment, then replication has to start from scratch. In order to reduce the risk of buffer full situations, the logshipping_async_buffer_size parameter can be adjusted to a value of 1 GB on the primary site.

The SAP HANA parameter datashipping_parallel_channels defines the number of network channels used by full or delta datashipping. The default value is 4, which means that four network channels are used to ship data.

In context of logreplay operations modes the logshipping_max_retention_size SAP HANA parameter defines the maximum amount of redo logs that are kept on primary site for synchronization with the secondary site (default: 1 TB). If the underlying file system isn't large enough to hold the complete configured retention size, it can happen in the worst case that the file system runs full and the primary site comes to a standstill.

A permanent license key is required to operate on a HANA system. If a permanent license key expires, a (second) temporary license key is automatically generated and will be valid for 28 days.

If log_mode is set to 'normal', HANA creates regular log backups, allowing for point-in-time recovery (restoring up to the moment before a failure). If log_mode is set to 'overwrite', no log backups are created; you can only recover the database to the last data backup.

The backup catalog can grow quite large over time, especially if it is not regularly cleaned up. This can lead to performance problems and can make it difficult to find the backups that are needed.

The automatic_reorg_threshold parameter specifies when automatic reorganization of row store tables is triggered. If the value is set to 30(default) automatic reorganization will not be triggered as often as it could be.

If the log partition file system disk usage ('usedDiskSpace' in percent of 'totalDiskSpace') is above the specified threshold, the logger will automatically trigger an internal 'log release' (0 = disabled). As default, the logger will keep all free log segments cached for reuse, segments will only be removed if a reclaim is triggered explicitly via 'ALTER SYSTEM RECLAIM LOG' or if a 'DiskFull'/'LogFull' event is hit on logger level. This threshold parameter can be used to trigger the reclaim internally before a 'DiskFull'/'LogFull' situation occurs.

Regular consistency checks are required to detect hidden corruptions as early as possible.

In databases with more than 235 GB allocation limit, the gc_unused_memory_threshold_rel and gc_unused_memory_threshold_abs parameters have to be configured. These parameters help to reduce the risk of hiccups (e.g. due to MemoryReclaim waits) when garbage collection happens reactively.

By default, multiple auto merges (up to num_merge_threads) of different tables or partitions can be executed up to a CPU utilization limit of 45%, but as soon as this limit is exceeded, a maximum of one auto merge is executed at any time. This can in the worst case result in an increased auto merge backlog although sufficient system resources for handling parallel auto merges would still be available. In this case you can consider increasing this parameter to a value that is both higher than the usual CPU utilization and lower than a critical limit that would allow auto merges to introduce resource bottlenecks.

If parallel_merge_threads is set to a specific value, this value is used for parallelism while token_per_table defines the number of consumed tokens.

The thread stack parameter default_stack_size_kb and worker_stack_size_kb determines the amount of data a newly created thread can access.

In a scale-out SAP HANA environment, maintaining consistency in OS and kernel across all nodes within the system is crucial for optimal performance and stability.

In a scale-out SAP HANA environment, maintaining consistency in timezones is crucial to maintain system stability.

The tables_preloaded_in_parallel parameter lets you control the number of tables loaded in parallel after you start your SAP HANA system, providing flexibility for performance optimization. We recommend a minimum value of 32.

To improve the performance of NUMA-based SAP HANA systems, enable the load_table_numa_aware parameter. When this parameter is enabled, SAP HANA optimizes data placement across NUMA nodes during table loading.

To ensure that X4 instances are optimized to support SAP workloads, you must run the command-line utility provided by Google Cloud's Agent for SAP to verify that the OS configuration matches best practice recommendations.

Creating backups regularly and implementing a proper backup strategy helps you recover your SAP HANA database in situations such as data corruption or data loss due to an unplanned outage or failure in your infrastructure. Google Cloud recommends following a backup strategy that includes creating at least one full system backup of your SAP HANA database weekly, and creating at least one delta backup or snapshot-based backup of the SAP HANA data volume daily. Daily full system backups can also be used as a substitute for delta or snapshot based backups. More frequent backups might be necessary to meet specific RPO requirements.

To enable the best performance of the Hyperdisk volumes used with SAP HANA, you must set values recommended by Google Cloud for the following SAP HANA properties: num_completion_queues, num_submit_queues, tables_preloaded_in_parallel, and load_table_numa_aware.