Maxwell Reid put forth on 8/7/2010 5:18 PM:
On Sat, Aug 7, 2010 at 3:06 AM, Stan Hoeppner stan@hardwarefreak.comwrote:
Noel Butler put forth on 8/6/2010 4:29 PM:
Actually you will not notice any difference. How do you think all the big boys do it now :) Granted some opted for the SAN approach over NAS, but for mail, NAS is better way to go IMHO and plenty of large services, ISP, corporations, and universities etc, all use NAS.
The protocol overhead of the NFS stack is such that one way latency is in the 1-50 millisecond range, depending on specific implementations and server load.
Yes, I would say NFS has greater overhead, but it allows for multi system access where fiber channel does not unless you're using clustered filesystems which have their own issues with latency and lock management....
Care to elaborate on this point? The NFS server sits in user space. All cluster filesystem operations take place in kernel space.
Using a FC SAN array with a dovecot farm, disk blocks are read/written at local disk speeds and latencies. The only network communication is between the nodes via a dedicated switch or VLAN with QOS for lock management, which takes place in the sub 1 millisecond range, still much faster than NFS stack processing.
Using NFS the dovecot member server file request must traverse the local user space NFS client to the TCP/IP stack where it is then sent to the user space NFS server on the remote machine which grabs the file blocks and then ships them back through the multiple network stack layers.
Again, with FC SAN, it's a direct read/write to, for all practical purposes, local disk--an FC packet encapsulating SCSI commands over a longer cable, if you will, maybe through an FC switch hop or two, which are in the microsecond range.
Dovecot clusters may be simpler to implement using NFS storage servers, but they are far more performant and scalable using SAN storage and a cluster FS, assuming the raw performance of the overall SAN/NAS systems is equal, i.e. electronics complex, #disks and spindle speed, etc.
-- Stan