As Frederico suggests below, multimaster LDAP is the answer for LDAP. Normal LDAP master/slave replication works too if you don't mind your LDAP DB going read-only when failed over (in practice this isn't usually a big deal - password changes are about the only non-IT controlled activity usually affected unless you're doing funky stuff with ldap). While it's not something I'd necessarily recommend, Windows Active Directory (or it's cousin, Active Directory Application Mode "ADAM") has rather good multimaster replication built in if you're after a set-and-forget config.

SQL DB - depends on your DB backend. Circular replication with MySQL gives you active-active live multimaster replication (yes, it also requires some maintenance to keep healthy, but it works), with MySQL Proxy configured on the SQL client machine (SOGo server) to handle failover. We hang a second passive readonly replica off each master for backup too.

You can also use clever Apache config to handle the case where Apache survives but one SOGo instance is down.

If you're going down this route btw I'd strongly recommend using a heavy VM infrastructure - piling all this on one OS install at each end is going to be painful and "breaky". If resources are a problem you can use careful combinations of vm instances with kernel-level containers (OpenVZ and such)

Also - you're going to want to monitor the hell out of everything because with a sufficiently redundant infrastructure it can be hard to know when something actually breaks :)

-Nathanael Bettridge

---- Original Message ----
*From:* Federico Alberto Sayd <fs...@uncu.edu.ar>
*Sent:* Wed, 31 Oct 2012  2:10 AM
*To:* users@sogo.nu
*Subject:* Re: [SOGo] Backup Redundant System
On 30/10/12 11:04, Carlin Hefner wrote:
Thank you Nathanael,
Your solution actually looks the best, because I started discovering issues with trying to use DRBD over WAN. I've started looking into your solution and have a couple questions. BTW I apologize, I'm a bit new at this, so I could be overlooking the obvious.

I have the MX and DNS failover under control for access to either location, and the replication sounds great, but how can I get service failover for LDAP, SQL etc if the primary network or server goes down? Eg if the primary server goes down, the MX failover will send messages to the backup MX but then that backup MX is still pointing to the primary LDAP db. I could use a failover to point it to the replicated LDAP but that wouldn't work since it's a consumer, not a provider, right? Same with the SQL DB?
You can use LDAP in multimaster mode, there is not a master LDAP server, you should point your DNS to the both LDAP servers

http://www.openldap.org/doc/admin24/replication.html

Regards

Thanks
Carlin


On Tue, Oct 30, 2012 at 6:05 AM, Nathanael Bettridge <nbettri...@yahoo.com <mailto:nbettri...@yahoo.com>> wrote:

    I know there's been active/passive disk image designs mentioned,
    but for something more application-level (and more expansive):

    - Use LDAP with replication for accounts
    - Use Cyrus IMAPd native replication and frontend/backend to
    handle mail (you can combine this with a Cyrus Murder to have a
    primary DB at each site along with a replica DB of the alternate
    site)
    - Use native SQL replication for the SOGo database
    - Use MX failover for inbound email, with live MXes at each site
    pointing at the same LDAP db and handing off delivery to the
    Cyrus frontends
    - Use anycast addresses, or DNS failover scripting, for
    user-connectivity failover (for some clients we can use SRV
    record tricks too)

    We use a setup something like this and it works rather well,
    though requires a fair few VM instances to run. We also put
    simple (non-persistent disk) loadbalancing/failover VM's in front
    of each service that can handle automatic failover (SQL, LDAP
    read, MX and Cyrus Frontends for example) to handle failures
    automatically.

    It also makes backup easy since you run backup on the replicas
    and nobody notices :)

    However, we're not using this with Exchange emulation (yet) so
    it'll be interesting to figure out how it behaves in this environment

    However for a simple deployment DRBD is probably easier :)

    Thanks,
    -Nathanael Bettridge


    carlinohef...@gmail.com <mailto:carlinohef...@gmail.com> wrote:
    Hi,
    I'm am looking at venturing into sogo as an exchange replacement, and have a
    question before I begin. I promise I have searched before posting, but can't
    find anything related (or I may have poor keyword choices :-) So I 
apologize if
    this has been discussed already.

    We have a couple of office locations, and I'd like to set up 2 servers, 1 at
    each location, that mirror each other. That way if one location goes down
    (power or internet loss or hardware failure) the other server can still at
    least receive SMTP. It would be great if the client side connectivity could
    also work when one or the other servers go down, but not as important as 
making
    sure we don't miss any incoming mail over SMTP.

    Is this possible?

    Thanks in advance,
    Carlin




--
users@sogo.nu
https://inverse.ca/sogo/lists

Reply via email to