Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Jul 2008 11:04:45 -0400
From:      "David Robillard" <david.robillard@gmail.com>
To:        "Maurice Volaski" <mvolaski@aecom.yu.edu>
Cc:        FreeBSD Questions <freebsd-questions@freebsd.org>
Subject:   Re: Would ZFS and gmirror work well together in a two-node failover cluster?
Message-ID:  <226ae0c60807140804g467facdn37756a244e0b7de@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
> I am looking to put together a two-node high-availability cluster
> where each node has identical data storage consisting of a set of
> internal data drives (separate from the boot drive). I want ZFS to
> manage the drives as a JDBOD in a RAIDZ2 configuration. Thus, if an
> individual drive misbehaves or fails, ZFS detects and handles the
> fault.
>
> But I'm also looking to mirror this entire setup in real time to a
> second identical server.
>
> Basically, my question is can this work well on FreeBSD while taking
> full advantage of ZFS?
>
> Specifically, my understanding is that the only way to handle the
> real time mirror is with gmirror and ggated, but it's not clear how
> gmirror would interact with ZFS.
>
> I am assuming that gmirror operates only on individual drives, so if
> I had a set of 24 drives on each server, there would be 24 mirrored
> drive pairs.
>
> One concern I have is that this setup could run into trouble with
> gmirror's potentially sabotaging ZFS's RAIDZ2. For example, when a
> drive starts failing, won't gmirror see it before ZFS does and take
> the unfavorable action of substituting the corresponding drive in the
> failover server in subsequent I/O, leaving ZFS's RAIDZ2 out of the
> loop?
>
> This is just one particular scenario, but in general, it's not
> entirely clear that it's possible to have fine-grained control of
> when, how much and in what direction gmirror manages synchronization
> among drive pairs.

Hello Maurice,

Which type of connection do you intend to use for the shared storage
JBOD? SAN or direct attached SCSI? Don't forget to change the SCSI
initiator ID on one of the nodes if you go the direct attached SCSI
road. I had this setup running back in 1999 with two Solaris boxes
using Solstice Disk Suite with shared disks. Both nodes knew about the
existance of the other and hence it worked quite well. But I don't
know if it can work with two FreeBSD nodes?

Now for the filesystem choice, keep in mind that ZFS is not a native
cluster, distributed, or parallel file system and cannot provide
concurrent access from multiple hosts as ZFS is a local file system.
Which means your two node cluster won't be active/active. You'll have
an active node and a failover node. That may be alright or it may not.
Depends on your application, how deep your pockets are and your the
level of risk your organization is willing to live with.

You might want to take a look at clustered file systems for your
setup. Check out Lustre (http://wiki.lustre.org/) or OpenGFS
(http://opengfs.sourceforge.net/) for instance. If your cluster
requires mostly reads and not much write, check out OpenAFS
(http://www.openafs.org/) which is a distributed filesystem. You could
always use NFS too, but then it depends on where you want to deploy
the cluster, as NFS is rather hard to secure.

Now if we come back to the problem at hand, mainly using zfs under
gmirror. I've never heard of anyone using this. It does sound a bit
strange to me since both zfs and gmirror will do mirroring. I would
advise to test and retest very carefully before you go into production
with such a setup. If you do try it, I'd be interested in reading what
you've tried and what conclusions you came to.

Good luck! HTH,

David
-- 
David Robillard
UNIX systems administrator & Oracle DBA
CISSP, RHCE & Sun Certified Security Administrator
Montreal: +1 514 966 0122

If you receive something that says "Send this to everyone you know",
then please pretend you don't know me.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?226ae0c60807140804g467facdn37756a244e0b7de>