Selective TCP/IP Stack Recovery via Segmented Groups
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current network communication systems in clusters of computer systems face disruptions when a TCP/IP stack fails, as the default recovery action involves deleting all dynamic virtual IP addresses and removing the stack from the cluster, which can be unnecessarily disruptive and affect other workloads.
Innovation Solution
Defining recovery groups on each TCP/IP stack with specific IP addresses, trigger conditions, and recovery actions allows for targeted recovery of failing groups without disrupting the entire stack, enabling a backup stack to take over only the failing group's functions while maintaining uninterrupted operation of other workloads.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the default recovery action is taken to delete all dynamic virtual IP addresses and remove the TCP/IP stack from the cluster, then the reliability of the network service is improved through failure recovery, but the productivity of other workloads deteriorates due to unnecessary disruption
Solution Approach 1:
The patent segments the TCP/IP stack's IP address management into independent recovery groups. Each recovery group contains specific IP addresses and associated services that can be independently monitored and recovered. When a failure occurs, only the affected recovery group is restored rather than the entire stack, allowing other workloads to continue operating uninterrupted.
Solution Approach 2:
The patent extracts the problematic recovery mechanism from the entire TCP/IP stack and applies it selectively to individual recovery groups. By isolating the recovery action to specific groups rather than the whole stack, the system takes out only the necessary components for restoration while leaving other services unaffected.
2Productivity
If selective recovery of individual recovery groups is implemented, then the productivity of other workloads is maintained through uninterrupted operation, but the device complexity increases due to recovery group configuration and monitoring
Solution Approach 1:
The patent creates a universal recovery mechanism that can handle multiple types of failures across different services through a standardized recovery group structure. The same monitoring and recovery infrastructure serves all recovery groups, reducing the need for separate complex configurations for each service while maintaining selective recovery capability.
Solution Approach 2:
The system implements self-service through automatic monitoring of trigger conditions and autonomous execution of recovery actions. The monitoring component continuously checks for failure conditions and automatically initiates recovery without human intervention, reducing operational complexity while maintaining productivity.
3Reliability
If monitoring of multiple recovery groups is implemented with trigger conditions and recovery actions, then the reliability of selective recovery is improved, but the use of energy and computational resources increases
Solution Approach 1:
The patent applies partial monitoring by focusing computational resources only on specific trigger conditions that indicate actual failures, rather than continuously monitoring all possible parameters. Recovery actions are initiated only when necessary trigger conditions are met, reducing unnecessary computational overhead while maintaining reliable selective recovery.
Data Source
AI summary
A method, system, and program product are provided. A plurality of recovery groups is defined on each transmission control protocol/internet protocol (TCP/IP) stack in a cluster of servers. The recovery group includes a service, one or more IP addresses associated with the service, a trigger condition, and a recovery action. Each of the recovery groups is monitored for an occurrence of the trigger condition associated with the service. In response to detecting the trigger condition, a backup TCP/IP stack is notified to automatically perform the recovery action defined for a failing recovery group on an owning TCP/IP stack. Only the failing recovery group is recovered and the remaining recovery groups execute uninterrupted.