Hey Andrew: This is fantasic information - great for our outfit who is currently testing a web farm using Application Center (to be Commerce Sever). Do you have or know of any links to MS articles that support what you have said is the new recommendation? I ask because we have setup App servers and Web servers in the traditional sense, and we would need a good justification to start over.
Thanks. -----Original Message----- From: Andrew Gayter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 6:26 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] ASP.NET and HTTP request routing in a web farm In general web farms don't employ Microsoft Component Load Balancing (CLB), or software enabled Network Load Balancing (NLB) due to the following reasons 1. The gathering of performance information is an unacceptable overhead 2. The limited number of nodes that are available in the configuration 3. Configuration and deployment 4. Software algorithms are slower than hardware ones 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. This is recommended because 1. Reduction of RPC calls between physical machines 2. Ease of security configuration 3. More available machines to serve incoming requests 4. Don't need CLB, or NLB 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. Normally the switches are configured not to maintain state i.e. are stateless, but they can also be configured for 'sticky' sessions - which means all subsequent requests from the same client are routed to the same server. This isn't recommended as it doesn't promote scalability! If state needs to be maintained between client requests consider using the DB. If this is a .NET application I wouldn't consider the ASP.NET session management, as the current implementation is poor and isn't fail safe! If you're interested it's because it uses tempdb to store information. Anyone who knows about tempdb will know it's not recoverable, nor is it part of SQL servers cluster strategy. The out-of process state engine also isn't failsafe - so if you loose either the service or the currently active SQL server - you've just lost ALL your session information!!!! 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) In your case you want a load balanced environment but want to have the ability to still target a specific machine. In the configuration above this is possible, providing your network routing doesn't re-direct requests back through the switches. Hope this helps A -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Peter Foreman Sent: 29 May 2002 08:04 To: [EMAIL PROTECTED] Subject: Re: [DOTNET] ASP.NET and HTTP request routing in a web farm To clarify a previous email: Clustering service provides: Windows 2000 Advanced Server - 2 nodes Data Center - 4 nodes .Net Servers Advanced Server - 4 nodes Data Center - 8 nodes And all do support some kind of Active/Active clustering (but I've never used it so I don't know details). Also, you will be able to build a cluster without a shared disk in .Net servers. Very clever. :-) 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. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
