Multilevel Multipath Distributed Computing Node Architecture

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Cloud computing architectures face challenges in combining on-site and off-site calculations due to differences in location and capabilities of computers, as well as the transient availability of cloud computers, leading to underutilization of resources and recovery issues.

Innovation Solution

A multilevel multipath widely distributed computational node architecture that includes a cloud computing broker node, a wide distribution proxy node, and a head node, which enables transparent offloading of calculations onto cloud workers, maps between logical and physical nodes, and recovers from node failures by re-routing requests, allowing applications to use both on-premise and cloud resources without modification.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If cloud computing resources are used to combine on-site and off-site calculations, then resource utilization is improved, but the complexity of managing transient availability and differences in computer capabilities increases

Engineering Contradiction:
Improveresource utilizationVSAvoidarchitecture complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent introduces intermediary components including a virtualization layer that abstracts physical cloud resources into virtual machines, and a service broker that mediates between applications and cloud services. These intermediaries hide the complexity of transient availability and capability differences, allowing applications to utilize diverse cloud resources without directly managing their heterogeneity or instability.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The architecture segments the cloud computing system into distinct functional layers: infrastructure layer (physical resources), virtualization layer (virtual machines), service layer (cloud services), and application layer. This segmentation isolates complexity within specific layers while presenting a simplified interface to applications, enabling high resource utilization without proportionally increasing application-side complexity.

Inventive Principle:
Principle #1Segmentation

2Power

If cloud computers are used for off-site calculations, then computing capacity is improved, but the reliability of computation is worsened due to transient availability

Engineering Contradiction:
Improvecomputing capacityVSAvoidcomputation reliability
Core Design Contradiction:
PowerVSReliability

Solution Approach 1:

The patent implements beforehand cushioning through multiple mechanisms: service brokers establish redundant service endpoints in advance, virtual machine images are pre-configured with necessary software environments, and service contracts define expected behavior patterns. These preparatory measures cushion against transient failures by having fallback options ready before disruptions occur.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

Solution Approach 2:

The architecture incorporates feedback loops where service brokers monitor cloud service availability and performance, automatically rerouting requests to alternative services when failures occur. The system continuously adjusts service allocation based on observed reliability metrics, learning from transient failures to improve future computation reliability while maintaining high computing capacity utilization.

Inventive Principle:
Principle #23Feedback

3Adaptability or versatility

If applications are modified to use both on-premise and cloud resources, then resource flexibility is improved, but the ease of operation is worsened

Engineering Contradiction:
Improveresource flexibilityVSAvoidapplication operation simplicity
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent creates universal interfaces and standardized service contracts that enable applications to interact with both on-premise and cloud resources through common protocols. The service broker provides multi-functional capabilities to discover, allocate, and manage diverse resources uniformly, allowing applications to access hybrid resources without modification while maintaining operational simplicity.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system creates virtual copies of on-premise resources in the cloud through virtual machine images and container templates. Applications interact with these virtual copies using the same interfaces as physical resources, enabling seamless hybrid operation without requiring application-specific modifications. The virtual copies preserve the operational characteristics of original resources while providing cloud-based accessibility.

Inventive Principle:
Principle #26Copying

4Loss of energy

If cloud resources are dynamically allocated, then resource efficiency is improved, but the difficulty of detecting and measuring resource status increases

Engineering Contradiction:
Improveresource efficiencyVSAvoidresource status monitoring
Core Design Contradiction:
Loss of energyVSDifficulty of detecting and measuring

Solution Approach 1:

The service broker implements comprehensive feedback mechanisms that continuously monitor resource allocation, utilization, and status across cloud and on-premise environments. Automated metrics collection and reporting systems provide real-time visibility into resource states, enabling efficient dynamic allocation while maintaining straightforward monitoring through centralized dashboards and standardized status indicators.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS9634956B2Multilevel multipath widely distributed computational node scenarios
Publication Date: 2017.04.25 MICROSOFT TECHNOLOGY LICENSING LLC
  • US9634956B2 patent drawing
  • US9634956B2 patent drawing
  • US9634956B2 patent drawing

AI summary

An application combines on-site and cloud-based calculations. The application selects a cloud computing broker from a list sorted by load. The broker receives computation requests from the application, sends corresponding load-balanced requests to local application service hosts and cloud proxies, receives responses, and sends the responses to the application without identifying the response source as local versus non-local. Each proxy has a logical-physical mapping of cloud-resident worker nodes. A scheduler receives session requests from applications, allocates local and cloud computing resources to a session, and tracks resource usage by session. An application previously run only on-premises can be executed partially on cloud worker nodes without modification. The proxy re-routes unfulfilled requests from a failed worker, undetected by the broker. If all workers assigned to that proxy fail, then the broker reassigns unfulfilled requests to another proxy, undetected by the application.