Autoencoder-Based Server Disaster Detection and Recovery

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current server maintenance systems face challenges in efficiently detecting and responding to disastrous events, such as crashes or data inaccessibility, due to the complexity of software regressions and limited user expertise, leading to potential new disasters and data loss.

Innovation Solution

A system utilizing a production server, backup server, and machine learning architecture to monitor performance metrics, analyze snapshots, and execute recovery scripts automatically, distinguishing between server disasters and minor anomalies using autoencoders and a log of previous disasters.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual monitoring and analysis of server performance metrics is performed by users, then the system can detect disastrous events, but the process is time-consuming and prone to errors due to limited user expertise and the complexity of software regressions

Engineering Contradiction:

Improvedisaster detection accuracyVSAvoidtime to detect and respond to disaster

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The system performs self-diagnosis by automatically analyzing performance metrics and comparing them against learned patterns of normal and abnormal server states. The machine learning model enables the system to autonomously detect disasters without requiring manual user analysis, thereby improving both reliability and response time.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The manual mechanical process of user analysis is replaced with an automated machine learning-based detection system. The ML model processes performance metrics and automatically identifies disaster conditions, substituting human expertise with an scalable automated intelligence that does not suffer from fatigue or limited skill levels.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

2Ease of repair

If users manually probe servers for defects and implement fixes, then specific disasters can be addressed, but different users may implement different fixes for the same error and layered changes can create new disasters

Engineering Contradiction:

Improvedisaster resolution capabilityVSAvoidsystem stability after repair

Core Design Contradiction:

Ease of repairVSReliability

Solution Approach 1:

The system automatically implements repairs by executing predefined remediation scripts corresponding to detected disaster types. This self-service approach ensures consistent application of proven fixes without variation between different users, eliminating the problem of layered changes creating new disasters.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The system changes the state of server parameters by executing specific remediation actions tailored to each disaster type. By automatically adjusting system parameters based on learned patterns and predefined scripts, the system ensures consistent and appropriate repairs without manual intervention variability.

Inventive Principle:

Principle #35Parameter changes

3Difficulty of detecting and measuring

If code instrumentation is used to profile software running on the server, then software behavior can be analyzed, but it causes perturbation in the software program's run-time behavior especially for parallel software

Engineering Contradiction:

Improvesoftware profiling capabilityVSAvoidsoftware run-time behavior

Core Design Contradiction:

Difficulty of detecting and measuringVSReliability

Solution Approach 1:

The system replaces intrusive code instrumentation with external observation of performance metrics. By monitoring system-level metrics such as CPU utilization, memory usage, and I/O patterns, the system can profile software behavior without inserting probes into the code, thereby avoiding perturbation of run-time behavior.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

Solution Approach 2:

The system introduces an intermediary layer that observes server performance metrics without directly interacting with the application code. This intermediary monitoring approach allows software profiling while maintaining the integrity and natural behavior of the original software, including parallel implementations.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS11249861B2Multi-layered disaster recovery manager

Publication Date: 2022.02.15 BANK OF AMERICA CORP

AI summary

A system includes a production server, a backup server, a telemetry analyzer, a memory, and a hardware processor. The telemetry analyzer takes snapshots of various performance metrics of the production server. The memory stores a log of previous disasters that occurred on the production server. The log includes a snapshot of the production server performance metrics from the time each disaster occurred. The memory also stores recovery scripts for each logged disaster. Each script provides instructions for resolving the linked disaster. The hardware processor uses a machine learning architecture to train an autoencoder. The trained autoencoder receives new snapshots from the telemetry analyzer and generates a reconstruction of the new snapshots. The hardware processor then determines a threshold for distinguishing between server disasters and minor anomalies. This distinction is made by comparing the difference between the reconstruction of the new snapshots and the new snapshots with the threshold.