On Tue, Apr 11, 2000 at 04:29:23PM -0400, Jeff Commando Sherwin wrote:
> > 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.
> >
>
> its just that our current situation does not yeild me extra ip space. So I
> dont have access to it. Therefore, Im useing an f5 like situation.
Port forward the smtp traffic to a single qmail box.
The point at which you need to multiplex qmail for incoming connections
is the point at which incoming smtp traffic is overwhelming your queue.
Even two external IP addresses would allow you to RR your smtp connections
without layer 4 hardware, but that's a situation you're more in touch with
than we are.
However, you certainly don't need to RR physical boxes, just to multiple
queue's on the same box by using tcpserver.
> > What I'm saying is that your inbound is likely to require more attention
> > focussed on you concurrency needs rather than your queue loads.
Geez, I'm not sure that's true. The first problem run into by high
volume incoming SMTP folks is the point at which qmail is unable to
preprocess fast enough. That's a queue issue, not a concurrency one.
A very good solution is to feed SMTP traffic to multiple queues on the
same machine.
> I agree. But given that I may want to have multiple queues, I'm looking
> for a pointer on how to handle multiple queues, hopefully with the
> benefits and drawbacks the setup.
tcpserver lets you do this in a couple different ways. First off, you
can set up your tcpserver to load balance qmail instances by originating
IP address. This isn't that attractive unless you have specific stats
in hand on originating IPs, and are willing to constantly monitor this.
The other method is to have multiple IPs on the box, have each tcpserver
bind to a specific IP, have each tcpserver feed to a specific qmail
instance, and RR smtp traffic to the IPs via some external mechanism.
DNS is very good for the last step, but you might have to use hardware,
as you don't seem to have that option.
> Im sorry for the confusion. Given boxes that are only for outbound
> traffic, are there specific optimizations for qmail servers justy for
> outbound traffic?
When you say outbound, you mean out to the internet? But the volume
is a small fraction of the incoming? The only thing to keep is mind
is that the PC should be able to cache all it's RAM, and that RAM
dictates quite a bit of your concurrency. These days, it's tough
not to buy 128MB of ram. Does one need 256MB? Probably not, unless
you plan multiple qmail instances with high concurrency, and you're
not running into your OS's process limit.
BTW, when you're ready to scale, check out cubix for their SBC based
chassis. 8 machines in 7U! Add redundant power, a layer 4 switch,
and a multi-host RAID 1+0 to act as the queue, and you're cooking.
Hmmm... qmail inc. anyone?
John
