How-To Use a Backup CDN Origin

Overview

You can use this document to learn how to use a backup CDN origin.

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. 

The primary origin fails over to backup if the CDN cannot connect or find the requested file. Every request is handled on a case-by-case basis, which means that the CDN will not stop sending requests to the primary origin based on failover history. 

Review the following response types that will trigger a failover: 

When requests are proxied to an origin from the CDN, StackPath will analyze 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.

1. An end-user requests an asset and requests resolve to StackPath CDN
2. The CDN approves the request and sends an additional request out to the primary origin.
3. A site's primary origin returns a 5XX, a 4XX, or the connection times out.
4. 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.
5. If the given file path exists on the backup Origin, the CDN will pull and cache this content.
   1. If it does not, the response code from the backup origin will be forwarded to the end user.
6. If the content is cacheable, the CDN will cache the backup origin content and no longer proxy to either origin.
7. The CDN returns to the state of Step 1. Each subsequent request goes through Step 1 to 7 until the primary origin recovers.

Backup Requests

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.

Request structure

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. 

Primary Path:
https://{primary_server.com}/folder/content/images/image005.jpg

Backup Path
https://{backup_origin.com}/folder/content/images/image005.jpg

Backup Responses

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. 

Latency

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. 

Backup Caching

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. 

Set up a backup CDN origin

At a high level, to set up a backup CDN origin, you must:

• Enter the secondary origin address
• Verify that the backup origin can receive and serve incoming requests from the StackPath CDN

1. In the StackPath Control, in the left-side navigation, click Sites. 
2. Locate and select the desired site. 
3. In the left-side navigation, click Settings. 
4. Next to Backup, use the slider to enable the option. 
5. In the field that appears, enter the IP address for the backup server, and then click Save. 
6. 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, then the CDN will be able to pull all requested files from your backup.

Configure response code exclusion

With the default settings, StackPath will make requests to the backup origin on any 4xx or 5xx primary server response codes or on timeouts; however, you can use this section to learn how to exclude specific response codes, such as 403 response.

1. In the StackPath Control, in the left-side navigation, click Sites. 
2. Locate and select the desired site. 
3. In the left-side navigation, click Settings. 
4. Next to Backup, under Exclude Codes, enter the desired code, and then click Add. 
   • You can enter multiple codes individually or add ranges with wildcards. 
5. Click Save.
   • StackPath will make requests to the backup server on all 4xx or 5xx codes which are not excluded, and on timeouts from the primary server.