next up previous contents
Next: Contents

Creating Redundant Linux Servers

Horms (Simon Horman)
horms@zip.com.au.

To be presented at
The 4th Annual Linux Expo
The Bryan University Center,
Duke University,
Durham,
North Carolina, USA
Thursday 28th - Saturday 30th May 1998

I would like to acknowledge the assistance of my employer Zip Internet Professionals http://www.zip.com.au./ for their assistance and patience that enabled this presentation to come together.

Additionally, I would like to thank Mr. O'Brien, Gus, Miss Kim, K and Raster for their help along the way.

Abstract:

For an organisation of any size fault tolerance is an important issue. A server going down should not leave users twiddling their thumbs. A simple solution to this is to create backup servers that can be switched in when a server goes down. Using Linux this can be easily achieved using either existing servers or dedicated backup servers.

Many services have good redundancy built in. Examples of this include mail servers and name servers. However services such as POP3 and manual proxies which require end users to specify a host to connect to, are not afforded such fault tolerance. It is for services such as this that providing backup servers becomes crucial.

The idea is to create a backup server that when called upon assumes the identity of the failed server in addition to any existing identities. The backup server is given an IP alias for the failed host and uses ARP spoofing to convince the rest of the network that the backup server is in fact the failed server.

This method of creating backup servers can be supplemented by using a TCP/IP Switch that allows content based services such as POP3 to be sourced from servers that may have other inaccessible services on them.

Additionally housing the content for services such as HTTP on a dedicated NFS server enables a backup HTTP server to serve a site as well as the primary server.

These are clearly a quick and dirty solutions to creating backup servers. They have however proved to be quite successful in practice and requires little or no outlay for additional hardware.



 
next up previous contents
Next: Contents
Horms
1998-04-13