Cloud Application Co-Residency Hazard Prevention via Failure Group Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud computing environments face the risk of single-point-of-failure hazards due to extreme co-residency configurations, where multiple application components are hosted on the same physical infrastructure, leading to potential service disruptions and increased complexity in designing effective anti-affinity rules.
Innovation Solution
A method is introduced to identify and mitigate extreme co-residency hazards by determining failure groups of application instances, establishing connections with peer applications, and comparing these groups to ensure separation and minimize the risk of simultaneous failures, using a combination of failure group determination and heuristic measurements to select non-co-resident peer instances.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If multiple application components are hosted on the same physical infrastructure to optimize resource utilization, then computing resource efficiency is improved, but the risk of single-point-of-failure hazards increases
Solution Approach 1:
The patent segments application components into distinct failure groups based on their physical hosting locations. By determining failure groups and using them to make routing decisions, the system prevents all components of a single application from being hosted on the same physical infrastructure, thereby eliminating single-point-of-failure hazards while maintaining resource efficiency through optimized placement.
Solution Approach 2:
The patent introduces failure group information as an intermediary mechanism between application components and physical infrastructure. This intermediary data structure enables the system to understand the physical relationships between components and make informed routing decisions that avoid co-residency risks, resolving the contradiction between resource efficiency and reliability.
2Reliability
If anti-affinity rules are designed to prevent co-residency, then reliability is improved, but the complexity of rule design and enforcement increases
Solution Approach 1:
The patent enables application components to self-determine their failure groups and make autonomous routing decisions based on this information. Each component independently queries failure group data and uses it to select appropriate peers, eliminating the need for complex centralized rule enforcement while maintaining reliability through distributed intelligence.
Solution Approach 2:
The patent changes the approach from designing complex anti-affinity rules to determining and utilizing failure group parameters. By transforming the problem into a parameter-based solution where components query and respond to failure group information, the system achieves reliability without the complexity of traditional anti-affinity rule design and enforcement.
3Duration of action of moving object
If application instances are rapidly routed to peer instances during failure events, then service continuity is improved, but the risk of routing to co-resident instances increases
Solution Approach 1:
The patent performs preliminary action by pre-determining failure groups for all application components during normal operation. This advance preparation of failure group information enables rapid and safe routing decisions during failure events, as the system already understands the physical relationships between components and can immediately identify safe peer instances without risking co-residency.
Data Source
AI summary
Various exemplary embodiments relate to a method of preventing extreme coresidency hazards among application instances in a cloud network. The method includes determining a first failure group of a first instance of an application; establishing a connection with a second instance of a peer application; determining a second failure group of the second instance; comparing the first failure group to the second failure group; and establishing a second connection with a third instance of the peer application if the first failure group and the second failure group share a failure point.