Virtualized Block Storage Servers in Cloud Substrate Extensions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The challenge in providing virtualized block storage services in a provider substrate extension is the difficulty in initializing the block storage service from a boot volume when there is no block storage service running on the substrate extension, leading to increased latency and security concerns due to reliance on the provider network for block storage servers.
Innovation Solution
The solution involves virtualizing the block storage service to run within a compute instance, allowing a single server to host both a compute instance and a block storage server, and implementing local boot techniques to load a boot volume from data stored in the provider network, enabling the launch of instances even without a block storage service present on the substrate extension.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If block storage service is centralized on provider network, then security and management are simplified, but latency increases and availability decreases
Solution Approach 1:
The block storage service is segmented into distributed block storage servers deployed across multiple substrate extensions. Each server independently manages local storage resources, enabling clients to access storage with lower latency while maintaining security through the virtualization layer. This segmentation resolves the contradiction by localizing storage operations closer to clients without compromising centralized security management.
Solution Approach 2:
The architecture introduces a new dimensional layer - the substrate extension - between the centralized provider network and client systems. This intermediate dimension enables block storage servers to be deployed closer to clients geographically while maintaining logical connection to the provider network, thereby reducing latency without sacrificing security or management control.
2Productivity
If block storage servers are distributed across substrate extensions, then latency is reduced and availability improved, but system complexity increases
Solution Approach 1:
The block storage server is designed as a universal component that can be deployed on any substrate extension with similar functionality. Each server implements the same standardized interface and operations, allowing them to perform multiple functions including storing data, booting instances, and providing I/O operations. This universality reduces system complexity by using identical components throughout the distributed architecture.
Solution Approach 2:
The virtualization layer acts as an intermediary between clients and distributed block storage servers, abstracting away the complexity of the distributed system. Clients interact with standardized virtual storage interfaces while the intermediary handles the complexity of locating, managing, and coordinating multiple physical storage servers, thereby reducing perceived system complexity for end users.
3Ease of operation
If boot volume is loaded from provider network, then no local storage service is needed, but latency increases and security concerns arise
Solution Approach 1:
Boot volumes are pre-loaded into local storage on block storage servers before instances need to boot. The system anticipates boot requirements and prepares storage resources in advance, allowing instances to boot quickly from locally cached boot volumes rather than loading them over the network at boot time, thereby reducing boot latency while maintaining ease of operation.
Solution Approach 2:
The system creates local copies of boot volumes on block storage servers. Instead of requiring the original boot volume to be accessible from the provider network during boot operations, the system copies the necessary boot data to local storage on the substrate extension, enabling fast local booting while maintaining security through controlled copy operations managed by the virtualization layer.
Data Source
AI summary
A first block storage server virtual machine to host a first volume using one or more storage devices of a computer system is executed by the computer system. A second virtual machine having access to a virtual block storage device is executed by the computer system. A block storage client is executed by the computer system. A first block storage operation is received by the block storage client from the second virtual machine, the first block storage operation to perform on the virtual block storage device. A message is sent by the block storage client to the first block storage server virtual machine to cause the first block storage server virtual machine to perform the block storage operation with the first volume.