Orchestrated Node Reconnect for Transparent VPN Headend Rolling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud-based VPN headend services face challenges in scaling nodes without disrupting client traffic or making users aware of node redeployments, requiring network administrators to manage node scaling and code deployment separately.
Innovation Solution
Implementing orchestrated reconnect techniques that signal clients to establish new connections through alternate nodes, allowing existing connections to remain unaffected while old nodes are drained and replaced, using load balancer and proxy nodes to redirect traffic.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If node scaling and code deployment are performed separately in cloud-based VPN headend services, then system scalability and redundancy are improved, but operational complexity and difficulty of managing node rolling increase
Solution Approach 1:
An orchestration controller is introduced as an intermediary component that manages the coordinated rolling of multiple node types (load balancers, proxy nodes, headend nodes). This controller receives rolling indications, identifies affected clients, and orchestrates the sequential draining and replacement of nodes, thereby reducing operational complexity while maintaining system scalability
Solution Approach 2:
The system performs preliminary identification of clients with existing connections through the target node before initiating the rolling process. This preliminary action allows the system to selectively send reconnect requests only to affected clients, enabling smooth transitions without disrupting overall system operation
2Reliability
If nodes are rolled to perform software updates or maintenance, then system reliability and security are improved, but client connection disruptions occur
Solution Approach 1:
The system identifies clients with existing connections through the target node before initiating rolling. This preliminary identification enables selective reconnection requests to be sent only to affected clients, allowing the node to be drained of connections in a controlled manner while maintaining service continuity for unaffected clients
Solution Approach 2:
The system dynamically adjusts traffic routing during the rolling process by refraining from sending new connection requests to the first node while allowing existing connections to drain. The orchestration controller monitors connection status and dynamically redirects new traffic to alternative nodes, ensuring continuous service availability
3Productivity
If orchestrated reconnect is implemented to enable transparent node rolling, then client connection continuity is improved, but system complexity and orchestration overhead increase
Solution Approach 1:
The system segments the rolling process into distinct phases: receiving rolling indications for specific node types, identifying clients with existing connections, sending reconnect requests to affected clients, draining connections from the first node, and finally rolling the node. This segmentation of the rolling process into manageable stages reduces orchestration complexity by providing clear procedural structure
Solution Approach 2:
The orchestration controller implements feedback mechanisms by monitoring connection establishment status and using this information to determine when it is appropriate to proceed with node rolling. The system receives feedback about successful reconnections and uses this to trigger the final rolling action, ensuring client connection continuity is maintained throughout the process
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
Techniques for the transparent rolling of nodes in a cloud-delivered headend service without disrupting client traffic or making users aware of the various nodes in the system being rolled are described herein. The techniques may include receiving an indication that a first node of a network is to be rolled. Based at least in part on the indication, new connection requests may not be sent to the first intermediate node. Additionally, a client device having an existing connection through the first node may be identified. In some examples, a request may be sent to the client device to prompt the client device to establish a new connection. After determining that the new connection has been established such that the new connection flows through a second node of the network, the first node may be rolled.