Date: Thu, 19 Apr 2007 12:28:16 +0200 From: Oliver Brandmueller <ob@e-Gitt.NET> To: freebsd-stable@freebsd.org Subject: Re: iscsi and geom mirror - stupid idea or not ? Message-ID: <20070419102815.GG95707@e-Gitt.NET> In-Reply-To: <E1HeTFQ-0009lC-DQ@dilbert.ticketswitch.com> References: <E1HeTFQ-0009lC-DQ@dilbert.ticketswitch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Apr 19, 2007 at 10:48:16AM +0100, Pete French wrote: > what would happen if I made a machine which contained a mirrored > geom pair consiting of one local driive and one drive accessed via iscsi = on > a remote machine ? would this work ? >=20 > what I am considering is two such machines, geographicly distinct. one is > a 'master' and boots off the mirrored drive, the other is a slave and > has a separate boot drive which just rngs FreeBSD to make the drive inside > it into an iscsi target for the first machine. The idea here is if the fi= rst > machine is catastrphicly killed (like building falls down on it or > something) then the second one can be rebooted from the internal drive, a= nd > will hence become the first one. It's basically a way of making a standby > machine in case of disaster. >=20 > I havent really looked at iSCSI until recently, and this is just one of > the ideas I came up with looking at the possibilities. You could also go and use ggate for that. And seems to get more and more=20 common to work like that, although probably most setups I heard of=20 probably don't have a long distance link between them. There are a few things you should consider: First, you have to make=20 absolutely sure, that for example the mirrored disk is not attached if=20 after a crash the original master comes back and the slave took over. If=20 this happens you're likely to damage something really bad. Second is, something like this gives you mirrored data with practically=20 no gap to the original disk. The price you have to pay: This does not=20 help you against logical errors (a filesystem damage will be replicated=20 just fine...). A setup like this does not serve as a backup. Third is, you'll have to fsck everything, so this defines your minimum=20 service outage. I'm not sure, if I'd trust background fsck here, also bg=20 fsck is a big performance penalty, which might or might not be a=20 problem for your setup. A replication (like rsync, ssync or similar) sure has the drawback of=20 the replication gap for the data. Also you cannot just take over the IP=20 of the NFS server, but have to remount everything. But you have fsck=20 time, lower chance damage due to logical error and the nice effect, that=20 you could do your backups from the replicated data, not affecting your=20 live system. But have to deal with lost data from probably several hours=20 or how to replicate changed data after recovery. - Olli --=20 | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGJ0Q/iqtMdzjafykRAjCrAJ0SG8hfxsXWi2bIN8yQ7Ei8kHrswwCcDV0l RyBBFKqykr8bX6WlNgxAhIU= =Mucs -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070419102815.GG95707>