Augmented Stub Failover via Naming Service
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In clustered computer systems, existing technologies face challenges in transparently detecting and recovering from node failures, leading to communication failures and loss of session state data, which complicates graceful failover and increases system complexity.
Innovation Solution
A system with an augmented stub that detects node failures and transparently fails over to another node, using a naming service to manage cluster membership and maintain cluster state data, ensuring seamless communication and session continuity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If nodes are made cluster-aware to detect failures and resume jobs, then graceful failover is achieved, but device complexity increases significantly
Solution Approach 1:
The patent introduces a naming service as an intermediary component that centralizes the complexity of cluster member management and failure detection. Individual nodes do not need to implement complex failure detection logic; instead, they rely on the naming service to provide updated references to active cluster members. This mediator absorbs the complexity burden, allowing nodes to remain simpler while still achieving graceful failover.
Solution Approach 2:
The naming service implements a feedback mechanism where it continuously monitors cluster member status and provides updated references back to clients. When a node fails, the naming service detects the failure and returns updated stub information to clients, enabling automatic failover without requiring complex local detection logic at each node.
2Stability of the object's composition
If load balancer directs all requests to a single node, then session state coherence is maintained, but communication failure occurs when that node fails
Solution Approach 1:
The patent makes the client stub dynamic by enabling it to automatically update its reference target based on cluster member status changes. Instead of a static reference to a single node, the stub can be reassigned to different active nodes through the naming service, maintaining session state coherence while adapting to node failures.
Solution Approach 2:
The system performs preliminary actions by having the naming service proactively detect node failures and update stub references before the client attempts communication with a failed node. This prevents communication failures by redirecting requests to active nodes in advance.
3Productivity
If multiple nodes run application components, then scalability and fault tolerance are improved, but detecting and recovering from failures becomes more difficult
Solution Approach 1:
The naming service acts as a central intermediary that simplifies failure detection in scaled environments. Instead of each client having to monitor multiple nodes independently, the naming service consolidates this function, providing a single point of query for active cluster members and their current status.
Solution Approach 2:
The naming service implements self-service by automatically monitoring cluster member status and proactively updating client stubs when failures occur. This eliminates the need for clients to implement their own complex failure detection and recovery logic, simplifying the scaled system while maintaining reliability.
Data Source
AI summary
Various embodiments of a system and method for failing over one cluster node to another are disclosed. The system may include a client networked to a cluster of computer nodes, connected to a persistent data store such as a database resident on a backend system. Each node of the cluster may be configured to run a distributed application component. The client may be configured to communicate with an instance of the application running on a first node. The client may include an augmented stub capable of accessing the instance of the application on the first node and capable of detecting a failure of the first node. In response to detecting a failure in the first node, the augmented stub may be capable of failing over to a second node and accessing the instance of the application on the second node, transparently to the client.