SAP Business Suite on SAP ASE or IBM Db2: Reference Architectures on Google Cloud

Overview

This document is for people who are evaluating Google Cloud as a platform for deploying SAP Business Suite applications on SAP ASE or IBM Db2, especially for people in the following kinds of jobs:

  • SAP technical architect
  • Cloud architect
  • SAP basis administrator
  • Enterprise architect

This document also lists issues to consider prior to installation, as well as linking to SAP Notes and other documentation to facilitate deployment.

Google Cloud provides a cost-effective, reliable, secure, and high-performance SAP certified infrastructure for running SAP Business Suite. For a complete list of supported SAP solutions on Google Cloud, see SAP on Google Cloud.

Licensing

If you're an SAP customer, then you can use your existing license to deploy SAP Business Suite on Google Cloud under a bring-your-own-license (BYOL) model. Google Cloud supports the BYOL model for both production and non-production use cases. Operating system licenses are included in Compute Engine prices; alternatively, you can bring your own OS image and licenses as well.

ASE

For information about licensing SAP ASE on Google Cloud, see the SAP ASE Planning Guide

IBM Db2

To deploy IBM Db2 on Google Cloud, you must bring your own license. You can obtain a license from SAP or from IBM. For more information on licensing and support, see SAP's IBM Db2 licensing and support page.

Sizing

Several sizing options are available based on the implementation type. For greenfield implementations, we recommend using the SAP Quick Sizer tool. For detailed information, see SAP's Sizing page. SAP also provides T-shirt guides for specific solutions and tools for migrating current on-premises solutions to Google Cloud. For example, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types . SAP and Google Cloud use different units to measure IOPS (input/output operations per second); consult your SI (Systems Integrator) partner to convert SAP sizing requirements into appropriately sized Google Cloud infrastructure.

ASE

To size an ASE database, see:

IBM Db2

To size an IBM Db2 database on Windows or Linux, see System requirements for IBM DB2 for Linux, UNIX, and Windows.

Supported machine types

SAP ASE and IBM Db2 are certified to run on the following Compute Engine machine types:

  • n1-standard machine type with 8, 16, 32, 64, or 96 vCPUs
  • n1-highmem machine type with 2, 4, 8, 16, 32, 64, or 96 vCPUs
  • Custom machines types

For more information the certified machine types, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types .

ASE

For more information about configuring VM types for SAP ASE, see VM configuration in the SAP ASE Planning Guide.

For more information about supported operating system versions for SAP ASE on Google Cloud, see SAP Note 2537664 - SAP Adaptive Server Enterprise (SAP ASE) 16.0 Certification for Google Cloud Platform.

IBM Db2

For more information about configuring VM types for IBM Db2, see VM configuration in the SAP ASE Planning Guide.

For more information about IBM Db2 on Google Cloud, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types .

Disks and file systems for SAP Business Suite

Google Cloud offers the following storage types:

  • Persistent disks for block storage
    • Standard (pd-standard): efficient and economical block storage backed by standard hard disk drives (HDD) for handling sequential read-write operations, but not optimized to handle high rates of random input-output operations per second (IOPS).
    • SSD (pd-ssd): provides reliable, high-performance block storage backed by solid-state drives (SSD).
    • Balanced (pd-balanced): provides cost-effective and reliable SSD-based block storage.
    • Extreme (pd-extreme): SSD-based, provides higher maximum IOPS and throughput options than pd-ssd for larger Compute Engine machine types. For more information, see Extreme persistent disks.
    • Local SSDs: High-performance local block storage.
  • Cloud Storage buckets: affordable object storage.
  • Filestore instances: fully managed NFS file servers on Google Cloud.

For more information, see Storage Options.

Google Cloud persistent disks are designed for high durability. They store data redundantly to ensure data integrity. Each persistent disk can store up to 64 TB, so you can create large logical volumes without managing arrays of disks. One key feature is that persistent disks are automatically encrypted to protect data.

Upon creation, a Compute Engine instance allocates a single root persistent disk by default that contains the operating system. You can add more storage options to the instance as needed. For SAP implementations, we recommend using persistent disks, because they are designed for high durability and compute instances can access them like physical disks on a local machine.

ASE

The following tables describe the Linux directory structure for the SAP Business Suite on ASE on Google Cloud. For more information, see the SAP ASE Installation Guide for Linux.

SAP application directory structure Storage type
/sapmnt Standard persistent disk (HDD)
/usr/sap Standard persistent disk (HDD)

All data and log files for ASE must be located under /sybase/SAPSID. SAPSID, or SAP System Identifier, is the SAP instance name used during installation.

SAP Business Suite on ASE directory structure Storage type
/sapmnt Standard persistent disk (HDD)
/usr/sap Standard persistent disk (HDD)
/sybase/SAPSID Standard persistent disk (HDD)
/sybase/SAPSID/sapdata_1 Standard persistent disk (HDD) or SSD-based persistent disk
/sybase/SAPSID/saplog_1 Standard persistent disk (HDD) or SSD-based persistent disk
/sybase/SAPSID/saptemp Standard persistent disk (HDD)
/sybase/SAPSID/sapdiag Standard persistent disk (HDD)
/sybasebackup Standard persistent disk (HDD)

For more information, download SAP Best Practice Guide ASE.

The following table describes the Windows directory structure for the SAP Business Suite on ASE. This directory structure applies to central server installation.

Drive Description Storage type
C:\ Boot Standard persistent disk (HDD)
D:\ Database binaries Standard persistent disk (HDD)
E:\ Database data files Standard persistent disk (HDD) or SSD-based persistent disk
L:\ Database log Standard persistent disk (HDD) or SSD-based persistent disk
P:\ Page file Standard persistent disk (HDD)
S:\ usr/sap and sapmnt Standard persistent disk (HDD)
T:\ Database temp and saptemp Standard persistent disk (HDD)
X:\ Backup Standard persistent disk (HDD)

For further reading, download SAP Best Practice Guide ASE.

IBM Db2

The following table describes the Linux directory structure for the SAP Business Suite on Db2 on Google Cloud.

SAP Business Suite on Db2 directory structure Storage type
/sapmnt Standard persistent disk (HDD)
/usr/sap Standard persistent disk (HDD)
/db2/SAPSID Standard persistent disk (HDD)
/db2/SAPSID/db2dump Standard persistent disk (HDD)
/db2/SAPSID/sapdata1 Standard persistent disk (HDD) or SSD-based persistent disk
/db2/SAPSID/saptmp1 Standard persistent disk (HDD)
/db2/SAPSID/log_dir Standard persistent disk (HDD) or SSD-based persistent disk
/db2backup Standard persistent disk (HDD)

For more information, see SAP on IBM DB2 for Linux and Windows.

The following table describes the Windows directory structure for the SAP Business Suite on Db2 on Google Cloud. This directory structure applies to central server installation.

Drive Description Storage type
C:\ Boot Standard persistent disk (HDD)
D:\ Database binaries Standard persistent disk (HDD)
E:\ Database data files Standard persistent disk (HDD) or SSD persistent disk
L:\ Database log Standard persistent disk (HDD) or SSD persistent disk
P:\ Page file Standard persistent disk (HDD)
S:\ usr/sap and sapmnt Standard persistent disk (HDD)
T:\ Database temp and saptemp Standard persistent disk (HDD)
X:\ Backup Standard persistent disk (HDD)

For additional details on the directory structure, see the SAP NetWeaver Planning Guide.

To calculate page file size requirements, see SAP Note 1518419: Page file and virtual memory required by the SAP system.

Deployment

SAP Business Suite consists of the following technical components:

Application layer:

  • ASCS—ABAP SAP Central Services. Contains the following components:
    • Message server (MS): Acts as a communication channel between application servers. Also handles load distribution.
    • Enqueue server (ES): Controls the lock mechanism.
  • PAS—Primary application server.
    • The first or only application server for the SAP system.
  • AAS—Additional application server.
    • Usually deployed for application level load balancing. You can install multiple AAS to achieve higher availability from an application layer perspective as well. If one of the application servers goes down, all user sessions connected to that application server are terminated, but users can log in again to the other associated AAS in the environment.
  • WD—Web Dispatcher (optional).
    • Intelligent software load balancer that distributes HTTP and HTTPS requests, based on application type, to PAS and AAS.

Currently the following databases are certified to run on Google Cloud for SAP Business Suite.

Database layer:

ASE

Google Cloud provides the following options to install ASE on Linux and Windows:

  • Manual
  • Terraform
  • Deployment Manager

For SAP Business suite installation, see SAP Business Suite installation documents.

For Linux installation, see Overview of Linux deployment for SAP NetWeaver.

For Windows installation, see Overview of Windows deployment for SAP NetWeaver.

IBM Db2

SAP has certified Google Cloud to run IBM Db2 on the following operating systems on Compute Engine VM instances:

  • SLES 12 SP2 and above.
  • RHEL 7.4.
  • Windows Server 2012 R2 and above.

For more information, see IBM Db2 Planning Guide for SAP NetWeaver.

Google Cloud provides the following options to install IBM Db2 on Linux and Windows:

  • Manual
  • Terraform
  • Deployment Manager

For SAP Business suite installation, see SAP Business Suite installation documents.

Deployment models

You can deploy SAP Business Suite in either of two models: centralized deployment or distributed deployment.

Centralized deployment

In a centralized deployment, you can install SAP Business Suite applications and the database on the same Compute Engine instance. We recommend this approach for non-production environments such as sandbox and development environments.

ASE

The following diagram shows a reference architecture for a centralized deployment of SAP Business Suite on ASE in a Linux environment. Note that SAP ASCS, PAS, and ASE are all installed on the same instance.

SAP ASCS, PAS, and SAP ASE are installed on a single VM with a Linux
directory structure

The following diagram shows a reference architecture for a centralized deployment of SAP Business Suite on ASE in a Windows environment. Note that SAP ASCS, PAS, and ASE are all installed on the same instance.

SAP ASCS, PAS, and SAP ASE are installed on a single VM with a Windows drive
  directory

Db2

The following diagram shows a reference architecture for SAP Business Suite on IBM Db2 in a centralized deployment model, in a Linux environment. Note that SAP ASCS, PAS, and IBM Db2 are all installed on the same instance.

SAP ASCS, PAS, and IBM Db2 are installed on a single VM with a Linux directory
  structure

The following diagram shows a reference architecture for SAP Business Suite on IBM Db2 in a centralized deployment model, in a Windows environment. Note that SAP ASCS, PAS, and IBM Db2 are all installed on the same instance.

SAP ASCS, PAS, and IBM Db2 are installed on a single VM with a Windows drive
  directory

Distributed deployment

In a distributed deployment, you can install the SAP Business Suite applications and the database on different instances. We recommend this approach for production environments or environments that require a lot of compute power to handle heavy transaction load. Each of the SAP application layer components described earlier (in "Deployment") can be independently installed on different instances.

Also, optionally, you can install one or more additional application servers (AAS), depending on your business requirements.

ASE

The following diagram shows a reference architecture for SAP Business Suite on ASE in a distributed deployment model. Note that SAP ASCS, PAS, and SAP ASE are all installed on different instances.

SAP ASCS, PAS, and SAP ASE are installed on separate VMs with a Linux
  directory structure

Db2

The following diagram shows a reference architecture for SAP Business Suite on IBM Db2 in a distributed deployment model. Note that SAP ASCS, PAS, and IBM Db2 LUW are all installed on different instances.

SAP ASCS, PAS, and IBM Db2 are installed on separate VMs with a Linux
  directory structure

A note on load balancing

In a distributed SAP environment, we recommend load balancing to achieve optimal application performance. You can configure application load balancing using the SAP application layer.

High availability and disaster recovery

High availability (HA) and disaster recovery (DR) are sets of techniques, engineering practices, and design principles to enable business continuity in the event of failures. These approaches work by eliminating single points of failure and providing the ability to rapidly resume operations after a system or component outage with minimal business disruption. Fault recovery is the process of recovering and resuming operations after an outage due to a failed component.

For example, here are some HA and DR tools:

Application server high availability and disaster recovery

To ensure high availability for the system, consider the following components:

  • ABAP Central Services (ASCS).
  • Primary application server (PAS).
  • SAP ASE or IBM Db2.

Application server HA considerations and deployment

  • An ABAP SAP Central Services (ASCS) HA setup consists of at least two SCS nodes. The primary node runs the message server (MS) and Enqueue Replication Server (ERS) service, and the secondary node runs ERS only.
  • A VIP (virtual IP) is set up to connect to the ASCS instance. The VIP is set up as a floating IP address. During a failover of the primary node, the SUSE cluster allows the secondary node to become active. Additionally, the VIP moves over to the secondary node so that the requests now go to the secondary node.
  • In a normal scenario, the ASCS primary node always runs a message server and the secondary node always runs the ERS.
  • NFS file shares are mounted from NFS servers to the primary and secondary ASCS nodes. You can use a high-availability service like Filestore Enterprise.
  • The following diagram shows two nodes:

    • Node 1 is the primary node and hosts ASCS—MS and ERS.
    • Node 2 is the secondary node and hosts ERS.
    • The numbering indicates the request flow:

      1. Request lands at the VIP.
      2. Request goes to the active node, Node 1 in the diagram below.
      3. Active node writes to the NFS shares.

One VM hosts active ASCS and inactive ERS. Another VM hosts inactive ASCS
and active ERS. The VM pair, ERS pair, and NFS each have their own VIP

Application server DR considerations and deployment

You can facilitate a DR node for an SAP Netweaver application server by restoring files under the mount points /usr/sap/SID and /sapmnt/SID. You can make an offline or online backup of these mounts and the underlying files; however, we recommend making at least one complete offline backup, so you can use it to set up the DR node. You can use Google snapshots to back up the persistent disks of the SAP volumes. You can restore these SAP volumes in any region or zone in case of disaster. For more details, see the SAP NetWeaver Operations Guide.

Database high availability and disaster recovery

ASE high availability

In ASE on Google Cloud, you can achieve HA and DR by configuring synchronous replication between the primary and standby servers, allowing the two servers to be always in sync with zero data loss. There are two versions of HA on ASE. The ASE always-on option is supported on Google Cloud; for further details, see the SAP ASE planning guide.

Both primary and secondary hosts should have the following components:

  • ASE.
  • SAP Host Agent—monitors server use of CPU, memory, and other resources.
  • RMA—Replication management agent.
  • SAP ASE Cockpit—Performs database activities.
  • Fault Manager—Fault Manager has its own host server and monitors primary and standby servers. Fault Manager ensures high availability of ASE by starting automatic failover. It monitors the following components: Replication Management Agent, replication server, applications, databases, and operating system. It also allows you to check the health of the database and restart the database if required.

For improved system availability, an ASE cluster enables workloads to be moved to the secondary node by monitoring for failure of the primary node. The following diagram shows a high-level reference architecture demonstrating how the ASE components described above could be installed on Google Cloud.

Primary and secondary instances of SAP ASE are installed on separate VMs. Data
is replicated synchronously between the two instances.

ASE disaster recovery

The disaster recovery system consists of two ASE servers—one designated as the primary, on which all transaction processing takes place, and the other designated as a standby server. In DR mode, the data is replicated from the primary server to the standby server using asynchronous replication. If the primary server fails, the standby server is promoted to the role of primary server either manually or automatically. We recommend using asynchronous replication mode for a DR setup.

The essential components of DR for SAP ASE are the same as for HA for ASE; see the list in the previous section.

The following diagram shows the flow of ASE disaster recovery.

The primary SAP ASE instance is installed on a VM in one zone. The
secondary instance is installed on a VM in a different zone. Data
is replicated synchronously between the two instances.

For further details on the operating systems that are certified for SAP ASE, see SAP Note 2537664, the ASE 16.0 certification report for Google Cloud Platform.

IBM Db2 high availability and disaster recovery

Google Cloud supports always-on high availability for IBM Db2, and SAP supports most IBM Db2 features on Google Cloud. However, the following features are currently not supported:

  • Multi partition Db2 databases.
  • IBM Db2 pureScale feature.

For further details, see IBM Db2 Planning Guide for SAP NetWeaver.

Backup and recovery

Make backups of your application server and database on a regular schedule so that you can recover in case of a system crash, data corruption, or other problems.

Application layer backups

You can make an application layer backup using persistent disks by using snapshots. You can back up the root disk and SAP binaries of the SAP Netweaver Suite. To obtain a consistent snapshot, you must first stop SAP Netweaver and the database from writing to the file system.

The following diagram shows snapshots of an application layer backup.

Diagram shows full and incremental snapshots of SAP application data on a
persistent disk

SAP ASE backups and restores

You can back up and restore an SAP ASE database using the dbbackup utility. You can use Google Storage as a backup destination for storing backup files and transaction log files. For further information, see Backup utility (dbbackup).

The SAP ASE database provides several options and commands to restore either the complete database or transaction logs from the backups taken to run a full or point-in-time recovery. For further reading, see SAP Note 1611715, How to restore an SAP ASE database server (Windows), and SAP ASE Database Backup Utility.

The following diagram shows snapshots of an ASE backup.

Diagram shows full and incremental snapshots of SAP ASE data on a persistent
disk

IBM Db2 backups and restores

You can back up an IBM Db2 database either online or offline.

  • Online mode—users continue to work during the backup.
  • Offline mode—database is shut down completely, and users cannot work during the backup.

The process for backing up depends on how many partitions your database has.

Single-partition database

In this configuration, you can perform a backup by signing in to the database server as user db2dbsid.

Execute the following command:

$db2 backup db DBSID

Multi-partition database

Sign in to the database server as user db2dbsid.

Execute the following command:

$db2 "backup db DBSID on ALL DBPARTITIONNUMS …"

You can also use the DBA Cockpit tool provided by IBM to perform a database backup.

For more information, see IBM Db2 Database Backup Method.

Recovery

IBM Db2 restore and recovery lets you restore the database from a successful backup. Recovery of the database is dependent on access to an up-to-date history file, because all information about backup images and log files is accessed from there.

You can recover from a backup using the RECOVER command:

  1. Sign in to the database server as user db2dbsid or sapsidadm.
  2. Execute the following command:
$ db2 RECOVER DB DBSID

To recover from a specific point in time:

  1. Sign in to the database server as user db2dbsid or sapsidadm.
  2. Execute the following command:
$ DB2 RECOVER DB DBSID to local time on the database server

For more information, see IBM Db2 Database Recovery method.

The following diagram shows snapshots of a Db2 backup.

Diagram shows full and incremental snapshots of IBM Db2 data on a persistent
disk

Important pre-deployment SAP Notes

Before beginning to deploy your SAP systems on Google Cloud, read the SAP Notes in the following list that are relevant to your planned configuration. Before proceeding with any SAP product implementation, always check the SAP Marketplace for updated product installation guides and notes.

For more information about installing ASE or IBM Db2, see the following pages: