[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Re: E-Mail Cluster



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 redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]