Orchestration Slave Local Storage for Container Availability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Container-based applications on IoT devices face interruptions due to unreliable connections with orchestration masters, leading to service disruptions and inability to manage safety-critical applications effectively.
Innovation Solution
Implementing an orchestration system where implementation information is saved persistently on the terminal device, allowing the orchestration slave to autonomously restart and manage container instances without continuous connection to the orchestration master, and utilizing a contingency policy to adapt resource allocation based on failure duration and type.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If container-based applications are managed through a central orchestration master with continuous connection requirements, then resource allocation and fault management are centralized and controllable, but service availability is compromised when connection interruptions occur
Solution Approach 1:
The orchestration slave unit stores implementation information locally in advance before connection interruptions occur. This preliminary action enables the slave unit to autonomously restart and manage container instances without requiring real-time connection to the orchestration master, thereby maintaining service availability during network failures.
Solution Approach 2:
The orchestration slave unit is empowered to autonomously manage container instances using locally stored implementation information when disconnected from the orchestration master. This self-service capability allows the slave unit to independently handle container deployment, monitoring, and recovery without external control, ensuring continuous operation during connection interruptions.
2Reliability
If the orchestration master continuously monitors and manages container instances, then fault detection and recovery are prompt, but service interruption occurs when the master becomes unreachable
Solution Approach 1:
The orchestration slave unit pre-stores implementation information including container configuration, resource allocation, and recovery procedures before disconnection occurs. This allows the slave unit to immediately detect faults and execute recovery actions using locally available information, eliminating the time delay associated with waiting for master unit responses during connection interruptions.
Solution Approach 2:
The system maintains local copies of implementation information as a buffer against connection failures. This beforehand cushioning ensures that even when the orchestration master becomes unreachable, the slave unit has sufficient information to detect faults and initiate recovery procedures without service interruption.
3Productivity
If container instances are swapped to other devices when a device becomes unavailable, then resource utilization is optimized, but safety-critical applications cannot be guaranteed on specific devices
Solution Approach 1:
The orchestration slave unit stores implementation information locally in advance, enabling it to autonomously restart container instances on the same device without requiring master unit intervention. This ensures that safety-critical applications remain anchored to their designated devices while still allowing non-critical applications to be swapped for optimized resource utilization.
Solution Approach 2:
The system applies different strategies to different applications: safety-critical applications are maintained on specific devices through local autonomous recovery capabilities, while non-critical applications can be swapped across devices for optimized resource utilization. This local quality differentiation resolves the contradiction between resource efficiency and application availability guarantees.
Data Source
AI summary
Provided is a method for orchestrating a container-based application that is executed on a terminal device, in which implementation information is received in an orchestration slave unit on the terminal device via a communication connection from an orchestration master unit, and the application is configured and/or controlled by the orchestration slave unit based on the implementation information, wherein the received implementation information is additionally saved persistently in a memory unit in the terminal device, and if the communication connection to the orchestration master unit is interrupted, the most recently saved implementation information is retrieved from the orchestration slave unit and the application is configured and/or controlled based on the most recently saved implementation information.