This checklist will help you to improve the design, migration, implementation, and maintenance of your SAP NetWeaver landscapes on Google Cloud. These tips have been suggested by Google Cloud Support and the Professional Services Organization (PSO) to enable scalable, production-ready enterprise workloads.
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.
Click on a checklist item to see more information and click the box when you complete a task.
- To scale your SAP NetWeaver landscape and increase redundancy, run SAP central services, each SAP application server, and each database server in its own separate Compute Engine VM instance.
- Follow these guidelines to ensure the correct sizing for your VM instances:
- Before you move your existing systems from on-premises or other cloud environments, use your current workload statistics and utilization as a baseline for sizing when migrating to Google Cloud.
- If you don't size the VMs correctly for the load, when you combine multiple SAP System IDs with other business solutions, your applications might become resource constrained and run poorly.
- To learn more about sizing for SAP solutions on Google Cloud, see What is sizing? and the SAP Quick Sizer.
- If you choose to run more than one SAP application instance on the same
VM or run multiple application servers from the same SID on the same VM,
you should install them with different hostnames to allow you to relocate
such instances if they outgrow a single VM.
- SAP profiles contain the instance hostname in both the file name and in SAP variables like SAPLOCALHOST and SAPGLOBALHOST. Because of this property, we recommend that you configure alias IPs and alias hostnames for those instances from the start.
- To maintain mappings of the alias IPs and hostnames for the entire project, configure Cloud DNS in Google Cloud as a central resolver rather than using a local DNS resolver.
- To adjust your workloads dynamically as application demand rises and
falls, consider implementing SAP application auto-scaling mechanisms:
- In most large SAP environments, application server workloads have daily, predictable variations. Because the timing and rate of these workload changes are generally consistent and rarely change, these servers are great candidates to benefit from the elastic nature of cloud infrastructure.
- To benefit from auto-scaling options for your SAP workloads, see Best practices for SAP app server autoscaling.
- For more information about SAP configuration standards and supportability, see the SAP Support Portal Home and SAP on Google Cloud solutions.
- To learn which regions and zones support specific Compute Engine VMs, see Available regions and zones. Keep in mind that SAP NetWeaver-certified Compute Engine VMs might not be available in all locations.
- Choose your regions and zones for an SAP NetWeaver deployment based on your business locations. SAP NetWeaver instances must be placed in the same region, and the high-availability components (such as SAP central services) should be deployed in different zones within the region for maximum redundancy.
- To select the best regions for your SAP NetWeaver deployment, see Best practices for Compute Engine region selection.
- To select a network design that can withstand different types of system failure, see Designing robust systems.
When installing SAP NetWeaver, we recommend that you use one of the following automation tools to deploy SAP workloads on Google Cloud:
- Google Cloud Deployment Manager--An application that installs and configures all the required packages necessary to run SAP NetWeaver on Google Cloud. To use Deployment Manager and find the appropriate templates for your SAP solution (including high-availability setup), see Automating SAP deployments on Google Cloud with Deployment Manager.
- Terraform--A popular industry application for building, changing, and versioning infrastructure safely and efficiently. To use Terraform for deployment automation, see Terraform scripts and Using Terraform with Google Cloud. (Note: Terraform is an open source, community-supported tool and not officially supported by Google Cloud Support.)
If your SAP NetWeaver deployment and installation requires a custom procedure (such as a manual installation, third-party tool, or provider), see the following deployment guides for manual setup and installation of SAP workloads:
- To select a machine type for your SAP NetWeaver deployment, see Certified machine types.
If you run SAP NetWeaver on the same host as SAP HANA in a two-tier architecture, the SAP HANA machine requirements apply. To see the SAP HANA certified machine types, see Certifications for SAP HANA on Google Cloud.
For OS image licensing, you can bring your own license provided by your OS vendor. If the guest OS image release you want isn't available in Google Cloud, you can import it as a custom image.
For more information about supported machine types, operating systems, and applications, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and VM types.
- For supported database types, vendors, and assigned SAP Application Performance Standard (SAPS), see the SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and VM types.
To learn about NFS and other file storage systems available for SAP NetWeaver Google Cloud, see Storage options for HA SAP systems on Google Cloud.
To secure the backup archives, you must store the backup files in a separate secure location. Here are some common choices:
- You can store the backups in Google Cloud Storage.
- You can store the archives on a drive in a custom or third-party location (for example, on-premises).
- You can also store the backups in Google Cloud by using Filestore or the NetApp Cloud Volumes Service.
- You should store multiple copies in multiple locations on different media types to assure recoverability.
Define the backup frequency and retention period for your file system data and database files based on your business needs for the recovery point objective (RPO) and the recovery time objective (RTO).
For more information about backup options for SAP NetWeaver, see SAP on Google Cloud: Backup strategies and solutions.
- To view the supported SAP configurations for high availability, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and VM types.
- For landscapes using SUSE Linux Enterprise Server (SLES) or Red Hat
Enterprise Linux (RHEL), the Pacemaker cluster application provides you
with the resources to configure your SAP applications in a
high-availability configuration. When using Pacemaker:
- For the RHEL and SLES operating systems, use Internal TCP/UDP Load Balancing to manage the virtual IP (VIP) address. The Load Balancer provides a highly available service and creates a floating VIP that can direct traffic between VMs in a cluster.
For Windows-based environments, the Windows native failover cluster feature provides high availability. For more information, see the following Windows OS resources:
If your landscape has VM instances that host multiple SAP systems with different system IDs, follow these high availability (HA) recommendations:
To provide high availability for SAP central services and database systems, configure high-availability mode by using one of Google Cloud's supported HA methods. See the High-availability planning guide for SAP NetWeaver or the SAP HANA high-availability planning guide.
To provide high availability for an IBM Db2 high-availability cluster in an SAP NetWeaver system, see the IBM Db2 high-availability cluster for SAP deployment guide.
To avoid associated complexities, do not run multiple software solutions in the same HA cluster. Instead, deploy software in the HA cluster (for example, SAP central services) on separate VMs that you've sized properly.
- Do not use different types of clustering software to manage resources on the same VM. The two cluster solutions might conflict with each other and could result in unexpected behavior.
- If you set up multiple services from different SAP
system IDs on the same high-availability VM cluster:
- The increased complexity hampers troubleshooting and recovery significantly.
- If a failure occurs, multiple systems can be impacted. Distributing resources reduces the extent of this impact.
If you choose a third-party failover solution for your SAP central services, document the setup and test it thoroughly.
For testing and rollout purposes, we recommend that you create a non-production HA system that is equivalent to your production environment.
- Although this might not be required by the business, you can use this test HA system to validate failover and maintenance procedures, perform extensive testing, and document the system for operational reference.
If you implement a standalone instance of SAP central services without high availability, make sure you document your manual procedure for the restore process and test it thoroughly.
- Note: SAP NetWeaver systems lacking high availability often result in longer service restoration times and unpredictable outages.
For more information about high availability, see SAP on Google Cloud: High availability.
- To learn about the ways to provide disaster recovery for SAP NetWeaver, see the Disaster recovery planning guide for SAP NetWeaver on Google Cloud.
- For integrated monitoring of the SAP NetWeaver infrastructure in
Google Cloud, use the Google Cloud monitoring agent for SAP
NetWeaver. The agent uses SAP ST06 monitoring tools.
- To set up the monitoring agent, see The Google Cloud monitoring agent for SAP NetWeaver and SAP Note 2469354 - Key Monitoring Metrics for SAP on IaaS Infrastructure.
- Ensure you implement a robust monitoring strategy for your application using SAP-native systems like Solution Manager or Focused Run, or appropriate third-party monitoring applications. Supplement this with Google Cloud Monitoring, which offers extensive cloud and operating system monitors with the ability to create custom metrics and alerts.
In addition to accessing SAP NetWeaver through a web interface or the SAP GUI, you might also need to establish inbound and outbound communication with other SAP solutions or third-party systems. Typical examples of this include IDOC interfaces, process integration with external business partners, and SAP Landscape Transformation Replication with on-premises reporting systems. To enable inbound and outbound interfaces, use the following resources to set up routing and firewall rules in your VPC network:
- SAP NetWeaver software supports a distributed architecture that allows the distribution of system instances over multiple virtual machines. This architecture provides benefits of both scale and redundancy.
- The distributed nature of SAP NetWeaver requires load balancing for
end-user requests. On Google Cloud you can use native SAP software
load balancing in combination with Google-native L4 or L7 load balancers,
or choose to set up third-party load balancers from the Google Cloud Marketplace.
- To explore options for a load-balancing strategy that considers the geographical location of users and the system landscape setup, see How to run SAP on Google Cloud if high availability is a high priority.
- To explore more ways to provide load-based system flexibility, see Best practices for SAP app server autoscaling on Google Cloud.