D-Direct Failover
Last updated
Last updated
Datafree D-Direct reverse bills traffic to a customer endpoint by proxying the traffic to the endpoint.
In this traffic flow, we can plan for two different types of failures: when there is a failure on the customer endpoint/origin server and when there is a failure on the Datafree D-Direct server.
If there is a failure on the origin server, or if the customer simply wants to cutover to a new endpoint, there are two main options for cutover while retaining the datafree aspect of the connection.
If the customer has an intermediate domain on the endpoint, then they can alternatively failover by updating the CNAME on the endpoint. In this scenario, no change on D-Direct server is necessary and the failover can be automated by updating the name server entry.
In the second scenario, there is a failure on the D-Direct Server. To plan for such a failure, a standby D-Direct server should be configured and provisioned in advance. This provisioning can be done in a separate geographic region if required (eg. AWS Ireland).
In the case of D-Direct failure* the CNAME for the client domain is updated to point to the failover D-Direct server. This failover D-Direct server is already configured to point to the customer’s production endpoint, so once the CNAME propagates, traffic immediately reaches the origin server and end users once again have access to the datafree app.
One option is to simply update the endpoint on the D-Direct config by logging into the and changing the endpoint domain or IP address (see screenshot). This would start forwarding traffic to the failover endpoint.
In order for the customer to determine if there is failure on the D-Direct server, a separate endpoint is configured on the same server for the purpose of uptime monitoring. Requests can be sent at a determined frequency, eg. every 60 seconds, and if consecutive responses are not seen, eg. 5 consecutive responses, then this would trigger the failover event.
