Date: Fri, 1 Jul 2016 11:54:58 -0500 From: Chris Watson <bsdunix44@gmail.com> To: Gary Palmer <gpalmer@freebsd.org> Cc: Julien Cigar <julien@perdition.city>, freebsd-fs@freebsd.org Subject: Re: HAST + ZFS + NFS + CARP Message-ID: <7D9B465F-0248-4F6D-895D-7BC3684EC6F7@gmail.com> In-Reply-To: <20160701154658.GA70150@in-addr.com> References: <20160701101524.GF5695@mordor.lan> <f74627e3-604e-da71-c024-7e4e71ff36cb@internetx.com> <20160701105735.GG5695@mordor.lan> <3d8c7c89-b24e-9810-f3c2-11ec1e15c948@internetx.com> <93E50E6B-8248-43B5-BE94-D94D53050E06@getsomewhere.net> <bbaf14e2-4ec6-545c-ba67-a1084100b05c@internetx.com> <20160701143917.GB41276@mordor.lan> <01b8a61e-739e-c41e-45bc-a84af0a9d8ab@internetx.com> <4d13f123-de18-693a-f98b-d02c8864f02e@internetx.com> <20160701151146.GD41276@mordor.lan> <20160701154658.GA70150@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Gary! So I'll add another voice to the KISS camp. I'd rather have two boxes each w= ith two NICs attached to each other doing zfs replication from A to B. Addin= g more redundant hardware just adds more points of failure. NICs have no mov= ing parts so as long as they are thermally controlled they won't fail. This i= s simple and as safe as you can get. As for how to handle an actual failover= is really like to try out the ctl-ha option. Maybe this weekend.=20 Sent from my iPhone 5 > On Jul 1, 2016, at 10:46 AM, Gary Palmer <gpalmer@freebsd.org> wrote: >=20 >> On Fri, Jul 01, 2016 at 05:11:47PM +0200, Julien Cigar wrote: >>> On Fri, Jul 01, 2016 at 04:44:24PM +0200, InterNetX - Juergen Gotteswint= er wrote: >>> dont get me wrong, what i try to say is that imho you are trying to >>> reach something which looks great until something goes wrong. >>=20 >> I agree..! :) >>=20 >>>=20 >>> keep it simple, stupid simple, without much moving parts and avoid >>> automagic voodoo wherever possible. >>=20 >> to be honnest I've always been relunctant to "automatic failover", as I >> think the problem is always not "how" to do it but "when".. and as Rick >> said "The simpler/reliable way would be done manually be a sysadmin".. >=20 > I agree. They can verify that the situation needs a fail over much better= > than any script. In a previous job I heard of a setup where the cluster > manager software on the standby node decided that the active node was > down so it did a force takeover of the disks. Since the active node was > still up it somehow managed to wipe out the partition tables on the disks > along with the vxvm configuration (Veritas Volume Manager) inside the > partitions. >=20 > They were restoring the partition tables and vxvm config from backups. > =46rom what I remember the backups were printouts, which made it slow goin= g > as they had to be re-entered by hand. The system probably had dozens > of disks (I don't know, but I know what role it was serving so I can > guess) >=20 > I'd rather not see that happen ever again >=20 > (this was 15+ years ago FWIW, but the lesson is still applicable today) >=20 > Gary >=20 >>=20 >>>> Am 01.07.2016 um 16:41 schrieb InterNetX - Juergen Gotteswinter: >>>>> Am 01.07.2016 um 16:39 schrieb Julien Cigar: >>>>>> On Fri, Jul 01, 2016 at 03:44:36PM +0200, InterNetX - Juergen Gottesw= inter wrote: >>>>>>=20 >>>>>>=20 >>>>>>> Am 01.07.2016 um 15:18 schrieb Joe Love: >>>>>>>=20 >>>>>>>> On Jul 1, 2016, at 6:09 AM, InterNetX - Juergen Gotteswinter <jg@in= ternetx.com> wrote: >>>>>>>>=20 >>>>>>>> Am 01.07.2016 um 12:57 schrieb Julien Cigar: >>>>>>>>> On Fri, Jul 01, 2016 at 12:18:39PM +0200, InterNetX - Juergen Gott= eswinter wrote: >>>>>>>>>=20 >>>>>>>>> of course I'll test everything properly :) I don't have the hardwa= re yet >>>>>>>>> so ATM I'm just looking for all the possible "candidates", and I'm= =20 >>>>>>>>> aware that a redundant storage is not that easy to implement ... >>>>>>>>>=20 >>>>>>>>> but what solutions do we have? It's either CARP + ZFS + (HAST|iSCS= I),=20 >>>>>>>>> either zfs send|ssh zfs receive as you suggest (but it's >>>>>>>>> not realtime), either a distributed FS (which I avoid like the pla= gue..) >>>>>>>>=20 >>>>>>>> zfs send/receive can be nearly realtime. >>>>>>>>=20 >>>>>>>> external jbods with cross cabled sas + commercial cluster solution l= ike >>>>>>>> rsf-1. anything else is a fragile construction which begs for desas= ter. >>>>>>>=20 >>>>>>> This sounds similar to the CTL-HA code that went in last year, for w= hich I haven???t seen any sort of how-to. The RSF-1 stuff sounds like it ha= s more scaling options, though. Which it probably should, given its commerc= ial operation. >>>>>>=20 >>>>>> rsf is what pacemaker / heartbeat tries to be, judge me for linking >>>>>> whitepapers but in this case its not such evil marketing blah >>>>>>=20 >>>>>> http://www.high-availability.com/wp-content/uploads/2013/01/RSF-1-HA-= PLUGIN-ZFS-STORAGE-CLUSTER.pdf >>>>>>=20 >>>>>>=20 >>>>>> @ Julien >>>>>>=20 >>>>>> seems like you take availability really serious, so i guess you also g= ot >>>>>> plans how to accomplish network problems like dead switches, flaky >>>>>> cables and so on. >>>>>>=20 >>>>>> like using multiple network cards in the boxes, cross cabling between= >>>>>> the hosts (rs232 and ethernet of course, using proved reliable networ= k >>>>>> switches in a stacked configuration for example cisco 3750 stacked). n= ot >>>>>> to forget redundant power feeds to redundant power supplies. >>>>>=20 >>>>> the only thing that is not redundant (yet?) is our switch, an HP Pro=20= >>>>> Curve 2530-24G) .. it's the next step :) >>>>=20 >>>> Arubas, okay, a quick view in the spec sheet does not seem to list >>>> stacking option. >>>>=20 >>>> what about power? >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> if not, i whould start again from scratch. >>>>>>=20 >>>>>>>=20 >>>>>>> -Joe >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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= " >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> 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. >=20 >=20 > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7D9B465F-0248-4F6D-895D-7BC3684EC6F7>