Master-Slave Server Redundancy Controller
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current master-slave server architectures require manual and time-consuming operator intervention for fault recovery, leading to inefficiencies, potential errors, and breaches of service availability commitments, as they lack automated mechanisms for switching services back to the master server after a fault has been resolved.
Innovation Solution
A system and method that automatically switches services from a slave server to a master server upon successful completion of automated tests, utilizing a controller to manage service redundancy, enabling and disabling service redundancy features, and performing tests to ensure the master server can safely recover services without human error.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If manual operator intervention is used for fault recovery and switching services back to the master server, then service redundancy can be maintained, but the process becomes time-consuming and error-prone
Solution Approach 1:
The system performs self-diagnosis and self-recovery through automated testing and switching mechanisms. The slave server automatically tests the master server and switches services back when readiness is confirmed, eliminating the need for manual operator intervention and significantly reducing fault recovery time while maintaining reliability
Solution Approach 2:
The system implements continuous monitoring and feedback loops where the slave server periodically tests the master server's readiness. Based on test results, the system automatically adjusts its state - either maintaining service on the slave server or switching back to the master server, creating a closed-loop control system that ensures service availability without manual intervention
2Productivity
If automated testing and switching mechanisms are implemented, then fault recovery efficiency is enhanced, but system complexity increases
Solution Approach 1:
The system introduces a controller as an intermediary component that manages the complexity of automated testing and switching. The controller coordinates between the master server, slave server, and testing mechanisms, centralizing the control logic and making the system's complexity manageable through a dedicated coordination layer rather than distributed complexity
Solution Approach 2:
The fault recovery process is segmented into distinct, manageable phases: health checking, service switching, and readiness testing. Each phase is handled by specific system components with dedicated functions, breaking down the complex recovery process into modular segments that can be independently implemented, tested, and maintained
3Reliability
If operator intervention is required for fault recovery, then service switching can be controlled, but manpower costs and potential errors increase
Solution Approach 1:
The slave server autonomously performs health checking of the master server and automatically switches services back when readiness is confirmed. This self-service capability eliminates operator workload entirely for the critical fault recovery operations while maintaining strict control through predefined testing protocols and automated decision-making logic
4Measurement precision
If manual diagnostic activities are performed, then service recovery can be verified, but authentication and non-repudiation issues arise
Solution Approach 1:
The system implements automated feedback loops where test results directly trigger switching decisions. The slave server continuously monitors master server health through structured tests and automatically responds based on objective criteria, eliminating human error and authentication issues while maintaining precise verification through programmable testing protocols with complete audit trails
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Methods of and systems provide service redundancy between a master server and a slave server. The master server provides access to a pool of resources to a client. In response to detecting a fault on the master server, the master server is marked as disabled and services held on the master server are switched to the slave server and to a secondary pool of resources. The master service may be restarted if down. Then, provided that the master server is up, one or more tests are performed on the master server. The master server is marked as enabled if the tests are successful. The services may be switched back to the master server when the server is enabled. Services may further be rolled back to the slave server in case of an additional fault occurrence. The technique may also be used for updating a configuration in a service infrastructure.