Containerizing Block Storage Service Components
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In a virtualized environment, block storage services like Cinder face dependency issues due to the need for direct access to host computer directories, leading to coordinated updates that can negatively impact running processes.
Innovation Solution
Containerizing the components of a block storage service, such as Cinder, into individual micro-services using containerization technologies like Docker, allowing each component to access necessary volumes and be upgraded independently.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If block storage service components are run directly on the host system, then they can directly access host directories and devices, but dependency issues arise between components and coordinated updates are required which negatively impact running processes
Solution Approach 1:
The block storage service is segmented into multiple independent components (scheduler, API, volume), each running in separate containers. This segmentation eliminates dependency issues between components while maintaining direct access to host directories and devices through volume mounting, resolving the contradiction between component independence and system complexity.
2Ease of operation
If block storage service components are updated together, then dependency consistency is maintained, but running processes are negatively impacted by coordinated updates
Solution Approach 1:
By segmenting the block storage service into independent containerized components, each component can be updated individually without requiring coordinated updates. The container isolation ensures that updating one component does not impact other running components, allowing updates without service disruption.
Solution Approach 2:
The container runtime acts as an intermediary layer between the block storage service components and the host system. This intermediary enables individual component updates while maintaining service availability, as the container orchestration manages the update process without requiring all components to be updated simultaneously.
3Adaptability or versatility
If block storage service components are containerized, then individual upgrades are facilitated and dependency issues are eliminated, but additional containerization infrastructure is required
Solution Approach 1:
The block storage service is segmented into independent containerized components, enabling individual upgrades and eliminating dependency issues. The segmentation approach accepts the added infrastructure complexity of containerization as a trade-off for achieving high adaptability and upgradeability.
Solution Approach 2:
The containerization infrastructure provides universal support for running multiple block storage service components with different versions and configurations. This multi-functional platform enables individual component upgrades, isolated testing, and flexible deployment, justifying the additional infrastructure requirements through enhanced versatility.
Data Source
AI summary
Containerization of a block storage service. A scheduler component of a block storage service is initiated in a first container via a containerization technology. A log volume maintained by a host operating system is mounted to the first container to allow the scheduler component access to the log volume. An application programming interface (API) component of the block storage service is initiated in a second container via the containerization technology. The log volume is mounted to the second container to allow the API component access to the log volume of the host operating system. A volume component of the block storage service is initiated in a third container via the containerization technology. A device volume is mounted to the third container to allow the volume component access to the device volume of the host operating system.