HAST + ZFS + NFS + CARP

Julien Cigar julien at perdition.city
Fri Jul 1 15:03:42 UTC 2016


On Fri, Jul 01, 2016 at 04:41:59PM +0200, InterNetX - Juergen Gotteswinter wrote:
> Am 01.07.2016 um 16:39 schrieb Julien Cigar:
> > On Fri, Jul 01, 2016 at 03:44:36PM +0200, InterNetX - Juergen Gotteswinter wrote:
> >>
> >>
> >> Am 01.07.2016 um 15:18 schrieb Joe Love:
> >>>
> >>>> On Jul 1, 2016, at 6:09 AM, InterNetX - Juergen Gotteswinter <jg at internetx.com> wrote:
> >>>>
> >>>> Am 01.07.2016 um 12:57 schrieb Julien Cigar:
> >>>>> On Fri, Jul 01, 2016 at 12:18:39PM +0200, InterNetX - Juergen Gotteswinter wrote:
> >>>>>
> >>>>> of course I'll test everything properly :) I don't have the hardware yet
> >>>>> so ATM I'm just looking for all the possible "candidates", and I'm 
> >>>>> aware that a redundant storage is not that easy to implement ...
> >>>>>
> >>>>> but what solutions do we have? It's either CARP + ZFS + (HAST|iSCSI), 
> >>>>> either zfs send|ssh zfs receive as you suggest (but it's
> >>>>> not realtime), either a distributed FS (which I avoid like the plague..)
> >>>>
> >>>> zfs send/receive can be nearly realtime.
> >>>>
> >>>> external jbods with cross cabled sas + commercial cluster solution like
> >>>> rsf-1. anything else is a fragile construction which begs for desaster.
> >>>
> >>> This sounds similar to the CTL-HA code that went in last year, for which I haven’t seen any sort of how-to.  The RSF-1 stuff sounds like it has more scaling options, though.  Which it probably should, given its commercial operation.
> >>
> >> rsf is what pacemaker / heartbeat tries to be, judge me for linking
> >> whitepapers but in this case its not such evil marketing blah
> >>
> >> http://www.high-availability.com/wp-content/uploads/2013/01/RSF-1-HA-PLUGIN-ZFS-STORAGE-CLUSTER.pdf
> >>
> >>
> >> @ Julien
> >>
> >> seems like you take availability really serious, so i guess you also got
> >> plans how to accomplish network problems like dead switches, flaky
> >> cables and so on.
> >>
> >> like using multiple network cards in the boxes, cross cabling between
> >> the hosts (rs232 and ethernet of course, using proved reliable network
> >> switches in a stacked configuration for example cisco 3750 stacked). not
> >> to forget redundant power feeds to redundant power supplies.
> > 
> > the only thing that is not redundant (yet?) is our switch, an HP Pro 
> > Curve 2530-24G) .. it's the next step :)
> 
> Arubas, okay, a quick view in the spec sheet does not seem to list
> stacking option.
> 
> what about power?

there is a "diesel generator" for the server room, and redundant power
supply on "most critical" servers (our PostgreSQL servers for example). 

Router and Firewall (Soekris 6501) runs CARP / PFSync, same for 
the load balancer (HAProxy), local Unbound, etc

(Everything is jailed and managed by SaltStack, so in worst case scenario
I could always redeploy "something" (service, webapp, etc) in minutes on
$somemachine ..)

No, the really SPOF that should be fixed quickly ATM is the shared files 
storage, it's a NFS mount on a single machine (with redundant power 
supply) and if the hardware die we're in troubles (...)

> 
> > 
> >>
> >> if not, i whould start again from scratch.
> >>
> >>>
> >>> -Joe
> >>>
> >>> _______________________________________________
> >>> freebsd-fs at freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> >>>
> >> _______________________________________________
> >> freebsd-fs at freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> > 
> 

-- 
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160701/71fdb981/attachment.sig>


More information about the freebsd-fs mailing list