Cloud Service Community Cloning for Hot Spot Load Balancing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing cloud platform management methods struggle to quickly adjust load pressure, leading to limited performance due to inefficient capacity expansion on individual cloud service components, which results in new components becoming hot points under high load.

Innovation Solution

Group cloud service components into communities based on call relationships, creating additional communities when necessary to share load, and apply load balancing strategies such as cloning and scaling to manage load pressure effectively.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If capacity expansion is performed on individual hot cloud service components one by one, then the hot point can be addressed, but the load pressure on the cloud platform cannot be quickly adjusted and performance is limited

Engineering Contradiction:
Improvehot point handlingVSAvoidload pressure adjustment speed
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the cloud service components into communities based on call relationships. Instead of treating individual components in isolation, the system groups them into functional units (communities) that can be managed together. This segmentation allows for more coordinated capacity expansion and load adjustment across related components, resolving the contradiction between handling hot points and quickly adjusting overall load pressure.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent merges multiple cloud service components into communities and treats them as a unified unit for capacity expansion. When a community is identified as needing expansion, the system expands capacity across the entire community rather than individually on each component. This merging approach enables faster load pressure adjustment while maintaining reliability, as the community acts as a cohesive unit that can absorb and distribute load more effectively.

Inventive Principle:
Principle #5Merging (Combining)

2Reliability

If cloud service components are adjusted individually, then specific hot points can be optimized, but the overall cloud platform performance is limited under heavy load

Engineering Contradiction:
Improvecomponent performanceVSAvoidplatform performance under load
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces dynamic community creation and merging capabilities. The system can dynamically create new communities based on call relationships and dynamically merge or split existing communities to optimize load distribution. This dynamic adaptation allows the platform to respond to changing load conditions and optimize performance under heavy load, rather than relying on fixed individual component adjustments.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent employs community copying mechanisms where successful community structures can be replicated to handle additional load. When a community proves effective in managing load, the system can create copies of that community structure to handle increased demand, providing a scalable approach to maintaining component performance while improving overall platform adaptability under load.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS20260056802A1Cloud platform management method and apparatus, program product, and storage medium
Publication Date: 2026.02.26 HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD
  • US20260056802A1 patent drawing
  • US20260056802A1 patent drawing
  • US20260056802A1 patent drawing

AI summary

The method includes: grouping multiple cloud service components in a cloud platform into communities based on call relationships, with intra-community call closeness no more less than a preset value and inter-community closeness less than the value; if at least one target component in a first community has performance below a preset level (meeting the first preset condition), creating a second community identical to the first to share part of its load.