Date: Fri, 1 Jul 2016 12:15:24 +0200 From: Julien Cigar <julien@perdition.city> To: InterNetX - Juergen Gotteswinter <jg@internetx.com> Cc: Ben RUBSON <ben.rubson@gmail.com>, freebsd-fs@freebsd.org Subject: Re: HAST + ZFS + NFS + CARP Message-ID: <20160701101524.GF5695@mordor.lan> In-Reply-To: <47c7e1a5-6ae8-689c-9c2d-bb92f659ea43@internetx.com> References: <20160630144546.GB99997@mordor.lan> <71b8da1e-acb2-9d4e-5d11-20695aa5274a@internetx.com> <AD42D8FD-D07B-454E-B79D-028C1EC57381@gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160701101524.GF5695>