[CentOS] Clustering

Fri Feb 5 11:54:24 UTC 2010
Simon Billis <simon at houxou.com>

Hi,

> On 2/4/2010 3:17 PM, Bo Lynch wrote:
> >
> > Right know we have about 30 or so linux servers scattered through out
> or
> > district. Was looking at ways of consolidating and some sort of
> redundancy
> > would be nice.
> > Will clustering not work with certain apps? We have a couple mysql
> dbases,
> > oracle database, smb shares, nfs, email, and web servers.
> 
> Each app has it's own best way to provide the redundancy and
> auto-failover and it's own set of tradeoffs of the added complexity vs.
> the possible reduced downtime if the primary fails.
> 
> I'd balance the options against the low-tech method of having raid
> mirrors in swappable bays with a spare similar server chassis or two
> around plus regular backups kept at a different location.  The raid
> lets
> you continue in the likely event of a disk failure so you can repair it
> at a convenient time.  Other failures (motherboard, power supply) are
> less likely but can be handled by swapping the drives into an alternate
> chassis (and with Centos you'll need to re-assign the IP addresses that
> are tied to the old NIC mac addresses) with a small amount of downtime.
>   And the backups cover things like operator or software errors (that
> would wipe a cluster too) or a building-level disaster that destroys
> the
> disks or the primary and spare chassis at the same time.  Some apps may
> be worth the effort to do better.

In our configurations we utilise different strategies depending on what we
want to achieve as there isn't really a panacea for this... We use virtual
servers, hot standby firewalls/routers, load balanced servers, warm standby
servers (using such things as mysql replication, rsync and DRBD to keep the
boxes in sync) and shared storage from disk arrays and servers with local
disk arrays for local performance and resilience. We have also utilised
hadoop (distributed filesystem) on some again to provide resilience within
the limitations of hadoop.

S.