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
