OS Deployment from Marketplace

Lesson: OS Deployment from Marketplace for SAP Infrastructure

Introduction: The Foundation of SAP Computing

In the modern enterprise landscape, the deployment of SAP systems is no longer a manual, multi-week process involving physical server racking and manual OS installation. Today, cloud providers offer automated marketplaces that allow architects to provision pre-configured, SAP-certified operating system images in minutes. Understanding how to leverage these marketplace images is critical for any SAP Basis administrator or cloud architect because the operating system serves as the foundational layer upon which the SAP application server, database management system, and underlying middleware reside.

Choosing the right OS image from a cloud marketplace is not merely a matter of picking a distribution; it is about selecting a pre-hardened, performance-tuned, and SAP-validated environment. When you deploy an OS from a marketplace, you are consuming an image that has been tested by both the cloud provider and SAP to ensure that kernel parameters, network configurations, and storage drivers are optimized for the specific demands of SAP HANA, NetWeaver, or S/4HANA workloads. If you get this initial step wrong, you risk performance bottlenecks, security vulnerabilities, and potential support issues with SAP itself.

This lesson explores the technical nuances of deploying OS images from cloud marketplaces, the criteria for selecting the right image, the configuration steps required to ensure compliance, and the best practices for maintaining these systems throughout their lifecycle. By mastering this process, you move from being a manual administrator to an automated infrastructure engineer, capable of spinning up complex SAP landscapes with consistency and reliability.

Understanding SAP-Certified Marketplace Images

Cloud marketplaces offer a variety of OS images, but not all are created equal. For SAP workloads, you must specifically look for images that are "SAP-certified" or "SAP-optimized." These images are distinct from standard, generic Linux or Windows Server images because they come with pre-configured settings that align with SAP’s technical requirements.

When you select an SAP-certified image, you are effectively inheriting a baseline configuration that includes:

• Tuned Kernel Parameters: Linux distributions like SUSE Linux Enterprise Server (SLES) or Red Hat Enterprise Linux (RHEL) for SAP have specific kernel settings for memory management, semaphore limits, and network throughput that are mandatory for SAP HANA.
• Pre-installed SAP Packages: Many marketplace images include the necessary repositories and packages (such as sapconf or tuned-adm profiles) that automatically apply performance tuning upon boot.
• Storage Driver Optimization: These images are tested against the specific block storage architectures of the cloud provider to ensure that I/O throughput meets the strict latency requirements of high-performance databases.
• Support Agreements: In many cases, using a marketplace image for SAP simplifies your support path. Because the cloud provider and the OS vendor (e.g., SUSE or Red Hat) have a joint support agreement, you can open a single ticket, and the vendors coordinate the resolution.

Callout: The "SAP-Optimized" vs. "Standard" Distinction It is a common mistake to assume that a standard OS image is sufficient for an SAP workload. While a standard image will technically run the SAP binaries, it lacks the specific performance tuning required for high-transaction environments. Standard images often fail to meet the SAP HANA Hardware Configuration Check Tool (HWCCT) requirements, leading to poor system performance and potential stability issues. Always prioritize images explicitly labeled for SAP.

Selecting the Right OS Distribution

The choice of operating system for SAP is largely dictated by your existing enterprise standards and the specific SAP product you are deploying. However, the two primary players in the SAP space are SUSE Linux Enterprise Server (SLES) for SAP Applications and Red Hat Enterprise Linux (RHEL) for SAP Solutions.

SUSE Linux Enterprise Server (SLES) for SAP

SLES is the most widely used operating system for SAP HANA. It is known for its deep integration with SAP’s own tools, such as the SAP HANA System Replication and Pacemaker for high availability. When you deploy a SLES for SAP image from a marketplace, you gain access to the "SAP-HANA-Stack" repositories, which provide all the necessary dependencies for a smooth installation.

Red Hat Enterprise Linux (RHEL) for SAP

RHEL for SAP has gained significant market share due to its stability and the familiarity many system administrators have with the Red Hat ecosystem. RHEL provides specific "SAP Solutions" subscriptions that include the necessary packages for high availability, including the RHEL High Availability Add-On.

Comparison Table: SLES vs. RHEL for SAP

Step-by-Step: Deploying from the Cloud Marketplace

While the specific user interface varies between Azure, AWS, and Google Cloud, the conceptual workflow for deploying an OS image remains consistent. We will walk through the general process, focusing on the critical decision points.

1. Searching the Marketplace

Navigate to your cloud provider's marketplace and search for "SLES for SAP" or "RHEL for SAP." Do not simply search for "Ubuntu" or "CentOS" unless you have a specific, non-production use case, as these are generally not supported for production SAP environments.

2. Selecting the Version

Always choose the latest long-term support (LTS) version that is certified for your specific SAP version. SAP publishes a Product Availability Matrix (PAM) that explicitly lists which OS versions are supported for which SAP release. Checking the PAM is a non-negotiable step before clicking "Deploy."

3. Configuring Instance Details

When setting up the virtual machine, pay close attention to:

• Region and Zone: Ensure your compute instance is in the same zone as your storage (e.g., managed disks or elastic block storage) to minimize latency.
• Instance Type: SAP has strict memory-to-CPU ratios. Use the cloud provider’s sizing calculator to select a "memory-optimized" instance type.
• Networking: Deploy within a private subnet. SAP systems should never be exposed directly to the public internet.

4. Storage Provisioning

This is where most deployments fail. SAP HANA requires high-performance storage for the /hana/data and /hana/log volumes. Even if you use a marketplace image, the default storage might be general-purpose SSD. You must manually provision high-performance block storage or use the cloud-native "ultra-disk" or "io2" equivalent to meet the IOPS and throughput requirements mandated by SAP.

Warning: The Storage Trap Marketplace images provide the operating system but rarely configure the data storage for SAP HANA. It is a critical error to deploy an OS image and assume the storage is ready for an SAP installation. You must manually attach, format, and mount the high-performance volumes required for the database data and logs according to the SAP storage documentation.

Automation and Infrastructure as Code (IaC)

Manually clicking through a marketplace UI is acceptable for a sandbox environment, but for production SAP landscapes, you should use Infrastructure as Code (IaC). Tools like Terraform or Bicep allow you to define the marketplace image reference in code, ensuring that every deployment is identical.

Example: Terraform Snippet for OS Deployment

Below is a conceptual example of how to reference a marketplace image in Terraform. This ensures that you are always deploying the exact version validated by your team.

resource "azurerm_linux_virtual_machine" "sap_app_server" {
  name                = "sap-app-01"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  size                = "Standard_E8ds_v4"
  admin_username      = "sapadmin"

  source_image_reference {
    publisher = "suse"
    offer     = "sles-sap-15-sp3"
    sku       = "gen2"
    version   = "latest"
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Premium_LRS"
  }
}

In this snippet, the source_image_reference block points to the marketplace image. By using version = "latest", you automatically consume the latest security patches. However, in a strict production environment, you might replace "latest" with a specific version number to prevent unexpected changes during a redeployment.

Post-Deployment Configuration and Hardening

Once the OS is deployed, it is not "SAP-ready" until you perform the post-deployment configuration. Even with a marketplace image, you must verify that the environment meets your organization's security and performance standards.

Key Post-Deployment Tasks:

1. Repository Registration: Ensure the OS is properly registered with the vendor (SUSE or Red Hat) to receive updates. If the system cannot reach the update servers, it will quickly fall out of compliance.
2. Kernel Tuning Verification: Run the sapconf or tuned-adm command to confirm the active profile.
   • For RHEL: tuned-adm active (should show sap-hana)
   • For SLES: systemctl status sapconf
3. Filesystem Layout: Create the standard SAP directory structure (/usr/sap, /hana/data, /hana/log, /hana/shared) and ensure the mount points have the correct permissions.
4. Network Hostname: Ensure the hostname is fully qualified and matches the DNS settings. SAP relies heavily on hostname resolution for inter-process communication.

Note: The Importance of /etc/hosts SAP systems are notoriously sensitive to hostname changes. Always ensure that the hostname is set correctly at the OS level during the initial deployment and that the /etc/hosts file contains the correct mapping of the IP address to the fully qualified domain name (FQDN). Modifying these after the SAP software is installed can lead to complex licensing and connectivity issues.

Common Pitfalls and How to Avoid Them

1. Ignoring the Product Availability Matrix (PAM)

The most common mistake is deploying an OS version that is "too new" for the SAP software version you intend to install. SAP software support is tied to specific kernel versions. Always check the PAM to ensure compatibility.

2. Failing to Configure NTP

SAP HANA requires strict time synchronization across all nodes in a cluster. If your OS deployment does not include an NTP configuration (or Chrony), your high-availability cluster will fail to form, and database replication will stop.

3. Using Ephemeral Storage for Databases

Some cloud instances come with local, ephemeral storage. This storage is fast but volatile; if the instance is rebooted or deallocated, all data is lost. Never place SAP database files on ephemeral storage. Use persistent, high-performance block storage specifically designed for databases.

4. Overlooking Security Groups and Firewalls

Marketplace images often come with default firewall settings. You must audit these settings to ensure that the ports required by SAP (e.g., 32xx for the dispatcher, 33xx for the message server) are open, while ensuring that administrative ports like SSH (22) are restricted to your corporate VPN or Bastion host.

Best Practices for Lifecycle Management

Deploying an OS image is just the beginning. A lifecycle management strategy ensures that your SAP infrastructure remains secure and performant.

• Image Patching: Do not rely on "in-place" upgrades for major OS versions. Instead, adopt a "Blue-Green" deployment strategy where you deploy a new instance with the updated OS, migrate the SAP application, and decommission the old instance.
• Automated Hardening: Use configuration management tools like Ansible to apply your organization’s security hardening policies (e.g., disabling unnecessary services, setting password complexity, configuring log rotation) immediately after the OS is provisioned.
• Monitoring: Integrate the OS with your cloud provider’s monitoring agent (e.g., Azure Monitor, CloudWatch) to track CPU, memory, and disk I/O. Use the SAP-specific monitoring extensions to gain visibility into the SAP process health.
• Backup and Snapshotting: Before making any configuration changes to the OS, take a snapshot of the root disk. This allows for an instant rollback if a kernel update or a configuration change causes the system to become unstable.

Comparison: Manual vs. Marketplace vs. IaC

To truly understand where marketplace deployment fits, we should compare it to other common methods:

The marketplace image provides the "Gold Standard" baseline. By using IaC to deploy that marketplace image, you achieve the best of both worlds: the speed and reliability of a tested image, combined with the precision of automated configuration.

Managing SAP-Specific Services

Once your OS is up and running, you will need to manage the SAP-specific services that are often bundled with marketplace images. On SLES for SAP, for example, the sapconf service is instrumental in keeping the system tuned.

Example: Checking SAP-Specific Service Status

You can verify the status of the tuning service using the following command:

# On SLES for SAP
systemctl status sapconf

# If it is not running, start it
systemctl enable --now sapconf

It is also important to verify the network configuration. SAP systems often require multiple network interfaces (NICs). One NIC might be for the public or internal application traffic, while another is reserved for the high-speed replication traffic between HANA nodes. Always verify these interfaces are configured with the correct MTU (Maximum Transmission Unit) settings, as SAP HANA often requires an MTU of 9000 (Jumbo Frames) for replication traffic to maximize throughput.

Security Considerations

Deploying from a marketplace requires a shift in how you handle security. Since these images are public, you must assume that the default settings are not sufficient for your specific security policy.

1. SSH Key Management: Disable password authentication entirely and force the use of SSH keys.
2. User Access: Remove all default users provided by the marketplace image except for the sapadm or the primary admin user you have created.
3. Audit Logging: Ensure that auditd is configured to log all system calls, particularly those related to the SAP binaries and configuration files.
4. Endpoint Protection: Install your enterprise-standard security agent (e.g., CrowdStrike, SentinelOne) immediately upon deployment. Ensure that the agent does not interfere with the high-speed I/O required by the SAP HANA database.

Callout: The "Shared Responsibility" Model When using marketplace images, remember the shared responsibility model. The cloud provider and the OS vendor are responsible for the security and maintenance of the base image. You are responsible for the configuration, the security hardening, the patching of the installed software, and the data stored within the system. Never assume the "SAP-certified" label implies the system is inherently secure for your specific environment.

Advanced Troubleshooting

Even with the most refined deployment process, issues arise. When a system fails to boot or perform as expected, follow these troubleshooting steps:

• Check the Console Logs: Most cloud providers offer a "Serial Console" or "Boot Diagnostics" view. If the OS hangs during boot, this is the first place to look. It will show you if the kernel is panicking or if a filesystem is failing to mount.
• Verify Cloud-Init Logs: If you use cloud-init to automate your post-deployment tasks, check /var/log/cloud-init.log. This file contains the results of your automation scripts. If your disk mounts or user creation failed, the error will be documented here.
• Analyze I/O Latency: If the system is slow, use iostat or iotop to identify if the bottleneck is at the disk level. SAP HANA is extremely sensitive to disk latency; if your latency exceeds the thresholds defined by SAP (typically < 1ms for log writes), you will experience severe performance degradation.

Summary and Key Takeaways

Deploying an OS from a marketplace is the modern standard for SAP infrastructure. It reduces the complexity of base installation, ensures compatibility with SAP requirements, and provides a consistent starting point for your SAP landscape. By following the practices outlined in this lesson, you ensure that your SAP systems are built on a solid, performant, and secure foundation.

Key Takeaways:

1. Prioritize Certified Images: Always use SAP-certified images (SLES for SAP or RHEL for SAP) to ensure that the OS kernel and packages are optimized for SAP HANA and NetWeaver.
2. Consult the PAM: Never assume compatibility. Always cross-reference your OS version with the SAP Product Availability Matrix (PAM) for the specific SAP software version you are installing.
3. Storage is Critical: The OS image is only the shell. You must manually provision high-performance, persistent block storage for SAP databases, as marketplace defaults are rarely sufficient for production workloads.
4. Use IaC for Consistency: Move away from manual UI deployments. Use Terraform or Bicep to automate the deployment of marketplace images to ensure consistency across development, quality assurance, and production environments.
5. Hardening is Mandatory: Marketplace images are generic. You must apply your organization’s security hardening policies and verify that the OS is registered for updates immediately after deployment.
6. Monitor Performance: SAP is resource-intensive. Use cloud-native monitoring tools to track the health of the OS and the underlying infrastructure, paying close attention to I/O latency and memory pressure.
7. Lifecycle Matters: Treat your OS deployments as ephemeral. Instead of patching in place, adopt a strategy of replacing instances with updated images to ensure that your configurations remain clean and predictable over time.

By mastering these concepts, you transition from managing individual servers to orchestrating robust, scalable SAP environments that can adapt to the changing needs of the enterprise. The marketplace is your starting point, but your architectural decisions regarding storage, security, and automation determine the ultimate success of your SAP infrastructure.