aiScaler implements admin fallback mode
Posted by Max Robbins on October 25th, 2010Operating Accelerated Websites in Fallback Mode.
A number of reasons can lead to a state when an origin server infrastructure is unable to serve any requests. – Database or file store failure are some examples.
Normally, without aiScaler front-ending the requests, the website would be in a hard down situation – not serving anything at all or serving all kinds of errors to the end users.
With aiScaler you can save the day by going into “forced fallback” mode. aiScaler automatically goes into this fallback mode when all origin servers are offline. When put in such mode, aiScaler behaves as follows:
• requests for cacheable content are instantly satisfied by (possibly stale) cached responses whenever possible, w/o attempting refresh against origin servers
• no requests are allowed to go to origin servers
• non-cacheable requests and requests for cacheable content that doesn’t exist in the cache are served instant 503 responses by aiScaler, again, no attempt is made to go to origin servers
• health checks, if any are configured, continue to be generated and sent to origin servers .
The idea behind fallback state are to make sure visitors see content back, even if it is stale and to shield the origin infrastructure from any user traffic so that you could restore the service faster.
The only way to put an accelerated website into fallback mode or to restore normal operation is to use CLI “fallback” command :
fallback hostname on|off
For example:
fallback www.acmenews.com on
fallback www.acmenews.com off
When an accelerated website is in fallback mode, it is indicated as such via a warning in Web monitoring page.
Every 100th client connection (request) that is served 503 response due to request’s website being in fallback mode, is logged in error log file with a message like:
[Sun Jan 18 08:59:21 2008 [notice] GetResponseThread: www.acmenews.com in fallback state, 503 served.
The logging of this error message is decimated not to overwhelm the error log file with these messages.
aiScaler also allows pattern-specific fallback configuration setting.
The differences:
• when in website forced fallback mode, aiScaler doesn’t try to reach origin servers, so stale cached response is served right away, as opposed to, in case of pattern-specific fallback, trying a number of requests against origin servers before failing-back to stale cached response (which can potentially take a significant amt of time
• no user requests are ever sent to origin servers when website is forced fallback mode.