> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:squirrelmail- > [EMAIL PROTECTED] On Behalf Of email builder > Sent: Friday, May 13, 2005 1:01 AM > To: [email protected] > Subject: RE: [SM-USERS] Re: Load Balancing and session side effect >
> > work and I only say should because I personally haven't tried storing > > PHP session information on an NFS share before. There was some recent > > Then how do you share your session data between more than one web server? > You have session data in a database? I don't need to. As described below, my load balancing device sends each session to the same machine it was originally directed to based on source IP. I believe LVS calls it the Persistent Port Solution (http://www.linuxvirtualserver.org/docs/persistence.html). > > that IP as well. We use hardware layer4 switches in front of our systems > > to perform automatic load balancing, health detection and failover. The > > particular devices we use can maintain user session to one machine or > > the other, negating the need to store the PHP session information on the > > NFS box. This is essentially filling the role of the LVS and allows us > > to provide very high service availability. > > Wow, must be nice to have that kind of money. :) How does a _switch_ > know > how to maintain session data for the _application_ layer in _front_ of a > web > server?? Sounds nice anyway. :) They're intelligent switches. The ones we use are strictly layer 4 meaning we can perform intelligent actions based on source IP, source port, dest IP, dest port and protocol (TCP/UDP). There are others that look at layer 7 meaning I could redirect to different machines based on actual content in the request like a cookie for example. We've used Alteon (now Nortel) and Foundry switches for years for this purpose (and others). They really do make load balancing a breeze and can work with high traffic loads. We're currently load balancing >4000 HTTP requests/sec and ~180 mbit/sec through one of them (not SM ;) ). We also use them for SMTP, POP and IMAP load balancing. This might sound like a sales pitch but it's not. ;) It looks like you can do some of the same things with LVS which didn't exist when we started our projects. > > As far as using Perdition, it wasn't really designed to be a load > > balancer, at least when I last used it and wouldn't really be effective > > at it. Your load balancing would be determined by WHO was logging in at > > a particular time instead of how loaded a machine was. If all the users > > assigned to server 1 were logged in an none assigned to server 2 you'd > > have one box loaded and one completely idle. I would suggest that if you > > Wow, OK, thanks for clarifying. Hadn't really read up on it yet, but will > certainly do so given what you say here. Sure. Perdition is _extremely_ useful for those who need its functionality. We wouldn't have been able to easily move 36,000 email accounts from an old VMS machine to our current email system without it. Using perdition, none of the users had to change any of their mail server settings as everything 'just worked'. > > get to the point where DNS load balancing isn't sufficient for your > > needs you take the plunge and set up a Linux load balancer or purchase a > > hardware switch that'll do it for you. Life is much easier that way =) > > If you scale even further, separate your IMAP/SMTP/HTTP servers. If you > > do that, you can grow the specific service that's being utilized the > > most without having to rebuild all services for each machine. By that > > time you should be bringing in enough money that cost wouldn't be > > prohibitive. > > Yeah, that's the first thing on our list once we take the next step, so > I'm > glad to hear someone reaffirm it. Don't really like IMAP/SMTP/HTTP on the > same server but we're stuck there for now. One possibility given the > other > response today is that maybe it's OK to run just one IMAP server on our > NFS > machine where the mail spool is. Our front-end HTTP/SMTP servers would > reduce their load a bit, as long as we don't kill the NFS server.... I personally think you should stick with two of everything you can. If you have one IMAP server and it dies then your entire mail system is dead from your customers' perspective. It doesn't matter if SMTP and HTTP are working, they still can't get their mail. You're making them even more dependent on your mail system because if they're using SM as their primary e-mail client, the only way they can see any of their e-mail is if your system is up. With a desktop client using POP at least they could see historical e-mails. In a case like this, redundancy is the mantra. You don't want to appear to have unreliable services. It's also highly unlikely you'll kill your NFS server. NFS processing is almost entirely disk and bandwidth. Even with 36,000 accounts we barely push either. Not everyone logs in at the same time so we generally see 3-4 mbit/s peak with the average more like 500 kb/s. -- Marc ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click -- squirrelmail-users mailing list Posting Guidelines: http://squirrelmail.org/wiki/wiki.php?MailingListPostingGuidelines List Address: [email protected] List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id)95 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
