Date: Tue, 17 May 2016 00:36:51 +0200 From: Palle Girgensohn <girgen@FreeBSD.org> To: Borja Marcos <borjam@sarenet.es> Cc: freebsd-fs@freebsd.org Subject: Re: Best practice for high availability ZFS pool Message-ID: <89D73122-FAC7-4449-AAB3-C4BBE74B960A@FreeBSD.org> In-Reply-To: <F3716A47-BC73-4C51-BF7C-911BCFE4D29F@sarenet.es> References: <5E69742D-D2E0-437F-B4A9-A71508C370F9@FreeBSD.org> <F3716A47-BC73-4C51-BF7C-911BCFE4D29F@sarenet.es>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_E981C4D9-6449-4B12-B476-356B0F43A9DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 16 maj 2016 kl. 15:51 skrev Borja Marcos <borjam@sarenet.es>: >=20 >=20 >> On 16 May 2016, at 12:08, Palle Girgensohn <girgen@freebsd.org> = wrote: >>=20 >> Hi, >>=20 >> We need to set up a ZFS pool with redundance. The main goal is high = availability - uptime. >>=20 >> I can see a few of paths to follow. >>=20 >> 1. HAST + ZFS >=20 > Which means that a possible corruption causing bug in ZFS would = vaporize the data of both replicas. >=20 >> 3. ZFS replication (zfs snapshot + zfs send | ssh | zfs receive) >=20 > If you don=E2=80=99t have a hard requirement for synchronous = replication (and, in that case, I would opt for a more application > aware approach) it=E2=80=99s the best method in my opinion. That was exactly my thought 18 months ago, and we set up two systems = with zfs snapshot + zfs send | ssh | zfs receive. It works, but the = problem is it just too slow and a complete sync takes like 10 minutes = for all the file systems. We are forced to sync the file systems one at = a time to get the kind of control and separation we need. Even if we = could speed that up somehow, we are really looking for a more recilient = system. Also, constant snapshotting and writing makes scrub very slow so = we need to tune down the amount of syncing every fourth week-end to = scrub. It's OK but not optimal, so we're pondering for something better. My first choice is really HAST at the moment, but I also dont find much = written in the last couple of years, apart from some articles about = setting it up in very minimal testbeds or posts about performance and = stability troubles. This makes me wonder, is HAST actively maintained? = Is it stable, used and loved by the community? I'd love to hear some = success stories with farily large installations of at least 20 TB or so. Palle --Apple-Mail=_E981C4D9-6449-4B12-B476-356B0F43A9DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJXOkuDAAoJEDQn0sf36Uls++IIAIGX1yPZt2BdPB9rly71u+TV 9jap9c0ZtUagYcwUNnUbKuShoEKr1FCyIv5trIB13CC7UieBV3f8AAprCa7fohb3 Hc5nENqjyqaG2udppYg7J5mXs1so5W6F9SdmSuIh2RSCvtV+aKm5ofmF+Ef7ZiEo zvR8jJzVcLEHm5RnpzQm1oU17U0eHwfF5fdWtaw69roHCWMk08MkQcJBocXORAh5 /+L7zzPxezQh4YeYfDnj9rC7vaerU8iyEQsw8MV6tY6gD+JiW1dfjZK6p0AwwkKk W876vHi+rbxpWt4bLYDBPbRsnRGYaL9AuX1bGSgAvXlhZS2Rod5DdnpoX5ez/+E= =kVC+ -----END PGP SIGNATURE----- --Apple-Mail=_E981C4D9-6449-4B12-B476-356B0F43A9DD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89D73122-FAC7-4449-AAB3-C4BBE74B960A>