Index: [Article Count Order] [Thread]

Date:  Tue, 9 May 2006 16:02:08 +0800 (SGT)
From:  patricko (at mark) staff.singnet.com.sg
Subject:  [coba-e:05109] Re: Bluequartz Cluster  - Draft version 0.1
To:  coba-e (at mark) bluequartz.org
Message-Id:  <Pine.LNX.4.44.0605091540130.21542-100000 (at mark) staff.singnet.com.sg>
In-Reply-To:  <200605082106.39214.bq (at mark) solarspeed.net>
X-Mail-Count: 05109

Hi,


Ok.


[point 1]

  Analogy:

  Administrating each BQ / cobalt server required 
  admin manual intervention.

  Administrating BQ cluster, Frontend node, for a start
  also required admin manual intervention.

  


My Simple clustering design that I am proposing avoid sharing application 
and its associates.


In another perpective, each individual BQ server does its own logging, 
hold its administrator profile and run its own application.

Creating administrator profile, making log rotate policies and setting 
up BQ application are One-time affair. Therefore this design, its still 
feasible. 



[point 2]

Rsync v.s. NFS

I think NFS is better in data consistency as the file locking in done
in the kernel space.



[point 3]


Definitely, there are room for improvement.
But let keep the design simple for good start.

***Thumb of rules: Its - simple design, is harder to break ***



Cheers
patrick


On Mon, 8 May 2006, Michael Stauber wrote:

> Hi Patrick,
> 
> been thinking about similar setups since my first contact with BQ. To some 
> degree you cannot avoid to also share parts of /etc/ and that's where it gets 
> a bit messy. Think /etc/mail, /etc/locks, possibly /etc/proftpd.conf as well. 
> 
> At the worst that can be handled off the NAS with symlinks or by synchronizing 
> via the directories through rsync, but throw in extra admins and then you 
> need to think about what to do with /etc/shadow and /etc/passwd as well 
> <ugh!>.
> 
> -- 
> 
> With best regards,
> 
> Michael Stauber
>