Multi-Tenant Application Server Patching via Rolling Restart

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multi-tenant application server environments, patching processes often result in system downtime and are complex, as administrators must manually apply patches to each node, shutting down servers and verifying their functionality, which can be time-consuming and risky for users.

Innovation Solution

A system and method that associates partitions with tenants, utilizing high-availability features for a controlled, rolling restart of patches, allowing for automated complex tasks and preserving previous software versions for rollback, ensuring zero downtime and automatic reversion in case of errors.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual patching is performed on each node, then patching can be applied, but system downtime increases and complexity increases

Engineering Contradiction:
Improvesystem availability during patchingVSAvoidpatching process complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the patching process into distinct phases: preparation phase (where patches are tested and validated), deployment phase (where patches are automatically applied), and verification phase (where patch effectiveness is confirmed). This segmentation allows the complex patching operation to be broken down into manageable stages, reducing overall complexity while maintaining system availability through parallel processing of preparation and deployment activities.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements preliminary actions by creating a preparation phase where patches are tested and validated before actual deployment. This includes pre-testing patches in isolated environments, validating patch compatibility with existing systems, and preparing rollback procedures in advance. These preliminary actions prevent issues during deployment, reducing the need for manual intervention and minimizing system downtime.

Inventive Principle:
Principle #10Preliminary action

2Ease of manufacture

If servers are shut down for patching, then patches can be applied, but application downtime increases

Engineering Contradiction:
Improvepatch application capabilityVSAvoidsystem downtime
Core Design Contradiction:
Ease of manufactureVSLoss of time

Solution Approach 1:

The patent applies dynamics by enabling the system to adapt its patching strategy based on real-time conditions. The automated patching system can dynamically adjust deployment timing, select optimal nodes for patching based on current load, and modulate the pace of patch application. This dynamic approach allows patching to occur with minimal disruption to ongoing applications, reducing downtime while maintaining patch application capability.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent ensures continuity of useful action by implementing background patching where patches are applied during low-activity periods or in a controlled manner that does not interrupt critical application operations. The system continues to serve requests during the patching process by routing traffic to unaffected nodes, maintaining service continuity while still applying necessary patches to improve system security and functionality.

Inventive Principle:
Principle #20Continuity of useful action

3Reliability

If rolling restart is used, then zero downtime is achieved, but process time increases

Engineering Contradiction:
Improvezero downtime patchingVSAvoidpatching process duration
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent implements periodic action by applying patches in controlled batches rather than all at once. The rolling restart process restarts servers in periodic cycles, with each cycle completing before the next begins. This periodic approach allows the system to maintain availability during patching by completing restarts in manageable timeframes, balancing zero downtime achievement with acceptable process duration through optimized batch sizing and timing.

Inventive Principle:
Principle #19Periodic action

4Device complexity

If automated patching is implemented, then complexity is reduced, but control over patching process decreases

Engineering Contradiction:
Improvepatching process complexityVSAvoidpatching control flexibility
Core Design Contradiction:
Device complexityVSEase of operation

Solution Approach 1:

The patent incorporates feedback mechanisms that allow administrators to monitor patching progress, verify patch effectiveness, and intervene when necessary. The system provides real-time status information about patch deployment, automatically verifies patch success through health checks, and can trigger rollback procedures if issues are detected. This feedback loop maintains ease of operation by keeping administrators informed and in control while reducing the complexity of manual patching through automation.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10853056B2System and method for supporting patching in a multitenant application server environment
Publication Date: 2020.12.01 ORACLE INT CORP
  • US10853056B2 patent drawing
  • US10853056B2 patent drawing
  • US10853056B2 patent drawing

AI summary

In accordance with an embodiment, described herein is a system and method for supporting patching in a multi-tenant application server environment. The system can associate one or more partitions with a tenant, for use by that tenant, wherein a partition is a runtime and administrative subdivision or slice of a domain. A patching process can take advantage of high-availability features provided by an application server clustering environment, to apply patches in a controlled, rolling restart, which maintains a domain's ability to operate without interruption, or with zero downtime. The process can be used to automate complex or long running tasks, including preserving an unpatched or prior version of an application server, application, or other software component for possible rollback, or providing automatic reversion in the event of an unrecoverable error.