Gluster users - Mar 2010 - Gluster and iSCSI

I'm just wondering how gluster and iscsi might work together. I suspect that
in many situations they could be used interchangeably, but how about them
working together? If a setup providing a gluster AFR service was on top of
remote iSCSI targets, would protocol overhead become a serious problem?

Marcus
-- 
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info at hand CRM solutions
marcus at synchromedia.co.uk | http://www.synchromedia.co.uk/

I've done this a few years ago but there were serious overhead problems 
with gigE (even with jumbo frames).
This is a good way of merging a traditional SAN with gluster but there's 
little advantage if you are using commodity equipment. It's better to 
just have the machine exporing the iscsi lun to just act as a second 
gluster server.

There has been talk about a delayed-write mirror before for offsite and 
slower mirroring maybe a dev can tell us how far out that is.
Currently every write would have to occur before the client could continue.

-Mickey Mazarick

Marcus Bointon wrote:
> I'm just wondering how gluster and iscsi might work together. I suspect
that in many situations they could be used interchangeably, but how about them
working together? If a setup providing a gluster AFR service was on top of
remote iSCSI targets, would protocol overhead become a serious problem?
>
> Marcus
>   

--

At 06:57 AM 3/12/2010, Marcus Bointon wrote:
>I'm just wondering how gluster and iscsi might work together. I 
>suspect that in many situations they could be used interchangeably, 
>but how about them working together? If a setup providing a gluster 
>AFR service was on top of remote iSCSI targets, would protocol 
>overhead become a serious problem?
you'll have a number of performance problems here.  iSCSI is a 
synchronous protocol, so even if you have an efficient filesystem on 
top of it (zfs, xfs, etc.) you'll still have latency that would be 
much worse than, say, NFS.
You should get better performance, however, than something like DRBD 
or some other remote block device method.
Whatever you have providing the iSCSI targets should be write-cache 
capable and whatever filesystem you put on top of the targets should 
be write-cache aware.  These will help reduce the performance issues 
you may experience.

It was already recommended, but you'll be better off running gluster 
directly from your iSCSI target rather than using a remote iSCSI 
target for a local Gluster store.

Keith

>Marcus
>--
>Marcus Bointon
>Synchromedia Limited: Creators of http://www.smartmessages.net/
>UK resellers of info at hand CRM solutions
>marcus at synchromedia.co.uk | http://www.synchromedia.co.uk/
>
>
>_______________________________________________
>Gluster-users mailing list
>Gluster-users at gluster.org
>http://gluster.org/cgi-bin/mailman/listinfo/gluster-users