Automatic failover lets customers with business critical websites maintain high availability in the event of an outage in an infrastructure component in a datacenter, or even an entire datacenter region. Failover is an optional component which you can add to your DXP instance.
Failover prevents websites from going down in the event of a server failure. Through automatic detection, an error on a primary server is detected, 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 that in case of a datacenter outage, traffic is sent to a backup server in a different location, providing redundancy across geographical regions.
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 always in the same state as the primary one.
The Web App endpoints are continuously checked for responses. If one of them stops responding, traffic is moved over to the secondary Web App. When the primary Web App is working again, traffic is directed back again. You can display a message informing that the site is in read-only mode.
DXP includes built-in endpoint monitoring and automatic endpoint failover. To use failover, you need to update the websites configuration to either handle all hosts (*), and/or add the failovers hostname. This is done in the Optimizely Admin view. See example below.
- Reduce the cache expiration so you do not cache items for an unnecessarily long time, because this may cause out-dated content to be displayed on the failover Web App, in case of failure.
- CMS and Commerce versions on your site must support Read-Only mode (CMS 9.7.0 and 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 a number of instances to meet maximum load are started before that load is expected, to get the failover environment quickly 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 transactions 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, to not throw write exceptions.
- Optionally, you can configure whether you want 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.
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)
Updated 3 months ago