Dynamic Request Rerouting for Edge Server Failures
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Content delivery networks (CDNs) face service delays due to the failure of edge servers, as existing systems rely on time-to-live (TTL) mechanisms that can take seconds or more to reroute requests to functioning servers, leading to inefficient service recovery.
Innovation Solution
Implementing a dynamic request rerouting (DRR) system within a point of presence (POP) that includes edge servers, a health monitoring server, and a DRR server to proactively assess server health and reroute requests to operational servers, reducing service delays by injecting substitute route information into the switch fabric and load balancer.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If TTL-based rerouting is used, then the system is simple to implement, but service delays occur taking seconds or more to reroute requests
Solution Approach 1:
The health monitoring server continuously monitors edge server status and the DRR server proactively generates substitute routes before failures occur. When a failure is detected, the system already has prepared rerouting paths and can immediately redirect requests without waiting for TTL expiration, reducing service delay from seconds to sub-second levels.
Solution Approach 2:
The patent introduces a DRR server as an intermediary component between the switch/router and edge servers. This mediator actively manages health information, generates substitute routes, and injects routing decisions into the switch fabric, enabling fast rerouting while adding controlled complexity to the system architecture.
2Loss of time
If proactive health monitoring and route injection is implemented, then service delay is reduced to less than a second, but system complexity increases
Solution Approach 1:
The system divides functionality into separate modules: a health monitoring server that gathers status information, a DRR server that processes health data and generates routes, and switch/router components that execute routing decisions. This segmentation allows each component to be optimized independently and simplifies maintenance while achieving fast rerouting.
Solution Approach 2:
The health monitoring server continuously collects status information from edge servers and feeds it back to the DRR server. This feedback loop enables the system to detect failures in real-time and dynamically adjust routing decisions, reducing service delay while managing complexity through automated closed-loop control.
3Speed
If dynamic route injection is used, then request rerouting speed increases, but network hops increase
Solution Approach 1:
The DRR server pre-calculates and prepares substitute routes based on health status information before failures occur. When an edge server fails, the system can immediately redirect requests along pre-planned paths rather than discovering routes in real-time, achieving fast rerouting with minimal additional network hops.
Data Source
AI summary
A point of presence includes edge servers having IP addresses and storing content, a switch/router that receives and forwards requests for content to the edge servers, a health monitoring server that gathers health information from the edge servers, and a dynamic request rerouting (DRR) server. The DRR server is connected with each of the edge servers. If the DRR server obtains a determination that one of the edge servers is down, it advertises a route including the IP address of the down edge server to the switch/router. The switch/router forwards a request for content, originally addressed to the down server, to the DRR server. The DRR server forwards the request to a working server that stores the content. The working server sends the content to the DRR server, the DRR server forwards the content back to the switch/router, and the switch/router responds to the original request with the content.