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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Nicholas Anderson
Administrador de Sistemas Unix
LPIC-1 Certified
Rede Fiocruz
e-mail: nicholas@xxxxxxxxxx
--
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
