Dynamic Request Rerouting for CDN 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 restoration.
Innovation Solution
Implementing a dynamic request rerouting (DRR) system within a point of presence (POP) that includes health monitoring servers and DRR servers to proactively detect server failures and reroute requests to operational edge servers, reducing service delays by injecting substitute route information into switch fabrics and load balancers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If TTL-based failover mechanism is used, then system simplicity is maintained, but service delay increases to seconds or more
Solution Approach 1:
The system performs preliminary actions by continuously monitoring edge server health status and pre-configuring reroute paths before failures occur. When a server fails, the DRR server immediately redirects requests along pre-established alternative paths, eliminating the need to wait for TTL expiration and achieving sub-second failover times.
Solution Approach 2:
The DRR server acts as an intermediary between the client and edge servers. It receives health information from health monitoring servers, determines operational status of edge servers, and dynamically adjusts routing decisions. This intermediary component enables proactive rerouting without requiring complex changes to the core network infrastructure.
2Loss of time
If proactive health monitoring and dynamic rerouting are implemented, then service delay is reduced to less than a second, but device complexity increases
Solution Approach 1:
The system segments the CDN infrastructure into distinct functional components: edge servers for content delivery, health monitoring servers for status detection, and DRR servers for routing decisions. This segmentation allows each component to specialize in specific tasks, making the overall complex system more manageable and easier to implement.
Solution Approach 2:
The DRR server performs multiple functions: receiving health information from monitoring servers, determining edge server operational status, generating reroute paths, and coordinating with load balancers and switch fabrics. This multi-functionality consolidates several responsibilities into a single component, reducing the number of separate systems needed.
3Speed
If dynamic route injection into switch fabric and load balancer is implemented, then request rerouting speed increases, but network configuration complexity increases
Solution Approach 1:
The system implements feedback loops where health monitoring servers continuously report edge server status to DRR servers. Based on this feedback, the DRR servers dynamically adjust routing configurations in real-time. This closed-loop feedback mechanism enables automatic adaptation to changing network conditions without manual intervention.
Solution Approach 2:
The network configuration system transitions from static TTL-based routing to dynamic, real-time route injection. The DRR server actively modifies routing tables in switch fabrics and load balancers based on current edge server health status, enabling flexible and adaptive network resource allocation that responds instantly to failures or performance degradation.
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.