Guidelines For High Availability & Disaster Recovery

Recommendations for achieving high availability with your LiveWhale powered site, as well as disaster recovery plans.

High Availability and LiveWhale’s Page Cache

LiveWhale implements a page cache layer which introduces a buffer between static web content (web pages) and the CMS files/database server. It is neither a traditional push or pull model, but rather a bridge script that automatically and passively syncs a local file system cache in parallel to ongoing web server activity.

Aside from achieving a high level or performance and scalability, the cache layer is also designed to protect against downtime related to non-availability of any of the resources with which web content is generated. Unresponsive CMS scripts or database/network downtime do not interfere with the serving of web content, which are not required to serve web pages. In the event of downtime the web server will continue to serve the most recent cached copies of web content until the resources come back online and the cache is able to be refreshed. This cache is stored locally on the server’s file system.

For more information on how the page cache works, see “About caching and scalability”.

Load Balanced Setups

Load balancing is recommended when possible, and options to support these configurations are available for LiveWhale. Any number of servers may be utilized for serving a LiveWhale site, once the load balancing DNS configuration is in place. A primary server should be designated for CMS upgrades by White Whale. The primary server should be the one accessible by LiveWhale’s (S)FTP. All upgrades, as well as page editing from within LiveWhale, are performed as (S)FTP transactions to the primary server. It is recommended that the servers be kept in sync with an rsync script, which should mirror the web content as well as the CMS files to your slave servers.

Additionally, LiveWhale incorporates automatic syncing of resources uploaded to the CMS. This feature is enabled automatically and only requires that the master LiveWhale configuration defines all hosts (or IPs) associated with the range of servers that may server the site. When content is uploaded, the resource syncing script is triggered and slave servers will automatically add or remove resources according to a log maintained in a shared database.

Clustered Database Setups

A clustered MySQL database is the recommended method for achieving high availability of your database. Note that LiveWhale’s licensing terms requires a single database source, representing a single set of stakeholders for your institution.  A single site may have any number of satellite sites in this configuration, all of which can share the clustered database for distribution across multiple database servers. Additional configuration is not required in LiveWhale to support these setups, as MySQL clustering will take care of the syncing of data. Please consult MySQL documentation for the most up-to-date guidelines for these configurations, based on the version you are running.

Backups and Disaster Recovery

LiveWhale implements basic daily database backups for the past month, per server. Additional configuration is not required for this, however optional configuration is available to limit backup generation to particular times. This backup process does not involve file system backups. We strongly recommend having your own additional backup procedure in place, according to the hosting solution you are deploying for LiveWhale powered sites.