[Linux-cluster] Replication for iSCSI target?

Alawi, Abraham Abraham.Alawi at team.telstra.com
Sun Apr 3 23:33:47 UTC 2011


Customer's requirements drive the solution, there are many ways to achieve HA storage.  I don't know your exact setup and resources but I reckon iSCSI will be just an unnecessary overhead layer if you are using GlusterFS. You can use DRBD with a clustered file system (e.g. gfs, ocfs, ..) or with  xfs/ext3/4 + NFS, you may consider using G/NBD as well. Again, the solution is driven by the customer's  requirements and the available resources.  GlusterFS is an awesome solution, provides HA & performance but it has some limited capabilities too, like it doesn't support POSIX ACL. Lastly my 2cents for a clustered file system, it sounds like a sexy solution but if it's deployed in a small scale (e.g. < 5 nodes) it might easily become a nightmare. For small scales HA storage without losing stability I'd recommend DRBD + XFS/EXT3/4 + NFS.


From: linux-cluster-bounces at redhat.com [mailto:linux-cluster-bounces at redhat.com] On Behalf Of chenzp
Sent: Sunday, 3 April 2011 2:43 PM
To: linux clustering
Subject: Re: [Linux-cluster] Replication for iSCSI target?

use drbd!



2011/4/2 Michael McGlothlin <michaelm at plumbersstock.com<mailto:michaelm at plumbersstock.com>>
I'm experimenting with setting up an iSCSI target that has data
replication between three nodes. Right now I'm trying Glusterfs which
seems workable but I'm not sure how it'll handle it if more than one
node is trying to access the same target device (1TB sparse file) at
the same time. Has anyone set something like this up before and can
give me some hints? I was looking at GFS before but it appeared to not
do replication? DRBD seemed like a possibility but having more than
two nodes sounded as if it might be an issue.

Each server has dual quad-core Xeon processors, 64GB RAM, 8 2TB
drives, and 10Gb Ethernet so I hope hardware won't be a limitation.
We've constantly had trouble with every iSCSI, SAN, NAS, etc we've
tried so I want to make something that is completely void of any
single point of failure.


Thanks,
Michael McGlothlin

--
Linux-cluster mailing list
Linux-cluster at redhat.com<mailto:Linux-cluster at redhat.com>
https://www.redhat.com/mailman/listinfo/linux-cluster

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20110404/af141e6e/attachment.htm>


More information about the Linux-cluster mailing list