[TriLUG] RHEL5 mail server dreams

[Kevin Flanagan]

Cristóbal,

   Ohh multi part questions!

  There is one question first, how many users?  I know that the volume per
user is insane, but....

  A few general observations:

   - SPAM, if you are dealing with a lot of mailboxes/users, then you most
likely need to have a front end process that will make the SPAM vs. HAM
decision, and handle things.

   - Security, do you want some securemail gateway?  If your user base deals
with sensitive information then you most likely will need some way that they
can use a magic word in the subject that trigers a process to send a link to
the far end, not the actual content, then allowing the desired recipient to
come get the information in an SSL session.

  - Archive/retention, you need solid policies, specifically what you do is
not as important as doing what your policies say.  If your written policy
says destroy everything older than 30 days, then you need to be able to
prove that you are actually doing it.  Of course this is much more
applicable to publicly traded companies, but state institutions would likely
face similar scrutiny.

  - Policies and procedures, you can't just say something,you have to write
it up, socialize it, get it approved, and publicize it if you have any hope
of ever being able to enforce it.

  -   Now, for the technical part of things.

1. Hardware  --- HP servers are what I know, but IBM and maybe even Dell
have similar feature sets.
    A "real server"
  - Redundancy
     Network connections - Minimum of 2 network connections, uplinked to at
least 2 different switches.
     Power - Dual power supplies, connected to different UPS, each connected
to different circuits.
  - Performance
     RAID in hardware
        Depending on what you are doing for storage, you may not need a lot
of disks internal, but you need 3 at a minimum, Mirrored disks and a hot
spare. This may present itself as multiple disks to the OS, but it's just
for booting anyways.
  - Out of band management
     A way to get to the system remotely when it's having issues, KVM over
IP, Integrated in the server, or an additional box.  In the HP server arena
you have what's called the Intelligent Lights Out (ILO) network port.  This
provides for full remote control, BIOS prompts and all.  You can even reload
a system from a hundred miles away.

   - Storage
     Being that you are talking about a lot of volume, the performance of
the spool space is going to be very important.  There are a lot of options,
SAN, NAS, or local.  Spreading the work across multiple spindles is
important.  It's very important that you don't have two conflicting types of
IO loads on the same set of spindles.  SAN folks have a habit of thinking
that it doesn't matter, it does.

        - SAN - If you are going with SAN storage you need at least 2 Host
Bus Adapters, preferred 10GB Fibre Chanel.  Typically SAN storage hides the
spindles completely, you just have LUNs provisioned form the storage folks,
or perhaps that's yourself.     Get the SAN admins to provision each LUN
from a different pool of disks, and keep track of what you tell them the
workload is.  Mail is more likely to be a lot of small files, rather than a
database that's massive, two very different work loads.

    -  NAS - This could be presented as NFS devices, or ISCSI, although
ISCSI is often discussed as SAN storage, it's a bit of a gray area.  Same
rules apply as for SAN in most regards, but you now have network connections
rather than Fibre Chanel, not so different.  You don't want to have any
bottlenecks imposed on you by your Storage Admins no matter what the method
you use to connect to your disks.

   -  Local storage  - If you go this route you will want a large chassis,
with lots of disk bays and multiple channels to the disk controllers, say a
chassis that has groups of 4 spindles per channel would allow you to use
multiple RAID controllers, or at the least channels to get to the disks,
keep those bottlenecks to a minimum.



  Honestly the Qmail, Postfix, etc wars don't mean as much to me, that's a
whole different set of arguements.  Either of those, or most other mail
handlers will behave in much the same way at the lower levels.  I'm not well
versed enough to say the details of a Qmail configuration so I won't try to.



So, perhaps you take my part, and marry that to what someone else has to say
on the software part, move on to a design that works for you.




Kevin



On Feb 12, 2008 5:03 PM, Cristóbal Palmer <cristobalpalmer at gmail.com> wrote:

> I've been tasked with authoring a proposal for a mail server, but the
> hardware is currently doing another job and won't be available for
> several months. Consequently I have a lot of time to dream up what my
> new mail server *should* be like. Help me dream?
>
> You might ask, "What's your volume like?" Dream big. Assume that we're
> getting more mail than sane people would want to handle and that the
> hardware will always be woefully inadequate. Unless you're going to
> buy us a new server, we aren't going to get one. "Don't you have some
> hardware specs for me to work with?" you ask. I do, but I want you to
> dream, so I'm not sharing them. Tell me what an ideal mail system
> would look like if the mail volume is always going to be insane and
> you have to juggle every kind of mail service known to man.
>
> Ideal dreams are fairly complete (ie. touch on everything, not just
> eg. postfix), have your logic articulated at length, and come out of
> your own experience, not a whitepaper's. Bonus points for dreams that
> make the best use of one box + NFS home directories. Any takers?
>
> Cheers,
> --
> Cristóbal M. Palmer
> http://tinyurl.com/3apraw "They also abandoned other volumes, later,
> while fleeing from the librarians."
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/




-- 
+---------------------------------------------------+
We must favor verifiable evidence over private feeling,
otherwise we leave ourselves vulnerable to those who
would obscure the truth.  -- Richard Dawkins