Secondary MX

[Tosin]

Please help.

I have two locations A and B with ZCS installed and running at both.

Now I want to achieve a situation where I have location A have its secondary MX in location B such that when the server in location A is down, users in location A can work out of location B for that period of downtime.

Every input will be appreciated.

[zelthian]

This is more complicated than just having a secondary MX record.

Having a secondary MX record would only route mail to the second IP address. It wouldn't achieve allowing "users in location A can work out of location B".

To do that, you would have to duplicate your server environment in the second site complete with accounts and mailboxes and have a way for the mailbox contents in each site sync with each other and be able to recover after downtime. Again, not impossible, but much more complicated than simply having a second MX record; it would be more in the area of DR and Site Resilience.

[Tosin]

what I have done is to create a duplicate site A domain on site B zimbra server with all user accounts. The challenge I now experience is that users mail in site B are not been delivered to site A. How do I correct this.

[phoenix]

Originally Posted by Tosin

what I have done is to create a duplicate site A domain on site B zimbra server with all user accounts. The challenge I now experience is that users mail in site B are not been delivered to site A. How do I correct this.

This won't work, you need something a bit more sophisticated than a Backup MX - that will only store mail while the primary MX is down and then deliver when it's back on-line. Search the forums and the wiki for the word DRBD, that will do what you need.

[zelthian]

Phoenix is right. Once an email has been stored, that's it. It's going to stay there. Let's take an example scenario:

1) Site A - call the server sitea.example.com
2) Site B - call the server siteb.example.com
3) Site A's MX record has a preference of 10, Site B's has a preference of 20
4) All mail will normally be routed to sitea.example.com, having the lower preference number
5) Site A goes down. SMTP servers can't contact sitea.example.com, so they start sending mail to siteb.example.com
6) Users get new email at their servers at siteb.example.com.

Now you have "historic" email at Site A, and new mail at Site B. This is further complicated when Site A comes back up, and mail starts getting routed back to Site A; now you have a short subset of emails sitting at Site B, which is what I think you're alluding to here. This is not an ideal scenario.

Once the emails are sitting in that second (separate) email server, getting tem back to the first email server is a hassle. You could export and re-import it, conceivably, but that's not a solution that scales well. Doing that for 10 users is annoying; doing it for 10,000 users would be time-prohibitive.

There are two ways, typically, that you can deal with a site failure in email:


Backup MX

Backup MX is what Phoenix was referring to. In this case, a simple smtp server is set up, typically by a service provider, to queue your incoming mail if your site or email server goes down. Once the site or email server is back up, the Backup MX server pushes the queued mail to your email server.

Pros: Affordable.
Cons: Typically a single-site solution. Users can't access this mail until your site/email server is back up. Bringing up a second site causes the issue described above.


DR Solution

A DR solution will bring up an email server in the second site that has the same characteristics and data set as the primary site email server in the case of a site failure. This process is generally called a failover. When the site comes back up, the email server is "failed back" to the primary site. This is a way of keeping the data and server where you want it when you need it.

Pros: Users can access data during a primary site failure.
Cons: Relatively expensive. Relatively complicated to set up.


The DR Solution is where I think you're trying to get to. Achieving it is going to cost money relative to the size of your email environment. DRBD is a host-based stretch cluster config that would be nice for small environments. Larger environments could use higher-end replication technologies to copy all the server data (including system data) and recover on the other side manually, or automate it with a different cluster solution. Virtual environments could automate with VMware SRM. Different ways to accomplish the same general task.

[LMStone]

Originally Posted by Tosin

Please help.

I have two locations A and B with ZCS installed and running at both.

Now I want to achieve a situation where I have location A have its secondary MX in location B such that when the server in location A is down, users in location A can work out of location B for that period of downtime.

Every input will be appreciated.

Why are the systems going down so frequently that you need to consider this solution?

In a situation like yours typically we suggest consolidating both office domains on one Zimbra server (or system, if you have a large number of accounts) hosted in a data center.

At each of the offices, deploy redundant, carrier-diverse Internet connectivity in failover or load-balancing mode, e.g. a DSL line plus cable modem.

At the data center, backup the Zimbra system files to a cloud so that you could use one of the office Zimbra servers for Disaster Recovery per Network Edition Disaster Recovery - Zimbra :: Wiki.

If redundant Internet isn't available at the offices, then deploy Zimbra Desktop for offline usage.

We have found that the above methodology provides higher availability and lower costs vs. trying to configure a Zimbra failover system and is much less complex than trying to use subdomains to provide Zimbra servers in each office.

Hope that helps,
Mark

[Tosin]

Thanks all. I found all responses quite informative