Storage Processor Failover via Local Management Database Copies
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In data storage systems, the time required for failover to a standby storage processor (SP) to become active and respond to system management commands is excessively long due to the need to start up the management stack and connect to the management database, resulting in an unacceptably long 'blackout period' during which the system is unavailable.
Innovation Solution
Maintaining separate copies of the management database on each SP and executing the management stack on both, with event-driven messaging for synchronization, allowing the standby SP to immediately take over management control upon the active SP's unavailability, reducing the failover time to as little as one second.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the standby SP connects to the management database and performs initiation tasks after failover, then the system ensures data integrity and proper management control, but the failover time becomes excessively long resulting in an unacceptably long blackout period
Solution Approach 1:
The standby storage processor maintains a local copy of the management database and keeps the management stack in a pre-initialized state before failover occurs. This preliminary preparation eliminates the need for post-failover database connection and initialization tasks, reducing the blackout period while ensuring data integrity through the maintained database copy
2Adaptability or versatility
If the management database is stored on shared storage for standby SP access, then the standby SP can use the database upon failover, but the database access bottleneck and startup procedures result in undesirably long failover time
Solution Approach 1:
The standby storage processor maintains a local copy of the management database on its own storage, eliminating the need to access the shared storage database during failover. This copying approach removes the database access bottleneck and allows immediate database availability upon failover, significantly increasing failover speed while maintaining data integrity
3Device complexity
If only the active SP executes the management stack and maintains the management database, then the system simplifies management operations, but the failover process requires the standby SP to start up the management stack and connect to the database resulting in long blackout period
Solution Approach 1:
Both the active and standby storage processors execute the management stack and maintain local copies of the management database. The standby SP keeps its management stack in a pre-initialized, ready-to-serve state before failover occurs. This preliminary action ensures that upon failover, the standby can immediately assume the active role without startup delays, reducing the blackout period while maintaining manageable system complexity through symmetric configuration
Data Source
AI summary
A data storage system includes storage processors that execute respective datapath components and management components. The datapath components maintain logical storage objects being the target of the storage I/O commands and for which underlying data is stored on an array of storage devices. The management components operate in an active-standby fashion in which (1) the management components maintain respective separate copies of a management database storing information about the logical storage objects, (2) an active management component serves external requests from a storage administrator by accessing its copy of the management database, and (3) a standby management component responds to non-availability of the first management component by becoming the active management component and serving subsequent external requests from the storage administrator by accessing its copy of the management database. Failover speed is increased due to the standby management component maintaining a current copy of the management database.