Introduction
Oracle Exadata provides simplicity, operational efficiency, and streamlined administration. All in an integrated, highly available, secure enterprise database platform with extreme performance for Oracle workloads of any scale and criticality. The Exadata development team pursues innovation and platform value by frequently adding new features and enhancements, and is deeply focused on real-world use cases. We’re now excited to tell customers who run third-party software on Exadata about an extension to Exadata patchmgr that minimizes maintenance work through improved dependency handling.
Intelligence in patchmgr to detect and manage Third-party software dependencies
Third-party software intended for installation on Exadata is delivered as RPMs, a package management system used in Linux primarily for distributing, managing, and updating software. Third-party software RPMs may cause conflicts during Exadata updates. The standard practice has been to uninstall third-party software before an Exadata System Software update and then reinstall after the update. The new extension in Exadata System Software 25.1 is designed to allow an update to Exadata without third-party software uninstall/reinstall, all in 5 easy steps.
Managing Third-party software during Exadata update
You’re ready to update Exadata, and one or more third-party software applications are installed on your database servers.
Step 1: Precheck for conflicts with third-party software
Use the patchmgr command with the –precheck option to determine whether third-party software will conflict with a library that will be upgraded along with the update. The output of the command appears on the local console. The output is verbose and prominently indicates any detected library dependency issues or conflicts.
The command syntax and explanation of the patchmgr command with the –precheck option are below.
./patchmgr --precheck --dbnodes db_nodes_list --log_dir_auto /home/oracle/patchmgr/log --repo { base_URL | zipped_iso_file }
Option help
===========
./patchmgr # Invoke the patchmgr utility
--precheck # Intelligently determine dependency errors on each node
# Run the pre-upgrade validation checks in the database nodes
# specified in the host list, in a non-rolling fashion.
--dbnodes # The db_nodes_list is a text file identifying the database
# servers that are the target of the patchmgr operation.
# The file must exist and contain one target database server host
# name or IP address on each line. The server running patchmgr
# cannot be included in the file
--log_dir_auto # The absolute path to the log directory, or you can specify
# "auto" to use a log directory that is based on the
# directory you started patchmgr from and the content of the nodes list file.
# Specifying the --log_dir option enables you to run multiple
# patch manager invocations and also to run patch manager
# as a non-root user.
--repo {base_URL | zipped_iso_file} # zip file with the Exadata ISO for the target release
As an example, the screenshot below captures an actual output with a conflict that is manually highlighted using “<<<<<<<<<<“. In this example, the conflict marker indicates that the package elfutils-debuginfod-client with version 0.189 requires the package elfutils-libelf to be at version 0.189, but the Exadata update intends to update the elfutils-libelf to version 0.190.
The lines in the log that indicate the detected conflict (magnified for easier reading) are:
This dependency conflict is intelligently identified by patchmgr and is called out during the precheck as an issue, and must be addressed before the update.
The above logs also point out that the application exadata-sun-kvn-computenode-minimum requires elfutils-libelf to be at version 0.190 or above. This situation reflects a dependency conflict where one application needs an underlying package to be version 0.189, and another needs at least version 0.190 or above.
Step 2: Get updated RPMs for the third-party software, if necessary
If the precheck shows a conflict with third-party software, the third-party software RPMs may also have to be updated. This requires that an updated third-party software RPM be obtained from the software vendor and added to an additional-rpms list. It is a requirement upon the vendor that this updated third-party software be tested against the new libraries that the update will bring in to ensure smooth operation on Exadata after the upgrade. This testing must be independently completed, and functionality must be verified before the updated RPMs are provided for installation.
In the example above, the client elfutils-debuginfod-client-0.189-3.e18.x86_64 is at version 0.189, and precheck indicates a conflict. The updated client version elfutils-debuginfod-client-0.190-3.e18.x86_64 is at the appropriate version and will not conflict. Similarly, any updated third-party software RPM must be made available.
Step 3: Determine nested dependency packages and RPMs
Package dependencies in Linux can extend hierarchically, with each dependency potentially relying on further nested dependencies. The best practice is to conduct an iterative check through repeated use of precheck and update of the additional-rpms list, and to eventually get a comprehensive list of the needed dependencies. All levels of the hierarchy must pass the precheck for the update to succeed. Once all the dependencies are understood, you have all the information for a complete list of packages required to complete the update smoothly.
You have multiple options in specifying the RPM list within the patchmgr command:
- Comma-separated RPM list on the patchmgr command line, shown as Option 1 in the text block below
- Point to a local directory that contains the needed RPMs, shown as Option 2 in the text block below
- Specify in a list on the patchmgr command line, shown in Option 3 in the text block below
- Download the needed RPMs from a yum or dnf repository, Option 4 in the text block below
# Options for specifying additional-rpms
Option 1: [--additional-rpms [ rpm_spec[,rpm_spec]...]]
# Optionally specifies additional packages (RPMs) to include during
# a pre-check or update operation. You can specify the additional RPMs
# as a comma-separated list
Option 2: [--additional-rpms [rpm_dir]]
# Variant of Option 1 but with a rpm directory specified. This is
# where the additional RPM list is maintained.
Option 3: [--additional-rpms-list rpm_list]
# Optionally specify a text file containing the list of additional
# packages (RPMs) to include during a pre-check or update operation.
# In the file, each RPM must be specified on a separate line.
Option 4: --additional-rpms-from-repo
# Optionally instructs the update target server(s) to download the RPMs
# directly from a Yum or DNF repository. A suitable repository must be
# configured on the target server and the configured repository must be
# accessible from the target server
NOTE: The option description text is partially reproduced here. The Oracle official
patchmgr command reference has a complete description of each option. |
If Step 3 is completed successfully, all the required dependencies have been determined, and new, tested, third-party software is also available.
Step 4: Precheck Test with the final additional-rpms list
The new extended patchmgr functionality can now refer to, pull, and merge additional RPMs. Additional RPMs are sourced from the additional-rpms directory created in the prior steps.
The RPMs listed in this additional-rpms list can now be installed by patchmgr by a newly available option, unsurprisingly called —additional-rpms. The patchmgr downloads the RPMs in the additional-rpms list to each database server that is being updated, and the patchmgr update operation merges these RPMs.
The syntax of the patchmgr command with the final precheck is shown.
$ patchmgr \
--dbnodes db_nodes_list \
# The database_node_file is a text file identifying the database
# servers that are the target of the patchmgr operation.
# The file must exist and contain one target database server host
# name or IP address on each line. The server running patchmgr
# cannot be included in the file.
--precheck # Final pre-check
--repo /scratch/u01/patchmgr/builds/exadata_ol8_25.1.0.0.0.xxxxxx_Linux-x86-64.zip \
# zip file with the Exadata ISO for the release being updated to
--target_version 25.1.0.0.0.xxxxxx \ # The full patch version
--log_dir auto \ # The absolute path to the log directory, or you can specify
# auto to use a log directory that is based on the directory
# you started patchmgr from and the content of the nodes list file.
# Specifying the --log_dir option enables you to run multiple
# patch manager invocations and also to run patch manager
# as a non-root user.
--additional_rpms /scratch/u01/patchmgr/test/
# Precheck using the required RPMs |
Step 5: Complete the Exadata update
Your third-party software and dependency RPMs are in place, and you are ready for the update. Complete the update by running the patchmgr command again, but with the –upgrade option.
The syntax of the patchmgr command with the upgrade option is shown.
# Run the patchmgr command with the upgrade option
$ patchmgr \
--dbnodes db_nodes_list \
# The database_node_file is a text file identifying the database
# servers that are the target of the patchmgr operation.
# The file must exist and contain one target database server host
# name or IP address on each line. The server running patchmgr
# cannot be included in the file.
--upgrade # Update
--repo /scratch/u01/patchmgr/builds/exadata_ol8_25.1.0.0.0.xxxxxx_Linux-x86-64.zip \
# zip file with the Exadata ISO for the release being updated to
# Specifying a web-based repository is also allowed.
# Example: http://<yum-repo-host>/yum/EXADATA/dbserver/24.2/latest/x86_64/
--target_version 25.1.0.0.0.xxxxxx \ # The full patch version
--log_dir auto \ # The absolute path to the log directory, or you can specify
# auto to use a log directory that is based on the directory
# you started patchmgr from and the content of the nodes list file.
# Specifying the --log_dir option enables you to run multiple
# patch manager invocations and also to run patch manager
# as a non-root user.
--additional_rpms /scratch/u01/patchmgr/test/
# Required RPMs
|
This completes the Exadata update. What happens below the covers is that when the patchmgr command is triggered, the RPMs in the additional-rpms list are downloaded to the database nodes and inserted into the update. Because the third-party software RPMs are also updated along with their newly determined dependency packages, and all needed dependencies are addressed, the third-party software continues to work without the additional load of uninstalling and reinstalling third-party software.
Takeaway
Exadata System Software 25.1 brings a huge enhancement for customers who install third-party software. Dependency conflicts during an Exadata platform update are detected and addressed by patchmgr in 5 easy steps, as shown above. Customers can now ensure that their third-party software remains functional before and after the Exadata update while keeping their Exadata infrastructure up to date. Customers can confidently plan for and set up their additionally needed or updated RPMs, and update Exadata without affecting critical third-party software. This enhancement reflects Oracle’s commitment to operational efficiency, streamlined third-party software management, and delivering greater value and convenience for customers.
Acknowledgments
This article benefits from the valuable insights and guidance of Rene Kundersma and Chris Craft. Rene is the architect of this innovation, and Chris is a seasoned Oracle technologist.