Failover

Automatic failover lets customers with business-critical websites maintain high availability in the event of an outage in an infrastructure component in a data center or even an entire data center region. Failover is an optional component that you can add to your DXP instance.

Failover prevents websites from going down in the event of a server failure. An error on a primary server is detected automatically, and traffic is automatically routed to a backup server in a secondary geographically redundant location within the same delivery region.

Failover in DXP is fully automatic, with no manual intervention. Geo-replication is included by default, meaning traffic is sent to a backup server in a different location in case of a data center outage, providing redundancy across geographical regions.

Failover architecture

The setup includes two application environments, where storage is replicated from the primary to the secondary (failover) environment. Optimizely ensures that the failover Web App is in the same state as the primary one.

Failover mechanism

The Web App endpoints are continuously checked for responses. If one stops responding, traffic is moved to the secondary Web App. When the primary Web App works again, traffic is directed back. You can display a message informing that the site is in read-only mode.

Failover configuration

DXP includes built-in endpoint monitoring and automatic endpoint failover. To use failover, you must update the website configuration to handle all hosts (*) or add the failover hostname. This is done in the Optimizely Admin view. See example below.

Considerations

• Reduce the cache expiration so you do not cache items unnecessarily long because this may cause outdated content to be displayed on the failover Web App in case of failure.
• Optimizely Content Management System (CMS) and Optimizely Customized Commerce versions on your site must support Read-Only mode (CMS 9.7.0 and Customized Commerce 9.9.0 or higher).
• Add-ons on the site must also support read-only mode.
• The site must handle aggressive autoscaling. That is when several instances to meet the maximum load are started before, and that load is expected to get the failover environment up and running. This may be an issue for sites where many calls are made to external systems during application startup.
• Configure warnings in your solution to handle read-only mode, such as using application state. For database transaction features, such as saving a posted form, or storage transaction features like image resizing, these features must be aware that the application is in read-only mode so as not to throw write exceptions.
• Optionally, you can configure whether to display an information message to end-users on the failover site when in read-only mode during a failure; see Find database mode by code in Database mode.

🚧

Important

When the site is in failover state, the used storage is read-only.

Related blog post – Episerver’s Digital Experience Cloud™ Automatic Failover Solution by Daniel Browne (now called Optimizely Digital Experience Platform)