Service Version Upgrade via Pre-spawned Host Processes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional methods for upgrading service versions in large-scale networked systems often result in disruptions, incompatibilities, and extended service unavailability due to issues like computing node failures and disasters during the update process.
Innovation Solution
The method involves pre-spawning both first and second host processes to provide the existing and new service versions respectively, with incremental adjustments based on validation and scaling constraints to ensure safe rollout and backward compatibility.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional update methods are used to upgrade service versions, then the new service version can be deployed, but service disruptions and unavailability occur during the update process
Solution Approach 1:
The system pre-spawns host processes for the new service version before the update is triggered. This preliminary action ensures that when the update occurs, the new version is already prepared and can take over immediately without causing service disruption, thus maintaining service availability while enabling smooth version transitions
Solution Approach 2:
The load balancer acts as an intermediary that distributes client requests between old and new service versions during the transition period. This allows the system to gradually shift traffic from the old version to the new version, ensuring continuous service availability while completing the update process
2Reliability
If service updates are performed without pre-spawning processes, then resource consumption is lower, but service disruptions occur during updates
Solution Approach 1:
The system spawns a limited number of host processes for the new service version rather than spawning all necessary processes upfront. This partial action approach maintains service continuity by having enough processes ready to handle traffic during transition, while avoiding excessive resource consumption by not over-provisioning the new version before it's actually needed
3Productivity
If all host processes are updated simultaneously, then the update process is faster, but fault tolerance decreases due to potential node failures
Solution Approach 1:
The system segments the host processes into different groups (old version and new version) and updates them in stages rather than simultaneously. This segmentation allows the old version processes to continue serving as backup while the new version processes are being prepared and validated, thus maintaining fault tolerance while completing the update efficiently
Solution Approach 2:
The system maintains a cushion of old version host processes that continue to run during the update transition. These cushion processes serve as a safety net in case the new version encounters issues, providing fault tolerance while enabling the update to proceed at a faster pace
4Productivity
If the new service version is deployed without validation, then deployment is faster, but incompatibilities and errors may occur
Solution Approach 1:
The system implements a validation mechanism that tests the new service version before full deployment. The load balancer directs traffic to validate the new version's compatibility and functionality, and based on the feedback from these validation tests, the system determines whether to proceed with full deployment. This feedback loop ensures version compatibility while maintaining efficient deployment
Data Source
Figure 1A
Figure 1B
Figure 2
AI summary
According to examples, a method for upgrading a version of a service includes instructing a host device to pre-spawn a number of first host processes configured to provide a first version of the service in a computing node and to pre-spawn a number of second host processes (312) configured to provide a second version of the service according to a first scaling constraint in the computing node (312). The method also includes, in response to receiving an indication that each of the second host processes is operating properly (314), instructing the host device to decrease the number of first host processes and to increase the number of second host processes as defined in a second scaling constraint (316).