[Linux-cluster] Diskless Shared-Root GFS/Cluster

Jayson Vantuyl jvantuyl at engineyard.com
Thu Feb 1 11:57:46 UTC 2007


We are talking about application servers.

One of the toughest things about clustering in general and GFS in  
particular is the failure scenarios.

When you have any sort of cluster issue, if your root is on a shared  
GFS, that GFS freezes in various ways until fencing happens.  The  
problem with this is that certain binaries that are on the same GFS  
may need to be used to recover.  How do you execute fence_apc to  
fence a failed node when it is on a GFS that is hung waiting on that  
same fencing operation?

There are ways around this involving RAM disks and the like, but  
eventually we just settled on having a minimal flash disk that would  
get us onto our SAN (but not clustered).  Only after we were on a non- 
clustered-FS on our SAN would we then start up our clustered  
filesystem.  This gave us the ability to move our nodes around  
easily.  This is an often overlooked benefit of a shared root that  
putting your root FS on SAN gives you as well.  There's nothing like  
booting up a dead node on spare hardware.  This also gives you a  
solid way to debug a damaged root system.  With shared-root it's all  
or nothing.  It's not so with this configuration.  You also have  
separate syslog files and other things that are one more special case  
on a shared root.  It's also easy to set up nodes with slightly  
different configurations (shared-root makes this another special  
case).  As for the danger of drive failure, a read-only IDE flash  
disk (Google for Transcend) is simple, easy, and dead solid.

After consolidating your shared configuration files into /etc/shared  
and placing appropriate symlinks into that directory, it is a simple  
matter of rsync / csync / tsync / cron+scp to keep them synchronized.

It is tempting to want to have a shared root to minimize management  
requirements.  It is tempting to want to play games with ramfs and  
the like to provide a support system that will function when that  
shared root is hung due to clustering issues.  It is tempting to  
think that having a shared GFS root is really useful.

However, if you value reliability and practicality, it's much easier  
to script up an occasional Rsync than it is to do so many acrobatics  
for such little gain.  For a cluster (and its apps) to be reliable at  
all, it needs to be able to function, recover, and generally have a  
stable operating environment.  Putting GFS under the userspace that  
drives it is asking for trouble.

On Jan 31, 2007, at 1:34 PM, isplist at logicore.net wrote:

> I'm thinking for application servers/cluster only, not workstation  
> users.
>
>
> On Wed, 31 Jan 2007 11:10:55 -0800, Tom Mornini wrote:
>> We boot from flash drives, then pivot root to SAN storage.
>>
>> I agree with no drives in servers, but shared root is a
>> whole different ball game if you mean everyone using a
>> single filesystem for root.
>>
>> --
>> -- Tom Mornini, CTO
>> -- Engine Yard, Ruby on Rails Hosting
>> -- Reliability, Ease of Use, Scalability
>> -- (866) 518-YARD (9273)

-- 
Jayson Vantuyl
Systems Architect
Engine Yard
jvantuyl at engineyard.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20070201/c0caed55/attachment.htm>


More information about the Linux-cluster mailing list