[plug] SAN Advice

Nathan Alberti nalberti at gmail.com
Fri Nov 16 12:29:53 WST 2007


Yes, in a typical block based read/writes but not considering a  
virtualised environment.

ESX server I/O is small, random block opts, IOs and response time  
matter more than bandwidth.
You only have a single managed disk I/O queue per host
You can use a single mount point across multiple IP's taking advantage  
of link aggregation and load balancing.
Most current NIC's have some sort of integrated TOE.

YMMV but bang for buck you can't beat NFS (in this type of environment).

Nathan.

On 16/11/2007, at 11:21 AM, Adrian Woodley wrote:

> I have to disagree with you here - FC will _always_ beat NFS for  
> speed. And iSCSI isn't even worth considering.
>
> FC headers are 24bytes long. Thats it.
>
> NFS involves many more layers, each with their own frame header,  
> which reduces the data:header efficiency:
>
> NFS (???bytes) + TCP (20bytes) + IP (20bytes) + Ethernet (14bytes) +  
> checksum (4bytes) = 58bytes
>
> FC HBAs are hardware accelerated, taking much of the load off the  
> CPU. NFS relies on the system to negotiate almost every layer in the  
> stack.
>
> To get the same through-put as FC, you'll be spending $$$ on top- 
> shelf hardware (accelerated NICs, stupidly fast switches, etc). Much  
> more than you'd spend on a comparable FC system.
>
> Thats all assuming you'd max-out any available bandwidth. If you're  
> access requirements are more modest, then you can get away with NFS  
> (or even iSCSI *shudder*)
>
> I will concede that NFS is easier to implement and potentially more  
> flexible. However with the advent of clustered filesystems such as  
> GFS and Lustre, multiple hosts accessing the same filesystem at the  
> block layer is being much easier.
>
> Adrian
>
> Nathan Alberti wrote:
>> Go NAS (NFS), simpler, more flexible and typically cheaper to  
>> implement than SAN, you will get as good if not better performance  
>> than ISCSI/FC with the right combination of NIC's, Switches and NFS  
>> server config.
>> Nathan.
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au




More information about the plug mailing list