I wouldn't say tier-consolidation is anything unexpected. In many cases physically partitioning applications into what are considered presentation, business and data tiers is over done. Even the meaning of what are presentation and data tiers is often misunderstood. It all boils down to someone along time ago thinking presentation (that must be the web server, IIS), business (that's MTS/COM+), data (the database). This gave rise to three different physical locations, not physical processes!
We should also have a look at the two different aspects of scalability. Placing processes on separate servers of course means more CPU and memory for the application, but adds complexity with deployment, resource sharing, session management etc. A web farm deployment of a well engineered distributed application is great, as the cost vs performance is very good - look at Google.com for an example of a high performance web farm. When considering scaling up (placing more CPU and more memory in a single server and hosting all processes) the benefits are advantageous. I only have to manage single machines, no security headaches, can use sticky sessions and still have the benefits of process isolation for fault tolerance. Other benefits are that the development costs for applications targeted for this type of deployment are typically less. So, do we scale out and risk poorly designed applications not scaling in a stateless resource sharing environment. Do we add more CPU and specifically design our applications in a less componentized manor to gain better performance, reliability and reduce overall development costs? I believe that practically both solutions should be used in combination, as it's specific to the requirements of the application and licensing costs. Consider a site that has to serve internet and intranet clients, do we want both to authenticate the same way? Do we want to share out the business components, do we want different subnets. Do we want one site to have better performance than the other, can we cache data on publishing servers, is Active Directory involved etc, etc. We architect our systems different ways. In your case consider the following IIS and COM+ are shipped on the same server product .NET Servers are specifically marketed on the same machine. COM+ v1.5 objects exposed via SOAP for remote invocation require IIS The pooled model of IIS 5/6 promotes COM+ components on the same machine There is a lot more to designing and building distributed applications than blindly following the DNA model ;-) All I can say is thank goodness for .NET because finally we have the tools to make our own design and deployment decisions! Nearly, forgot. Remember to get the MS guy who sold you App Centre to buy you a drink. You probably helped him meet his targets ;-) A p.s. Can't really direct you at any papers etc. sorry. -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Bailey, Mark Sent: 29 May 2002 12:58 To: [EMAIL PROTECTED] Subject: Re: [DOTNET] ASP.NET and HTTP request routing in a web farm 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. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
