VM Resizing for Optimization

Module: Maintain SAP Workloads

Section: Performance and Cost Optimization

Lesson: VM Resizing for Optimization

Introduction: The Necessity of Right-Sizing SAP Workloads

When managing SAP environments in the cloud, one of the most critical operational tasks is ensuring that your Virtual Machines (VMs) are sized correctly. Unlike on-premises environments where hardware is fixed for years, cloud infrastructure allows for dynamic adjustment. However, many organizations fall into the trap of "over-provisioning," where they assign significantly more CPU and RAM to an SAP instance than it actually requires. This leads to unnecessary monthly expenditures and, in some cases, can even degrade performance due to hypervisor overhead or non-optimal memory-to-CPU ratios.

VM resizing for optimization is the process of periodically evaluating the performance metrics of your SAP application servers, database servers, and central services, and adjusting their instance types to better match actual usage patterns. This lesson covers the methodologies, technical considerations, and best practices for resizing SAP workloads without compromising the stability of your mission-critical business processes.

Why does this matter? For a large SAP deployment, a 20% reduction in over-provisioned resources can equate to tens of thousands of dollars in annual savings. Beyond cost, correct sizing ensures that the SAP HANA database, which relies heavily on memory-to-CPU ratios, operates within the parameters defined by SAP’s hardware certification programs. By mastering VM resizing, you transition from being a passive infrastructure consumer to an active architect of your SAP landscape.

Understanding SAP-Specific Sizing Requirements

Before you can resize a VM, you must understand that SAP workloads are not typical web servers. They have specific requirements regarding memory bandwidth, storage I/O throughput, and CPU architecture. SAP publishes "SAPS" (SAP Application Performance Standard) benchmarks for various cloud instance types. When you resize a VM, you are not just changing the number of cores; you are changing the underlying performance characteristics of the hardware.

Key Metrics to Monitor

To make informed decisions about resizing, you must aggregate data over a significant period. A single day of high usage does not justify keeping a large VM running if the average utilization is low.

• CPU Utilization: Look for the 95th percentile of CPU usage. If your SAP application servers consistently sit below 30% utilization, they are prime candidates for downsizing.
• Memory Utilization: SAP HANA is an in-memory database. If you are resizing a HANA database server, you must ensure that the new instance type has enough physical RAM to hold the entire data set plus room for delta merges and system processes.
• I/O Throughput and IOPS: Database servers are often constrained by disk speed rather than CPU. Before downsizing a database VM, verify that the new instance type supports the same or higher disk throughput limits.
• Network Bandwidth: For distributed SAP landscapes, the network throughput between the app server and the database is vital. Check if your current VM size is a "bottleneck" that limits data transfer speeds.

Callout: The "Right-Size" Philosophy Right-sizing is not about choosing the smallest possible instance. It is about choosing the instance that provides the best balance between cost and consistent performance. An undersized SAP system will lead to user complaints, long-running batch jobs, and potential database locks, which are far more expensive than the cost of a slightly larger VM.

Step-by-Step Methodology for Resizing

Resizing a VM in a cloud environment generally follows a standard lifecycle. While the specific commands vary between providers like Azure, AWS, or Google Cloud, the logical steps remain consistent.

Step 1: Performance Baselines

Before making any changes, collect at least 30 days of performance data. Use native cloud monitoring tools (e.g., Azure Monitor, CloudWatch) to track CPU, RAM, and Disk metrics. Export this data to a spreadsheet or a time-series database to visualize trends.

Step 2: Validation Against SAP Certification

Check the SAP Certified IaaS Platforms list. Every instance type you consider must be officially certified for the specific SAP database (HANA, ASE, DB2, etc.) you are running. Using a non-certified instance type can lead to lack of support from SAP in the event of a critical failure.

Step 3: Scheduling the Maintenance Window

Resizing almost always requires a virtual machine reboot. For an SAP system, this means a planned outage. Coordinate this with your business stakeholders. If you have a high-availability (HA) setup, you can perform a "rolling" resize, where you resize the standby node first, failover the production workload, and then resize the original primary node.

Step 4: The Execution Process

1. Stop the SAP Instance: Use the SAP Management Console or OS-level commands (stopsap) to gracefully shut down the application.
2. Snapshot the Disks: Always take a full snapshot of your OS and Data disks before resizing. If the new instance type fails to boot, you need a recovery path.
3. Perform the Resize: Use the cloud console or CLI to change the instance type.
4. Restart and Verify: Boot the VM and check the /var/log/messages or system event logs for hardware-related errors.
5. Start SAP: Bring the SAP services back online and monitor the "Work Process" overview in transaction SM50 to ensure performance is stable.

Technical Considerations: Code and Configuration

When you change the underlying hardware of a VM, you may need to update OS-level settings to optimize the new resources. For example, if you move from an instance with 16 vCPUs to one with 64 vCPUs, you may need to adjust the SAP profile parameters.

Example: Adjusting SAP Profile Parameters

After increasing CPU capacity, you might need to increase the number of available work processes to take advantage of the additional cores.

# Example: Using the SAP 'sapcontrol' utility to check current processes
# This command helps verify if the system recognizes the new hardware capacity
sapcontrol -nr <InstanceNumber> -function GetProcessList

# If you need to change the number of work processes, 
# you modify the instance profile file (usually located in /sapmnt/<SID>/profile/)
# Example line in the profile:
rdisp/wp_no_dia = 20
rdisp/wp_no_btc = 10

Note: Always perform a backup of your profile files before editing. A syntax error in the SAP profile can prevent the application server from starting, leading to an extended, unnecessary downtime period.

Comparing Instance Families

When selecting a target instance for resizing, you must understand the "Family" logic used by cloud providers. Usually, instances are categorized based on their primary strength:

Choosing the Right Family

If you are running an SAP HANA database, you should almost exclusively look at Memory Optimized instances. These instances are designed to provide high memory bandwidth, which is essential for the column-store operations used by HANA. If you move a HANA database to a Compute Optimized instance, even if the CPU count is the same, you will likely see a significant degradation in query response times because the memory bus is not optimized for the data-intensive nature of the database.

Best Practices and Industry Standards

To avoid the common pitfalls associated with resizing, follow these industry-accepted practices.

1. The "One-Change-At-A-Time" Rule

Never resize a VM and perform an OS update or a kernel upgrade at the same time. If the system fails to start, you will not know whether the issue was caused by the hardware change or the software update. Isolate your variables to simplify troubleshooting.

2. Monitor Cost vs. Performance

Set up automated alerts for your cloud spend. If a resize leads to an unexpected increase in costs (e.g., you accidentally chose an instance with premium storage billing), you want to know within 24 hours, not at the end of the billing cycle.

3. Leverage "Burstable" Instances Carefully

Some cloud providers offer "burstable" instances where you pay for a base level of performance and can "burst" to higher performance for short periods.

• Warning: Do not use burstable instances for production SAP HANA databases. The performance throttling that occurs when you exhaust your "CPU credits" will cause the database to hang, leading to severe application-level errors and potential data corruption.

4. Tagging and Documentation

Every time you resize a VM, document the reason in your configuration management database (CMDB). Tag the resource with the date of the change and the person who authorized it. This provides an audit trail that is essential for compliance and internal governance.

Common Pitfalls and How to Avoid Them

Even experienced basis administrators make mistakes during resizing. Here are the most common traps and how to navigate them.

Pitfall 1: Ignoring Storage Throughput Limits

A common mistake is assuming that if you have enough CPU and RAM, the system will run fine. However, cloud VMs often have strict limits on disk I/O throughput (measured in MB/s) and IOPS. If you downsize to a smaller instance type, you might inadvertently lower your disk throughput limit, causing the database to "wait" for the disk, resulting in high "Direct Read" times in SAP.

• Avoidance: Before resizing, check the documentation for your current instance and the target instance. Ensure the "Max Disk Throughput" is equal to or greater than your current peak usage.

Pitfall 2: Memory-to-CPU Ratio Mismatch

SAP HANA expects a specific ratio of memory to CPU. If you move to an instance that provides a high amount of RAM but very few CPUs, you may find that the system cannot process parallel queries efficiently.

• Avoidance: Stick to the SAP-certified instance configurations. Do not try to "mix and match" custom sizes that have not been validated by the SAP HANA hardware certification team.

Pitfall 3: Failing to Update Cloud-Init or Agents

Some cloud platforms require specific agents (like the Azure VM Agent or AWS SSM Agent) to be updated when moving between major instance generations (e.g., moving from a Gen4 to a Gen5 instance).

• Avoidance: Always review the provider's migration documentation for the specific instance family you are moving to.

Callout: The Importance of HA and DR If you are resizing a production environment, ensure your HA (High Availability) setup is fully synchronized before you begin. If you resize the primary node and it fails to come back up, you should be able to failover to the secondary node immediately. Never resize both nodes of an HA pair simultaneously.

Advanced Scenarios: Automated Resizing

In mature cloud environments, you can move beyond manual resizing. Many organizations use Infrastructure as Code (IaC) tools like Terraform or Bicep to manage their SAP landscape.

Using Terraform for Resizing

Instead of clicking through a web console, you define your VM size in a configuration file. When you need to resize, you simply update the instance_type variable and run a deployment.

# Example snippet of a Terraform configuration for an SAP App Server
resource "azurerm_linux_virtual_machine" "sap_app" {
  name                = "sap-app-01"
  resource_group_name = var.resource_group
  location            = var.location
  size                = "Standard_E8ds_v4" # Change this to resize the VM

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

By using IaC, you ensure that the entire infrastructure configuration is version-controlled. If a resize causes issues, you can easily "roll back" to the previous configuration by reverting the commit in your Git repository. This removes human error from the process of selecting the wrong instance size or missing a configuration setting.

Performance Tuning Post-Resize

After you have successfully resized the VM, your job is not finished. You must verify that the SAP system is actually utilizing the new resources effectively. Use the following transaction codes (T-Codes) to verify performance:

• ST06 (Operating System Monitor): Check the OS-level view to ensure the CPU and Memory metrics look healthy.
• DB02 (Database Statistics): Monitor the HANA database performance. Look for high "Long-running statements" or "Memory allocation" issues that might indicate the new hardware is not meeting demand.
• ST02 (Tune Summary): Check the SAP buffer hit ratios. If your buffers are now too small for the increased workload capacity, you may need to adjust the profile parameters again to allocate more memory to the SAP buffers.
• SM66 (Global Work Process Overview): See if your work processes are waiting on locks or I/O. If you see high wait times, the system might still be constrained despite the resize.

Quick Reference: Resizing Checklist

Use this checklist every time you plan a resize project:

1. Baseline: Is there 30 days of performance data?
2. Certification: Is the target instance type SAP-certified?
3. Throughput: Does the target instance meet the disk I/O requirements?
4. Backups: Is there a full snapshot of the VM?
5. Schedule: Is there a documented maintenance window?
6. Communication: Have the business stakeholders been notified of the outage?
7. Rollback: Is there a clear plan to revert if the new instance fails to boot?

FAQ: Common Questions on SAP VM Resizing

Q: How often should I resize my SAP VMs? A: There is no set frequency. However, you should review your sizing every 6 months or after any major business event (e.g., a large acquisition or a significant increase in user count).

Q: Can I resize a VM without stopping it? A: In most public cloud environments, resizing requires a "Deallocate/Stop" and "Start" operation. You cannot perform a live resize of a running VM while maintaining the SAP application state, as the hardware memory and CPU are re-initialized during the boot process.

Q: Does resizing affect my SAP license? A: Generally, no. SAP licenses are usually tied to the System ID (SID) or the hardware key, but not the specific cloud instance size. However, always check your specific SAP contract terms, especially if you are moving between different hardware architectures.

Q: What if I resize and performance gets worse? A: If performance degrades, first check the OS-level logs to ensure there are no hardware errors. If the OS is clean, check the disk I/O throughput. If throughput is the issue, you may need to increase the size of your disks or switch to a higher-tier storage option rather than just resizing the VM.

Key Takeaways

1. Data-Driven Decisions: Never resize based on intuition. Always use historical performance data (CPU, RAM, I/O) to justify your changes.
2. Certified Hardware Only: Always cross-reference your chosen cloud instance type with the official SAP hardware certification directory to ensure ongoing vendor support.
3. Storage is King: In SAP HANA environments, disk throughput and memory bandwidth are often more important than raw CPU count. Always check storage limits before downsizing.
4. The Maintenance Window: Always treat a resize as a major infrastructure change. Plan for a full shutdown, take snapshots, and have a clear rollback strategy in place.
5. IaC for Consistency: Move toward using Infrastructure as Code to manage your environment. This reduces configuration drift and allows for easy rollbacks if a resize does not yield the expected results.
6. Post-Resize Monitoring: Resizing is not "set it and forget it." Spend time in transactions like ST06, DB02, and ST02 after the move to ensure the system is tuned to the new capacity.
7. Avoid Burstable Instances: For production databases, avoid burstable or "shared-core" instances, as the performance throttling can lead to catastrophic application failures during peak load.

By following these principles, you ensure that your SAP landscape remains cost-effective and performant. Right-sizing is a fundamental skill for any cloud-based SAP administrator, serving as the bridge between operational efficiency and business agility. As you continue to manage your workloads, keep these practices at the forefront of your strategy, and you will effectively minimize costs while maintaining the high availability that SAP users demand.