From owner-freebsd-fs@FreeBSD.ORG Fri Feb 5 16:35:09 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EF7D106566C; Fri, 5 Feb 2010 16:35:09 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.223.174]) by mx1.freebsd.org (Postfix) with ESMTP id 36D088FC17; Fri, 5 Feb 2010 16:35:08 +0000 (UTC) Received: by iwn4 with SMTP id 4so4296239iwn.27 for ; Fri, 05 Feb 2010 08:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7xZSEbF/3JjSqgCWAek5byZyoG57Mrtb7TPlldxtxLM=; b=Er9Zi8mQjrNuOSbp16wPVTZulvcx0DTsVSxmHESdWjJlAQBrBN54MXd6+aEWAuxDY/ eqk5SheRHR7rnAWrQNK5gFeADpCyq6U90YNhfSuBdXyPvgEL3hdhUaKVz3Uq6QSViKum kmTWTO8ok2z9gP1BgQozOL6WkjOO1ZIKqypiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TfW3ZnLYCyg4o9e6WXWC7qhhJ0Km+a2PNsFCsshk06VnzeC2aP3yyIvjU32G3zLtWz odqbrI1tPj5+UNsUQmogj8DJjKbYanJaKVd+Zr3s5RBz+mLFYySkPKR5rOCNmLiTmQHN 4liu/dOwm2+TWvTHG25UO3qTMQKzosP1mD02U= MIME-Version: 1.0 Received: by 10.231.143.12 with SMTP id s12mr886996ibu.38.1265387708332; Fri, 05 Feb 2010 08:35:08 -0800 (PST) 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> Date: Fri, 5 Feb 2010 08:35:08 -0800 Message-ID: From: Freddie Cash To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HAST Project? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 16:35:09 -0000 On Thu, Feb 4, 2010 at 1:05 PM, Pawel Jakub Dawidek 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