Replication/failover on OpenBSD? - BSD

This is a discussion on Replication/failover on OpenBSD? - BSD ; First off, two smallish points: I'm not quite an experienced OpenBSD user (being mostly a Linux guy looking around, right now), and all of this is basically for my amusement as it's major overkill in our situation. I've build and ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Replication/failover on OpenBSD?

  1. Replication/failover on OpenBSD?

    First off, two smallish points: I'm not quite an experienced OpenBSD
    user (being mostly a Linux guy looking around, right now), and all of
    this is basically for my amusement as it's major overkill in our
    situation.

    I've build and are currently maintaining a server for a small students'
    organization I am a part of. We have little traffic, and can acquire
    oldish machines for little or no cost via sponsors, the university, &c.
    Thus, while performance is a personal point of pride, it's ultimately of
    less concern than security (as in both 'not getting hacked' and 'not
    losing data').

    I'm thinking about replacing our current Linux server with an OpenBSD
    box. This is mostly because of the relative ease - OpenBSD is stable,
    secure, and a lot better documented than the hardened Linux From Scratch
    derivative I installed. Not to mention less buggy, and pkg_add or
    /usr/ports are remarkably painless if you're used to wading through
    ../configure options.

    Since we have plenty of hardware, but none of it could be called
    reliable, some sort of failover solution seems called for (of course,
    RAID would take care of part of the problem, but that's just too easy to
    be any fun). Last year saw some of our people bringing the server down
    by damaging the power cable (still haven't got a lockable cabinet, damn
    them!), a hard disk crashing after years of hard work under
    not-so-perfect conditions, and at least one weekend of effective
    downtime after I misconfigured the network. Over SSH. Oooops.

    Application-level replication could take care of some of the work, but
    is a pain to set up, and there'll always be someone who thinks up a neat
    application that does not handle replication. Or naively installs/codes
    a webapp.

    We currently provide several services, some of which handle dynamic data
    (SQL daemon, subversion repository, FTP and SAMBA for documents, and of
    course, mail storage). Not everything can be replicated at the
    application level (ftp, samba and the inevitable buggy webapp being most
    troublesome), and it also makes configuration a lot more complex.

    The canonical solution would be to use some form of shared storage,
    either SCSI-ish stuff which we'll have big trouble laying our hands on
    and even more trouble finding replacement parts (or even trained
    members) for, or an NFS server on stored hardware which just moves the
    problem. (And opens up quite a can of worms wrt locking.)

    Rsync and the like are not good enough, as the system should be able to
    go down without any data being lost (connections being lost is fine, but
    everything that is reported as written to disk should be secure).

    While researching this, I was quite happy to see drbd (www.drdb.org),
    but it doesn't work on OpenBSD, obviously.

    There's some sporadic stuff on the net about NBD for OpenBSD, which
    looks neat at first glance until I discovered I couldn't find a client
    for OpenBSD. If there's one, RAID-1 over NBD could work. (However, while
    someone, according to Google, seems to have ported the nbd server from
    nbd.soureforge.net to OpenBSD, the client still has a line #include
    ).

    Of course, in any case, hacking together some heartbeat-like
    (www.linux-ha.org) is required, getting the firewall to understand all
    this, and creating per-application failover scripts. ifstated, which
    also turned up, may be of some value here.

    Is there some option for OpenBSD that will do synchronous data
    replication, meaning that I can, during the most heavy load, pull the
    plug on the currently active server without losing any 'committed' data?
    (Assuming well-behaved daemons, a working backup node, &c.; by
    'committed' I mean that the daemon in question has told the client he
    received it, or at least finished writing; please note that this
    should work with PostgreSQL databases if at all possible!)

    Ideally, two nodes should be allowed r/w access, but this is not
    necessary (and of little practical value, as one node can easily handle
    the load - and if not, failover will not help much anyway until we place
    at least 3 boxes there).

    If only I had time to try some kernel hacking...

    Thank you all, and excuse me for the lengthy rambling,

    Joachim

  2. Re: Replication/failover on OpenBSD?

    not all OSes do all things, what your looking for in a file/web/etc
    server already exists in linux, and possibly in fbsd through GEOMdisk
    (or something like that) i have yet to play with drbd, but was thinking
    it would go well with xen...

    anyway, at least your firewall/router machines can failover as you seek.
    see carp and pfsync in the faq.

    Joachim Schipper wrote:
    > First off, two smallish points: I'm not quite an experienced OpenBSD
    > user (being mostly a Linux guy looking around, right now), and all of
    > this is basically for my amusement as it's major overkill in our
    > situation.
    >
    > I've build and are currently maintaining a server for a small students'
    > organization I am a part of. We have little traffic, and can acquire
    > oldish machines for little or no cost via sponsors, the university, &c.
    > Thus, while performance is a personal point of pride, it's ultimately of
    > less concern than security (as in both 'not getting hacked' and 'not
    > losing data').
    >
    > I'm thinking about replacing our current Linux server with an OpenBSD
    > box. This is mostly because of the relative ease - OpenBSD is stable,
    > secure, and a lot better documented than the hardened Linux From Scratch
    > derivative I installed. Not to mention less buggy, and pkg_add or
    > /usr/ports are remarkably painless if you're used to wading through
    > ./configure options.
    >
    > Since we have plenty of hardware, but none of it could be called
    > reliable, some sort of failover solution seems called for (of course,
    > RAID would take care of part of the problem, but that's just too easy to
    > be any fun). Last year saw some of our people bringing the server down
    > by damaging the power cable (still haven't got a lockable cabinet, damn
    > them!), a hard disk crashing after years of hard work under
    > not-so-perfect conditions, and at least one weekend of effective
    > downtime after I misconfigured the network. Over SSH. Oooops.
    >
    > Application-level replication could take care of some of the work, but
    > is a pain to set up, and there'll always be someone who thinks up a neat
    > application that does not handle replication. Or naively installs/codes
    > a webapp.
    >
    > We currently provide several services, some of which handle dynamic data
    > (SQL daemon, subversion repository, FTP and SAMBA for documents, and of
    > course, mail storage). Not everything can be replicated at the
    > application level (ftp, samba and the inevitable buggy webapp being most
    > troublesome), and it also makes configuration a lot more complex.
    >
    > The canonical solution would be to use some form of shared storage,
    > either SCSI-ish stuff which we'll have big trouble laying our hands on
    > and even more trouble finding replacement parts (or even trained
    > members) for, or an NFS server on stored hardware which just moves the
    > problem. (And opens up quite a can of worms wrt locking.)
    >
    > Rsync and the like are not good enough, as the system should be able to
    > go down without any data being lost (connections being lost is fine, but
    > everything that is reported as written to disk should be secure).
    >
    > While researching this, I was quite happy to see drbd (www.drdb.org),
    > but it doesn't work on OpenBSD, obviously.
    >
    > There's some sporadic stuff on the net about NBD for OpenBSD, which
    > looks neat at first glance until I discovered I couldn't find a client
    > for OpenBSD. If there's one, RAID-1 over NBD could work. (However, while
    > someone, according to Google, seems to have ported the nbd server from
    > nbd.soureforge.net to OpenBSD, the client still has a line #include
    > ).
    >
    > Of course, in any case, hacking together some heartbeat-like
    > (www.linux-ha.org) is required, getting the firewall to understand all
    > this, and creating per-application failover scripts. ifstated, which
    > also turned up, may be of some value here.
    >
    > Is there some option for OpenBSD that will do synchronous data
    > replication, meaning that I can, during the most heavy load, pull the
    > plug on the currently active server without losing any 'committed' data?
    > (Assuming well-behaved daemons, a working backup node, &c.; by
    > 'committed' I mean that the daemon in question has told the client he
    > received it, or at least finished writing; please note that this
    > should work with PostgreSQL databases if at all possible!)
    >
    > Ideally, two nodes should be allowed r/w access, but this is not
    > necessary (and of little practical value, as one node can easily handle
    > the load - and if not, failover will not help much anyway until we place
    > at least 3 boxes there).
    >
    > If only I had time to try some kernel hacking...
    >
    > Thank you all, and excuse me for the lengthy rambling,
    >
    > Joachim


  3. Re: Replication/failover on OpenBSD?

    none <""pixel\"@(none)"> wrote:
    > not all OSes do all things, what your looking for in a file/web/etc
    > server already exists in linux, and possibly in fbsd through GEOMdisk
    > (or something like that) i have yet to play with drbd, but was thinking
    > it would go well with xen...
    >
    > anyway, at least your firewall/router machines can failover as you seek.
    > see carp and pfsync in the faq.


    Yes, that's good.

    For the record - we'll go with OpenBSD on RAID. Should be good enough
    for our needs, and the multitudes of servers required for a failover
    solution would make the office very, very full...

    Joachim

+ Reply to Thread