Backup Servers on the CSM
On the CSM, you can configure a vserver to use a main and backup serverfarm which is used if a serverfarm is toast. If all the RIPs in the main farm are out-of-service, the CSM will start to treat the backup farm just as if it’s configured to be the main one. Once one or more of the main farm RIPs have recovered, the CSM reverts back and uses those again. "Give me an example when I’d use it!," you say? Since the CSM is made for HTTP connections, we’ll assume that you are using it for such.
The example I’ve found over and over again involves HTTP redirect servers. If the whole main serverfarm is dead, you can send requests to a set of redirect servers. Once connections land there, you can send the user to another site, such as your west coast center, your European center, your main corporate page, or wherever.
You can also send traffic to a server that does nothing but show an error page. Let’s say you set up a group of servers that only display a "We’re sorry, but we suck and can’t handle your request" page. If your main serverfarm is unavailable, the user won’t get the page they’re looking for, but it’s better than just timing out, right? (Remind me to do this for some customers.)
How about if you’re moving your serverfarm to another rack and you have to do it all at once (for some unknown reason)? You can use the backup serverfarm to move traffic to another set of server (say, the dev boxes) until you get the main serverfarm back online.
These backup farms are quite easy to configure. When you assign the serverfarm to the vserver, you simply give it a backup like this.
vserver TEST-VS
serverfarm MAIN-SF backup BACKUP-SF
You can also use a backup on a policy.
policy TEST-POL
serverfarm POL-SF backukp BACKUP-SF
Bon appetit.
https://masto.ai/@aconaway
- Generating Network Diagrams from Netbox with Pynetbox - August 23, 2023
- Out-of-band Management – Useful Beyond Catastrophe - July 13, 2023
- Overlay Management - July 12, 2023
Just a minor detail: if you use the “we’re sorry, but we suck” approach, make sure the web page returns HTTP error code 503 (500 is also OK, but 503 is better) with the Retry-After header. If you return a regular HTML page, it might get cached by search engines instead of your actual content.
Good point, Ivan. There is a definite art to corralling search engine spiders.
Part of the “we suck” setup could also be a robots.txt that tells everyone to go away. That would keep the well-behaved spiders from caching the page. The misbehaving ones are a different story, though.