Hello all,
So I wanted to double-check some of my thinking here...
I have been reading through all the posts about active/stand-by zimbra setups... looking to setup a warm redundancy server for our zimbra setup at a co-lo.
My thought... The store and index folders are all file based objects, right? Would it not be possible to rsync the index and store to a second server and either modify the mysql config for replication -or- use DRBD only for the DB and LDAP? This would suspect this could save a lot of wan traffic.
Anyone with more internal understanding know if this would work or if I am barking up the wrong tree?
Also, a side question for anyone with that kind of internal knowledge... forum searching didn't turn up any results, but can the index and store folders be placed on an NFS share?
Thanks again!
-Cheers, Peter.
Another slightly different active/stand-by question
-
Krishopper
- Outstanding Member
- Posts: 769
- Joined: Fri Sep 12, 2014 10:23 pm
Another slightly different active/stand-by question
rsync is the suggested method to migrate to a new server, so it is a valid method for replicating files.
however, if you are rsync'ing indexes, you are going to have a large bandwidth increase across your wan. Whenver a message comes in, the index(es) for that particular user are updated.
You can ignore the indexes completely, and during a failover you can re-index every single user.
Why not use iSCSI instead of NFS? You can deal with replication of the block-based file system underneath the iSCSI target using DRBD (or method of your choice), and you won't have to nit-pick about what you are replicating - you will simply get everything.
This also works great with Amazon Storage Gateway to keep remote offsite snapshots of your Zimbra system
Don't forget about your postfix queues. You may not want to lose messages in transit that haven't been delivered to the local users mailbox, or mail that is queued for outbound delivery.
Lastly, if you configure MySQL for replication, you may run into problems with upgrading if Zimbra introduces a MySQL upgrade. Since they do not support MySQL replication currently, there is no telling if an upcoming change will back you into a corner.
Another suggestion is that you can do a rsync/backup [**] of your whole system, and then replicate the redo log files. When your redo log archive becomes too big, you can do a new rsync/backup of the whole system, and continue with a fresh set of redo logs from there. Use the redo logs in your DR plan - they are a powerful tool.
this assumes you are on VMware, which is the only platform supported by AWS Storage Gateway.
[**] if possible, do a snapshot using LVM or something so you get a consistent snapshot to take a backup of. This is even more helpful if you can flush/freeze the MySQL database and filesystem during the snapshot process to ensure the whole filesystem is consistent.
however, if you are rsync'ing indexes, you are going to have a large bandwidth increase across your wan. Whenver a message comes in, the index(es) for that particular user are updated.
You can ignore the indexes completely, and during a failover you can re-index every single user.
Why not use iSCSI instead of NFS? You can deal with replication of the block-based file system underneath the iSCSI target using DRBD (or method of your choice), and you won't have to nit-pick about what you are replicating - you will simply get everything.
This also works great with Amazon Storage Gateway to keep remote offsite snapshots of your Zimbra system
Don't forget about your postfix queues. You may not want to lose messages in transit that haven't been delivered to the local users mailbox, or mail that is queued for outbound delivery.
Lastly, if you configure MySQL for replication, you may run into problems with upgrading if Zimbra introduces a MySQL upgrade. Since they do not support MySQL replication currently, there is no telling if an upcoming change will back you into a corner.
Another suggestion is that you can do a rsync/backup [**] of your whole system, and then replicate the redo log files. When your redo log archive becomes too big, you can do a new rsync/backup of the whole system, and continue with a fresh set of redo logs from there. Use the redo logs in your DR plan - they are a powerful tool.
this assumes you are on VMware, which is the only platform supported by AWS Storage Gateway.
[**] if possible, do a snapshot using LVM or something so you get a consistent snapshot to take a backup of. This is even more helpful if you can flush/freeze the MySQL database and filesystem during the snapshot process to ensure the whole filesystem is consistent.