StackPath features the option to set a backup CDN origin to serve assets if your primary origin becomes unavailable. The backup origin provides an extra layer of protection when a primary server fails to respond for any reason.
How does it work?
The primary origin fails over to backup if the CDN cannot connect or find the requested file, for any reason. Every request is handled on a case-by-case basis, that is, the CDN will not stop sending requests to the primary origin based on failover history.
Types of responses that trigger failover
|Connection Timeout||DNS errors & unresponsiveness|
|4XX||All Client Errors|
|5XX||All Server Errors|
When requests are proxied to an Origin from the CDN, StackPath analyzes the response code of each request to determine how to handle the response. The following steps track a request in a full cycle, from end-user request to end-user response.
- An end-user requests an asset and requests resolve to StackPath CDN
- The CDN approves the request and sends an additional request out to the primary origin.
- A site's primary origin returns a 5XX, a 4XX, or the connection times out.
- This response triggers the backup origin policy. The CDN will attempt to open a connection with your backup server and request the same file path from the alternate host.
- If the given file path exists on the backup Origin, the CDN will pull and cache this content.
- If it does not, the response code from the backup origin will be forwarded to the end user.
- If the content is cacheable, the CDN will cache the backup origin content and no longer proxy to either origin.
- The CDN returns to the state of Step 1. Each subsequent request goes through Step 1 to 7 until the primary origin recovers.
When a request hits the primary origin, and the response fails, a second identical request is sent to the backup origin. No information derived from the first request is included in the backup request, and likewise, no additional headers indicating a mishap are sent to the client.
The CDN sends two similar requests to the primary or backup origin. Each request sent to the primary or secondary origin differs only by a host header for serverside authentication. Due to this behavior, it's important to mirror the primary origin's structure directly onto the backup origin. Variance in file paths may lead to unexpected File not found errors.
From the end-user perspective, the backup response should not change as compared to an origin response. Although users are subject to varying amounts of latency when a failover occurs, no supplemental information is added by the CDN in the body or headers of the response.
The latency for requests that respond with 5XX errors is substantially longer than those that are triggered by 4XX errors. When dealing with 5XX response codes, the CDN must wait for a primary origin to time out before proxying the request to a backup origin. Under normal circumstances, 4XX response codes resolve much quicker and are often imperceptible.
Any asset pulled from a backup origin can be served while the primary origin is on or offline, which allows the CDN to fetch, cache, and serve content even when something unexpected goes wrong. The cache for a site is shared between the primary and backup origin, so the backup origin's content can seamlessly fill a primary origin's shortcoming.
When a request to a primary origin fails, two things happen. Requests are immediately proxied to the backup and the CDN caches all approved uncached content for future requests. This behavior prevents performance bottlenecking, even when an origin is out of commission.
After primary origin recovery:
When the CDN caches a webpage, response headers for each request are cached with it. After the primary origin recovers, we recommend purging the cache to revalidate all content and ensure it is up to date. Shown below; it is possible after a primary origin failure to have cached content from both the primary and backup origin.
Setting up a Backup origin
Configuring a backup origin in the StackPath control panel is as simple as entering the secondary origin address in CDN origin Settings. Verify that the backup origin can receive and serve incoming requests from the StackPath CDN, just as a primary origin can.
- Login to the StackPath Control Panel
- Navigate to Sites > Website Domain > Settings. Backup is listed under the Origin heading. Flip the switch to On
- This opens a text box for the IP address for the backup server, you can type that in, or paste it in here and select Save.
- To test the Backup Origin, you can temporarily switch your backup origin to your primary origin and purge all cache. If the backup origin works as a primary origin, the CDN will be able to pull all requested files from your backup.
- Congratulations, your backup origin is now protecting your site from primary origin downtime.
Response Code Exclusion
With the default settings, we will make requests to the backup origin on any 4xx or 5xx primary server response codes or on timeouts. However, you may wish to exclude some response codes (like 403 responses, for example). That option is available via the portal.
- Below the entry for the backup origin, there is a field for Exclude Codes. You can add codes one at a time, or add ranges with wildcards:
- Click "Add" to add the code to the exclusion list
- After adding all of the codes which you wish to exclude from the backup, click "Save"
- At this point, we will make requests to the backup server on all 4xx or 5xx codes which are not excluded, and on timeouts from the primary server.
If you have any additional questions or concerns, please contact StackPath via 24/7 live chat.