Cross-Cluster Resource Sharing in Orchestrated Environments
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In orchestrated environments, unused hardware resources across clusters are not efficiently shared due to a 1:1 allocation of nodes to orchestrators, leading to surplus and unused resources being reserved without being utilized.
Innovation Solution
A method for resource sharing across multiple orchestrators, where clusters exchange load information to select target nodes based on utilization status, allowing resources to be dynamically allocated and used across clusters, with a provisioning policy ensuring specific requirements are met, and enabling flexible distribution of container instances.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If nodes are allocated 1:1 to orchestrators, then each orchestrator has dedicated resources, but surplus and unused resources are reserved without being shared across clusters
Solution Approach 1:
The patent merges resource pools across multiple clusters by allowing orchestrators to request nodes from other clusters' resource pools. The resource pool is no longer isolated to a single cluster but is shared across clusters, enabling resources to be allocated based on actual demand rather than fixed 1:1 orchestrator-to-node mappings. This resolves the contradiction by combining dedicated resource assurance with shared resource efficiency.
Solution Approach 2:
The patent introduces dynamic resource allocation where nodes can be dynamically assigned to different orchestrators based on real-time demand. The system transitions from static 1:1 allocation to dynamic pooling where nodes can be requested, allocated, and reassigned across clusters as needed. This dynamic approach ensures reliable resource availability when needed while maximizing overall utilization efficiency.
2Reliability
If clusters hold surplus resources in reserve, then load peaks can be absorbed, but these resources remain unused when not needed
Solution Approach 1:
The patent changes the parameter of resource allocation from fixed per-orchestrator to demand-based across clusters. When an orchestrator needs additional resources during load peaks, it can request nodes from the shared resource pool of other clusters. This parameter change allows the system to maintain reliability during peak loads while avoiding the waste of holding surplus resources idle, as resources are allocated only when actually needed across the entire multi-cluster system.
3Productivity
If resources are shared across multiple clusters, then resource utilization efficiency increases, but resource allocation complexity increases
Solution Approach 1:
The patent introduces a resource pool as an intermediary mechanism that simplifies cross-cluster resource sharing. Instead of complex direct orchestrator-to-orchestrator negotiation, the resource pool acts as a centralized abstraction layer where nodes from multiple clusters are pooled and can be requested by any orchestrator. This intermediary approach maintains high flexibility in resource distribution while reducing the complexity of management by abstracting the underlying cluster boundaries.
4Reliability
If nodes are allocated exclusively to their own cluster, then core tasks are ensured availability, but cross-cluster resource sharing is prevented
Solution Approach 1:
The patent segments the node allocation mechanism into two independent parts: (1) the resource pool that collects nodes from multiple clusters, and (2) the orchestrator's core tasks that run on allocated nodes. This segmentation allows nodes to be pooled across clusters while ensuring that when an orchestrator requests nodes, they are allocated to fulfill core task requirements. The segmentation maintains both cross-cluster flexibility and task availability guarantees by separating the pooling mechanism from the allocation purpose.
Data Source
AI summary
A method and assembly for resource sharing in an orchestrated environment is provided including a first cluster and a second cluster, wherein each cluster automatically managing a container instance on at least one node of the clusters, the instance being designed to: receive a request including a provisioning policy; determine a first utilization status of first nodes of the first cluster; determine a second utilization status of second nodes; select a target node from one of the first and second according to the provisioning policy and according to the first utilization status and the second utilization status via the first orchestration unit; and start the container instance on the target node using the second orchestration unit, if the selected target node is a second node.