Hi
Just a quick email, while I'm having lunch..
I don't like the proposed data/scaling model at all. I cant see it
scaling that well, and will be a nightmare to provide HA.
Another issue I dont like, mysql clusters are a total nightmare to keep
running. (i have extensive experience with multimaster and galera based
mysql clusters)
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.
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
