If you have very heavy loads on your system, or you feel the need to upsize your solution you can consider to split your install. Either by dividing the users on two servers, or dividing the services on separate servers. By separating the services mx-inbound, and smtp-host for your users, you divide the traffic. By splitting the user base on two separate servers only half your user base will be impacted in the case of a failure. When putting the mail-directories on a share you get overhead that is unneccessary, plus the possibility of a single point of failure - which you also do not need.

Mercury is file based - by keeping a nightly copy of an empty Mercury configuration file/directory tree (meaning all config files, but not cnm files - ie the actual e-mails) you can jump start Mercury from last night onto another computer within 60-seconds in the event of a hardware failure. If you also use redundant MX-hosts, with Petr J.'s daemons, you will receive e-mails at all times.

Most important is the entire chain of dependencies, from actual cabling, power-supplies, grounding, cooling, IP-numbers, to DNS configurations, firewall rules, software setups, file placement etc that you need to analyze - any single point of failure that can occur is likely to occure one day. The only thing that counts is how long it takes to be back up and running again, and from that standpoint you should make your analysis and foundation for redundance decisions.

Good luck with your investigations, and please let us know your findings.

Hello,

I like to build a reduntant Mercury/32 enviroment with 2 Servers.

What's good practice to do this?

Thanks :)

Uhm, a few possible solutions:

1) Use Microsoft Clustering. Install Mercury on a virtual node. Only 1 installation of Mercury necessary. For best results, run Mercury as a service

2) Use Microsoft Network Load Balancing (NLB). Deploy Mercury on multiple servers. Put the mail box store on a shared location, accessible for each server. Connect to a Mercury system through the virtual cluster node name/ip number

3) Active-Passive configuration. Deploy Mercury on multiple servers. Put the mail box store on a shared location, accessible for each server. Only one server is active. When that server fails, use DNS to switch host ip numbers and/or MX records to point to the passive server which will become the active server.

4) Active-Active configuration. Deploy Mercury on multiple servers. Put the mail box store on a shared location, accessible for each server. You might even have multiple MX host records to define preference levels. Use DNS to define a single host name and multiple ip numbers

The problem with 2-4 is to keep the Mercury config in sync on each server. This could be scripted though. I have tested most of these configurations, they will work for you. There's an extra challenge if you also use applications like Spamhalter or Graywall, which keep their own local database. Data will probably be lost when synchronizing from a single source. I suppose a procedure could be developed (perhaps in cooperation with Lukas Gebauer) to extract data from these databases and import them into the database on the source server. This database then could be synchronized.

Which type of shared location did you use on your tests?

Did you use iScsi  or simple windows share?

Greetings