From owner-freebsd-fs@freebsd.org Fri Jul 1 10:15:29 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 89586B8991B for ; Fri, 1 Jul 2016 10:15:29 +0000 (UTC) (envelope-from julien@perdition.city) Received: from relay-b01.edpnet.be (relay-b01.edpnet.be [212.71.1.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "edpnet.email", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 353E42E15 for ; Fri, 1 Jul 2016 10:15:28 +0000 (UTC) (envelope-from julien@perdition.city) X-ASG-Debug-ID: 1467368124-0a7ff569f61010f70001-3nHGF7 Received: from mordor.lan (213.219.165.225.bro01.dyn.edpnet.net [213.219.165.225]) by relay-b01.edpnet.be with ESMTP id ZjsvAlY8xm21USlM (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 01 Jul 2016 12:15:25 +0200 (CEST) X-Barracuda-Envelope-From: julien@perdition.city X-Barracuda-Effective-Source-IP: 213.219.165.225.bro01.dyn.edpnet.net[213.219.165.225] X-Barracuda-Apparent-Source-IP: 213.219.165.225 Date: Fri, 1 Jul 2016 12:15:24 +0200 From: Julien Cigar To: InterNetX - Juergen Gotteswinter Cc: Ben RUBSON , freebsd-fs@freebsd.org Subject: Re: HAST + ZFS + NFS + CARP Message-ID: <20160701101524.GF5695@mordor.lan> X-ASG-Orig-Subj: Re: HAST + ZFS + NFS + CARP References: <20160630144546.GB99997@mordor.lan> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w3uUfsyyY1Pqa/ej" Content-Disposition: inline In-Reply-To: <47c7e1a5-6ae8-689c-9c2d-bb92f659ea43@internetx.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Barracuda-Connect: 213.219.165.225.bro01.dyn.edpnet.net[213.219.165.225] X-Barracuda-Start-Time: 1467368124 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://212.71.1.221:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 3817 X-Virus-Scanned: by bsmtpd at edpnet.be X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0100 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30920 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 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 10:15:29 -0000 --w3uUfsyyY1Pqa/ej Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 01, 2016 at 11:42:13AM +0200, InterNetX - Juergen Gotteswinter = wrote: > >=20 > > Thank you very much for those "advices", it is much appreciated!=20 > >=20 > > I'll definitively go with iSCSI (for which I haven't that much=20 > > experience) over HAST. >=20 > good luck, i rather cut one of my fingers than using something like this > in production. but its probably a quick way if one targets to find a new > opportunity ;) why...? I guess iSCSI is slower but should be safer than HAST, no? >=20 > >=20 > > Maybe a stupid question but, assuming on the MASTER with ada{0,1} the= =20 > > local disks and da{0,1} the exported iSCSI disks from the SLAVE, would= =20 > > you go with: > >=20 > > $> zpool create storage mirror /dev/ada0s1 /dev/ada1s1 mirror /dev/da0 > > /dev/da1 > >=20 > > or rather: > >=20 > > $> zpool create storage mirror /dev/ada0s1 /dev/da0 mirror /dev/ada1s1 > > /dev/da1 > >=20 > > I guess the former is better, but it's just to be sure .. (or maybe it's > > better to iSCSI export a ZVOL from the SLAVE?) > >=20 >=20 > are you really sure you understand what you trying to do? even if its > currently so, i bet in a desaster case you will be lost. >=20 >=20 well this is pretty new to me, but I don't see what could be wrong with: $> zpool create storage mirror /dev/ada0s1 /dev/da0 mirror /dev/ada1s1 /dev/da1 Let's take some use-cases: - MASTER and SLAVE are alive, the data is "replicated" on both nodes. As iSCSI is used, ZFS will see all the details of the underlying disks and we can be sure that no corruption will occur (contrary to HAST) - SLAVE die, correct me if I'm wrong the but pool is still available, fix the SLAVE, resilver and that's it ..? - MASTER die, CARP will notice it and SLAVE will take the VIP, the failover script will be executed with a $> zpool import -f > > Correct me if I'm wrong but, from a safety point of view this setup is= =20 > > also the safest as you'll get the "fullsync" equivalent mode of HAST > > (but but it's also the slowest), so I can be 99,99% confident that the > > pool on the SLAVE will never be corrupted, even in the case where the > > MASTER suddently die (power outage, etc), and that a zpool import -f > > storage will always work? >=20 > 99,99% ? optimistic, very optimistic. the only situation where corruption could occur is some sort of network corruption (bug in the driver, broken network card, etc), or a bug in ZFS ... but you'll have the same with a zfs send|ssh zfs receive >=20 > we are playing with recovery of a test pool which has been imported on > two nodes at the same time. looks pretty messy >=20 > >=20 > > One last thing: this "storage" pool will be exported through NFS on the= =20 > > clients, and when a failover occur they should, in theory, not notice > > it. I know that it's pretty hypothetical but I wondered if pfsync could > > play a role in this area (active connections)..? > >=20 >=20 > they will notice, and they will stuck or worse (reboot) this is something that should be properly tested I agree.. >=20 > > Thanks! > > Julien > >=20 > >> > >>>>>> ZFS would then know as soon as a disk is failing. > >>>>>> And if the master fails, you only have to import (-f certainly, in= case of a master power failure) on the slave. > >>>>>> > >>>>>> Ben > >> _______________________________________________ > >> freebsd-fs@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs > >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > >=20 --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --w3uUfsyyY1Pqa/ej Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXdkK4AAoJELK7NxCiBCPAH3YQAOQsTySZm0whwykZIiG0ivVk nvik34mCVTWMpmtfhTW3m9+u+0YeoQlnyT1sI4Mtw+hLrU0U+EZoDafAk99jnaRA WHyLi+0232fdGD8K0VO+tq3JOqCAJBN5AzXTVzJtDzyLnMl1x+AzX4c6FMIQMyiV tSDBYJ8vmJmKWrlvvsNaxheVadnkitpsHuHYMykw+NKKv6MRVNtMlWtGIUCmAhbf o0fA+LsWgpkWNi5q6IpUqdbRc4Btz8XR9v5zkQiY4gDWN146AIFzWi8irCzqnoe8 Hgk9ZrPoPWlfYW12kWkO++zyd5zFEO+0SY+o9I996snXA2soaMyJkAGbISnoqX3F 5zQ9nVKvf/A9xtLZyLBIxm89ltxomAtxVCL/iEQ/NNKXxaz02DXDpbgA3aO1mloj WpVnldKWeHh3cVXc4+6t2LdYUsCY5ZrRetN0RPCn1HMs0UJvHPVukl0EldgbBTqa Q2E4A9Uz+sgEpqPJqIIOnrf1XOy29ax4jpUljswH1LMkrt81KhumEsRLlgBLEkwx 1/YmSCjYorV1QW1fGmyCi0+lVUm7WZB4DPkj+JEQqe12JE7acjy7fOgBGCt5YIv2 DEarGdAFqCQp+KzlFK+Thnk5n+PCtXv4GJOLWDrqRVLYmsJb3A4aml+uj+ZRs2H3 seWCUQE2MCAJKihq7h45 =SNJt -----END PGP SIGNATURE----- --w3uUfsyyY1Pqa/ej--