> -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] On Behalf Of Karl R. Balsmeier > Sent: Tuesday, May 22, 2007 11:01 PM > To: CentOS mailing list > Subject: Re: [CentOS] Vsftpd & Iscsi - fast enough ++ > > 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? Let the list know what your current setup is. If you are looking to have a single back-end storage system shared with multiple front-end FTP servers, then you have a number of choices: - Use a cluster filesystem like GFS/OCFS etc. with a shared storage system, either SCSI, Fiber or iSCSI. - Utilize a network file system to a shared storage server, either NFS, CIFS, or some other network file system protocol. > 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. There are a lot of possibilities and not one single one will be perfect. The trick is finding the one that handles the core problem you have. > -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'? There are a lot of choices even when you take Fiber out of the picture. > 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. True, and if you are using a shared block storage solution then you will need to use a clustered file system, but there is another solution too... > 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. Yes, in affect creating a traditional, active-active FTP cluster. > 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. I utilize adaptive load balancing bonding (ALB) with iSCSI with good results from multiple initiators. 802.3ad (?) or traditional aggregated links doesn't do so hot as it is per-path instead of per-packet. > 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 How about this idea for size: iSCSI storage server backend serving up volumes to a Xen server front-end which then provides NFS/CIFS network file system access to multiple local PV FTP servers. You can then add a second iSCSI server later and use DRBD 8.X in a multiple primary setup doing active-active block-level replication between two storage servers, which then provides storage for two Xen server front-ends that can use something like heartbeat to fail-over virtual machines in the event of a Xen server failure. Then you can use MPIO in round-robin or fail-over mode (or a combination) between the two back-end iSCSI servers and the two front-end Xen servers. > -----snip---------- <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.