[Linux-cluster] Re: E-Mail Cluster

[Nicholas Anderson]

Hi again all .....

I guess i'm starting to understand how the things should work ....

I was reading about GFS and all the documents that i found suppose that 
you have a storage with a SAN and 2 or more machines connected through 
FC to the SAN.
Well, it seems to me that in this case the storage or the SAN switch 
still being one single-point-of-failure right? If the storage or SAN 
goes down, the whole service will be offline right ?

I thought that with GFS i could do something like a "Parallel FS" where 
2 (or more) machines would have the same data in their disks, but this 
data would be synchronized in realtime ....
am i totally noob or there really has a way to make FS's work in 
parallel, synchronizing in realtime?
I'd like to do this without having a SAN (cause i don't have one :-) and 
i have only 1 storage ) and without leaving a single-point-of-failure.

Let me try to explain exactly what I'm thinking ...

3 servers, each one with a 300GB SCSI disk (local, no FC) to be 
synchronized with the others (through GFS?? mounted and shared as a 
/data f.ex.), and one 36GB disk only for the SO.
All the servers would have smtp(sendmail with spamassassin and clamav), 
imap and pop3 services running, and probably a squirrelmail.

Is it possible to do this? Is it possible to get this data synchronized 
in realtime ?

Thanks again for your really really important answers, and sorry for 
asking so much noob questions :-)


Nick





Riaan van Niekerk wrote:
>
> We are running 700 000 users on a 2.5 GFS, 4 nodes, with POP, IMAP 
> (direct access and SquirrelmMail) and SMTP. To make things worse, we 
> use NFS between our GFS nodes and our mail servers.
>
> We initially had huge performance problems in our setup, which I wrote 
> in this message:
> http://www.redhat.com/archives/linux-cluster/2006-July/msg00136.html
>
> We ended up bumping the spindle count from 36 to 60 and then to 114, 
> without it making a noticeable difference.
>
> Our main killer was Squirrelmail over IMAP (the solution is primarily 
> a webmail-based one)
> Our performance problems were solved by the following:
> - removing the folder-size plugin (built-in) and mail quota plugin 
> (3rd party) reduced the traffic between IMAP servers and storage 
> backend by 40%.
> - Implement imap proxy (www.imapproxy.org). This is giving us a 1 to 
> 14 hit ratio. This storage which could not keep up previously, is now 
> humming along fine.
>
> Our initial mistake was to try and optimise on the FS layer (there 
> werent any real performance optimizations in our setup to be made) and 
> throw hardware at the problem, instead of suspecting and optimizing 
> our application. Despite GFS not being designed for lots of small 
> files, and not recommended for use with NFS, with the above changes, 
> it performs more than adequately. We hope to see another performance 
> gain once we get rid of the NFS and have our mail servers access the 
> GFS directly.
>
> Riaan
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster


-- 
Nicholas Anderson
Administrador de Sistemas Unix
LPIC-1 Certified
Rede Fiocruz
e-mail: nicholas at fiocruz.br