1 Introduction to Zero Downtime Patching

This chapter provides an overview of Zero Downtime Patching, including the types of workflows that you can create, how the patching workflow proceeds, and how patching is reverted.

This chapter contains the following sections:

What is Zero Downtime Patching?

WebLogic Zero Downtime Patching (ZDT Patching) automates the rollout of out-of-place patching or updates across a domain while allowing your applications to continue servicing requests. After defining your patching strategy, you can use either WLST or the WebLogic Server Administration Console to orchestrate the rollout of updates across some or all of the servers in your domain.

Although WebLogic Server has supported rolling upgrades since version 9.2, the process has always been manual. ZDT Patching automates this process by using workflows that you define. You can patch or update any number of nodes in a domain with little or no manual intervention. Changes are rolled out to one node at a time, allowing a load balancer such as Oracle Traffic Director to redirect incoming traffic to the remaining nodes until the node has been updated.

Types of Patching Workflows

ZDT Patching supports the following tasks. You can create a workflow that performs any one of these tasks. You can also create a workflow that performs any combination of an Oracle Home update, Java version update, and application update.

  • Moving servers to a patched Oracle Home—The workflow transitions the Administration Server or clusters or both to another Oracle Home that has already been patched using OPatch.

  • Updating to a new Java version—The workflow updates the Administration Server or clusters or both to use a newly installed Java Home.

  • Deploying updated applications—The workflow deploys updated applications to the selected clusters.

  • Performing a rolling restart of servers—The workflow will sequentially restart the Administration Server or servers in the selected clusters or both safely, including graceful shutdown of the servers and starting them up again.

Prior to creating a patching workflow, preliminary steps must be completed for each of these tasks with the exception of rolling restarts. See Chapter 2, "Preparing for Zero Downtime Patching," for more information.

Patching Workflow Process

When using a ZDT Patching workflow to roll out an update, the rollout:

  • systematically works its way through each applicable node

  • identifies the servers on the node that are included in the rollout

  • gracefully shuts down those servers

  • When switching to a patched Oracle Home:

    • Backs up the existing Oracle Home to a backup directory

    • Calls Node Manager to switch the contents of the current Oracle Home to the contents of the specified Oracle Home.

  • When updating to a new Java version:

    • Updates all scripts in the domain's Oracle Home that contain a reference to Java Home to point to the new Java Home

    • Updates all scripts in the domain's home directory that contain a reference to Java Home to point to the new Java Home.

  • When updating to new application versions:

    • Locates the current directory for each application

    • Moves the current directory for each application to a backup location

    • Moves the directory for the new version of each application to the location of each original application.

  • Restarts each server once the update has completed on the node.

The workflow executes the appropriate steps in order and monitors the success of each step. If a step fails, the workflow may attempt to retry it. If a step cannot be completed successfully, the workflow reverts each previous step in order. The revert process can be configured to execute automatically or can be initiated manually, as described in the next section.

Reverting an Update

ZDT Patching is also able to revert an update at any point in the process, even after it has completed. Updates can be reverted:

  • Automatically—When creating a workflow, you can opt to have the update revert automatically if there is a failure. The update will be rolled back from the point of failure, starting with the last successfully completed step.

  • Manually—While a workflow is in progress, you can stop it and revert it at any point. The update will then be rolled back, starting with the last successfully completed step.

    After a workflow has completed, you can revert it by creating a workflow to reverse the update that was made. This differs slightly depending on the update you are reverting. If reverting to the previous Oracle Home, you are provided with an option to specify that it is a rollback. For Java and applications, you simply point to the previous version of Java or the application.

For more information on reverting an update, see Executing, Reverting, and Resuming Stopped Workflows.

Overview: Rolling Out a Patched Oracle Home

This section provides a high-level overview of how to roll out a patched Oracle Home to all nodes in your domain. Prior to doing the rollout:

  • The domain must be distributed across all nodes and must be stored in the same location on all nodes

  • The existing Oracle Home must be in the same location on all nodes

  • Node Manager must be running on all nodes

  • All Managed Servers in all clusters that will be included in the rollout must be running.

See ZDT Patching Restrictions, for additional requirements and restrictions. Figure 1-1 at the end of this section shows the operations that are performed for an Oracle Home rollout on each node, regardless of whether you use OPatchAuto, WLST, or the Administration Console to perform the rollout.

To roll out a patched Oracle Home:

  1. If you want to use OPatchAuto:

    1. Create the patched Oracle Home archive.

      For details, see Creating a Patched Oracle Home Archive Using OPatchAuto.

    2. Distribute the archive to all nodes to which you want to roll out the patched Oracle Home.

      For details, see Distributing the Patched Archive to Each Node Using OPatchAuto.

    If you want to manually create and distribute the patched Oracle:

    1. Use the copyBinary command to create an archive of your existing Oracle Home.

      For details on this step and the next step, see Creating a Second Oracle Home.

    2. Use the pasteBinary command to create an Oracle Home to be patched on a development or test system that has a similar domain topology as your production domain. This gives you an Oracle Home that has the same patch level and products as you have on your production system.

    3. Use the Oracle OPatch tool to apply the desired patch or patches to the Oracle Home on your development or test system.

      For details, see Applying Patches to the Second Oracle Home, and Patching with OPatch.

    4. Test and verify the patched Oracle Home.

    5. Once you are satisfied that the patched Oracle Home is stable, use copyBinary to create an archive of the patched Oracle Home.

      For details on this and the next step, see Creating an Archive and Distributing It to Each Node.

    6. Distribute this archive to all nodes in your production system.

      Note:

      There is no need to use pasteBinary to explode the archive on each node. The rollout process will create the new Oracle Home on each node from the archive.

  2. If you did not use Node Manager to start your Administration Server, shut down the Administration Server and use Node Manager to start it.

    For details, see Using Node Manager to Start the Administration Server.

  3. Create a ZDT workflow to roll out the patched Oracle Home to your Administration Server. You can do this in any of the following ways:

  4. After the workflow completes successfully, create another ZDT workflow to roll out the patched Oracle Home to the clusters in your domain. You can do this in any of the following ways:

    • Use OPatchAuto to initiate the rollout and specify a cluster or a comma-separated list of clusters as the rollout target.

      For details, see Using OPatchAuto to Initiate a Rollout.

    • Use the WLST rolloutOracleHome command and specify a comma-separated list of clusters as the rollout target.

    • In the Administration Console, select the ZDT Control > Clusters tab, select the Clusters to which you want to rollout the Oracle Home, and then initiate and configure the workflow.

    Note:

    You can combine the last two steps into one workflow by either specifying the domain as the target in the opatchauto or rolloutOracleHome command, or by initiating and configuring the workflow from the ZDT Control > Domains tab.

Figure 1-1 Oracle Home Rollout Operations

Description of Figure 1-1 follows
Description of ''Figure 1-1 Oracle Home Rollout Operations ''

Overview: Rolling Out a New Java Version

This section provides a high-level overview of how to roll out a new Java version to all nodes in your domain. Prior to doing the rollout:

  • The domain must be distributed across all nodes and must be stored in the same location on all nodes

  • Oracle Home must be in the same location on all nodes

  • Node Manager must be running on all nodes

  • All Managed Servers in all clusters that will be included in the rollout must be running.

See ZDT Patching Restrictions, for additional requirements and restrictions.

To roll out a new Java version:

  1. Install the new Java version to all nodes. The full path to this Java Home must be the same on all nodes.

    For more details, see Preparing to Upgrade to a New Java Version.

  2. If you did not use Node Manager to start your Administration Server, shut down the Administration Server and use Node Manager to start it.

    For details, see Using Node Manager to Start the Administration Server.

  3. Create a ZDT workflow to roll out the new Java Home to your Administration Server. To do this, you can either:

  4. After the workflow completes successfully, create another ZDT workflow to roll out the new Java Home to the clusters in your domain. To do this, you can either:

    • Use the WLST rolloutJavaHome command and specify a comma-separated list of clusters as the rollout target.

    • In the Administration Console, select the ZDT Control > Clusters tab, select the clusters to which you want to rollout the new Java version, and then initiate and configure the workflow.

    Note:

    You can combine the last two steps into one worfklow by either specifying the domain as the target in the rolloutJavaHome command or by initiating and configuring the workflow from the ZDT Control > Domains tab.

Overview: Rolling Out Updated Applications

This section provides a high-level overview of how to roll out new application versions to all Managed Server nodes in your domain. Prior to doing the rollout:

  • The domain must be distributed across all nodes and must be stored in the same location on all nodes

  • Oracle Home must be in the same location on all nodes

  • Node Manager must be running on all nodes

  • All Managed Servers in all clusters that will be included in the rollout must be running.

See ZDT Patching Restrictions, for additional requirements and restrictions. Figures (UNKNOWN STEP NUMBER) through (UNKNOWN STEP NUMBER) at the end of this section illustrate the scenario for staged, no-stage, and external staged applications. The patched application source will be moved to the appropriate application source locations for each stage type during the rollout.

To roll out new application versions to your Managed Servers:

  1. (Stage mode) Place a copy of each updated application directory on the domain's Administration Server.

    (No-stage mode and external stage mode) Place a copy of each updated application directory on each node that will be affected. The directory must be the same on each node.

    For details, see Impact of Staging Modes.

  2. Create a JSON file that defines each application name, the path and file name for each updated application archive, and the path and file to which you want to back up the original application archive.

    For details, see Creating an Application Update JSON File.

  3. If you did not use Node Manager to start your Administration Server, shut down the Administration Server and use Node Manager to start it.

    For details, see Using Node Manager to Start the Administration Server.

  4. Create a ZDT workflow to roll out the new application versions. To do this, you can either:

    • Use the WLST rolloutApplications command and specify a comma-separated list of clusters as the rollout target.

    • In the Administration Console, select the ZDT Control > Clusters tab, select the Clusters to which you want to rollout the applications, and then initiate and configure the workflow.

Figure 1-2 Patching Staged Applications

Description of Figure 1-2 follows
Description of ''Figure 1-2 Patching Staged Applications''

Figure 1-3 Patching No-Stage Applications

Description of Figure 1-3 follows
Description of ''Figure 1-3 Patching No-Stage Applications''

Figure 1-4 Patching External Staged Applications

Description of Figure 1-4 follows
Description of ''Figure 1-4 Patching External Staged Applications''

In-Memory Session Replication for ZDT Rollouts

For webapps that use in-memory session replication, the in-memory sessions are never replicated or persisted to allow for failover, as a result of which webapps may lose session state due to a server crash or frontend misdirection causing the request to land on a sever without the session.

With regard to Zero Downtime (ZDT) rollouts, when you shut down any server that holds the in-memory session, the server waits for that session to complete before shutting down. Since the default value for session timeout is one hour, the server may be in the SUSPENDING state for one hour or even longer if sessions continue to be utilized or updated. If you do not wait for the session to complete its lifecycle, then the state is lost as in-memory sessions are neither replicated nor persisted for webapps.

If you do not want to wait for an hour or longer, it is recommended that you set the shutdownTimeout option argument to the time (in seconds) that you want the server to wait before shutting down. For information about using the shutdownTimeout option argument, see Table 3-1, "Arguments for WLST rollout Commands".