-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@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@centos.org [mailto:centos-bounces@centos.org] On Behalf Of chrism@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.