Distributed Orchestrator Swarm for Resource Allocation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current centralized and decentralized systems for deploying client applications in computer networks face bottlenecks and single points of failure, leading to inefficiencies and unreliability in resource allocation and management.

Innovation Solution

A distributed computer network where orchestrators from different infrastructures form a swarm, using a consensus protocol to synchronize and harmonize resource allocation decisions, avoiding bottlenecks and failures by distributing evaluations and ensuring unique and consistent resource allocation for client applications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a centralized system is used for deploying client applications, then resource allocation decisions can be made centrally, but the central node becomes a bottleneck and a single point of failure

Engineering Contradiction:
Improveresource allocation managementVSAvoidsystem reliability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent divides the centralized resource allocation function into multiple distributed orchestrators that operate independently across different infrastructures. Each orchestrator handles resource allocation decisions locally, eliminating the single central node and distributing the workload across multiple entities, thereby removing both the bottleneck and the single point of failure.

Inventive Principle:
Principle #1Segmentation

2Reliability

If a decentralized system is used for deploying client applications, then bottlenecks and single points of failure are avoided, but ensuring unique and consistent resource allocation becomes more difficult

Engineering Contradiction:
Improvesystem reliabilityVSAvoidcoordination complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a feedback mechanism where orchestrators exchange information about resource allocation decisions through a cooperation interface. When an orchestrator allocates resources, it notifies other orchestrators to prevent duplicate allocations. This feedback loop ensures consistent resource allocation across the distributed system without requiring complex centralized coordination.

Inventive Principle:
Principle #23Feedback

3Productivity

If multiple orchestrators independently allocate resources without coordination, then deployment speed may increase, but resource allocation consistency and uniqueness cannot be guaranteed

Engineering Contradiction:
Improvedeployment speedVSAvoidresource allocation consistency
Core Design Contradiction:
ProductivityVSManufacturing precision

Solution Approach 1:

The patent introduces a cooperation interface as an intermediary mechanism between orchestrators. This interface enables orchestrators to communicate allocation decisions and coordinate with each other, ensuring that resource allocation remains consistent and unique across the distributed system while maintaining the speed benefits of parallel independent operations.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3732565B1Computer network of computing resource infrastructures and method for allocating said resources to client applications
Publication Date: 2023.06.28 BULL SA
  • EP3732565B1 patent drawingFigure 1(A)~2
  • EP3732565B1 patent drawingFigure 3~4
  • EP3732565B1 patent drawingFigure 5

AI summary

The invention relates to a computer network comprising a group of multiple computing resource infrastructures (51 to 56) associated with multiple orchestrators (41 to 46), said orchestrators being responsible for allocating the resources of this infrastructure (51 to 56) to one or more additional components of an already-hosted client application (17) and being grouped together in a swarm in which they are interconnected by a cooperation interface (3). The allocation of resources is decided by a decision method based first on evaluations distributed to the orchestrators (41 to 46), then on a consensus protocol, between the orchestrators (41 to 46), which is based on the evaluations and which is implemented at the cooperation interface (3) in order to select one of the infrastructures (51 to 56) from the group to host the additional component(s) of the client application (17).