MX fallback solution

[mangelot]

any idea's on a howto for fallback email ?
controlled out of the panel..?

[ephigenie]

shouldn't be that difficult ...
it's more a thing of replicating the postfix maps to another server so that the virtual domains & users are known to them, too.
then a second MX - entry and a few changes in the main.cf of the second(fallback) MX that should be enough, i think.

The replication can be established like some people do with bind atm. (download via cronjob & http) .

[stefan]

Has everyone a solution for that - if it is so easy can evereyone do this for us. We would like to have this - and we would pay for this.

Regards

Stefan

ephigenie Wrote:shouldn't be that difficult ...
it's more a thing of replicating the postfix maps to another server so that the virtual domains & users are known to them, too.
then a second MX - entry and a few changes in the main.cf of the second(fallback) MX that should be enough, i think.

The replication can be established like some people do with bind atm. (download via cronjob & http) .

[mangelot]

ephigenie Wrote:shouldn't be that difficult ...
it's more a thing of replicating the postfix maps to another server so that the virtual domains & users are known to them, too.
then a second MX - entry and a few changes in the main.cf of the second(fallback) MX that should be enough, i think.

The replication can be established like some people do with bind atm. (download via cronjob & http) .

I think you are suggesting to download the accounts from the secondary server?
But I was thinking of an solution on the same single ispCP server.
example:

mx10 my home ipadres
mx20 my ispcp server

when my home ip is down, the secondary mx20 will fallback the emails for the period of time mx10 is offline,
there are further no email accounts in ispCP, only the possibility of to relay/backup mail for a domain during fallback.

are I'm I talking stupid right now
I'm not so into fallback systems..
sorry for my english...

[Kermit]

mangelot Wrote:I think you are suggesting to download the accounts from the secondary server?
But I was thinking of an solution on the same single ispCP server.
example:

mx10 my home ipadres
mx20 my ispcp server

when my home ip is down, the secondary mx20 will fallback the emails for the period of time mx10 is offline,
there are further no email accounts in ispCP, only the possibility of to relay/backup mail for a domain during fallback.

are I'm I talking stupid right now
I'm not so into fallback systems..
sorry for my english...

No, you're right. Or at least what you're asking for makes sense.
This kind of architecture consists in a MX host and a so-called "Backup MX", a host that queues mail for more than 72 hours until the main host is up again.
This is quickly achieved by setting two DNS records with different priority and configuring secondary SMTP as a backup MX for all domains on it. Just a matter of writing the right conf.

@ stefan> A real fallback solution should consist in a pair of (or more) identical mailservers with a failover policy, but that's hard to achieve unless you don't put mailboxes on a common storage device (such a third host) and use the two SMTP hosts to relay mails and to check mailboxes on the third one via POP3/IMAP services. Still I really don't know how POP3/IMAP servers on the market could manage concurrent access to a shared filesystem.
Anycase the trouble with this kind of topic is how to make users access their mailboxes if the primary server is down: the only solution that solves that is (as far as I know) a single storage server for MTA's virtual users tables and mailboxes. Anycase, nobody assures you that the storage server lasts forever, so you have to have a redundancy/replication solution with load balancing... things get hard on this. Off course, they get hard until you don't have enough money to spend... in theory you could consider yourself safe with three servers: 2 MXs and 1 load balancer.
Good luck!

[ephigenie]

The easiest solution is the one i mentioned.
Nowadays a secondary mX has to know the local-parts of domains to accept only mail for valid recipients.

Of course we can think of a way to manage it in a highend solution - with shared storage, maybe a lvs director in front or some Big5 Iron to make loadbalancing between 2 or even more frontend MX's.

But for mail volumes < 5000 mails/hour there's no need to setup extra loadbalancing.
The secondary MX approach is the best thing for that.

If the primary MX is down - the secondary is automatically choosed - and the secondary is regularly testing if the primary is up - and when - all qeued mail is delivered.
This is a simple but efficient fallback solution - no mail is lost.
To acomplish redundant mail-servers we've to play with a true fallback - solution.
If anyone is interested in that and needs such a thing for its business - i'd be happy to help to achieve that but this goes far beyond that for what vhcs-omega is thought for atm.

[Kermit]

ephigenie Wrote:The secondary MX approach is the best thing for that.

I agree. My post wasn't a proposal but a deterrent panorama.

ephigenie Wrote:If anyone is interested in that and needs such a thing for its business - i'd be happy to help to achieve that

I fear a request flooding now...
Jokes apart, I think a backup MX manager should be a good point to VHCS in the future but more would be overkill atm.

[pierg75]

And what about an openmosix cluster (just two-nodes cluster) that will make everything redundant?

Pier

[ephigenie]

Do you have a openmosix capable mail - server ?

[pierg75]

ephigenie Wrote:Do you have a openmosix capable mail - server ?

Not yet, but this is what we want to do in the next months.
If i can finish this servers soon, i'd like to make a little cluster to train.

Pier