This guide provides an overview of how SAP Adaptive Server Enterprise (ASE) works on Google Cloud, and provides details that you can use when planning the implementation of a new SAP ASE system.
For details about how to deploy SAP ASE on Google Cloud, see:
Google Cloud basics
Google Cloud consists of many cloud-based services and products. When running SAP products on Google Cloud, you mainly use the IaaS-based services offered through Compute Engine and Cloud Storage, as well as some platform-wide features, such as tools.
See the Google Cloud platform overview for important concepts and terminology. This guide duplicates some information from the overview for convenience and context.
For an overview of considerations that enterprise-scale organizations should take into account when running on Google Cloud, see best practices for enterprise organizations.
Interacting with Google Cloud
Google Cloud offers three main ways to interact with the platform, and your resources, in the cloud:
- The Google Cloud Console, which is a web-based user interface.
gcloudcommand-line tool, which provides a superset of the functionality that Cloud Console offers.
- Client libraries, which provide APIs for accessing services and management of resources. Client libraries are useful when building your own tools.
SAP deployments typically utilize some or all of the following Google Cloud services:
|VPC Networking||Connects your VM instances to each other and to the Internet. Each instance is a member of either a legacy network with a single global IP range, or a recommended subnet network, where the instance is a member of a single subnetwork that is a member of a larger network. Note that a network cannot span Google Cloud projects, but a Google Cloud project can have multiple networks.|
|Compute Engine||Creates and manages VMs with your choice of operating system and software stack.|
|Persistent disks||Persistent disks are available as either standard hard disk drives (HDD) or solid-state drives (SSD).|
|Google Cloud Console||Browser-based tool for managing Compute Engine resources. Use a template to describe all of the Compute Engine resources and instances you need. You don't have to individually create and configure the resources or figure out dependencies, because the Cloud Console does that for you.|
|Cloud Storage||You can back up your SAP database backups into Cloud Storage for added durability and reliability, with replication.|
|Cloud Monitoring||Provides visibility into the deployment, performance, uptime, and health of
Compute Engine, network, and persistent disks.
Monitoring collects metrics, events, and metadata from Google Cloud and uses these to generate insights through dashboards, charts, and alerts. You can monitor the compute metrics at no cost through Monitoring.
|IAM||Provides unified control over permissions for Google Cloud resources. Control who can perform control-plane operations on your VMs, including creating, modifying, and deleting VMs and persistent disks, and creating and modifying networks.|
Pricing and quotas
Google Cloud resources are subject to quotas. If you plan to use high-CPU or high-memory machines, you might need to request additional quota. For more information, see Compute Engine resource quotas.
A basic single-node SAP ASE installation on Google Cloud comprises the following components:
- One Compute Engine VM running your SAP ASE database.
Four or five attached persistent disk drives:
Drive contents Linux Windows Root directory of the database instance sybase/[DBSID] ASE (D:) Database data files /sybase/[DBSID]/sapdata ASE Data (E:) Database transaction logs /sybase/[DBSID]/logdir ASE Log (L:) Database temporary table space /sybase/[DBSID]/saptmp ASE Temp (T:) Diagnostic tablespace for SAPTOOLS /sybase/[DBSID]/sapdiag Not applicable
Optionally, you can expand your installation to include the following as well:
- A drive for backups. On Linux the backup drive is
/sybasebackup. On Windows it is
- A NAT gateway. A NAT gateway allows you to provide Internet connectivity for your VMs while denying direct Internet connectivity to those VMs. You could also configure this VM as a bastion host that allows you to establish SSH connections to the other VMs on your private subnet. See NAT gateways and bastion hosts for more information.
NetWeaver directories, including:
/usr/sapon Linux or
SAP (S:)on Windows
/sapmnton Linux or
Pagefile (P:)on Windows
A warm standby server, which you need to set up if you're using SAP ASE's always-on high-availability disaster recovery (HADR) option. The warm standby server requires the same disk configuration as a basic SAP ASE installation.
For important software requirements for the SAP ASE always-on option, see Supported SAP ASE features.
For more information about setting up HADR for SAP ASE, see the HADR Users Guide.
Fault manager servers, such as Pacemaker and other such high-availability resource management software, are not currently supported with SAP ASE on Google Cloud.
Different use cases might require additional devices or databases. For more information, see SAP ASE Configuration Guide for UNIX > Optional Devices and Databases.
In many ways, running SAP ASE on Google Cloud is similar to running it in your own data center. You still need to think about computing resources, storage, and networking considerations. For more information, see SAP Note 2537664: SAP ASE 16.0 Certification Report for Google Cloud.
SAP ASE is certified to run on all Compute Engine machine types, including custom types. For information about different machine types and their use cases, see Machine Types in the Compute Engine documentation.
The number of vCPUs required varies depending on the application load on SAP ASE. You should allocate a minimum of two vCPUs to your SAP ASE installation. Follow the Performance and Tuning Guides for SAP ASE to achieve best use of existing resources, and then increase your computing resources as needed.
Your SAP ASE VM should have at least 4 GB of RAM per vCPU. Of this amount, approximately 80% of your RAM should be allocated to SAP ASE, with the rest allocated to the OS on which SAP ASE is running.
The optimal amount of memory for your use case depends on the complexity of the queries you're running, the size of your data, the amount of parallelism you're using, and the level of performance you're expecting. For further guidance about optimizing your memory configuration, see the SAP ASE Performance and Tuning Series.
By default, each Compute Engine VM has a small root persistent disk that contains the operating system. In addition, you should create, attach, format, and mount additional disks for your database, your logs, and your stored procedures.
Your disk size and performance requirements will depend on your application. Size each device according to your needs.
For more information about the persistent disk options for SAP ASE, see Persistent disks.
For guidance from SAP on disk sizing, see Configuration Guide for UNIX > Determine the Size of a Database Device.
Supported SAP ASE versions
SAP has certified the following SAP ASE versions on Google Cloud:
- SAP ASE 16.0 SP02 PL06 HF1
- SAP ASE 16.0 SP02 PL07
- SAP ASE 16.0 SP03
For more information about the supported SAP ASE versions on Google Cloud, see SAP Note 2537664.
Supported SAP ASE features
- Real Time Data Services
- Web Services
- SAP ASE High Availability option with native cluster managers
- Raw disk as database devices
- Kernel Process Mode
- Tivoli Storage Management
SAP ASE always-on option is supported on Google Cloud. For the supported operating system versions and requirements for the SAP ASE always-on option, see the SAP ASE documentation.
For more information about the supported SAP ASE features on Google Cloud, see SAP Note 2537664.
Supported operating systems
SAP supports SAP ASE on the following operating systems:
- Windows Server
Compute Engine provides current versions of these operating systems that you can use. For information about the operating system versions that are available from Compute Engine, see Images.
For the current operating system versions that SAP ASE supports, see SAP Note 2489781.
Regions and zones
When you deploy a VM, you must choose a region and zone. A region is a specific geographical location where you can run your resources, and corresponds to a data center location. Each region has one or more zones.
Global resources, such as preconfigured disk images and disk snapshots, can be accessed across regions and zones. Regional resources, such as static external IP addresses, can be accessed only by resources that are in the same region. Zonal resources, such as VMs and disks, can be accessed only by resources that are located in the same zone.
When choosing regions and zones for your VMs, keep the following in mind:
- The location of your users and your internal resources, such as your data center or corporate network. To decrease latency, select a location that is in close proximity to your users and resources.
- The location of your other SAP resources. Your SAP application and your database must be in the same zone.
Persistent disks are durable block storage devices that function similarly to the physical disks in a desktop or a server.
Compute Engine offers different types of persistent disks. Each type has different performance characteristics. Google Cloud manages the underlying hardware of persistent disks to ensure data redundancy and to optimize performance.
You can use any of the following Compute Engine persistent disk types:
- Standard persistent disks (
pd-standard), which are backed by standard hard-disk drives, are efficient and economical for handling sequential read-write operations, but are not optimized to handle high rates of random input-output operations per second (IOPS).
- Balanced persistent disks (
pd-balanced), which are backed by solid-state drives (SSD). Balanced persistent disks offer a balance between cost and performance.
- SSD persistent disks (
pd-ssd), which offer the best performance.
Persistent disk performance scales automatically with size, so you can adjust performance by resizing your existing persistent disks or adding more persistent disks to a VM.
The type of VM you are using and the number of vCPUs it contains also affects persistent disk performance.
Persistent disks are located independently from your VMs, so you can detach or move persistent disks to keep your data, even after you delete your VMs.
For more information about the different types of Compute Engine persistent disks, their performance characteristics, and how to work with them, see the Compute Engine documentation:
- Storage options
- Block storage performance
- Other factors that affect performance
- Adding or resizing zonal persistent disks
- Creating persistent disk snapshots
Local SSD (non-persistent)
Google Cloud also offers local SSD disk drives. Although local SSDs can offer some advantages over persistent disks, don't use them as part of an SAP ASE system. VM instances with local SSDs attached cannot be stopped and then restarted.
NAT gateways and bastion hosts
If your security policy requires truly internal VMs, you need to set up a NAT proxy manually on your network and a corresponding route so that VMs can reach the Internet. It is important to note that you cannot connect to a fully internal VM instance directly by using SSH. To connect to such internal machines, you must set up a bastion instance that has an external IP address and then tunnel through it. When VMs do not have external IP addresses, they can be reached only by other VMs on the network, or through a managed VPN gateway. You can provision VMs in your network to act as trusted relays for inbound connections, called bastion hosts, or network egress, called NAT gateways. For more transparent connectivity without setting up such connections, you can use a managed VPN gateway resource.
Using bastion hosts for inbound connections
Bastion hosts provide an external facing point of entry into a network containing private-network VMs. This host can provide a single point of fortification or audit and can be started and stopped to enable or disable inbound SSH communication from the Internet.
You can achieve SSH access to VMs that do not have an external IP address by first connecting to a bastion host. A complete hardening of a bastion host is outside the scope of this guide, but you can take some initial steps, including:
- Limit the CIDR range of source IPs that can communicate with the bastion.
- Configure firewall rules to allow SSH traffic to private VMs from only the bastion host.
By default, SSH on VMs is configured to use private keys for authentication. When using a bastion host, you log into the bastion host first, and then into your target private VM. Due to this two-step login, you should use SSH-agent forwarding to reach the target VM instead of storing the target VM's private key on the bastion host. You must do this even if you are using the same key-pair for both bastion and target VMs, as the bastion has direct access only to the public half of the key-pair.
Using NAT gateways for traffic egress
When a VM does not have an assigned, external IP address, it cannot make direct connections to external services, including other Google Cloud services. To allow these VMs to reach services on the Internet, you can set up and configure a NAT gateway. The NAT gateway is a VM that can route traffic on behalf of any other VM on the network. You should have one NAT gateway per network. Be aware that a single-VM NAT gateway should not be considered highly available, and cannot support high traffic throughput for multiple VMs. For instructions on how to set up a VM to act as a NAT gateway, see either the SAP ASE Deployment Guide for Linux or the SAP ASE Deployment Guide for Windows.
After your system is up and running, you can create custom images. You should create these images when you modify the state of your root persistent disk and want to be able to easily restore the new state. You should have a plan for how to manage the custom images you create. For more information, see Image Management Best Practices.
User identification and resource access
When planning security for an SAP deployment on Google Cloud, you must identify:
- The user accounts and applications that need access to the Google Cloud resources in your Google Cloud project
- The specific Google Cloud resources in your project that each user needs to access
You must add each user to your project by adding their Google account ID to the project as a member. For an application program that uses Google Cloud resources, you create a service account, which provides a user identity for the program within your project.
Compute Engine VMs have their own service account. Any programs that that run on a VM can use the VM service account, as long as the VM service account has the resource permissions that the program needs.
After you identify the Google Cloud resources that each user needs to use, you grant each user permission to use each resource by assigning resource-specific roles to the user. Review the predefined roles that IAM provides for each resource, and assign roles to each user that provide just enough permissions to complete the user's tasks or functions and no more.
If you need more granular or restrictive control over permissions than the predefined IAM roles provide, you can create custom roles.
For more information about the IAM roles that SAP programs need on Google Cloud, see Identity and access management for SAP programs on Google Cloud.
For an overview of identity and access management for SAP on Google Cloud, see Identity and access management overview for SAP on Google Cloud.
Networking and network security
Consider the information in the following sections when planning networking and security.
Minimum privilege model
One of your first lines of defense is to restrict who can reach your network and your VMs by using firewalls. By default, all traffic to VMs, even from other VMs, is blocked by the firewall unless you create rules to allow access. The exception is the default network that is created automatically with each project and has default firewall rules.
By creating firewall rules, you can restrict all traffic on a given set of ports to specific source IP addresses. You should follow the minimum privilege model to restrict access to the specific IP addresses, protocols, and ports that need access. For example, you should always set up a bastion host and allow SSH into your SAP NetWeaver system only from that host.
Custom networks and firewall rules
You can use a network to define a gateway IP and the network range for the VMs attached to that network. All Compute Engine networks use the IPv4 protocol. Every Google Cloud project is provided with a default network with preset configurations and firewall rules, but you should add a custom subnetwork and firewall rules based on a minimum privilege model. By default, a newly created network has no firewall rules and hence no network access.
Depending on your requirements, you might want to add additional subnetworks to isolate parts of your network. For more information, see Subnetworks.
The firewall rules apply to the entire network and all the VMs in the network. You can add a firewall rule that allows traffic between VMs in the same network and across subnetworks. You can also configure firewalls to apply to specific target VMs by using the tagging mechanism.
Some SAP products, such as SAP NetWeaver, require access to certain ports. Be sure to add firewall rules to allow access to the ports outlined by SAP.
Routes are global resources attached to a single network. User-created routes apply to all VMs in a network. This means you can add a route that forwards traffic from VM to VM within the same network and across subnetworks without requiring external IP addresses.
For external access to Internet resources, launch a VM with no external IP address and configure another virtual machine as a NAT gateway. This configuration requires you to add your NAT gateway as a route for your SAP instance. For more information, see NAT gateways and bastion hosts.
Google Cloud VPN
You can securely connect your existing network to Google Cloud through a VPN connection using IPsec by using Google Cloud VPN. Traffic traveling between the two networks is encrypted by one VPN gateway, then decrypted by the other VPN gateway. This protects your data as it travels over the Internet. You can dynamically control which VMs can send traffic down the VPN using instance tags on routes. Cloud VPN tunnels are billed at a static monthly rate plus standard egress charges. Note that connecting two networks in the same project still incurs standard egress charges. For more information, see the VPN Overview and Choosing a VPN Routing Option.
Securing a Cloud Storage bucket
If you use Cloud Storage to host your backups for your data and log, make sure you use TLS (HTTPS) while sending data to Cloud Storage from your VMs to protect data in transit. Cloud Storage automatically encrypts data at rest. You can specify your own encryption keys if you have your own key-management system.
For security best practices, see Cloud Storage Security.
Related security documents
Refer to the following additional security resources for your SAP environment on Google Cloud:
- Securely Connecting to VM Instances
- Security Center
- Compliance in the Google Cloud
- Google Cloud security whitepaper
- Google Infrastructure security design
Backup and recovery
You must have a plan for how to restore your system to operating condition if the worst happens. For general guidance about how to plan for disaster recovery using Google Cloud, see:
This section provides information about licensing requirements.
Running SAP ASE on Google Cloud requires you to bring your own license (BYOL). For more information, see:
- SAP Note 2446441 - Linux on Google Cloud Platform (IaaS): Adaption of your SAP License
- SAP Note 2456953 - Windows on Google Cloud Platform (IaaS): Adaption of your SAP License
For more information about SAP licensing, contact SAP.
Operating system licenses
In Compute Engine, there are two ways to license SLES, RHEL, and Windows Server:
With pay-as-you-go licensing, your Compute Engine VM hourly cost includes licensing. Google manages the licensing logistics. Your hourly costs are higher, but you have complete flexibility to increase and decrease your costs, as needed. This is the licensing model used for Google Cloud public images that include SLES, RHEL, and Windows Server.
With BYOL, your Compute Engine VM costs are lower because the licensing isn't included. You must migrate an existing license or purchase your own license, which means paying up front, and you have less flexibility.
For issues with Google Cloud infrastructure or services, contact Google Cloud Support. You can find contact information on the Support Overview page in the Google Cloud Console. If Google Cloud Support determines that a problem resides in your SAP systems, you are referred to SAP Support.
For SAP product-related issues, log your support request with SAP support. SAP evaluates the support ticket and, if it appears to be a Google Cloud infrastructure issue, transfers the ticket to the Google Cloud component BC-OP-LNX-GOOGLE or BC-OP-NT-GOOGLE.
Before you can receive support for SAP systems and the Google Cloud infrastructure and services that they use, you must meet the minimum support plan requirements.
For more information about the minimum support requirements for SAP on Google Cloud, see:
To deploy SAP ASE on Linux, see the SAP ASE Deployment Guide for Linux.
To deploy SAP ASE on Windows, see the SAP ASE Deployment Guide for Windows.