Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Feb 2010 08:35:08 -0800
From:      Freddie Cash <fjwcash@gmail.com>
To:        Pawel Jakub Dawidek <pjd@freebsd.org>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: Any news on the HAST Project?
Message-ID:  <b269bc571002050835i60c1569aqbaf7a891ce5f47b2@mail.gmail.com>
In-Reply-To: <20100204210522.GB1733@garage.freebsd.pl>
References:  <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> <20100204210522.GB1733@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 4, 2010 at 1:05 PM, Pawel Jakub Dawidek <pjd@freebsd.org> wrote:

> On Wed, Feb 03, 2010 at 03:53:37PM +0100, Lorenzo Perone wrote:
>  > On 28.01.2010, at 14:26, Hywel Mallett wrote:
>  > > About the same time a status update was posted on the FreeBSD
> Foundation blog at
> http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-project.html
> >
> > Thanx, also to pjd's answer. That gives some nice insight already. Great
> work! HAST could in fact change radically the way of using block devices and
> distributing mass storage. I look forward to testing it first on a few
> vboxes and shortly thereafter on real machines.
> >
> > Really curious on how several things are implemented, e.g. performance /
> latency / fail / sync issues (what happens for example when a big huge file
> is written locally on a very fast primary, and there is not enough ram to
> buffer it before sending it to a secondary.. etc, scenarios like that).
>
> Every write request is handled synchronously by HAST. It is reported as
> completed only when it is stored on local and on remote node.
>
> > And how well it will do with ZFS too: although ZFS has its 'own' HAST via
> send/recv (and besides might get its own implementation for some sort of
> 'streaming' send/recv..) it is also true that it'd allow for some great
> flexibility in creating primary/secondary volumes (zvols). Just imagining a
> scenario with sparse zvols and HAST disting them around.. ok ok I stop here
> :-)
>
> ZFS send/recv is something else. It can't work synchronously, where HAST
> works always that way. This means that when your primary node dies you
> won't lose even a single bit of data.
>
> Although be aware that file systems like UFS can be in inconsistent
> state after primary failure, so secondary node after switching to
> primary role has to check file system with fsck(8) before mounting it.
> This also makes ZFS great choice for running on HAST as 'zpool import'
> is very fast as oppose to fsck (at least until Jeff finish his SU+J
> project).
>
> Am I correct in thinking that this will solve my issue with creating a
fail-over SAN setup, as detailed here back in June?
    http://lists.freebsd.org/pipermail/freebsd-fs/2009-June/006394.html

In essence, create a master storage server at SiteA using HAST as the
underlying GEOM for the zpool, and create an identical slave storage server
at SiteB, also using HAST to create the zpool.  Then use CARP to create a
shared IP between the two, and use that IP for the iSCSI links to the VM
servers at each site.

The setup would be like so:
    [Server Room 1]       .      [Server Room 2]
   -----------------      .    -------------------
                          .
   [storage server]       .     [storage server]
          |               .            |
          |               .            |
   [storage switch]       .      [storage switch]
          |        \----fibre----/     |
          |               .            |
          |               .            |
   /---[switch]---\       .     /---[switch]---\
   |       |      |       .     |      |       |
   |    [VM box]  |       .     |   [VM box]   |
   |       |      |       .     |      |       |
[VM box]   |      |       .  [VM box]  |       |
   |       |   [VM box]   .     |      |    [VM box]
   |       |      |       .     |      |       |
   [network switch]       .     [network switch]
           |              .            |
           |              .            |
       [internet]         .        [internet]

Server room 1 would be live, with the storage server marked as master, and
the storage server in Server room 2 would be the slave.  Initially, the VMs
would run in server room 1, but could fail-over or migrade to server room.

Will be very interesting to see how this all works with ZFS.  Could be a
killer combination:  all the GEOM goodies, HAST, ZFS, CARP, etc.  It's days
like this that I'm glad I use FreeBSD.  :D

Keep up the good work!!
-- 
Freddie Cash
fjwcash@gmail.com



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