--- Andrew Gayter <[EMAIL PROTECTED]> wrote: > In general web farms don't employ Microsoft Component Load Balancing > (CLB), or software enabled Network Load Balancing (NLB) due to the > following reasons
I don't think you can lump these two together. CLB is very niche, because most people stick their components on the web server anyway. NLB is something altogether different from CLB. A web farm would typically employ some front end load balancing to web servers, whether it is Windows NLB or via a dedicated network device. > 2. The limited number of nodes that are available in the configuration 32 nodes per cluster on modern hardware is a pretty big farm! > 3. Configuration and deployment I don't see how NLB makes this harder. > Instead Microsoft are now actually promoting what is called tier > consolidation, which is the moving of the components (typically sat in > COM+ on different physical machines) onto the same machine as the web > server. This consolidation results in a larger number of web/application > servers. Hasn't this been the case for years? I can't think of any Microsoft designs suggesting anything different for a long, long time. > In a typical web farm requests are received from the outside through a > number of proxy/cache servers e.g. ISA. The request then hits either a > hardware layer 4 or layer 7 switch (Cisco can provide them). These > switches re-direct the request either at the IP level or HTTP - just > think OSI model. I agree that dedicated network devices are the way to go for large scale load balancing. > Between the web servers and the DB we normally have another layer of > firewalls to protect the DB. SQL Server is normally clustered to 4 nodes > in an active/passive mode - all sharing a RAID Array - best configured > to RAID 11 (one, one) Any reason to suggest 4 node over 2 node as a rule, given the expense? Peter __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
