DR/HA for Zimbra in a small business environment?

[SpecialKdkj]

We have Zimbra in a 50 user environment. We have been mandated to provide continuous access. What are our redundancy options? Here's what I see:

- we aren't running RHEL, so no cluster support (nor do I think we can afford the hardware to cluster)
- we've tried a second Zimbra install, but you can't simply duplicate data and any solutions seem fragile and "hackish" (like the heartbeat/cold server setups in the wiki and forums)

Would the best option be to run a light email server such as squirrelmail at a separate location as a lower priority on the MX and with the same accounts?

[Rich Graves]

phoenix: I'd call that a good example of fragile and "hackish."

SpecialKdkj: having tried RHEL clustering, I would call it rather fragile and hackish. You're not missing much. Even though you don't have RHEL AP, you are paying for NE, so you have proper backups and redologs, and you have a cold failover option not available to OSS-only folks in the wiki.

Unless you have the money to do it right, striving for HA and hot failover is more likely to cause downtime via complexity and sysadmin error than to avert it. Go for simplicity, and make a good DR/business continuity plan, not a HA plan. Your DR plan should include GMail, YIM, and cell phone contacts for key principals.

Make all of /opt/zimbra its own software, not hardware, RAID1, on two hot-swappable disks. Make sure you have another server chassis that will accept those hot-swappable disks. It can/should be a server that you use for other things, but make sure that you can steal it back in a pinch.

If you must have geographic diversity, mount /opt/zimbra/backup from the remote site (via FC, iSCSI, or NFS, over a VPN if necessary). Run /opt/zimbra/bin/zmbackup -i -a all frequently -- hourly might be fine, but it's up to you. Rsyncing /opt/zimbra/redolog/archive is roughly equivalent, but it adds complexity, so I'd go with zmbackup -i.

Your DR strategy for server chassis failure is to move the disks to the other chassis. Your DR strategy for complete primary site failure is to run zmrestore on the remote server.

A plan is not a plan until it's written down, and someone other than you has demonstrated an ability to follow it. Avoid anything fragile or hackish.

Also: Especially if your users are accessing the server over commodity Internet connections anyway, seriously consider outsourcing. Several partners will run Zimbra for you. If you *are* a small outsourcing provider for small business, then you have a small conflict of interest. Work on getting bigger so that you provide good HA for everyone. :-)

[SpecialKdkj]

Great in-depth feedback. I'll certainly be looking into all the options you've posed here and researching further.

Thanks again, Rich!

[Rich Graves]

phoenix: The steps described at Scripts to sync to a remote Zimbra backup machine - Zimbra :: Wiki will not work. If you run zmprov ca separately on the primary and backup, then the primary and backup will have different zimbraId's. If you subsequently restore LDAP from the primary into the secondary, then zimbraId will not map to the zimbra and mboxgroupN databases and every account will be completely broken.

The only reasponable way to get failover or backups with ZCS open-source edition is to spend a lot of money (or equivalently time) on a good SAN with solid snapshotting features. You could probably do it with Linux LVM on top of DRDB, but I'd still consider DRDB fragile and hacky.

My suggestion above assumes that you're OK with the time required to do a full recovery from backup with zmrestore -a. For just 50 accounts, that really ought not to be a problem, assuming that you have fast SCSI or SATA disks and (at least as importantly) the backup server's /opt/zimbra and /opt/zimbra/backup are on *separate* pairs of spindles (one pair software-mirrored for each). You want to be able to do mostly sequential reads from one set of disks, and mostly sequential writes to the other. If you're convinced that you can't take the recovery time hit, then look at DRBD. I'd assume that a proper SAN with asynchronous replication capabilities is *way* beyond your budget.