AWS for SAP
The Safe SUSE Upgrade: Avoiding Pitfalls When Upgrading AWS Instances
In this blog, we will discuss how to upgrade SUSE Linux Enterprise Server (SLES) to the next service pack and how to perform a major version upgrade from SLES 12 to SLES 15. SAP customers who are running their SAP workloads using SLES 12 or SUSE Linux Enterprise Server for SAP Applications (SLES for SAP)12 on AWS, need to plan for the end of general support on October 31, 2024. Although, the blog highlights SLES, the same commands and principles apply to SLES for SAP. Additionally, we will provide information on the mechanisms AWS Marketplace uses to identify Amazon EC2 instances launched using AWS Marketplace listings for SLES for SAP.
Since 2010, AWS and SUSE have worked together to provide a robust, secure, highly reliable, and cost optimized infrastructure to SAP customers which meets their application’s availability SLA and ensures efficiency. SUSE’s experience providing products and services for SAP customers on AWS is a key reason that AWS and SUSE announced their Strategic Collaboration Agreement (SCA) on September 8, 2022. The SCA between SUSE and AWS outlines shared programs and investment areas that will help ensure smoother migration of customers’ SAP landscapes to AWS.
AWS and SUSE publish Amazon Machine Images (AMIs) for SLES and SLES for SAP, which are built by SUSE, and provided and supported by AWS. Currently, SLES and SLES for SAP can be launched using the AWS Console, AWS Command Line Interface (CLI), or via one of the various SDKs available (such as the AWS SDK for SAP ABAP). These AMIs are available either under a Pay-As-You-Go (PAYG) model, or by Savings Plans or Reserved Instances, which offer a savings for advance usage commitments. SUSE also provides AMIs for customers who want to bring their existing subscriptions to AWS, through a Bring Your Own Subscription (BYOS) model. All of these AMIs are installed and bootable image of these products, that can be used to launch new Amazon Elastic Compute Cloud (Amazon EC2) instances. These AMIs are updated on a periodic basis for each supported version of SUSE Linux.
SAP customers need to update their SAP applications on a regular basis by applying support packages and patches at the application layer. In addition, SAP customers need to apply patches and security fixes to their SUSE Linux distribution as well through service packs. The SAP Lens for AWS Well-Architected Framework Best Practice 4.2 states that customers should regularly patch their SAP landscape and operating systems “to gain features, address issues, and remain compliant with governance.”
With the end of general support on October 31, 2024, SAP on AWS customers using SUSE Linux should work backwards from the end of general support date and create a project in their organization to upgrade the SUSE operating systems to the latest supported SLES 15 or SLES for SAP 15 version supported by SUSE and their SAP application. Customers should follow SUSE Product Lifecycle dates available on SUSE’s portal, and ensure that the Amazon EC2 instances are running supported versions of SLES or SLES for SAP and continue to plan for any upcoming end of general support dates.
SUSE’s service pack and major release upgrade
The following section will cover the SUSE upgrade process for service packs and major version upgrades. It will focus on SUSE tools that AWS customers have successfully used to perform SUSE Linux upgrades. Customers will need to consider SAP application related pre-requisites or AWS related pre-requisites that are not covered in this blog like stopping SAP and database (DB) applications, performing DB backups, and performing Amazon Elastic Block Store (Amazon EBS) snapshots.
In order for the upgrade process to be fully supported, the SLES Amazon EC2 instance must have an active support subscription. Additionally, SUSE documentation detailing the upgrade process for the SUSE Linux version you are upgrading should always be read for more details.
All SUSE commands are performed with root permissions.
Service pack upgrade SLES 15 Service Pack 3 (SP3) to SLES 15 SP5
In the example, the upgrade will be performed on SLES 15 SP3. SUSE recommends a two-step approach to complete service pack upgrades for SUSE Linux: (1) PREPARE and (2) MIGRATION.
The first step in the PREPARE phase is to identify the orphaned packages installed on the system. Orphaned packages are package files no longer referenced by any associated repositories. These packages will not be migrated and there is no guarantee they will work after the migration. To get the list of orphaned packages run:
zypper packages --orphaned
If the system contains orphaned packages, a determination will need to be made if the packages are required by the instance. For orphaned packages that are required, review if the package is supported on SLES 15 SP4 or if a later package version is required for SLES 15 SP4. If the package is not required the orphaned packages can be removed.
Before the service pack upgrade, ensure that the SLES Amazon Elastic Compute Cloud (EC2) instance is up to date with the latest available patches by running the following command:
zypper patch
Output will show a list of patches which are ready to update. It is important to read the command results as it may show a reboot is suggested or a package manager restart is required.
Next is the MIGRATION phase where the instance is updated by executing:
zypper migration
The command zypper migration executes a zypper patch-check --updatestack-only as part of the upgrade process which determines if required packages need to be installed and/or upgraded. Since the instance was patched in the previous step, there will not be any required patches to install.
The upgrade process will start validating the connected repositories that have a corresponding repository for the upgraded version of SLES. In the example, there are repositories connected to the system named ‘SUSE Cloud Application Platform Tools Module 15 SP3 x86_64’ and ‘Python 2 Module 15 SP3 x86_6’ that are no longer supported by SUSE and should be removed from the instance so the upgrade can be completed (Figure 1).
Executing 'zypper refresh' Repository 'SLE-Module-Basesystem15-SP3-Pool' is up to date. Repository 'SLE-Module-Basesystem15-SP3-Updates' is up to date. Repository 'SLE-Module-Containers15-SP3-Pool' is up to date. Repository 'SLE-Module-Containers15-SP3-Updates' is up to date. Repository 'SLE-Module-Desktop-Applications15-SP3-Pool' is up to date. Repository 'SLE-Module-Desktop-Applications15-SP3-Updates' is up to date. Repository 'SLE-Module-DevTools15-SP3-Pool' is up to date. Repository 'SLE-Module-DevTools15-SP3-Updates' is up to date. Repository 'SLE-Module-Legacy15-SP3-Pool' is up to date. Repository 'SLE-Module-Legacy15-SP3-Updates' is up to date. Repository 'SLE-Module-Public-Cloud15-SP3-Pool' is up to date. Repository 'SLE-Module-Public-Cloud15-SP3-Updates' is up to date. Repository 'SLE-Module-Python2-15-SP3-Pool' is up to date. Repository 'SLE-Module-Python2-15-SP3-Updates' is up to date. Repository 'SLE-Module-CAP-Tools15-SP3-Pool' is up to date. Repository 'SLE-Module-CAP-Tools15-SP3-Updates' is up to date. Repository 'SLE-Product-SLES15-SP3-Pool' is up to date. Repository 'SLE-Product-SLES15-SP3-Updates' is up to date. Repository 'SLE-Module-Server-Applications15-SP3-Pool' is up to date. Repository 'SLE-Module-Server-Applications15-SP3-Updates' is up to date. Repository 'SLE-Module-Web-Scripting15-SP3-Pool' is up to date. Repository 'SLE-Module-Web-Scripting15-SP3-Updates' is up to date. All repositories have been refreshed. Can't get available migrations from server: SUSE::Connect::ApiError: There are activated extensions/modules on this system that cannot be migrated. Deactivate them first, and then try migrating again. The product(s) are 'SUSE Cloud Application Platform Tools Module 15 SP3 x86_64, Python 2 Module 15 SP3 x86_64'. You can deactivate them with SUSEConnect -d -p sle-module-cap-tools/15.3/x86_64\n SUSEConnect -d -p sle-module-python2/15.3/x86_64 '/usr/lib/zypper/commands/zypper-migration' exited with status 1
Fig 1: ‘zypper migration’ output showing unsupported repositories
The next step is to remove the unsupported repositories so the migration can continue (Figure 2).
SUSEConnect -d -p sle-module-cap-tools/15.3/x86_64 SUSEConnect -d -p sle-module-python2/15.3/x86 #> SUSEConnect -d -p sle-module-cap-tools/15.3/x86_64 Deregistering system from registration proxy https://smt-ec2.susecloud.net Deactivating sle-module-cap-tools 15.3 x86_64 ... -> Removing service from system ... -> Removing release package ... #> SUSEConnect -d -p sle-module-cap-tools/15.3/x86_64\n SUSEConnect -d -p sle-module-python2/15.3/x86_64 Deregistering system from registration proxy https://smt-ec2.susecloud.net Deactivating sle-module-python2 15.3 x86_64 ... -> Removing service from system ... -> Removing release package ...
Fig 2: Deregistering unsupported repositories using SUSEConnect
If the command zypper patch was not run on the instance, an error will be encountered stating the instance cannot deregister the unsupported repositories using SUSEConnect. To resolve the issue the zypper patch command will need to be run.
After the modules are removed, re-run zypper migration. In the example there are two options available for SLES 15 SP3: SLES SP4 and SLES SP5 (Figure 3).
Available migrations: 1 | SUSE Linux Enterprise Server 15 SP5 x86_64 Basesystem Module 15 SP5 x86_64 Containers Module 15 SP5 x86_64 Desktop Applications Module 15 SP5 x86_64 Server Applications Module 15 SP5 x86_64 Development Tools Module 15 SP5 x86_64 Legacy Module 15 SP5 x86_64 Public Cloud Module 15 SP5 x86_64 Web and Scripting Module 15 SP5 x86_64 2 | SUSE Linux Enterprise Server 15 SP4 x86_64 Basesystem Module 15 SP4 x86_64 Containers Module 15 SP4 x86_64 Desktop Applications Module 15 SP4 x86_64 Server Applications Module 15 SP4 x86_64 Development Tools Module 15 SP4 x86_64 Legacy Module 15 SP4 x86_64 Public Cloud Module 15 SP4 x86_64 Web and Scripting Module 15 SP4 x86_64 [num/q]: 1
Fig 3: Selecting SLES 15 SP5 as the upgrade target version
After selecting the upgrade version, a notification of the packages that will be upgraded is displayed. This will be followed by a prompted to accept the terms of service. In order to proceed with the upgrade, the terms of service must be accepted. At the end of the upgrade, the instance will need to be rebooted. When the instance is available after the reboot, the upgrade can be verified by looking at the file /etc/os-release which will contain the SLES version or compare the instance’s SUSE Linux kernel version to SUSE’s published list of SUSE Linux Kernel versions and release date (Figure 4).
#> cat /etc/os-release NAME="SLES" VERSION="15-SP5" VERSION_ID="15.5" PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5" ID="sles" ID_LIKE="suse" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:15:sp5" DOCUMENTATION_URL=https://documentation.suse.com/ #> uname -r 5.14.21-150500.55.7-default
Fig 4: Contents of the /etc/os-release file and kernel version on an upgrade SLE instance
Major version upgrade
When customers perform a major version upgrade from SUSE Linux 12 to SUSE Linux 15, SUSE recommends the same two-step approach used to complete service pack upgrades: PREPARE and MIGRATION
The series of packages and scripts that allows an upgrade from SUSE Linux 12 SP4 or SP5 to SUSE Linux 15 SP1 is the SUSE Distribution Migration System. It uses SUSE’s zypper migration workflow. The process requires the SUSE Linux instance to be registered and connected to repository servers like SUSE Cloud Update Infrastructure (SCUI), SUSE Customer Center (SCC), or a supported repository server. Customers that purchase SLES or SLES for SAP from AWS and use the default AMIs which will connect to the SCUI running on AWS.
As part of the PREPARE phase there are two key considerations for the filesystem. The first consideration is all core OS functional directories such as /var, /etc, and /usr must be on a single partition. Multiple partition support, such as LVM, cannot mount SUSE’s critical OS directories to separated partitions. For example, SUSE Distribution Migration System will encounter issues if /varis on a separate partition from root. The directory /homeis not considered a critical directory and can be mounted on a separate directory. The second consideration is /etc/fstab will need to be edited. Any reference to an NFS, network, or data filesystem that does not contain OS directories needed during the upgrade process will need to be removed. This will prevent any issues that may occur during the upgrade process.
SUSE Distribution Migration System supports upgrading from SLES 12 SP4 or SLES 12 SP5 to SLES 15 SP1. Prior versions of SLES are required to be upgraded to SLES 12 SP4 or SLES 12 SP5 before they can upgraded to SLES 15 SP1. To determine the SUSE Linux version, review the /etc/os-release or look at the kernel version which is described in the service pack upgrade section (Figure 4).
An important step in the PREPARE phase is to read the documentation for SUSE Distribution Migration System. When reading the documentation, there is an ‘Upgrade Pre-Checks’ section stating encrypted file systems are incompatible with SUSE Distribution Migration System. This does not apply to Amazon Elastic Block Storage (EBS) root volumes that are encrypted using AWS Key Management Services. An instance with an encrypted Amazon EBS volume using AWS Key Management can be upgraded successfully.
The first step in the MIGRATION phase is to install SUSE Distribution Migration System. DO NOT install the packages unless the Amazon EC2 instance is ready for the upgrade process to begin. When SUSE Distribution Migration System is installed the upgrade process will start during the next reboot.
zypper in suse-migration-sle15-activation
As part of this installation, the bootloader configuration will be installed and an ISO image of a later version of SLES will be added. During next boot this specific ISO image will be loaded by the bootloader config. In the SUSE Distribution Migration System documentation the run_migration command is referenced to start the migration. The run_migration command uses kexec in the script to reboot the instance; however, it is not supported for Amazon EC2 instances using the Xen hypervisor. The reboot command will start the upgrade process and can be used for both Amazon EC2 instances using the Xen or Nitro hypervisor:
reboot
Once a reboot is started, the upgrade process will start with a live loaded image and start the automated distribution migration process. The upgrade process will take approximately 40 minutes. No actions should be taken against the Amazon EC2 instance until the process completes and the upgrade process reboots the instance. Once the instance is available customers can connect Amazon EC2 instance using their normal methods and confirm the OS version is SLES 15 SP1.
SUSE has allowed for customers to connect to their Amazon EC2 instance during the upgrade process via ssh with a temporary user named migration that SUSE Distribution Migration System creates. This will allow them to view /var/log/distro_migration.log so they can follow the upgrade process while its occurring (Figure 5).
#> ssh migration@ip-address -i private-certificate.pem migration@localhost:~> sudo tail -f /system-root/var/log/distro_migration.log Upgrading product SUSE Linux Enterprise Server 15 SP1 x86_64. Upgrading product Basesystem Module 15 SP1 x86_64. Upgrading product Containers Module 15 SP1 x86_64. Upgrading product Desktop Applications Module 15 SP1 x86_64. Upgrading product Python 2 Module 15 SP1 x86_64. Upgrading product Server Applications Module 15 SP1 x86_64. Upgrading product Development Tools Module 15 SP1 x86_64. Upgrading product Legacy Module 15 SP1 x86_64. Upgrading product Public Cloud Module 15 SP1 x86_64. Upgrading product Web and Scripting Module 15 SP1 x86_64. Executing 'zypper --root /system-root --releasever 15.1 ref -f' Warning: Enforced setting: $releasever=15.1 Forcing raw metadata refresh Retrieving repository 'SLE-Module-Basesystem15-SP1-Pool' metadata [....done]
Fig 5: Displaying the entries of the migration log file during the ugrade process
During the OS upgrade if the Amazon EC2 instance encounters any issues or failures that prevent the completion of upgrade, the entire process is designed to roll back to the starting SUSE Linux version by default. SUSE Distribution Migration System captures the upgrade output in the log file /var/log/distro_migration.log. In the event of a failed upgrade, the log file should be reviewed to determine the cause of the failure. If a customer encounters an issue with the upgrade and technical support is needed, they are advised to reach out to the AWS Support team. If the Amazon EC2 instance is registered using a SUSE Linux BYOS, the support is provided through that subscription, which in most cases means the customer should contact SUSE for support.
The process to validate a major version upgrade is the same process for validating a service pack upgrade. Customers can choose to examine the /etc/os-release or look at the kernel version which was described in the service pack upgrade section (Figure 4). It’s important to note that once the Amazon EC2 instance is upgraded from SLES 12 SP4 or SLES SP5 to SLES 15 SP1, it will need to upgraded to a supported SLES version since SLES 15 SP1 general support ended January 31, 2021.
SUSE Linux Enterprise Server for SAP Applications Considerations
Now that we have covered SUSE service pack and distribution upgrade, let’s take a look at the SLES for SAP listings in the AWS Marketplace. AWS has been reselling SLES for SAP since 2017. For each major version and service pack of SLES for SAP, there is a corresponding and unique AWS Marketplace listing. Over the past 6 years, AWS has published SLES for SAP versions from 12 SP1 all the way through 15 SP4. The SLES for SAP versions are listed as separate listings in the AWS Marketplace (Figure 6). It is important to call out there are listings for SLES for SAP which are no longer visible. For example, if an AWS Marketplace a customer searches for SLES for SAP 12 SP1, it will not return a result for the AWS Marketplace listing. This behavior is by design. Older listings are set as a limited listing to prevent customers from launching SLES for SAP versions that are end of life.
Fig 6: AWS Marketplace Search Results for listings AWS has published for SLES for SAP
The next section will examine how the AWS Marketplace tracks Amazon EC2 instances launched from AWS Marketplace listings. This is important because AWS Marketplace associates an Amazon EC2 instance throughout the life of the instance to the AWS Marketplace listing used to launch the Amazon EC2 instance. The AWS Marketplace does not track instance’s current service pack or distribution version.
How AWS Marketplace identifies the AMI and Amazon EC2 instance
All AWS Marketplace Listings have a unique Product ID associated to them. The Product ID is used to track the AWS Marketplace products that customers subscribe to. This is important because many of our customers will subscribe to different AWS Marketplace listings for SLES for SAP and launch Amazon EC2 instances from the different SLES for SAP listings. In the AWS Console a customer can review their AWS Marketplace Subscriptions and see all the AWS Marketplace listings they are subscribed to (Figure 7). From this menu they can click on an AWS Marketplace subscription and view the Product ID and the Amazon EC2 instances associated with their subscription.
Fig 7: AWS Console’s Manage Subscriptions for AWS Marketplace
If they were to use the AWS Command Line Interface (AWS CLI) to view the attributes of an AWS Marketplace AMI (Figure 8) used to the launch the Amazon EC2 instance they will also see the ProductCodeID associated with the AMI and the ProductCodeType defined as ”marketplace“.
aws ec2 describe-images --image-ids ami-xxxxx
<snip>
"PlatformDetails": "Linux/UNIX",
"UsageOperation": "RunInstances",
"ProductCodes": [
{
"ProductCodeId": "dtiu2w0ef1urb9ucbu7pc60nv",
"ProductCodeType": "marketplace"
Fig 8: AWS CLI output with the ProductCodeID associated with the AMI
Each Amazon EC2 instance that is launched has an instance identity document that provides information about the instance itself. The instance identity document can be retrieved by connecting to the Instance Metadata Service (Figure 9). The attribute marketplaceProductCodes contained in the instance identity document, contains the AWS marketplace product code. It is associated to the AWS Marketplace listing that the Amazon EC2 instance was launched from. For more information on how to retrieve the instance identity document, please visit the AWS documentation for the instance identity documents.
"billingProducts" : null, "devpayProductCodes" : null, "marketplaceProductCodes" : [ "dtiu2w0ef1urb9ucbu7pc60nv" ], "imageId" : "ami-09c55b1fcd629f470",
Fig 9: Example of an Instance identity document’s marketplaceProductCodes value
The attributes and their values associated with the AMI and the Amazon EC2 instance are immutable and are used by AWS Marketplace to track the SLES for SAP usage. For example, when a customer uses a snapshot of a SLES for SAP instance to create a golden image, any instances that are launched from that golden image will have the Product ID and the marketplaceProductCodes associated with that instance. This is by design to ensure our customers remain in software compliance for AWS Marketplace AMI subscription products that include subscriptions.
Ensure annual subscriptions match the AWS Marketplace products
In order to cost optimize SLES for SAP subscriptions, a customer needs to know what AWS Marketplace listing is associated to an instance. There are two payment options available for SLES for SAP from the AWS Marketplace. The first option is an hourly payment option and the second is an annual contract option. This allows customers to use SLES for SAP at an hourly rate that is on-demand and without a commitment, while the annual pricing option provides customers a 70% discount when compared to the hourly rate. For more information about the different pricing options please read the Optimize SUSE subscription cost for SAP workloads on AWS blog that outlines the different purchasing options.
Let’s consider that a customer has an SAP landscape that is currently using SLES for SAP 15 SP3 as the standard version of their Linux distribution. Their leadership team has tasked them to optimize the SLES for SAP cost of their SAP landscape. They currently have used three AWS Marketplace subscriptions to launch their SLES for SAP instances. The subscriptions are SUSE Linux Enterprise Server for SAP Applications 12 SP5, SUSE Linux Enterprise Server for SAP Applications 15 SP2, and SUSE Linux Enterprise Server for SAP Applications 15 SP3.
Although all their instances are running or may have been upgraded to SLES for SAP 15 SP3 as their standardized Linux version, each of those instances are launched from one of three different listings. The AWS Marketplace unique identifiers, the ProductID and the marketplaceProductCodes follow the instance throughout its lifecycle. This means any annual contracts that are being purchased for the SLES for SAP instance types need to be purchased using the AWS Marketplace listing associated to the specific instance.
The customer would need to identify the ProductCodeID from the AMI or the marketplaceProductCodes from the instance for each of the listings and run the following command (Figure 10) where the marketplaceProductCodes is 4ahriiqjtpu71834m4md9d3n5 (SLES for SAP 12 SP5 marketplaceProductCodes).
aws ec2 describe-instances --filters Name=product-code,Values=4ahriiqjtpu71834m4md9d3n5
Fig 10: AWS CLI command that filters based off the marketplaceProductsCodes
Once the customer identified the instances for each of the listings, they could proceed to purchase the annual contract for SLES for SAP for each listing. For more information, please click on the AMI products with contract pricing documentation.
What’s next
The SUSE Linux on AWS workshop has been published to AWS Workshop Studio! The workshop gives an introduction to SUSE Linux and what services they offer on AWS, before continuing into a series of labs designed to educate users on how to perform SUSE Linux major version upgrades, service pack upgrades as well as how to manage Amazon EC2 instances running SUSE Linux Enterprise Server. Contact your account team to learn more!
Conclusion
In this blog we shared the SUSE Linux 12 end of general support date, how customers should prepare for their SLES upgrades, and how they can familiarize themselves with Amazon EC2 instances and associated attributes in your SAP landscape. We also discussed the overall “How-To” process for updating support pack level as well major version of SLES version to the latest SUSE version available.
Join the SAP on AWS Discussion
In addition to your customer account team and AWS Support channels, AWS provides public Question & Answer forums on our re:Post Site. Our SAP on AWS Solution Architecture team regularly monitor the SAP on AWS topic for discussion and questions that could be answered to assist you. if you need help or have a question about planned usage, best practices, or other related areas, consider joining the discussion over at re:Post and adding to the community knowledge base.