From owner-freebsd-fs@freebsd.org Fri Jul 1 11:40:15 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEC8AB8E089 for ; Fri, 1 Jul 2016 11:40:15 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F980206C for ; Fri, 1 Jul 2016 11:40:15 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B4BB028450; Fri, 1 Jul 2016 13:40:12 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id E331A28458; Fri, 1 Jul 2016 13:40:11 +0200 (CEST) Message-ID: <5776569B.3050504@quip.cz> Date: Fri, 01 Jul 2016 13:40:11 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Julien Cigar CC: InterNetX - Juergen Gotteswinter , freebsd-fs@freebsd.org Subject: Re: HAST + ZFS + NFS + CARP References: <71b8da1e-acb2-9d4e-5d11-20695aa5274a@internetx.com> <20160630153747.GB5695@mordor.lan> <63C07474-BDD5-42AA-BF4A-85A0E04D3CC2@gmail.com> <20160630163541.GC5695@mordor.lan> <50BF1AEF-3ECC-4C30-B8E1-678E02735BB5@gmail.com> <20160701084717.GE5695@mordor.lan> <47c7e1a5-6ae8-689c-9c2d-bb92f659ea43@internetx.com> <20160701101524.GF5695@mordor.lan> <20160701105735.GG5695@mordor.lan> In-Reply-To: <20160701105735.GG5695@mordor.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 11:40:15 -0000 Julien Cigar wrote on 07/01/2016 12:57: >>> why...? I guess iSCSI is slower but should be safer than HAST, no? >> >> do your testing, please. even with simulated short network cuts. 10-20 >> secs are way enaugh to give you a picture of what is going to happen > > of course I'll test everything properly :) I don't have the hardware yet > so ATM I'm just looking for all the possible "candidates", and I'm > aware that a redundant storage is not that easy to implement ... > > but what solutions do we have? It's either CARP + ZFS + (HAST|iSCSI), > either zfs send|ssh zfs receive as you suggest (but it's > not realtime), either a distributed FS (which I avoid like the plague..) When disaster comes you will need to restart NFS clients in almost all cases (with CARP + ZFS + HAST|iSCSI) and you will lose some writes too. And if something bad happens with your mgmt scripts or network you can end up with corrupted ZFS pool on master and slave too - you will need to recovery from backups. For example in some split brain scenario when both nodes will try to import pool. With ZFS send & receive you will lose some writes but the chance you will corrupt both pools are much lower than in the first case and the setup is much simpler and runtime error proof. I rather prefer some downtime with safe data than shorter downtime but data in risk. YMMV Miroslav Lachman