Resource usage of Patching Jobs

In BMC Server Automation, software patches released by a patch vendor (for example, Microsoft, Red Hat, Adobe, Oracle) are conceptualized as comprising metadata that describes the patch and its applicability, and a payload that contains the actual bits of the patch.

Patches are stored in a patch repository in the computing environment, which is an NSH-accessible directory somewhere in the BMC Server Automation environment. An offline or air-gapped environment is one in which the repository does not have direct access to the internet and, therefore, patches cannot be directly downloaded from the vendor site to an offline repository. A common strategy for populating an offline repository is to transfer patch content on removable media with the help of a BMC-provided download utility.

Patches are organized into patch catalogs, according to filters defined in BMC Server Automation. For example, the catalog for Windows patches is separate from the catalog for Red Hat patches.

If a repository is to include Microsoft Windows patches and the Application Server is running on a Linux host, then you must identify a Windows Helper Server Location when you create the repository. The Windows Helper Server Location is a user-defined temporary directory on a Windows server which is used to decrypt files that are downloaded from the vendor site.

Catalog Update Jobs

You can create Catalog Update Jobs for each type of patch repository. Online patch catalogs are updated by downloading additional content from vendor and/or metadata-provider websites. The Application Server that is running a catalog update job for an online repository requires web access to these sites (that is, the Application Server must be configured to allow traffic to pass through any firewalls and web proxy servers).

Offline patch catalogs are updated by transferring content from a local server, which typically mounts removable storage media where patch information is already loaded.

The following table shows a summary of resource usage by Catalog Update Jobs.

Patching Jobs

On all supported platforms for BMC Server Automation version 8.0 and later, patch analysis processing takes place on the affected target. That is, the relevant metadata (typically less than 5 MB) is transferred from the repository to the target agent, where the target agent performs the necessary calculation to determine which patches to install on the target.
The BMC Server Automation version determines whether patch analysis is performed on the target server or the Application Server:

• Version 7.6 and earlier — Patch analysis for Oracle Solaris is performed primarily on the Application Server, rather than on the target. This can present a moderate to high work load on the Application Server.
• Version 8.0, Version 8.1 and later — Patch analysis for Solaris occurs on the target. Further, patch analysis for all target types now uses an asynchronous agent call, allowing greater concurrency on the Application Server.

The table shows a summary of resource usage by Catalog Update Jobs.

¹See version-specific notes above the table for Solaris patch analysis.

Patch Remediation Jobs

A patch remediation job does the following:

• Runs a patch download job to download patch payloads of missing patches that have not yet been downloaded. For Windows and Solaris, you can run analysis with just the metadata, without downloading the payload. Red Hat requires a payload download. Therefore, you can create a Windows patch catalog with all Windows 2008 patches and only download payloads of the patches that are found missing.
• Based on the patch analysis results, the patch remediation job runs an algorithm that creates a set of BLPackages and BLPackage Deploy Jobs. If multiple servers have the same set of missing patches, the patch remediation job creates a single Deploy Job with BLPackages that target the servers. If different servers have different patches missing, the patch remediation job creates a Deploy Job for each unique set of missing patches.
• The BLPackage Deploy Jobs are wrapped into a Batch Job.
• The Batch Job then executes immediately (if specified), or is scheduled to execute at a later time.

The table shows a summary of resource usage by Patch Remediation Jobs.

For more information about the resource demands of the deploy operations, see BLPackage Deploy Jobs. Patch resources are stored in the patch repository, which might experience heavy workload during the Staging phase of deployment.