Distributed Server Failure Prevention via Shared Information

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In distributed systems, especially those using cloud computing, failures such as deadlocks, excessive memory consumption, and excessive CPU usage can occur due to defects in application programs, leading to system-wide failures and increased operational costs as the number of servers increases, with existing technologies not effectively addressing these issues in a distributed environment.

Innovation Solution

A distributed system architecture where servers capable of executing the same application generate and share failure information to prevent failures by determining and mitigating the cause of the failure, allowing one server to perform failure prevention processing based on the information received from another, thereby reducing the load on system operators and preventing system-wide failures.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If the number of servers is increased to distribute load, then system capacity and availability are improved, but the probability of failure occurrence increases and operational costs increase

Engineering Contradiction:

Improvesystem capacityVSAvoidfailure probability

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The system implements feedback by having servers monitor each other's operational status and automatically share failure information. When a server detects a failure in another server, it receives failure information and performs prevention processing, creating a closed-loop feedback mechanism that continuously improves system reliability without requiring additional human intervention or increasing failure probability

Inventive Principle:

Principle #23Feedback

Solution Approach 2:

Servers automatically perform failure prevention processing based on shared failure information without requiring system operators to manually intervene. The system serves itself by autonomously detecting failures, sharing information, and executing prevention measures, which maintains reliability while scaling the system capacity

Inventive Principle:

Principle #25Self-service

2Reliability

If manual monitoring and restart of failed servers is performed, then failure recovery is achieved, but system operator workload increases and downtime occurs

Engineering Contradiction:

Improvefailure recoveryVSAvoidoperator workload

Core Design Contradiction:

ReliabilityVSEase of operation

Solution Approach 1:

The system enables servers to automatically perform failure prevention processing and recovery actions without human intervention. When failure information is shared, receiving servers autonomously execute prevention measures, eliminating the need for operators to manually monitor, diagnose, and restart failed servers, thus reducing workload while maintaining recovery effectiveness

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The system performs preliminary failure prevention actions by sharing failure information across the server network before actual failures occur. Servers proactively adjust their operations based on received failure information, preventing failures before they impact service availability and eliminating the need for reactive manual recovery

Inventive Principle:

Principle #10Preliminary action

3Reliability

If application program is modified to fix defects, then fundamental failure prevention is achieved, but system complexity increases and deployment time increases

Engineering Contradiction:

Improvefailure preventionVSAvoidsystem complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The system introduces failure information as an intermediary mechanism that mediates between servers to prevent failures caused by application defects. Instead of modifying application programs, servers share failure information and adjust their operations accordingly, providing fundamental failure prevention through information sharing rather than code modification, thus avoiding increased system complexity

Inventive Principle:

Principle #24Intermediary (Mediator)

4Reliability

If temporary measures such as periodical restart or parameter tuning are applied, then failure recurrence is prevented, but operational costs increase and system performance fluctuates

Engineering Contradiction:

Improvefailure recurrence preventionVSAvoidoperational cost

Core Design Contradiction:

ReliabilityVSLoss of energy

Solution Approach 1:

The system implements continuous feedback through automatic failure information sharing, allowing servers to adjust their operations in real-time based on actual failure patterns rather than relying on periodic restarts or parameter tuning. This feedback-driven approach prevents failure recurrence more efficiently, reducing unnecessary operational interventions and associated costs while maintaining stable system performance

Inventive Principle:

Principle #23Feedback

Data Source

PatentUS9342426B2Distributed system, server computer, distributed management server, and failure prevention method

Publication Date: 2016.05.17 NEC CORP

AI summary

A distributed system according to an exemplary embodiment includes first and second servers capable of executing the same application, wherein when a failure occurs in the application in the first server, the first server generates failure information identifying a cause of the failure in the application, and the second server performs failure prevention processing which is determined based on the failure information and intended to prevent a failure in the application.