-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Wednesday, May 23, 2007 9:10 AM To: CentOS mailing list Subject: Re: [CentOS] Vsftpd & Iscsi - fast enough
Matt Shields wrote:
On 5/23/07, Les Mikesell lesmikesell@gmail.com wrote:
hey this part is fascinating, -so how would one
practically deploy
this,
-say 4 GB NICs and some supported hardware? for traffic
100 - 200 megs
daily perhaps this is too much?
There's no such thing as 'too fast', but do you really
need to complete
you daily transfer in less than a second? On the
practical side the
underlying disks aren't going to be that fast anyway.
You might if you have thousands of requests per second!!!
A 200 Meg file is likely to be completely cached in the ftp server's RAM
- and the cheapest way to get performance is to be sure that happens.
Yes, cache is king here, whether it be FTP, CIFS, or SQL DBs.
Think 64-bit, and as much RAM as you can afford/fit into it.
As a side note, when using the Promise VTrak and iSCSI it supports multipath.
It would probably be simpler to provide a separate interface or two for the ftp server <-> storage network than to go too crazy with multipathing. And for an ftp server you shouldn't need a great deal more speed on the filesystem side than you have on client connection side.
How about two 4-port e1000 cards, PCI-X 133 if you have 2 PCI-X 133 slots... If that is over-kill, then 2 2-port cards.
You can then mix-up bonding and multi-pathing for SAN and Internet traffic and have 2 separate cards for redundancy, though I have yet to see a network card fail, in my experience memory, storage HBAs/disks, graphics cards and the occassional motherboard seem to be the biggest culprits.
I would definitely keep the SAN traffic, Internet traffic and system management traffic separate.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.