Distributed Resource Management for Cloud Job Queues

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional distributed schedulers fail to efficiently manage dynamic cloud computing environments, where resources are scaled up or down based on demand, leading to inefficiencies such as high overhead in job execution and inadequate support for computationally intensive tasks.

Innovation Solution

A system and method for distributed resource management that identifies suitable nodes to add to a cluster based on composite memory and processing core requirements, using a bidding process to dynamically allocate resources and ensure efficient job execution while minimizing costs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If cloud computing resources are dynamically scaled up or down based on demand, then resource utilization efficiency is improved, but conventional distributed schedulers fail to handle the dynamic element satisfactorily leading to job execution failures

Engineering Contradiction:
Improveresource utilization efficiencyVSAvoidjob execution reliability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The scheduler dynamically adapts to changing cloud computing resources by continuously monitoring resource availability and adjusting job allocation in real-time. When resources are added or removed from the cloud cluster, the scheduler automatically recalculates resource requirements and redistributes jobs to maintain both efficiency and reliability.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system implements feedback mechanisms where the scheduler receives status updates from cloud resources and adjusts its allocation decisions accordingly. This closed-loop control ensures that job execution reliability is maintained even as the underlying cloud infrastructure dynamically changes capacity.

Inventive Principle:
Principle #23Feedback

2Reliability

If cloud based solutions spin up an entire virtual node for each job chunk, then job isolation and resource allocation are improved, but overhead per submitted job increases to two-to five-minutes substantially reducing efficiency of short jobs

Engineering Contradiction:
Improvejob isolationVSAvoidjob execution overhead
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The scheduler consolidates multiple small job chunks onto shared cloud computing nodes rather than spinning up separate virtual nodes for each chunk. This merging approach maintains job isolation through software-based resource allocation while eliminating the overhead of repeatedly provisioning virtual infrastructure, thereby significantly reducing execution time for short jobs.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The system pre-provisions cloud computing nodes and keeps them in a ready state before jobs are submitted. This preliminary action eliminates the need to spin up virtual nodes at job submission time, reducing overhead while maintaining the ability to isolate jobs through controlled allocation to pre-prepared resources.

Inventive Principle:
Principle #10Preliminary action

3Quantity of substance

If cloud based solutions provide ample memory support for each chunk, then memory availability is improved, but cost effectiveness deteriorates

Engineering Contradiction:
Improvememory availabilityVSAvoidcomputing cost
Core Design Contradiction:
Quantity of substanceVSLoss of energy

Solution Approach 1:

The scheduler allocates memory resources dynamically based on actual job requirements rather than providing ample memory to every job by default. This partial action approach ensures that memory is available when needed while avoiding the excessive allocation that would drive up costs, achieving a balance between memory availability and cost-effectiveness.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system changes memory allocation parameters dynamically based on job characteristics and current cloud resource states. By adjusting memory limits and allocations in real-time according to actual needs, the scheduler maintains adequate memory availability for computationally intensive tasks while optimizing cost effectiveness by avoiding unnecessary memory provisioning.

Inventive Principle:
Principle #35Parameter changes

4Productivity

If operations groups add and renew resources to clusters without restarting nodes, then operational continuity is improved, but conventional distributed computing schedulers do not support this feature satisfactorily

Engineering Contradiction:
Improveoperational continuityVSAvoidscheduler flexibility
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The scheduler is designed to dynamically detect and adapt to changes in the cloud cluster composition. When operations groups add or renew resources without restarting nodes, the scheduler automatically monitors for these changes, updates its resource inventory, and redistributes jobs to utilize the new capacity, thereby maintaining operational continuity and demonstrating high flexibility.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS9946577B1Systems and methods for distributed resource management
Publication Date: 2018.04.17 10X GENOMICS INC
  • US9946577B1 patent drawing
  • US9946577B1 patent drawing
  • US9946577B1 patent drawing

AI summary

Methods, nontransitory computer readable media, and systems are disclosed for servicing a job queue. Each job has node resource requirements. Composite job memory and processor requirements is determined from these requirements. Nodes that satisfy these requirements are identified by obtaining, for each class of a plurality of node classes: an availability score, a number of processors, and a memory capability. A request for nodes of a class is made when a demand score for the class satisfies the class availability score. An acknowledgement and updated availability score is received upon request acceptance. A declination is received upon request rejection. The submitting and receiving is performing multiple times, if needed, until each class has been considered for a request or sufficient acknowledgements are received to satisfy the composite requirements of the jobs. Each node in the cluster draws jobs from the queue subject to the collective requirements of the drawn jobs.