We're taking your advice and trying to stick with the registry instead of LDAP. We are going to play around with doing our own registry replication, where we use Windows API hooks to capture registry adds/updates/deletes and then message the changes out to the other machines. And use a file on a network drive to store changes for any machines that were offline when the changes occurred. Our programmer feels we can do this quite efficiently. And we will most likely use "sticky sessions" on our load balancer.
If that all tests out well, the only remaining issue is making sure our shared storage can be efficiently accessed by all the machines. Any advice on a good solution without spending a huge amount of money? Between 2-4 machines will need access to the data initially. Bill -----Original Message----- From: Sanford Whiteman Sent: Mon, 6 Jan 2003 02:37:52 -0500 Subject: Re[6]: [IMail Forum] Problems changing external databases 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/ 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/
