Re: Hardware considerations for mail/directory
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On (2006-03-30 19:19), Maykel Moya wrote:
>
> I have to plan a deployment of a descentralized mail and directory
> system. The system should handle at least 250k and should scale to
> about 500k accounts.
>
> The mailboxes will be in a storage (NAS) attached to many front servers
> (IMAP & POP). I have to choose between:
>
> 1. HP DL360 G4 2 GB RAM 2 x Xeon or
> 2. HP DL560 G4 6 GB RAM 4 x Xeon
>
> The cost of DL560 is about five times the cost of the DL360 (last time
> I checked). I thought the best tradeoff is to maximize the server count
> so I think I'll opt for DL360s. Any comments?
This depends on how many messages-per-second you are expecting, how you break
up functionality (if you try to run everything on one box, you will need
bigger boxes), how many simultaneous POP/IMAP/webmail connections you expect,
and what sort of spam runs you get hit with...
My advice for hardware would be to look at your current hardware and
guesstimate ;) We are currently forwarding an aggregate of 45-million
and rejecting 50-million messages/week with eight servers (a collection of
old Sun Netras and 2xP3 500 Dells). Note that this is only as a
backup-mx/relay service for customers, no IMAP/POP, or complex spam/virus
filtering. This is done with Postfix (everything that can be hashed has
been):
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_rbl_client $MY_RBL_SERVER,
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_unverified_sender,
permit_mx_backup,
reject_unauth_destination,
reject
Our new hardware is probably going to be a collection of 20 Dell blade
servers, but we will be adding some additional spam/virus filtering (and
hopefully won't have to add hardware for at least two years)
> What do you recommend to do load balancing in terms of benefits/cost.
> Is it better to have some equipment (hardware) to do the balancing, or
> a software solution (HA + director) is pretty enough?
Personally, I prefer a seperate hardware load balancer: I find it easier to
keep users from doing silly things like picking a physical IP to send
everything to, when the boxes will only accept on the virtual, and then
calling to complain that they can't send/receive email (some silly sales
critter gave them the wrong IP).
It also makes maintanence more manageable. The last software-based HA
solution I used would hang/die under light load, and then we would have to go
to dozens of boxes and restart the heartbeat daemon so that they could all
resync... It has been about 4 years since I worked there, but I haven't had
similar issues with any of the hardware I've used since then
For hardware, I am most familiar with the Foundry ServerIron, but have heard
good things about Alteon and F5 (insert normal foam-at-mouth-zealot
arguements here)
> For directory, I'm thinking in 4 servers, 2 DL360s HA clustered to host
> the master LDAP and two DL560s to host two LDAP replicas. I choose
> DL560s here for the amount of RAM available. It is better here to have
> many DL360s instead of two DL560 for replicas?
If you can get 4GB+ of RAM for the DL360s, I would think that they have the
horsepower to do it, but I've not run an LDAP setup for this many clients.
Look at your current CPU and memory utilization, and then estimate from that.
The same goes for the number of simultaneous webmail/IMAP/POP connections.
If you don't have historical stats, I would suggest installing Munin (or
something similar) and then shelve this for a month. In my mind, if you
don't know what your current hardware is doing, it is hard to predict what
you need.
my $0.02
/joshua
- --
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
- Douglas Adams -
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFELZvpJr8VjiIHVH0RAt1SAJ0TE8RECqQVGFnNpieUnNo6UlI1LwCaAmBN
kcv5EH4ij0qw8/Q9wUT1Gmg=
=LcKd
-----END PGP SIGNATURE-----
Reply to: