Rolling Software Upgrades Using Active Testing Nodes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software updates in server clusters often introduce delays and errors due to incompatibilities between old and new software versions, requiring patches and downtime, especially when upgrading or downgrading software applications across multiple nodes.
Innovation Solution
A software change system that uses active testing nodes to detect and resolve issues by upgrading or downgrading software on one node while others remain on the current version, generating and distributing configuration data to address errors and incompatibilities, and maintaining an original network stack for compatibility.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If software is patched to resolve incompatibilities between old and new versions, then reliability is improved, but loss of time increases due to shutdowns and reboots
Solution Approach 1:
The system segments the cluster into multiple nodes that can be upgraded independently. Each node is upgraded separately while others remain operational, allowing the system to maintain functionality throughout the upgrade process. This segmentation eliminates the need for complete system shutdown and enables continuous operation during software updates.
Solution Approach 2:
The system performs preliminary actions by maintaining a standby node in the old software version that can handle requests before the new version is fully deployed. Configuration data and network stack information are prepared in advance, allowing seamless switching between versions without service interruption.
2Adaptability or versatility
If patches are applied to the previous software version to enable communication with new version, then adaptability is improved, but device complexity increases
Solution Approach 1:
The system introduces an intermediary mechanism in the form of configuration data that bridges the old and new software versions. This configuration data contains network stack information and compatibility settings that enable communication between versions without requiring complex patching of the old software. The intermediary layer simplifies the interaction between incompatible versions.
Solution Approach 2:
The system creates copies of configuration data and network stack information from the old software version and applies them to the new version. This copying approach ensures compatibility without modifying the original old version software, reducing complexity compared to patching. The new version node is configured with the necessary information to communicate with old version nodes.
3Productivity
If all nodes are upgraded simultaneously to ensure resource availability, then productivity is improved, but reliability worsens due to increased errors and downtime
Solution Approach 1:
The upgrade process is segmented into sequential node-by-node updates rather than simultaneous updates. Each node is upgraded individually, tested, and validated before proceeding to the next node. This segmentation approach maintains system stability by ensuring that at least some nodes remain operational and can handle requests during each upgrade step.
Solution Approach 2:
The system implements feedback mechanisms where each upgraded node is monitored for errors and compatibility issues before the upgrade is considered successful. If errors are detected, the system can roll back or pause the upgrade process. This feedback loop ensures system reliability by preventing propagation of errors across all nodes simultaneously.
Data Source
AI summary
A software change system and method implements changes of a current active software version hosted one or more testing nodes of a cluster(s) to a different software version, while other nodes within the cluster(s) continue to employ the current active software version. To determine and resolve errors and incompatibilities introduced by the different software version, the at least one testing node is upgraded to the different software version and employed to query resources and data associated with the current active software version. Resolution data pertaining to the different software version is generated reflecting changes to the data employed by the different software version, or changes to the different software version, to resolve the errors and incompatibilities. The resolution data may be deployed to other nodes of the cluster(s) before, during, or after the nodes are upgraded on a rolling or other basis to the different software version.