On Tue, Apr 11, 2000 at 02:51:50PM -0400, Jeff Commando Sherwin wrote:
>
> > Is the front end SMTP server doing anything more than relaying? If it's only
> > relaying then take it out of the picture. It's only adding a point of failure
> > for you.
>
> no, the front end is not smtp relaying.... its like an f5 box, essentially
> port forwarding to one of many internal ip addresses.
Right. I don't see much point in it then for inbound SMTP. Let the DNS and
MX prefs do the job they were designed to do. IP address space isn't *that*
expensive.
> > As long as you are accepting connections for every MTA that wants to connect
> > at any given time, then there is nothing more you can do.
>
> Are you saying that it is a complete waste to have multiple queues running
> on the same box, as the load on those boxes rises?
No. I was answering your concern about SMTP having high latency and not
utilizating your 100Mb (or whatever it was).
I stand by my original comments:
> > Have all your real SMTP servers accept connections and make sure they have
> > enough qmail-smtpd concurrency (via tcpserver, which can be trivially monitored),
> > and that's it.
High latency means (relatively) low load per connection and high concurrency rates.
What I'm saying is that your inbound is likely to require more attention
focussed on you concurrency needs rather than your queue loads.
It's hard to be more specific without actually seeing your inbound profile.
If you don't know what the inbound profile will be, then we're all speculating,
and I'm doing it based on experience.
> > > If I have a seperate box for outbound messages, what are best
> > > optimizations?
> >
> > One box? I'd tend to give my outbound more redundancy than inbound. If no one
> > can send email because this box is down, the complainst will come thick and
> > fast. If inbound is down for a little while, no one tends to knows.
> >
>
> Not one seperate box, but a "model" multiple box that I can replicate.
Right. You didn't say that. You said "a seperate box". We can only respond
to the data you give.
> > It's not the media that's important, it's redundancy I'm talking about.
>
> The redundancy would be taken care of at the hardware level... I'm not
> going to worry about the disc side of things just yet. Ill get to that
> later, assuming I build a robust enough system that can handle
> compatibilty to emc/netapps/whatever i choose.
>
> >
> > What if the fibre channel breaks? What if the Netapps fails, what if
> > the disks fail? What if the scsi cable melts?
>
> these are issues of fail safe-ness on disc. Im not so concerned with that
> now as i am in handeling the traffic in a scaleable manner. the route to
> storage can change.
Sure. Your choice. I'm just giving you advice based on having done these
systems and seeing what happens. My advice is that the mailstore is the
most important and hardest bit to get right. Everything else is easy by
comparison. Good luck.
Regards.
