Key-Per-IO Multi-Tenant Isolation Through Double-Indexed Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing key-per IO (KIPO) processing for multiple tenants faces challenges in managing key changes atomically, leading to bandwidth loss for unaffected tenants during operations on keys.
Innovation Solution
Implementing indirect-double-indexing to duplicate the key-index list during key manipulation requests, allowing all tenants to continue working until the request is complete, and then switching to the updated table.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the key-index list is updated atomically for key management operations, then key integrity and security are maintained, but all tenants must stop working during the update process causing bandwidth loss
Solution Approach 1:
The key-index list is segmented into multiple independent lists (first key-index list and second key-index list). The controller can switch between these lists, allowing one list to be updated while tenants continue to operate using the other list. This segmentation resolves the contradiction by enabling atomic updates without forcing all tenants to stop working.
Solution Approach 2:
The system changes the operational parameter from a single static key-index list to multiple dynamic lists that can be switched between. By maintaining both a first and second key-index list with different states (one being updated, one being used for operations), the system allows continuous tenant operations while key management updates occur in the background.
2Productivity
If the key-index list is duplicated to allow continuous operations during updates, then tenant bandwidth is maintained, but device complexity increases
Solution Approach 1:
Multiple key-index lists are merged into a unified management structure controlled by a single controller. The controller maintains both the first and second key-index lists and manages the switching between them, consolidating the complexity of managing multiple lists into a single control unit rather than distributing complexity across multiple independent systems.
3Ease of operation
If a tenant requests to manipulate the key-index table, then key management operations can be performed, but the requesting tenant and other tenants experience bandwidth loss during the operation
Solution Approach 1:
The system prepares a second key-index list in advance as a backup or alternative operational list. When a tenant requests key manipulation, the controller can perform the manipulation on the second list while tenants continue to operate using the first list, eliminating the need to stop operations for key management.
Solution Approach 2:
The controller acts as an intermediary between tenant requests and the key-index lists. It receives manipulation requests, processes them on the appropriate list (typically the second list), and manages the switching between lists, allowing tenant operations to continue uninterrupted while key management occurs in the background.
Data Source
AI summary
The present disclosure generally relates improved key-per IO (KIPO) processing for multiple tenants. Rather than when a tenant requests a key change to stop tenants from working, indirect-double-indexing can be used to prevent bandwidth loss in tenants during adaptions for other tenants. When a tenant requests to manipulate the key-index table, the system will keep working. The current key index list will be duplicated. While the duplicated key-index list is manipulated according to the request, all tenants may still work on their current key-index tables until the request is complete. Once the request is complete, the tenant with the request will switch to the new table, while the old table is updated. Once the old table is updated, the tenant will switch to the updated table for continued work. No tenant, including the tenant that makes the request, continues working as the request is completed.