Network Hypervisor Boot Images for Fast Server Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional server reboots for software upgrades, such as Openstack®, kernel, or security patch upgrades, are time-consuming and disruptive, requiring serial rebooting of multiple servers over hours or days, leading to extended downtime.
Innovation Solution
A method and apparatus for generating a bootable hypervisor image, storing it in non-volatile memory, and configuring servers to boot from a network, allowing simultaneous reboot and execution of the image across multiple servers, thereby minimizing downtime.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If servers are rebooted serially one at a time for software upgrades, then service disruption is minimized, but the total upgrade time becomes extremely long (hours or days)
Solution Approach 1:
The upgrade process is segmented into two independent phases: (1) generating and storing bootable images beforehand, and (2) executing simultaneous reboots. This segmentation allows the time-consuming image preparation to be done in advance while the actual reboot operation can be performed in parallel across multiple servers, resolving the contradiction between maintaining service availability and reducing upgrade time.
Solution Approach 2:
Bootable images are generated and stored in non-volatile memory before the reboot process begins. This preliminary action ensures that when servers need to be rebooted, they can immediately boot from pre-prepared images without waiting for image generation during the reboot process, enabling simultaneous reboots while maintaining service availability.
2Loss of time
If multiple servers are rebooted simultaneously, then upgrade time is reduced, but service disruption increases
Solution Approach 1:
Instead of rebooting all production servers simultaneously, the system creates bootable images that can be used to boot identical or equivalent server instances. This copying approach allows for simultaneous reboots while maintaining service continuity through image-based deployment, potentially using standby servers or enabling rapid restoration if issues occur.
Solution Approach 2:
A management system acts as an intermediary to coordinate the reboot process. It manages the generation of bootable images, configures servers to boot from network, and orchestrates the reboot sequence. This intermediary layer provides control and monitoring capabilities that enable simultaneous reboots while minimizing service disruption through automated management.
3Reliability
If conventional reboot processes are used with multiple sequential tasks, then system stability is maintained, but the reboot process becomes extremely slow
Solution Approach 1:
The conventional mechanical reboot process (sequential execution of multiple tasks within each server) is replaced with an image-based boot mechanism. Servers boot from pre-generated images stored in non-volatile memory or network storage, eliminating the need for sequential task execution during reboot. This substitution dramatically increases reboot speed while maintaining system stability through verified image deployment.
Solution Approach 2:
The boot process parameters are changed from sequential task execution to parallel image-based booting. By modifying the boot configuration to load from network or non-volatile memory and execute pre-prepared images, the system transforms the reboot process from a time-consuming sequential operation to a rapid parallel operation across multiple servers.
Data Source
AI summary
This application relates to apparatus and methods for booting servers, such as cloud datacenter compute servers. The servers may execute one or more hypervisors, such as stateless hypervisors, with each hypervisor supporting one or more virtual machines. In some examples, each of a plurality of servers are configured to boot from a network. The compute servers may obtain an IP address identifying a location of hypervisor bootable images. Upon a reboot, the servers may request and obtain a hypervisor bootable image from the IP address. The servers may execute the hypervisor bootable image to run a hypervisor. In some examples, the servers also obtain virtual machine images from the network. One or more hypervisors executing on each server may obtain, and execute, one or more of the virtual machine images to run one or more virtual machines.