From owner-freebsd-stable@FreeBSD.ORG Thu Jul 17 14:16:59 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E777106564A; Thu, 17 Jul 2008 14:16:59 +0000 (UTC) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.freebsd.org (Postfix) with ESMTP id CA4F98FC19; Thu, 17 Jul 2008 14:16:58 +0000 (UTC) (envelope-from sven@dmv.com) Received: from [216.240.97.46] (lanshark.dmv.com [216.240.97.46]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id m6HEGtN0018597; Thu, 17 Jul 2008 10:16:57 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: Pete French In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OUlfW357Kn9I5gRG34WM" Date: Thu, 17 Jul 2008 10:16:55 -0400 Message-Id: <1216304215.14562.19.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 Cc: koitsu@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Multi-machine mirroring choices X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2008 14:16:59 -0000 --=-OUlfW357Kn9I5gRG34WM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-07-15 at 16:20 +0100, Pete French wrote: > > However, I must ask you this: why are you doing things the way you are? > > Why are you using the equivalent of RAID 1 but for entire computers? I= s > > there some reason you aren't using a filer (e.g. NetApp) for your data, > > thus keeping it centralised? >=20 > I am not the roiginal poster, but I am doing something very similar and > can answer that question for you. Some people get paranoid about the > whole "single point of failure" thing. I originally suggestted that we bu= y > a filer and have identical servers so if one breaks we connect the other > to the filer, but the response I got was "what if the filer breaks?". So > in the end I had to show we have duplicate independent machines, with the > data kept symetrical on them at all times. >=20 > It does actually work quite nicely actually - I have an "'active" databas= e > machine, and a "passive". The opassive is only used if the active fails, > and the drives are run as a gmirror pair with the remote one being mounte= d > using ggated. It also means I can flip from active to passive when I want > to do an OS upgrade on the active machine. Switching takes a few seconds, > and this is fine for our setup. >=20 > So the answer is that the descisiuon was taken out of my hands - but this > is not uncommon, and as a roll-your-own cluster it works very nicely. >=20 > -pete. > _______________________________________________ I have for now gone with using ggate[cd] along with zpool and so far it's not bad. I can fail the master, stop ggated on the slave at which point geom reads the glabeled disks. From there I can zpool import to an alternate root. When the master comes back up I can zpool export and then, on the master, zpool import at which point zfs handles the resilvering. The *big* issue I have right now is dealing with the slave machine going down. Once the master no longer has a connection to the ggated devices, all processes trying to use the device hang in D status. I have tried pkill'ing ggatec to no avail and ggatec destroy returns a message of gctl being busy. Trying to ggatec destroy -f panics the machine. Does anyone know how to successfully time out a failed ggatec connection so that I can zpool detach or somehow have zfs removed the unavailable drive? Sven --=-OUlfW357Kn9I5gRG34WM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBIf1RXSnmnd8q3JGsRAlKBAKCE22yRLMrtzKkG4YyoY3rA2ZuU0wCdGegC LV/XmxCaWiNzl08keY/U1AY= =Nh7v -----END PGP SIGNATURE----- --=-OUlfW357Kn9I5gRG34WM--