Container Failover Orchestration via Local Filesystem Remounting
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-node clusters, Docker containers face challenges in maintaining data availability and performance during node failures or migrations, as existing solutions like Kubernetes and Docker Swarm require a minimum of three nodes and incur performance overhead when using clustered filesystems or network shares.
Innovation Solution
An orchestration system that coordinates the destruction of Docker volumes on one node, unmounts and remounts application data as a local filesystem on another node, and creates Docker volumes to restart the container, enabling seamless failover across nodes without relying on clustered filesystems or network shares, even on a two-node cluster.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If clustered filesystems or network shares are used to share application data across nodes, then data availability is improved, but performance overhead increases
Solution Approach 1:
The system performs preliminary actions by pre-mounting the shared physical device containing application data to each cluster node before container startup. This allows the node to access data locally without requiring real-time network access to clustered filesystems or network shares during container operation, thus maintaining data availability while avoiding performance overhead.
Solution Approach 2:
The shared physical device acts as an intermediary between the clustered storage system and the container's local filesystem. By mounting this physical device locally on each node, the system creates a local cache layer that provides fast access to application data while the actual data resides on shared storage, thus bridging the gap between data availability and performance requirements.
2Adaptability or versatility
If existing orchestration systems like Kubernetes or Docker Swarm are used, then container management is improved, but minimum node requirements increase to three nodes
Solution Approach 1:
The invention extracts the essential orchestration functionality needed for container failover from complex systems like Kubernetes and Docker Swarm. By implementing a simplified orchestration mechanism that only handles the critical aspects of container lifecycle management and node failover, the system achieves container management capability with fewer nodes, removing unnecessary complexity and minimum node requirements.
Solution Approach 2:
The system changes the parameter of minimum cluster size from three nodes to two nodes by modifying the failover mechanism. Instead of requiring a quorum of three nodes for consensus, the invention implements a simpler failover approach where a single active node can be failed over to a standby node, thus reducing the minimum node requirement while maintaining orchestration capabilities.
3Reliability
If Docker containers are moved between nodes during failover, then system reliability is improved, but data access complexity increases
Solution Approach 1:
The invention merges the data access paths by mounting the shared physical device containing application data directly to each cluster node's local filesystem. This consolidation allows containers on any node to access data through a unified local mount point, simplifying data access complexity while enabling seamless container migration between nodes for improved reliability.
Data Source
AI summary
Failover of a Docker container between nodes of a cluster is orchestrated to enable the Docker container's data to be made available across all nodes of the cluster. Using this orchestration system, if a second cluster node is selected to be used to bring up a Docker container, the orchestration system coordinates destroying the previous Docker volumes on the first cluster node, unmounting a physical device containing the application data from the first cluster node's virtual filesystem, remounting the physical device containing the application data in the virtual filesystem of the second cluster node, creating a Docker volume referencing the application data on the second cluster node, and using the Docker volume to start a new instance of the Docker container on the second cluster node. This enables the Docker container to be started on any node of a cluster and have the application data available as a local filesystem.