Fabric Controller Timeout Optimization for Server Node Recovery

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In cloud-computing environments, minimizing server node downtime is challenging due to factors like planned maintenance and system failures, with current methods often resulting in suboptimal recovery actions that increase downtime.

Innovation Solution

A fabric controller determines a timeout value for recovery actions based on predictive models of historical patterns, balancing the cost of waiting for node self-recovery against the cost of intervention, and falls back to default or datacenter-level settings when necessary.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If the fabric controller performs a recovery action immediately upon detecting node failure, then the downtime for customer workloads is reduced, but the cost of intervention increases

Engineering Contradiction:
Improvedowntime for customer workloadsVSAvoidcost of intervention
Core Design Contradiction:
Loss of timeVSLoss of energy

Solution Approach 1:

The fabric controller performs preliminary actions by detecting node failure immediately and initiating recovery procedures without waiting for complete system shutdown. The controller proactively manages the recovery process by detecting failure conditions and executing recovery actions to minimize downtime before the node can be fully restored to operational state.

Inventive Principle:
Principle #10Preliminary action

2Loss of energy

If the fabric controller waits for node self-recovery before performing intervention, then the cost of intervention is reduced, but the downtime for customer workloads increases

Engineering Contradiction:
Improvecost of interventionVSAvoiddowntime for customer workloads
Core Design Contradiction:
Loss of energyVSLoss of time

Solution Approach 1:

The system allows nodes to attempt self-recovery when failure is detected. The fabric controller monitors node status and permits autonomous recovery processes to occur without immediate external intervention. This self-service approach reduces the cost of intervention by allowing nodes to resolve certain failures independently before controller assistance is required.

Inventive Principle:
Principle #25Self-service

3Reliability

If the fabric controller monitors each node continuously to detect failures, then the reliability of service level agreements is improved, but the device complexity increases

Engineering Contradiction:
Improveservice level agreementsVSAvoidfabric controller complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

Nodes provide periodic status signals to the fabric controller, creating a feedback mechanism that enables failure detection without requiring continuous active monitoring. The controller receives status updates from nodes and uses this feedback information to determine when recovery actions are needed, balancing reliability requirements with controller resource consumption.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3646568B1Determining an optimal timeout value to minimize downtime for nodes in a network-accessible server set
Publication Date: 2021.06.23 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP3646568B1 patent drawingFigure 1
  • EP3646568B1 patent drawingFigure 2A~2B
  • EP3646568B1 patent drawingFigure 3~4

AI summary

Methods, systems, and computer program products are described herein for minimizing the downtime for nodes in a network-accessible server set. The downtime may be minimized by determining an optimal timeout value for which a fabric controller waits to perform a recovery action. The optimal timeout value may be determined for each cluster in the network-accessible server set. The optimal timeout value advantageously reduces the overall downtime for customer workloads running on a node for which contact has been lost. The optimal timeout value for each cluster may be based on a predictive model based on the observed historical patterns of the nodes within that cluster. In the event that an optimal timeout value is not determined for a particular cluster (e.g., due to a lack of observed historical patterns), the fabric controller may fall back to a less than optimal timeout value.