Event-Driven Resource Management in Cluster Computing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional cluster computing systems face scalability issues due to centralized database architectures, performance bottlenecks from CPU-intensive metadata transport, and inefficient resource management through polling, which restricts resource utilization and flexibility.

Innovation Solution

Implementing a mobile state object for metadata storage and transport, an event-driven resource management architecture that allows atomic-level job decomposition and distribution, and an agentless system for resource management, enabling real-time tracking and efficient load-balancing without the need for centralized polling.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a centralized database architecture is used to store metadata, then data consistency and centralized control are improved, but scalability and system performance deteriorate due to heavy load on the database

Engineering Contradiction:
Improvedata consistencyVSAvoidsystem scalability
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the centralized metadata storage into distributed key-value stores across multiple nodes. Each node maintains its own local metadata, eliminating the single-point bottleneck. The segmentation allows the system to scale horizontally by adding more nodes, as each node independently handles its metadata without overwhelming a central database.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent extracts the metadata storage function from the centralized database and places it in distributed key-value stores on each compute node. This extraction removes the heavy load from the centralized database while maintaining the necessary metadata management capabilities at the edge, improving both scalability and performance.

Inventive Principle:
Principle #2Taking out (Extraction)

2Loss of information

If a conventional transport architecture with protocol messages is used, then structured data transmission is improved, but CPU processing time and network bandwidth consumption increase due to serialization, parsing, and message handling

Engineering Contradiction:
Improvestructured data transmissionVSAvoidCPU processing time
Core Design Contradiction:
Loss of informationVSLoss of time

Solution Approach 1:

The patent extracts the essential metadata (job ID, node ID, status) from complex protocol messages and transmits only these critical key-value pairs. This extraction eliminates the overhead of serialization, parsing, and message encapsulation while retaining the necessary information for job tracking and resource management.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent uses simple key-value pairs as lightweight copies of the essential information from complex protocol messages. Instead of transmitting full structured messages, the system transmits simplified representations that capture the necessary state information with minimal processing overhead.

Inventive Principle:
Principle #26Copying

3Reliability

If polling technique is used for resource management, then centralized control and monitoring are improved, but network traffic and system load increase significantly

Engineering Contradiction:
Improvecentralized controlVSAvoidnetwork traffic
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent inverts the polling approach by having compute nodes proactively notify the resource manager of their status changes and resource availability. Instead of the resource manager continuously querying each node, nodes push updates when their state changes, dramatically reducing network traffic while maintaining centralized visibility.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The patent implements an event-driven feedback mechanism where compute nodes automatically notify the resource manager of status changes, job completion, and resource availability. This feedback loop maintains centralized control without requiring continuous polling, as the system responds to actual events rather than periodic queries.

Inventive Principle:
Principle #23Feedback

4Reliability

If an agent-based resource management system is used, then resource monitoring and control are improved, but device complexity and ease of joining new systems deteriorate due to installation and configuration requirements

Engineering Contradiction:
Improveresource monitoringVSAvoidsystem configuration
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent enables compute nodes to self-register with the resource manager by automatically announcing their presence and capabilities. Nodes do not require pre-installed agents or complex configuration; they simply connect to the network and the resource manager discovers and manages them automatically, reducing complexity while maintaining monitoring capabilities.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent uses a lightweight key-value store as an intermediary between compute nodes and the resource manager, eliminating the need for heavy agent software. The key-value store serves as a simple communication medium that nodes can access without complex installations, while the resource manager queries this store for resource information.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS10067791B2Methods and apparatus for resource management in cluster computing
Publication Date: 2018.09.04 ADOBE INC
  • US10067791B2 patent drawing
  • US10067791B2 patent drawing
  • US10067791B2 patent drawing

AI summary

Embodiments of an event-driven resource management technique may enable the management of cluster resources at a sub-computer level (e.g., at the thread level) and the decomposition of jobs at an atomic (task) level. A job queue may request a resource for a job from a resource manager, which may locate a resource in a resource list and grant the resource to the job queue. After the resource is granted, the job queue sends the job to the resource, on which the job may be partitioned into tasks and from which additional resources may be requested from the resource manager. The resource manager may locate additional resources in the list and grant the resources to the resource. The resource sends the tasks to the granted resources for execution. As resources complete their tasks, the resource manager is informed so that the status of the resources in the list can be updated.