Hello,
thanks for your comments. However a few questions popped in my mind.
On 2014-02-24 15:35, admin-at-extremeshok-dot-com wrote:
Maybe do a more isolated management node (gui) with multiple
independent worker nodes (piler+searchd), which are centrally
controlled from the management node.
The worker nodes would get a map xml from the management node,
mapping what email domains they would be storing on each worker node.
It would be a good idea to provide some sort of message transport
system between the nodes (rabbitmq) in order for them to transfer
emails from one node to another.
since we deal with smtp, I'd rather replace rabbitmq with an smtp
frontend, so we don't have to introduce yet another protocol and
a way different type of technology.
So by tweaking your scheme we would have the following:
mail server -> smtp proxy (or frontend) #1 -> piler01,piler02,....
frontend #1 handles AAA.com,BBB.com,CCC.com and DDD.com, and it has a
transport
map to forward the given domain's emails to the appropriate piler node,
eg.
AAA.com -> piler01
BBB.com -> piler02
CCC.com -> piler03
DDD.com -> piler04
if piler02 were down, then the frontend would store and queue up those
messages
until piler02 comes back. Note that the smtp proxy could be installed
on the piler
worker nodes provided that piler is bound to 127.0.0.1, but in this
case you need
a more complex MX settings perhaps to push emails from the mail server
to the
appropriate piler node. So I'd recommend a single (pair) of postfix
node(s)
to store the transport map, and route messages to their destination
worker nodes.
However what happens if piler02 is vaporized? Then what if AAA.com is
so huge
that it barely fits in a single piler node? Your only choice is to
scale up (ie.
add more cpu, memory, disk to the given mode).
With such a setup you also need a http proxy to forward AAA.com users
to piler01,
BBB.com users to piler02, etc.
Janos
Now my thought:
Single Instance
==============
[master gui + piler01]
XML : AAA.com, BBB.com,CCC.com,DDD.com
Failover + scaling
=========================
[master gui + piler01] --- [slave gui + piler02]
XML : AAA.com , BBB.com | CCC.com, DDD.com
Failover + Scaling
=====================
GUI/control: [master gui] <==> [slave gui] (optional slave)
\\\\ the master gui, could be located on piler01, to allow for a
single instance
Worker nodes: [piler01] --- [piler02]---[piler03]---[piler04]
XML : AAA.com | BBB.com | CCC.com | DDD.com
Treat the worker nodes as independent nodes, ie. storage and
searchd/database is on each node.
piler01 is archive all email for AAA.com, piler02 is archiving all
email for BBB.com
Normal operation, email from AAA.com arrives, piler01 process and
archives
Infinite scaling would be possible
BBB.com was running on piler01, and then moved to piler02 to scale..
if piler02 goes offline, piler01 would know what domains belong to
piler02, and thus would accept the messages, but not process them.
Instead when piler02 comes online, it would send the messages to
piler02 via rabbitmq.
The gui/control could be entirely XML or Mysql based. easiest would
be to use mysql replication, and the slave node would be readonly,
unless it was changed to a master node.
With my way, its the easiest to scale for 1----100 nodes, you could
add HA to the gui node from the get go, or just run piler as a single
server install.
As for distributed/shared storage.. Ideal is to leave that to the
admin, one could use DAS/NAS/ceph/glusterfs
Regards
admin-at-extremeshok-dot-com
