[CentOS] Vsftpd & Iscsi - fast enough ++

Karl R. Balsmeier karl at klxsystems.net
Wed May 23 03:00:47 UTC 2007


Ross S. W. Walker wrote:
>> -----Original Message-----
>> From: centos-bounces at centos.org 
>> [mailto:centos-bounces at centos.org] On Behalf Of chrism at imntv.com
>> Sent: Tuesday, May 22, 2007 7:07 PM
>> To: CentOS mailing list
>> Subject: Re: [CentOS] Vsftpd & Iscsi - fast enough
>>
>> Ross S. W. Walker wrote:
>>     
>>> Well there goes the neighborhood... Now I have to talk memory in
>>> MiB and GiB and comm and storage in MB and GB.
>>>
>>> Anyways datacom and storage has always been base 10, why, well I'll
>>> leave that to the conspiracy theorists.
>>>   
>>>       
>> Perhaps it would be possible to leave the semantics games 
>> alone and just 
>> answer the guy's question?  I don't have any personal experience with 
>> iSCSI or I would try to do that.
>>     
>
> The question was answered earlier and what does your comment contribute?
>
> Jeez, there is nothing like a me-too troll to suck the fun out of a
> thread.
>
> -Ross
>   
well, he (Chris) does have a point.  I was excited to see my question 
get so many responses.  But I only got one enterprise-relevant answer, 
from Matt Shields (thanks matt!).  We definitely got side-tracked here, 
har.  Let us chase down this iSCSI vs  rsync pros/cons question a little 
more...

I have sort of ruled out doing iSCSI over GFS because of all the moving 
parts and some inherent dangers similar to what mentions about stopping 
data flows on such designs.  Am I that much better off to ditch even the 
iSCSI component and just stick with the current setup that relies on rsync?

I'd like to ditch rsync, and latency isn't that *big*of an issue because 
those boxes don't push more than 10-20 megs of data normally.  So is 
there a case where I could extend onto iSCSI and see some benefits vs. 
staying with the FTP server pair & rsync?  I sort of asked some of this 
in another thread, but curious about what folks have to say. 

-essentially the question is 'what's after rsync, when you don't have 
fibre channel budget, and don't want to stoop so low as iATA called 
Ethernet-over-IP'?

here's the GFS over iSCSI strategy....

essentially, you're going to abstract the one filesystem, pretending 
it's "out" of any of the hosts (it can still be physically in the one 
host), and create a GFS volume on it (by creating one or more PV's into 
the GFS LVM). 

then configure the other cluster members to mount the GFS cluster-fs 
volume/filesystem using the GFS services over the iSCSI protocol.

that will allow all of the FTP servers to mount the shared volume 
read/write concurrently.  no more rsync.

i'd use the iSCSI hba to expose the backup volume as an iSCSI target and 
attach to it from the other set members. 
to do it right, you'll need to put up two additional hosts and install 
GFS & iSCSI services on all of them.

you'll need to be using GbE, preferably channel-aggregated, if possible, 
between the cluster members
read won't be as fast as direct-attach scsi raid, but there won't be any 
rsync/cross-copy latency.

if load not too high on daily basis, maybe one gbe per host dedicated to 
the iSCSI/GFS sync/locking traffic, and another to reach the outside world
-----snip----------

> ______________________________________________________________________
> 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.
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>   




More information about the CentOS mailing list