hi zimbra folks, am extensivly testing your email system and so far i can pound it at 14,143 emails every 10 minutes and none got dropped, or corrupted. but would like to go one step beyond this.
my enterprise has about 5 thousand users throughout the world, and we are seriously evaluating zimbra. is it possible to have the following setup.
2 zimbra frontend servers
1 backend mysql ndb server (clustered)
can i tell zimbra that all the services it requires are not locally but on remote servers.
i will take the lead in getting this done, but if you can point me in the right direction as to where all the configure files that have all the pointers for mysql etc.. are i would appreciate it.
i am planning on installing the whole package on the 2 zimbra servers and then modify the code so that it uses a remote mysql ndb server.
clustered zimbra
-
- Zimbra Alumni
- Posts: 273
- Joined: Fri Sep 12, 2014 9:53 pm
clustered zimbra
Think of Zimbra mailbox server's use of mysql as an embedded database,
ie, each mailbox server has its own database instance. Contrast this
with applications that require one humongous database instance on a
remote server.
Two main advantages of the embedded-databse-per-mailbox-server
approach:
- Database scalability, wrt data size and load, is less of an issue.
Hardware is cheaper. Remember email is write heavy on the
database (more reads than writes with email, but write heavy
compared to other types of applications).
- Maintaining integrity between message files, search index, and
database becomes a problem that is local to a box, and therefore
easily managed.
The disadvantage of many mailbox instances is: database servers have
to be babied, and if you have many it's that much more work. I argue
that they have to be babied most of the time because they are huge -
for some applications you must have one database, but for mail - you
don't HAVE to.
The trend now is towards clustering, and for good reason. A cluster
where data can be paritioned is the best kind of cluster. Users are
inherently partitionable (er, a set of users are - can't partition a
single user - literally or in ZCS . So why throw a big database
instance in the mix.
That having been said, if you want to try and run Zimbra with single
database instance, a good place to start is:
- see what the zmmyinit script does to bless and initiliaze a
database - watch out for those GRANT statements - we only grant
permissions to localhost. Double check the generated my.cnf
file also.
- zmlocalconfig -e mysql_bind_address= mysql_port=
(Look in DbPool.java to see how these local config settings are
used). tomcat restart will be required - zmcontrol might not like
mysql not being there, so can not restart with that.
ie, each mailbox server has its own database instance. Contrast this
with applications that require one humongous database instance on a
remote server.
Two main advantages of the embedded-databse-per-mailbox-server
approach:
- Database scalability, wrt data size and load, is less of an issue.
Hardware is cheaper. Remember email is write heavy on the
database (more reads than writes with email, but write heavy
compared to other types of applications).
- Maintaining integrity between message files, search index, and
database becomes a problem that is local to a box, and therefore
easily managed.
The disadvantage of many mailbox instances is: database servers have
to be babied, and if you have many it's that much more work. I argue
that they have to be babied most of the time because they are huge -
for some applications you must have one database, but for mail - you
don't HAVE to.
The trend now is towards clustering, and for good reason. A cluster
where data can be paritioned is the best kind of cluster. Users are
inherently partitionable (er, a set of users are - can't partition a
single user - literally or in ZCS . So why throw a big database
instance in the mix.
That having been said, if you want to try and run Zimbra with single
database instance, a good place to start is:
- see what the zmmyinit script does to bless and initiliaze a
database - watch out for those GRANT statements - we only grant
permissions to localhost. Double check the generated my.cnf
file also.
- zmlocalconfig -e mysql_bind_address= mysql_port=
(Look in DbPool.java to see how these local config settings are
used). tomcat restart will be required - zmcontrol might not like
mysql not being there, so can not restart with that.
clustered zimbra
I'd like to also add that MySQL Cluster is a pretty new technology and a separate storage engine from InnoDB. There are a number of features that ZCS uses that are not supported on MySQL Cluster, notably foreign keys:
MySQL Cluster Limitations
We've done no testing on MySQL Cluster at this point.
Boris
MySQL Cluster Limitations
We've done no testing on MySQL Cluster at this point.
Boris
-
- Posts: 40
- Joined: Fri Sep 12, 2014 9:55 pm
clustered zimbra
I have a similar question. Is there a painless (or an efficient way, even if it's painful) way to cluster Zimbra in any way at all? I mean, if we use it for, say, 100 thousand users or 1 mi, what would be the best way to do it?
-
- Ambassador
- Posts: 4558
- Joined: Fri Sep 12, 2014 9:52 pm
clustered zimbra
[quote user="rodrigoccurvo"]I have a similar question. Is there a painless (or an efficient way, even if it's painful) way to cluster Zimbra in any way at all? I mean, if we use it for, say, 100 thousand users or 1 mi, what would be the best way to do it?[/QUOTE]
Yes. The first step is deploy standalone servers for the various services (MTA, LDAP, Mailboxes, etc). This allows you to split the user base across multiple servers. So a pool of MTA servers, a centeral LDAP server, and multiple mailbox servers each with some part of the user base. This can be done now. It's just a deployment exercise. On the mailbox server(s) just say 'N' to installing LDAP and it will prompt you for your centeral LDAP install.
Our network edition will include cluster(ie primary and failover) support for all the services. Stay tuned for more announcements here.
Yes. The first step is deploy standalone servers for the various services (MTA, LDAP, Mailboxes, etc). This allows you to split the user base across multiple servers. So a pool of MTA servers, a centeral LDAP server, and multiple mailbox servers each with some part of the user base. This can be done now. It's just a deployment exercise. On the mailbox server(s) just say 'N' to installing LDAP and it will prompt you for your centeral LDAP install.
Our network edition will include cluster(ie primary and failover) support for all the services. Stay tuned for more announcements here.