Clustering

Post by **martin** » 2006-09-20 19:30

As hMailServer 5 will most likely have some kind of support for clustering, it would be interested to hear what you would expect from it.

My view is that it should be possible to run hMailServer on a couple of computers in the same network. From the users point of view, it should not matter which server you access - you should be able to receive and send email just as normal. For incoming email, you could specify all the 4 servers as MX records in your DNS and use round-robin to balance the load on the hMailServer servers.

Perhaps this could be accomplished by simply removing some parts of the the caching in hMailServer. This way say 4 hMailServer servers could access the same database and file area. (The database server could be clustered as well to avoid a single point of failure).

^DooM^ · Post by **^DooM^** » 2006-09-21 00:47

That would be how I would implement it. That is pretty much what I did when I moved my mailserver earlier this year.

Used the same DB for both mail servers and mirrored the data directory across the 2 local networked machines.

westdam · Post by **westdam** » 2006-09-21 12:27

mmm yep martin i agree with you..

in the past i've done a little "clustering" with another mailserver with the DFS of windows2000 server and works well, ( it was a bit slow 'couse networks was 100 mbit.. )

iprat · Post by **iprat** » 2006-09-21 12:50

martin wrote:The database server could be clustered as well to avoid a single point of failure.

And what happens to the data directories ?

^DooM^ · Post by **^DooM^** » 2006-09-21 13:03

If the server is clustered with others then the data directory will be on every server.

iprat · Post by **iprat** » 2006-09-21 13:13

^DooM^ wrote:If the server is clustered with others then the data directory will be on every server.

Well that's what I was thinking, what happens if A receives a message, it stores data in database (wich is common to A and B) and then A stores the message in data directory ? Data directory is in the database server wich is visible to both ? Or will each server have it's own data directory and A will update the others data directory with an inter-server comunication (sounds redundant but...)?

I think I would prefer to have data where database was stored, but any comments are welcome

Post by **martin** » 2006-09-21 17:22

I thought about that and in the first version, I think it will be required that you have a central storage for data files.

^DooM^ · Post by **^DooM^** » 2006-09-21 18:19

I suppose another way to do it would be each server has their own data directory but share the same/clustered database. When any hmail server in the group is accessed it checks the database for any new messages. hmail then checks the database to find out on which server the relating .eml file is located. hmail could then either copy the .eml file to a temp directory of its own over the network to allow a user to download it or possibly shunt them over to the mailserver that has the email message.

If you had a lot of emails though that could be very resource hungry bouncing a user between email servers.

A central storage would be ok but that brings back a single point of failure unless hmail had the capabilities to copy the .eml files to more than one location over the network upon receiving an email. hmail would have to remove the .eml from both places as well though upon the end user receiving the email too.

A tricky thing to implement without having some sort of mirroring going on between servers.

koncept · Post by **koncept** » 2006-09-21 18:21

i dont think you would have a single point of failure if you used a raid cluster...

^DooM^ · Post by **^DooM^** » 2006-09-21 18:25

Agreed but i was thinking on a smaller scale where some users/companies have no idea or don't want to invest in setting up a raid configuration.

I guess its finding a balance within hmail to allow failover for joe bloggs who runs his personal mailserver for himself and his friends and adding the functionality for major companies who have the time/skill and resourses to setup raid configs.

Just my feelings on it

koncept · Post by **koncept** » 2006-09-21 18:30

im not sure if this is possible, but what about setting up a list of delivery locations on each server. that way if you don't wnat to enable clustering you can have the file sent to the other servers when received by one. in this setup i would recomend using a second nic & have the ability to tell hms to use x ip or x nic

^DooM^ · Post by **^DooM^** » 2006-09-21 18:34

What would be the advantage of adding a second nic aside lowering network congestion on a single nic?

koncept · Post by **koncept** » 2006-09-21 18:36

other than to keep one open for pop, smtp, imap, web and keep managment and clustering data on a separate to lower usage none that i know of...

^DooM^ · Post by **^DooM^** » 2006-09-21 18:43

I agree its a good idea but you are thinking for big companies like your own.

Maybe Martin could add all 3 functionalities.

1) proper clustering support (stacks of users big companies)

2) Simple clustering with 2 nics (for medium usage and smaller companies)

3) 'Just copy the damn file' support (for billy onemate with his pc and his laptop)

That way you keep hmail viable for everyone

aldoenviro · Post by **aldoenviro** » 2006-10-06 20:20

When dealing with clustering, is it necessary to have functionality specifically created for "billy onemate" users? Clustering isn't usually a mechanism these users want, require, or have the ability to setup. Setting up a secondary MX and using a backup schedule should create the necessary redundancy for such users. Not to mention, if a "billy onemate" user desires or needs the reliability and capacity of clustering failover and load balancing features, they really aren't a "billy onemate" user anymore. The only true way to implement clustering and have it perform the actual goals desired is by using enterprise level solutions like RAID, SAN, or NAS.

When implementing a mail clustering solution, I think it would be advantageous to only focus on the enterprise level solution. This will allow the development team to focus on the best possible performance and reliability based clustering solution. If “billy onemate” wants to use a high-end mail clustering solution, they will have to evolve their hardware to support such a solution. However, allowing users to select a wide range of data store and or SQL server technology and the locations of these servers should leave room for low cost implementations. Moving the message store to the same machine as the SQL server would effectively release the front end app from the binds of the data store. You could then create multiple front end servers connecting to a shared backend data store. It would be the job of Hmail, in this case, to manage disk access for the shared data store. Preventing other front end cluster members from accessing the same files at the same time is important. Some type of temporary flag file or file renaming should work. The data access mechanism simply needs to check for this flag file or naming convention. If it is there, it doesn’t access the file, but rather waits and retries after some random time frame. If the redundancy of a data store is not controlled by the data store hardware (RAID, mirroring, etc) then hmail could also give this feature. Users could point hmail to two separate hard drives, and hmail would perform multiple writes to each drive as changes to the data occur. A Sync process could also run that reconciles the changes and verifies the integrity of multiple drives at a configurable rate. From what I can tell, the only real obstacle that stands in the way of making Hmail cluster compatible is moving the data store from the individual servers to a shared back end or creating the extra write process to update a second, third, or tenth mirrored data store when one of the cluster members receives some activity. These additional write processes could, as mentioned before, occur on a second NIC or “internal” network making an hmail controlled mirrored data store not just for redundancy, but for increasing performance too. In all clustered environments, it seems you will need a shared SQL server. This could be of any configuration the admin desires. SQL clustering is well documented and supported. Pointing hmail to a remote SQL server isn’t hard. Maybe creating a mechanism to hang the SQL off of one NIC and the data store off of another may prove beneficial. 10.10.10.50 = data store NIC, 10.10.10.55 = SQL NIC, hmail then creates the routes to push all data traffic out the data store NIC and all the SQL traffic out the SQL NIC. This is in a pure TCP/IP environment. iSCSI, Fibre channel, or other form factors could be implemented.

aldoenviro · Post by **aldoenviro** » 2006-10-06 20:20

What do you think?

^DooM^ · Post by **^DooM^** » 2006-10-06 21:12

I agree with your sentiments that if billyboy needs to use clustering then he should lean more towards an enterprise solution. I was merely trying to keep hmail a viable option for everyone big or small which has been the case so far.

aldoenviro · Post by **aldoenviro** » 2006-10-06 21:22

With regards to clustering... It should definately be an optional install path. A standalone "all in one" install path will most likely remain the most popular method.

koncept · Post by **koncept** » 2006-10-06 22:01

well if we look at this from the point of hms 5, why not build clustering as a module that supports x y and z and can then be modified on its own later on

Post by **martin** » 2006-10-06 22:02

Sure, you wouldn't be required to run hMailServer in a cluster.

Perhaps the plugin/module support in v5 could be used, when such plugin/module support exists.

CraigHarris · Post by **CraigHarris** » 2006-10-11 21:48

Native support for clustering would be great, I think it needs to have the option to use a shared file space, and a 2nd option to maintain files on each server, mail should be copied to the other's shortly after delivery - should a message be requested which isn't yet copied over, then it is copied on-demand; the db would track which servers each message exists on .... maybe some options to not keep N copies of old/archived/large emails ... but otherwise seems to be the ideal way of achieving 100% uptime and true load balancing.

Post by **martin** » 2006-10-11 21:51

Yeah. I'm still thinking on how to implement interaction between different servers running in a cluster. I'm leaning towards using web services for the communication between the servers.

If the file server and database server is shared, this isn't neccessary. But if the two servers are supposed to be able to hand messages to eachother I think something like web services is needed.

Paulo Meireles · Post by **Paulo Meireles** » 2006-10-21 16:56

Clustering serves two very different purposes: increased reliability (active-passive, failover) and increased performance (active-active, load-balancing). We're talking about several components here, and each has its different needs which should also be addressed differently. Investing time and effort into something that won't be used is a waste.

- the "database" server, which is already separated from hMailServer, should be easy to cluster (active-passive). The database server should not be a bottleneck. Performance issues should be addressed through database tuning and better hardware.
- the "storage" server, where email messages are stored, is currently a local filesystem. Allowing it to be a remote filesystem via a share (which is easily clustered) should imply little effort. Similar to the database, it would be a single repository, active-passive cluster. With adequate hardware redundancy (RAID), clustering could be skipped altogether. Performance issues should be addressed through database tuning and better hardware. With time, this fileserver-based repository may evolve into something more refined (like a distributed message-based repository). However, my opinion is that, until the need of such beast is clearly shown to exist, replication should not be integrated into hMailServer, as there are already lots of different ways to do that (some synchronous, some asynchronous); it would be reinventing the wheel and making the solution unnecessarily complex.
- the "SMTP" server is part of hMailServer. MX records already provide a simple active-passive failover mechanism, alleviating the need of clustering. I can't imagine hMailServer running on an environment where adequate hardware can't solve performance problems, so I see no need for a complex active-active SMTP cluster solution to be implemented.
However, an active-passive cluster should be feasible, for cases when several public IPs are not available.
- the "POP3/IMAP" is also part of hMailServer, and IMAP server is a resource hog. It definitely needs clustering - active-active if possible - which would provide both redundancy and load-balancing.
- active-active clusters of webmail servers could also be implemented on their own machines, interacting with the SMTP and POP3/IMAP servers.

With functionality comes complexity, and the installer should be made smarter, allowing several install types (maybe something like "single server", "dual server", "multiple server").
The services should also be easy to migrate from server to server, eventually at install time, with server configuration residing on a central location - maybe on the database.

Just my €0.02 ... Ok, I may have exceeded it a bit...

Paulo

CraigHarris · Post by **CraigHarris** » 2006-10-21 17:25

The XML processing overhead of web services will dent the perfomance ... but they are a very flexible and interoperable choice .... I think that for hMail -> hMail communication an optimised binary protocol would be prefered ..... though XML web services would be easier for multi-site synchronisation.

I'm thinking that the overhead of putting emails into database is going to be worthwhile to simplify the hMail clustering architecture.

Thing is, can we truely cluster MySQL without buying the commercial versions?

mbreitba · Post by **mbreitba** » 2006-10-21 18:00

Paulo Meireles wrote: I can't imagine hMailServer running on an environment where adequate hardware can't solve performance problems, so I see no need for a complex active-active SMTP cluster solution to be implemented.

Why could you not envision an environment where adequate hardware wouldn't solve the problem? How many domains/email accounts do you think it would take to overwhelm a high end server?

Paulo Meireles · Post by **Paulo Meireles** » 2006-10-21 18:33

My quote above is specific to the SMTP service. I believe hMailServer - running just SMTP, with other functionality (POP3/IMAP/storage) on other servers - is still not ready to run email servers that would choke a 4-way quad-core server (16 cores) with two bonds of four gigabit NICs each, one bond for SMTP and the other connected to the message storage. When time comes, if hMailServer reaches that (very narrow) market, I bet Martin will have contracted a horde of programmers to help him do whatever is needed to achieve it...

Paulo

CraigHarris · Post by **CraigHarris** » 2006-10-21 18:36

I'd much rather have a cluster of 4 cheap servers than 1 damn expensive server.

No one would be forced to use the clustering features, but having them available is a big bonus.

Paulo Meireles · Post by **Paulo Meireles** » 2006-10-21 18:57

CraigHarris wrote:I'd much rather have a cluster of 4 cheap servers than 1 damn expensive server.

I absolutely agree with you. However, it seems I wasn't very clear earlier, so here's my rationale:

After splitting hMailServer into several self-contained services, we can run the same workload (whichever it is) on several lower-end servers instead of a big server. The next step - providing redundancy for each of these services - can now be taken by treating each service differently, according to its own needs.

As a pure SMTP server does not store messages - it relies on another server to do it - its potencial bottlenecks are CPU and network I/O. Having two or three SMTP servers for redundancy, and relying on MX records for failover, is essencially an active-passive cluster, where only one server will be receiving SMTP traffic in any given moment, which does not provide load-balancing.

If an hypothetical low-end SMTP server cannot cope with all your SMTP traffic (which would be astounding), my guess is that it would be better/cheaper to upgrade the hardware before implementing stuff like active-active SMTP clusters, which is not trivial.

My ultimate argument is that a low-end server today is so powerful that it can cope with an enormous amount of email, so if you get more email than you can process with a low-end server - and you can pay for all that bandwidth - I'm sure you have enough money to invest on some decent servers.

Paulo

Post by **martin** » 2006-10-21 19:02

and you can pay for all that bandwidth - I'm sure you have enough money to invest on some decent servers.

Minor note: This probably depends on where you live. Here in Sweden my 100Mbit (duplex) internet connection costs $25 / month. The bandwidth is much cheaper than the hardware required to fill it..

Paulo Meireles · Post by **Paulo Meireles** » 2006-10-21 19:08

martin wrote:
and you can pay for all that bandwidth - I'm sure you have enough money to invest on some decent servers.
Minor note: This probably depends on where you live. Here in Sweden my 100Mbit (duplex) internet connection costs $25 / month. The bandwidth is much cheaper than the hardware required to fill it..

Ok... got your point now. I'm paying 40€/month for a 2Mbit/s ADSL line with no traffic limits.

I bet everyone is envying you now, Martin!

Even then, any dual-core machine should allow wirespeed SMTP service on a 100MBit/s interface. And if you get this kind of traffic, you'll need to store it somewhere; but I digress. You all got my point by now, and I'm sure everyone has a calculator...

Paulo

Post by **martin** » 2006-10-21 19:11

Even then, any dual-core machine should allow wirespeed SMTP service on a 100MBit/s interface.

It could? That must be assuming that you have good disks. My dual-core computer starts to lag down when I create several hundred files per second..

CraigHarris · Post by **CraigHarris** » 2006-10-21 19:12

My home connection in the UK is 7MBit downstream, 380KBit upstream for £35 a month.
My main web/mail server is also in the UK, but it's on a 100MBit full duplex connection in a datacentre and 2 terrabytes a month of bandwidth costs £45 ... I intend to have a cluster in that datacentre within a year .... backup MX records will continue to go to a US-based server which then forwards them to my UK servers when it can.

Now, ideally I need the hMail instances running on each of those to keep synchronised with each other ... this isn't yet possible, but something I'm hopeing to do in the future --- the nearest I get at the moment is by running scheduled IMAPCopy's --- but that's very inefficient.

Paulo Meireles · Post by **Paulo Meireles** » 2006-10-21 19:17

martin wrote:
Even then, any dual-core machine should allow wirespeed SMTP service on a 100MBit/s interface.
It could? That must be assuming that you have good disks. My dual-core computer starts to lag down when I create several hundred files per second..

I'm talking strictly about the SMTP service, assuming that it runs alone on a server and that it stores the messages on some other server (what I called the "storage server"), not locally as it is now. If that other server cannot cope with the traffic, the bottleneck is not the SMTP server, and this was my point from the beginning: as I see it, it's much more likely that the whole email system's bottleneck to be the storage component than the SMTP servers; that's why I said I could hardly conceive a system where the SMTP server itself would be overloaded.

Paulo

Paulo Meireles · Post by **Paulo Meireles** » 2006-10-21 19:21

CraigHarris wrote:Now, ideally I need the hMail instances running on each of those to keep synchronised with each other ... this isn't yet possible, but something I'm hopeing to do in the future --- the nearest I get at the moment is by running scheduled IMAPCopy's --- but that's very inefficient.

If you have some money to burn, take a look at DoubleTake: http://www.sunbelt-software.com/Double-Take.cfm
It provides real-time file-based replication between Windows servers.

Paulo

Post by **martin** » 2006-10-21 19:33

If POP3/IMAP is made clusterable, I would probably have to spend more time if I wanted SMTP not to be clusterable compared to making it clusterable. As you say, all the SMTP-part does is to receive the email and store it on disk.

(Btw, you can already configure hMailServer to store files on a separate disk, for example a shared folder. Guess you know it but a post in this thread indicated that you didn't)

Paulo Meireles · Post by **Paulo Meireles** » 2006-10-22 04:35

martin wrote:If POP3/IMAP is made clusterable, I would probably have to spend more time if I wanted SMTP not to be clusterable compared to making it clusterable. As you say, all the SMTP-part does is to receive the email and store it on disk.

I was thinking about an active-active SMTP cluster, with all nodes sending and receiving messages simultaneously, which I suppose would be a bit invoving. Of course that, if by "clusterable" you just mean the active-passive cluster provided by MSCS, taking SMTP out of it would mean additional - and wasted - effort...

martin wrote:(Btw, you can already configure hMailServer to store files on a separate disk, for example a shared folder. Guess you know it but a post in this thread indicated that you didn't)

No, you're right, I didn't know about that! So, it's already possible to provide the message store some additional resilience. Pretty neat! You spoil us with features!

Paulo

g0yjs0 · Post by **g0yjs0** » 2006-10-22 18:20

I stumbled on this file synchronizer the other day. It works on both Linux and Windows, and I believe it's open source. Might be worth looking at for ideas.

Unison File Synchronizer

nebo · Post by **nebo** » 2006-11-25 22:20

Hi all,

Just want some clarification to the "caching" issue in hMailserver. Picture the following scenario:

- two servers running hMailserver, both serving as MX, SMTP, POP hosts för the same domain, evenly distributed load
- they share the same data store (mail files), via network share och cluster service
- individual SQL databases, but accounts are kept in sync (push/pull) by sql-replication, virtually meaning they have the same database

As I understand from previous postings this setup could work, for SMTP and POP3 as long as IMAP isnt used? Since IMAP messages are "cached" by each server respectively? Correct? Or does it only apply when the mails are stored in the database? Any other drawbacks to this attempt at load balancing/failover setup?

Does the script event system have any issues when the data store is shared? Any chance of events being fired multiple times when temp-files (mails in delivery) are seen by both servers?

Slug · Post by **Slug** » 2006-11-26 12:36

martin wrote:Here in Sweden my 100Mbit (duplex) internet connection costs $25 / month.

Are you kidding me ....... Here in Australia for that you would be charged many thousands of dollars per month .... I'm on a 512k/128 plan for $50 a month ..... bastards

Michael

^DooM^ · Post by **^DooM^** » 2006-11-26 13:23

I'm on 8mbit down / 448kbit up for £35 a month. I think I may emigrate to Sweden

g0yjs0 · Post by **g0yjs0** » 2006-11-26 15:54

cable modem: 4Mbps down/256k up for US$45/mo.
Switching to DSL soon: 4Mbps down/892 up for US$35 with a bundle of services.

Definitely envious of Martin's connection. One day they'll get it right here in the states.

Post by **martin** » 2006-11-26 17:18

Haha, live is unfair

nebo:
No. Message lists are cached, and that also applies when using POP3. In hMailServer 4.4 I've added an option to make it possible to turn off folder and message list caching.

nebo · Post by **nebo** » 2006-11-26 19:03

Too bad, that makes failover/clustering virtually impossible then?

Is 4.4 far away? Maybe you could make a 4.3 B249, with just this option added? Or is it very complex?

Post by **martin** » 2006-11-26 19:31

Depends on how you configure the failover and what type of clustering you're using. If you just start the secondary hMailServer service when the first one fails, you have one type of failover. And it's possible to run several parallel severs hosting the same domain but different accounts.

Hmm, I won't add it to 4.3. It wouldn't make any sense to have several different 4.3 versions out. That would just be extremely confusing.

Do you actually need this functionality or are you just guessing? Clustering for example? Are you sure that the performance of one hMailServer server isn't enough? There's a lot of users hosting thousands of accounts on a single server and that works fine.

As for 4.4, I don't give any dates since I'll probably just break them anyway, but the features have been implemented. The remaining things are adding workarounds to avoid Outlook issues and testing.

nebo · Post by **nebo** » 2006-11-26 20:55

Hi Martin,

As far as performance is concerned I havent tested the absolute limits of a single hMailServer instance but so far im really impressed and im sure that if you throw in enough hardware the performance will not be an issue. What Im after is some form of redundancy/failover where one could make an MX-farm and be able to add X number of servers as load increases. And also, as far as possible, eliminate single points of failure. The system im maintaining currently has over ten thousand accounts, so both performance and failover are crucial.

ATM the POP/IMAP list caching seems to be the only obstacle to being able to achieve this kind of setup.

Its really nice to hear that this feature has already been implemented! Would it be possible to try this any time soon? Maybe an alpha? If its only down to the "IMAP idle" issue its okay with me since im currently only interested in SMTP/POP.

Post by **martin** » 2006-11-26 21:04

There will probably be an alpha sometime next week. But the time I have available for this project goes up and down a lot so it's hard to be sure...

^DooM^ · Post by **^DooM^** » 2006-11-26 21:07

Hey Nebo, You may wan't to read this post

http://www.hmailserver.com/forum/viewtopic.php?t=6193

It won't help with clustering but it shows just how versatile hmail is under heavy load.

DogmanDave · Post by **DogmanDave** » 2022-03-12 11:46

Hi,

My solution (untested) for an hMailServer cluster within the same LAN is as follows:

1. Setup a Windows server cluster using Server 2019 Data Center with 3 or more nodes
2. Setup Storage Spaces Direct across the nodes to create the cluster shared volume to be used for the data directory
3. Setup a MySQL cluster across the nodes for the hMailServer database
4. Install hMailServer on every node using the shared volume data directory and IP of the MySQL cluster for the database

Then users just point their mail clients to the IP of the server cluster which is a virtual IP and then Windows handles which node to send the request to but as each instance is accessing the same data, it doesn't matter which node your directed to and hMailServer and the user doesn't need to know and each user is effectively "bound" to whatever node they first connect with as long as that node doesn't go down during the session.

This means you only have one IP for your mail server - that of the Windows cluster. The replication and failover is handled by Windows and S2D and you have hardware and software failover. Any server goers offline and the rest take up the slack. As your using S2D rather than a simple shared folder, there are no issues with sharing permissions if 2 nodes access the same data files at exactly the same time.

If using this configuration, there's no need for hMailServer to make any updates or changes to handle clustering as Windows Server Clustering and MySQL would do the work HOWEVER, one big reason to add clustering support directly to hMailServer app would be to cluster servers at different sites or on different public IP addresses incase of an internet failure and then you would need multiple MX records in DNS and so forth but this isn't what I am trying to do in this project.

I might be wrong in my assumptions here as I haven't tested it (working on it as I write this) - by all means I welcome constructive feedback on my plans - there are likely a lot of issues I haven't taken into account - please let me know if you think of any.

Dravion · Post by **Dravion** » 2022-03-12 14:40

Hi DogmanDave and Welcome to the Forum

DogmanDave wrote: ↑
2022-03-12 11:46
My solution (untested) for an hMailServer cluster within the same LAN is as follows:

Interesting Idea but i think this Debatte is better located in the Feature request Forum because it's not really a Development specific topic.

1. Setup a Windows server cluster using Server 2019 Data Center with 3 or more nodes
2. Setup Storage Spaces Direct across the nodes to create the cluster shared volume to be used for the data directory
3. Setup a MySQL cluster across the nodes for the hMailServer database
4. Install hMailServer on every node using the shared volume data directory and IP of the MySQL cluster for the database

A few thought's on this one.
Windows Datacenter Server with Clustering Option has a big price tag (according to this (https://www.microsoft.com/en-us/windows-server/pricing)
It's roughly $6,155 per 1 Windows Server Datacenter License (Standard $1069 and Essential $501). So if you setup 3 Datacenter Boxes or VM's
if will cost you 18.465 US Dollars (or the equivalent in your local currency). MySQL Cluster can be used without costs.

Then users just point their mail clients to the IP of the server cluster which is a virtual IP and then Windows handles which node to send the request to but as each instance is accessing the same data, it doesn't matter which node your directed to and hMailServer and the user doesn't need to know and each user is effectively "bound" to whatever node they first connect with as long as that node doesn't go down during the session.

This isn't very practical and raises a few problems. If you run your Now day Email clients on a unencrypted Connection you will get Warnings or permanent Warnings.
To solve the issue you have to click away any of the Warnings or you have to setup a valid SSL-Certificate for your hMailServer from a Certificate Company your EMail
Clients trust (Trusted Root Authority). This can be for example let's encrypt (no costs) or a cheap or expansive SSL-Certificate from a Third party. so your Email Client's
doesn't show Warnings to the User. So, you need a DNS-Server running, map your ip address to your mx record, to your imap and/or pop3 DNS A records. You also
maybe want to setup autodiscover / or autoconfig so Users can setup new Email accounts Office wide without Problems themselves.

This means you only have one IP for your mail server - that of the Windows cluster. The replication and failover is handled by Windows and S2D and you have hardware and software failover. Any server goers offline and the rest take up the slack. As your using S2D rather than a simple shared folder, there are no issues with sharing permissions if 2 nodes access the same data files at exactly the same time.

It can be done this way, but you have to issue the same DNS SSL/TLS Configurations for your nodes as well as if it would be if it runs in a single instance.
Plus if the node has a failure, the Connection to the MUA (Email program the User is using) will be dropped, so there is no instant failover possible with such a configuration.

If using this configuration, there's no need for hMailServer to make any updates or changes to handle clustering as Windows Server Clustering and MySQL would do the work HOWEVER, one big reason to add clustering support directly to hMailServer app would be to cluster servers at different sites or on different public IP addresses incase of an internet failure and then you would need multiple MX records in DNS and so forth but this isn't what I am trying to do in this project.

Yeah, but you keep in mind only a portion of the Email Data hMailServer maintains is saved in the SQL-Database. The most Data are saved in C:\Program Files (x86)\hMailServer\Data\*.*
(or where ever your hMailServer Data folder is located) as plain text *.eml files. The Attachements (PDF's, JPG's etc) are encoded as Base64 binary values directly into the *.eml files.

So you have to take care to mirror the Data folder among all 3 Nodes of your configuration, which can be a bit difficult. I think the OpenSource tool Rsync can help with this Problem efficiently

PS: I you have not a lot of physical Hardware to experiment, you can use Oracle Open Source VM Tool Virtualbox which allows you to setup virtual Networks in which multiple
Virtualbox VM's can act as your nodes, should be ok for testing and experimenting.

shuston · Post by **shuston** » 2022-07-15 20:50

I don't have a dog in this fight as I only run hMailserver as a store-and-forward SMTP relay for automated or user-stimulated backend processes. I do have a redundant pair (VMs on different servers), but they are not clustered as I do not need to share any data between them and I do have a load balancer farm to manage which box gets SMTP (internal-only) connections.

Dravion wrote: ↑
2022-03-12 14:40

1. Setup a Windows server cluster using Server 2019 Data Center with 3 or more nodes
2. Setup Storage Spaces Direct across the nodes to create the cluster shared volume to be used for the data directory
3. Setup a MySQL cluster across the nodes for the hMailServer database
4. Install hMailServer on every node using the shared volume data directory and IP of the MySQL cluster for the database
A few thought's on this one.
Windows Datacenter Server with Clustering Option has a big price tag (according to this (https://www.microsoft.com/en-us/windows-server/pricing)
It's roughly $6,155 per 1 Windows Server Datacenter License (Standard $1069 and Essential $501). So if you setup 3 Datacenter Boxes or VM's
if will cost you 18.465 US Dollars (or the equivalent in your local currency). MySQL Cluster can be used without costs.

Datacenter is not needed for Failover Clustering, just Standard. https://docs.microsoft.com/en-us/window ... erver-2022
Datacenter is needed for Storage Spaces Direct which is not the only option for shared storage for a cluster. If you're running a production environment you probably already have a highly available, redundant storage you can leverage. If not, you're probably not a candidate for this anyway.

Dravion wrote: ↑
2022-03-12 14:40

If using this configuration, there's no need for hMailServer to make any updates or changes to handle clustering as Windows Server Clustering and MySQL would do the work HOWEVER, one big reason to add clustering support directly to hMailServer app would be to cluster servers at different sites or on different public IP addresses incase of an internet failure and then you would need multiple MX records in DNS and so forth but this isn't what I am trying to do in this project.
Yeah, but you keep in mind only a portion of the Email Data hMailServer maintains is saved in the SQL-Database. The most Data are saved in C:\Program Files (x86)\hMailServer\Data\*.*
(or where ever your hMailServer Data folder is located) as plain text *.eml files. The Attachements (PDF's, JPG's etc) are encoded as Base64 binary values directly into the *.eml files.

So you have to take care to mirror the Data folder among all 3 Nodes of your configuration, which can be a bit difficult. I think the OpenSource tool Rsync can help with this Problem efficiently

I've never installed hMailserver to C:\ but in a cluster I probably would, then just move the \Data (and maybe others?) folder to the shared drive (e.g. X:\hMailServer\Data) and make a hardlink from C:\Program Files\hMailServer\Data to location (e.g. X:\hMailserver\Data) How hMailserver updates work is the thing to thoroughly understand in this process.

BTW: I've done this (hardlink folders) with a number of applications which are not generally designed for WSFC. Works great.

I've also set up a number of more 'nix'ish "clustered" applications using CARP, HSRP, VRRP. Those don't tend to be applications with a large amount of storage to share and have no "shared" data, just configuration and state synchronization.

Clustering

Clustering

Re: Clustering

Re: Clustering

Re: Clustering

Re: Clustering