Device Criticality Analysis for Hot-Plug Stability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
High-availability computer systems face complexity in performing online hot plug operations due to the need for resource analysis to determine the criticality of components, which can lead to system instability and unintended reboots, especially when multiple slots share a common power line.
Innovation Solution
A method and system using a directed acyclic graph (DAG) to represent the component hierarchy and perform device criticality analysis, allowing for multiple paths to affected devices, thereby determining the redundancy and criticality of components, and generating a device criticality report to guide online hot plug operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If resource analysis is performed to determine criticality of components before hot-plugging operations, then system stability is improved and unintended reboots are prevented, but device complexity and operational complexity increase
Solution Approach 1:
The system performs resource analysis and determines component criticality before hot-plugging operations are executed. The component criticality determination module analyzes the component hierarchy graph in advance to identify which components are essential for system operation, allowing the system to prevent unintended reboots by knowing ahead of time which components cannot be hot-plugged.
Solution Approach 2:
The patent introduces an intermediary component criticality determination module that acts as a mediator between the hot-plugging operation request and the actual execution. This module analyzes the component hierarchy graph and determines whether a component is critical, thereby preventing direct hot-plugging operations that could cause system instability while allowing safe operations to proceed.
2Reliability
If conventional resource analysis assigns critical level to all essential resources, then system availability is maintained, but false positives occur preventing operations that could be safely performed
Solution Approach 1:
The patent applies local quality by making the criticality determination specific to each component and its context within the component hierarchy. Instead of applying a uniform critical level to all essential resources, the system analyzes the specific component hierarchy graph to determine criticality on a local basis, allowing operations to be permitted when the specific component being hot-plugged is not critical to system operation.
Solution Approach 2:
The system dynamically determines component criticality based on the current component hierarchy graph and the specific hot-plugging operation requested. The criticality is not fixed but is determined in real-time by analyzing the component relationships and dependencies, allowing the system to adapt its decisions based on the specific operational context.
3Device complexity
If multiple slots share a common power line for simplified power management, then power distribution is simplified, but hot-plugging operations become more complex and riskier due to cascading power loss
Solution Approach 1:
The patent segments the power domain analysis by introducing slot power domain information into the component hierarchy graph. This allows the system to identify which slots share common power lines and analyze the impact of hot-plugging operations on each power domain separately, preventing cascading power loss by making informed decisions about which operations can be safely performed.
Data Source
AI summary
The invention relates to a method for determining device criticality in a computer system comprising the steps of building a component hierarchy graph using computer configuration information; labeling the nodes of component hierarchy graph with redundancy attribute; traversing the component hierarchy graph; and determining whether the device loses an access path by inspecting the redundancy attributes within the component hierarchy graph. Furthermore, one of a plurality of severity levels is assigned to each identified affected resource based on predetermined criteria. The severity levels include a low severity level, a medium severity level, and a high severity level. Each severity level represents degree of impact to the computer system if functionality of the identified affected resource became unavailable.