Bill, Some more thoughts on your proposed setup:
- If your LDAP implementation lets you store passwords as regular attributes (or if you chose to nominate another attribute to serve as the IMail password, unsynchronized with the actual password used for LDAP authentication), you can get much better performance than if you used LDAP in its native fashion, which requires hundreds of thousands of authenticated sessions per day. Even so, the threading will be a bear, and if you aren't plugging IMail into an inherited LDAP-centric environment (or NDS or AD), you're unlikely to get a satisfying return on your development and testing. - The performance advantages of the Registry are far more pronounced with Webmail, since it consults the userbase constantly throughout a session. If you are using POP3 and SMTP exclusively, you *may* still get away with ODBC--especially because you are spreading out the calls across servers. Remember that big, fat client/server SQL is not necessarily the fastest database technology; try CodeBase, Apollo, et al. to see how fast "old-school" databases can be. - The Registry synchronization functionality offered by Win2K AS can be used with or without full clustered storage, and is quite reliable, though one-to-one. The Vinca/Legato one-to-many options are quite worthy. In both cases, you have to set things up as if you are creating a full cluster, then "pull away" to just Registry sync. Yet if your load balancer isn't doing "sticky sessions," even a 2-second replication delay could cause you problems. The Registry sync technologies don't do true two-phase commit and therefore have a "resolution" that is not as fine as the resolution (that is, time between sessions) of busy SMTP servers. - Some are against shared storage outright, but I find it a quite reasonable choice for fault-tolerance plus the performance benefits of dedicated spool, application, swapfiles, etc. However, the fact remains that if your system is being taxed not only in outgoing volume but also in incoming volume (typically true), shared storage will eventually be limiting. - I don't think you should turn your back on IMail peering: used in conjunction with full clustering, it's a good way to be both scaleable and be fault-tolerant. We like to set up active-active clusters, where each server has, say, half the userbase, but can handle the whole userbase in an emergency. In front of the cluster, we put an auto-address-rewriting, anti-spamming, anti-virus gateway with no mailboxes on board but a big enough drive cache that all of its functions are run from RAM. -Sandy To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
