HAST + ZFS self healing? Hot spares?

[Pawel Jakub Dawidek]

On Fri, May 20, 2011 at 01:03:43AM +0200, Per von Zweigbergk wrote:
> Very well, that is how failures are handled. But how do we *recover*
> from a disk failure? Without taking the entire server down that is.

HAST opens local disk only when changing role to primary or changing
role to secondary and accepting connection from primary.
If your disk fails, switch to init for that HAST device, replace you
disk, call 'hastctl create <resource>' and switch back to primary or
secondary.

> I already know how to deal with my HBA to hot-add and hot-remove
> devices. And how to deal with hardware failures on the *secondary*
> node seems fairly straightforward, after all, it doesn't really
> matter if the mirroring becomes degraded for a few seconds while I
> futz around with restarting hastd and such. The primary sees the
> secondary disappear a few seconds, when it comes back, it will just
> truck all of the dirty data over. Big deal.

You don't need to restart hastd or stop secondary. Just use hastctl to
change role to init for the failing resource.

> But what if the drive fails on the primary side? On the primary
> server I can't just restart hastd at my leisure, the underlying
> filesystem relies on it not going away. Ideally I'd want to just be
> able to tell hast that "hey, there's a new drive you can use, just
> suck over all the data from the secondary onto this drive, and route
> I/O from the secondary in the meantime" - without restarting hastd.
> Is this possible?

Yes.

> These unresolved questions is why I would feel safer in simply
> running ZFS on the metal and running HAST on Zvols. :-) If running
> ZFS on top of a Zvol is a bad idea, there is always the option of
> simply exporting the HAST resource backed by Zvols as an iSCSI
> target and run VMFS on the drives. But that does mean losing some of
> the cooler features of ZFS which is a shame.

I'd suggest to test configuration that seems best in theory and then see
if it works for your or not. If not, then we can wonder what to do next.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110519/c0eebcdb/attachment.pgp