Home > Articles > Programming > Windows Programming

Web Farms: Availability and Scalability

Scalability and availability go hand in hand in Web farms that use .NET enterprise servers. By understanding these technologies, you have a roadmap for making the tough choices at each tier. Explore these choices and their challenges.
This chapter is from the book

In this chapter

  • Understanding Availability
  • Understanding Scalability
  • Scaling a Web Farm

Availability and scalability are the two most important concepts to understand when planning a Web farm using .NET enterprise servers. Success of an online business is dependent on a site's capability to meet the needs of a customer when that customer first browses the site. If a customer's initial experience is met with site unavailable messages and slow response times, confidence is decreased, no money exchanges hands, and return visits are unlikely. While not the direct concern of the administrator, any business owner will eventually demand that the site be highly available and perform well. Success in this area requires a thorough understanding of how the .NET platform handles scalability and availability.

The goals of this chapter are to help you

  • Understand the concept of availability as it relates to a Web farm. Concepts introduced include the availability rating as it relates to the network, servers, and applications in a Web farm. Using the availability rating as a metric for success in a Web farm is also covered.

  • Understand the concept of scalability as it relates to a Web farm. How scaling helps handle increased user load is covered, along with using scale to become a Web farm.

  • Understand the techniques used in scaling a Web farm to handle increased user load. Network load balancing, hardware load balancing, component load balancing, and Windows Server clusters are all introduced as means to achieve scalability and availability in a Web farm.

Understanding Availability

When a user browses to a Web site and encounters any error or unexpected message, this results in a perception problem. This is equivalent to a customer walking into a store and finding all the employees in disarray and nothing getting done. Offline businesses have expected hours for business operations. For online businesses, operating hours are 24 hours a day. The expectation is for an online business to accept money whenever a transaction is executed. This capability to accept transactions 24 hours a day is called availability.

When a site is unavailable, it is said to have taken an availability "hit." When a site takes an availability hit, it is said to be "down." It is helpful to divide availability hits into two categories: scheduled and unscheduled downtime.

Unscheduled downtime is any time that site availability is affected except during scheduled maintenance, upgrades, new software releases, or other planned outages.

The Dot9s Scale

Availability is a ratio of the uptime of a site to unscheduled downtime over a given time period. This is referred to as the "dot9s" scale. A site is given an availability rating such as .9, which is "one nine," or .9999, which is "four nines." A "four nine" site is 99.9999% available. The formula for calculating this ratio is 100 – (Unscheduled Downtime/Period of Time)x100. For example, if a site is down for one hour in a day, the availability of that site in one day is 100 – (1/24)x 100 = 95.83333%. If a site is down one hour in a week, the availability is 100 – (60/10080) x 100 = 99.404%.

Is 100% Availability Realistic?

For a Web farm to obtain 100% availability, it cannot have unscheduled downtime. This should always be the goal of any Web farm, but it is unlikely. From the availability formula, a "four nine" site can have 31.536 seconds of downtime in a year, long enough to replace a network cable! This availability comes at considerable cost in redundant systems, and most businesses accept one or two nines as the goal. Table 3.1 shows some availability measurements.

Table 3.1 Availability Measurements

Percent Available

Downtime Per Year


36.5 Days


18.25 Days


7.3 Days


3.65 Days


8.76 Hours


52.56 Minutes


315 Seconds


31.5 Seconds

Assessing a Web Farm's Availability

Availability measurements are useful only if an organization uses them properly. A successful strategy for considering availability statistics is to break the measurements into categories. These categories will differ for each Web farm, but basic categories include server availability, application availability, and network availability.

The disjointed nature of these categories means each measurement can be considered separately. This separation provides hard numbers for where money and resources should be spent to improve availability. If network availability is low, it doesn't make sense to invest time and effort in solving application availability problems.

All complex systems fail. Any failure can affect a Web farm's availability rating if the failure has no contingency. Realistic availability goals are achievable through redundancy. Redundancy is the first line of defense for any site failure. In hardware systems, redundancy comes from complete copies of critical components. For example, a system with a redundant CPU has a spare CPU that is not used unless the primary CPU fails. If this failure occurs, the spare CPU takes over, enabling the system to continue processing without missing an instruction. With software systems like SQL Server 2000, redundancy comes from a cluster of servers, each capable of owning the database of the others. Redundancy eliminates single points of failure in complex systems. Each availability area has different ways to solve this problem.

Monitoring is the final step in assessing the availability of a Web farm. Without monitoring, it is not possible to determine when a component fails. Each area of a Web farm has different methodologies for error reporting.

Understanding Network Availability

The majority of network systems in a Web farm are physical. When building a network for high availability, redundancy must be considered at every level. Every point in the network should have a backup. From the connection, to the Internet, to the routers that move traffic throughout the farm, each level must be considered. Not every system in a Web farm network has to be redundant, however, and a cost-benefit analysis is the best way to determine at which points to build in redundancy.

For example, Foo.com has a front-end router that handles traffic from the Internet. If this router fails, the site is down. However, router failures are rare, and Foo.com decides to take a calculated risk and not have a cold spare sitting unused. A four-hour response time agreement with the router manufacturer is Foo.com's reason why they accept this downtime if it occurs. However, Foo.com decides that having redundant connections to the Internet is important, so they spend the extra money to have two connections to the Internet at all times. Each business will make the same decisions differently.

The most common area of failure in any network system is at the cable level. It is usually cost prohibitive to have redundant network cables between every point in a network. Luckily, it is relatively easy to diagnose and replace a faulty cable in a network.

Vendor-specific tools best handle monitoring the network for failures. There are tools that exist today that take the pulse of the entire network, ensuring that each connection is functioning correctly. When a failure does occur, these tools can alert an administrator to the problem.


More information for building Web farm networks is found in Chapter 4, "Planning a Web Farm Network."

Understanding Server Availability

Single points of failure in server hardware include CPUs, hard drives, motherboards, and network cards. Hardware redundancy is purely a cost issue. Available on the market today for a price are servers that have three levels of redundancy for every internal system. Some businesses will invest considerable dollars to achieve complete hardware redundancy.

With .NET enterprise servers it is possible to create redundant configurations without the need for extreme hardware redundancy. The .NET platform eliminates single points of failure by providing simple software solutions so that multiple servers can handle the same task. With .NET, an administrator can designate two or more servers to provide redundancy and increased availability at the server level. This availability creates a natural pathway to scalability for a Web farm.

Monitoring server availability is best accomplished with the server vendor's tools. As part of the decision to standardize on a particular hardware platform, the monitoring software available should be a factor in the decision. These centralized monitoring tools can inform an administrator when any critical component of a server fails, from the CPU to the power supply. Without tools like this, monitoring for hardware failures is a crapshoot. If the drivers for a piece of hardware log errors to the NT event log, then tools like Microsoft Health Monitor can provide an alert. Watching the NT event log with Health Monitor is a way to alert on failures in redundant software systems like Windows Cluster Server and network load balancing.


More Information on Health Monitor is available in Chapter 14, " Monitoring a Web Farm with Application Center 2000."

Understanding Application Availability

A more subtle aspect of building highly available systems is application availability. Application availability measures how the functions and features of a specific application perform throughout the Web site lifecycle. By gauging application availability, actual uptime is measurable. If any functional portion of a site, such as credit card authorization, must function to complete a transaction, then that portion's availability affects the overall site availability measurement. Even if the Web site itself is successfully providing content, if a transaction fails at any point, the site is unavailable.

By considering application availability, a new type of thinking emerges for application design. While load-balancing techniques help eliminate single points of failure in physical systems, software single points of failure are a more difficult problem to solve. With the credit card example, the application must be robust enough to continue the transaction either by deferring credit card authorization or switching to a different credit card service. Availability planning for credit card processing must consider redundant connections to a lending institution and load-balanced redundancy for credit card processing servers, and it must also provide service-level redundancy.

Building software systems that have this level of redundancy is a unique challenge. Each application will have different requirements. However, at the fundamental design level there are a few key points to consider when orchestrating an application availability solution.

  • Create software systems with well-defined boundaries. This means that in the credit card example it should be fairly easy to tell when an application has entered the credit card processing engine. This enables an application to drop in a different system as long as the boundaries into that system look the same.

  • When an application data path leaves the boundaries of a Web farm, this process is a good candidate for application availability. For instance, if an application makes a WAN connection to an external bank, this connection is by definition not under the control and management of the IT staff that manages the Web farm. In situations like this, alternative mechanisms from the Network layer to the Application layer should be thought through to provide the highest level of redundancy. This may mean purchasing a second WAN connection of a lesser speed and cost and having an agreement for credit card processing with a second bank.

  • For transaction-oriented systems, build into the architecture a way to move to a batch-oriented processing engine. This means that in the credit-card example the same information would be gathered to process a credit card authorization, it would just not happen in real-time. The functionality of an application would be decreased in batch mode, but at least the transaction could be completed at a later time. It is much better to switch to batch-oriented processing than tell a customer to come back later. Later may never come.

The most complicated monitoring problem is application availability monitoring. Many applications rely on customer input to determine when critical systems fail. Beyond this, most monitoring endeavors for applications are custom built. Critical application components should add time in a delivery schedule to build and implement the appropriate monitoring. In some cases, there are tools that generate replay scripts that can simulate a user on a Web site. These tools can be used to test the functionality of a site and report when errors occur. Even tools like this will likely demand a full-time resource to manage and maintain these scripts for even remotely sophisticated sites.

Understanding Scheduled Downtime

Scheduled downtime should be the only reason a site becomes unavailable. Whenever a site has a scheduled release, hardware upgrade, planned ISP outage, or other required downtime scenario, this is scheduled downtime. Consider these downtimes as a separate measurement from unscheduled downtime. While it is important to improve this availability number, the goal should stay within what is reasonable in today's Web farms. New .NET Enterprise technologies, like Application Center 2000, will help improve the scheduled availability rating. Most of the improvements are to be made by improving the process for releasing new features into the production Web farm.

Measuring Overall Availability

When measuring overall availability, a business should consider total downtime as a separate measurement from total unscheduled downtime. Each area of availability is calculated separately to help direct where efforts to improve availability should be made. Keep a running total of the network, server, application, unscheduled, and scheduled availabilities. Combine the network, server, and application availability to create the unscheduled availability quotient. Combine all the availability ratings to create the overall availability rating. Table 3.2 has the availability ratings and goals for Foo.com, based on a six-month period.

Table 3.2 Foo.com's Availability Goals for Six Months


Availability Goal


Availability Measurement



1 hour




5 hours




10 hours




70 hours




17 hours




87 hours


Foo.com does a good job of preventing unscheduled downtime. It is 0.3% away from its stated unscheduled availability goal. However, this is approximately 12 hours of downtime. In order to achieve this goal, application availability problems need to be addressed. To improve overall availability, Foo.com needs to work on the time it takes to perform scheduled maintenance tasks. Foo.com needs to make up 43 hours to reach its overall availability goal of 99%.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020