One of the primary reasons for including Network Load Balancing in your network design solution is to provide the ability to scale out your network by adding additional servers. Any other methods of improving client response times are not directly related to Network Load Balancing, but rather to the network infrastructure and system hardware associated with the cluster. Figure 8.13 illustrates the steps involved in incorporating scaling options in your Network Load Balancing solution.
Figure 8.13: Scaling Network Load Balancing Solutions
Also, you can ensure the scalability of applications and services by using methods that are specific to the applications and services running on the cluster. For more information about improving the scalability of services running on Network Load Balancing, see "Additional Resources" later in this chapter.
| Note |
Document your design on your organization's network diagram. For a Word document to assist you in documenting your Network Load Balancing design decisions, see "NLB Cluster Host Worksheet" (Sdcnlb_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "NLB Cluster Host Worksheet" on the Web at http://www.microsoft.com/reskit). |
During the lab testing and pilot testing of your Network Load Balancing design, you might discover that the cluster hosts are not responding within the requirements for your solution. Also, as you anticipate the increase in growth that your design must support, the cluster hosts need to continue to respond in accordance with your solution requirements. When a cluster becomes unable to respond the client requests within a specified time, you can improve the performance by scaling up your solution.
Take the following actions to scale up your solution:
Increase system resources (such as processors, memory, disks, and network adapters) for the existing cluster host.
Replace the existing cluster host with another system that has greater resources.
Scaling up is appropriate in the following situations:
You want to reduce the total cost of ownership (TCO) by including fewer, more powerful cluster hosts in your design.
The client response time is insufficient for a cluster host that is supporting the required number of users.
Scale up your solution by adding system resources by completing the following steps:
Identify the applications or services running on the Network Load Balancing cluster.
Identify the system resources that are consumed by the applications or services running on the cluster.
Because Network Load Balancing requires only minimal system resources, the applications and services running on the cluster determine the system resources that are consumed first. For more information about the system resource requirements for services running on Network Load Balancing, see "Additional Resources" later in this chapter.
Verify the system resource estimates in your deployment lab.
Modify the system resource requirements based on the data from your testing in the deployment lab.
Document the system requirements in your design.
| Note |
You can reduce the system resource requirements for your cluster hosts and avoid scaling up by eliminating any unnecessary applications or services. For more information about the required applications or services in your solution, see "Additional Resources" later in this chapter. |
Another method that you can use to improve client response time is scaling out. You scale out your solution when you add cluster hosts to existing clusters.
Scaling out your solution is appropriate in the following situations:
You want to reduce TCO by including more, less-expensive cluster hosts in your design.
You cannot further upgrade the system resources of the existing cluster hosts.
| Tip |
To further improve client response time, consider scaling up the cluster host system resources as you scale out. |
Scale out your solution by adding cluster hosts to the cluster and completing the following steps:
Identify the applications or services that require scaling out.
Identify any port rules that are associated with the application or services.
Include the additional cluster hosts in the cluster.
When appropriate, divide the cluster hosts into separate clusters and use round robin DNS to distribute client traffic across the clusters.
Determine the number of cluster hosts that are required in your design by estimating the number of clients each host can support and then testing your estimates in your lab. The maximum number of clients that each cluster host can support depends on the applications and services running on the host. For more information about capacity planning for the applications and services running on Network Load Balancing clusters, see "Additional Resources" later in this chapter.
The maximum number of cluster hosts in a cluster depends on a number of factors, such as the network infrastructure or protocols used by the applications and services running on the cluster, in addition to any Network Load Balancing limitations.
The only method of determining the maximum number of hosts in a cluster is by testing your configuration in a lab. When your lab tests indicate that you are unable to support the number of simultaneous clients by scaling out within a single cluster, scale out by using multiple clusters.
Network infrastructure devices, such as routers or switches, can also limit the network throughput to the cluster and ultimately affect how much you can scale out a cluster. To overcome this limitation, you can increase the network infrastructure capacity by changing the number and placement of routers and switches. However, the changes to the network infrastructure capacity might prevent you from keeping the cluster hosts on the same subnet or VLAN. Because all the cluster hosts must be on the same subnet or VLAN, scaling out with a single cluster is inadequate and you must scale out by using multiple clusters on separate subnets or VLANs.
If you are unable to scale out your applications on a single cluster, you can scale out by using multiple clusters. Then distribute the client traffic across the multiple clusters by using round robin DNS.
For example, an organization is getting ready to deploy a new high-volume Web site for its Internet presence. To support the required number of client requests, 72 cluster hosts are necessary. In lab testing, the organization determines that the network infrastructure can support only 9 clusters hosts per VLAN. As a result, eight clusters are required to scale out the organization's Web farm. Table 8.21 lists the clusters and the IP addresses that are assigned to each cluster.
|
Assigned IP Address |
|
|---|---|
|
IISNLB-01 |
10.0.1.100 |
|
IISNLB-02 |
10.0.2.100 |
|
IISNLB-03 |
10.0.3.100 |
|
IISNLB-04 |
10.0.4.100 |
|
IISNLB-05 |
10.0.5.100 |
|
IISNLB-06 |
10.0.6.100 |
|
IISNLB-07 |
10.0.7.100 |
|
IISNLB-08 |
10.0.8.100 |
Figure 8.14 illustrates an IIS 6.0 Web farm in which client traffic is distributed across multiple Network Load Balancing clusters by using round robin DNS.
Figure 8.14: Using Round Robin DNS to Distribute Client Traffic Across Clusters
The DNS name of the IIS 6.0 application Web farm is www.contoso.com. The DNS zone for contoso.com contains multiple entries for www.contoso.com, as required by round robin DNS. Each DNS entry corresponds to a Network Load Balancing cluster in the IIS 6.0 application Web farm. Round robin DNS distributes client traffic to the clusters, and then Network Load Balancing distributes client traffic within the cluster.
One of the assumptions in combining Network Load Balancing and round robin DNS is that an entire cluster is never taken offline. When an entire cluster is offline, DNS still directs client requests to the offline cluster and some clients will experience service outages, as they do when round robin DNS entries point to an individual server that is offline. To prevent clients from experiencing service outages, take only individual cluster hosts offline for maintenance or for other reasons.
For more information about round robin DNS, see "Deploying DNS" in Deploying Network Services of this kit.
Other steps in improving client response time directly affect the cluster hosts themselves. However, even with a highly optimized cluster, inadequate network bandwidth between the clients and the cluster can increase client response times to unacceptable levels.
Increase the available bandwidth between clients and the cluster by completing the following steps:
Identify the intermediary network segments, routers, and switches between the clients and the clusters.
Calculate the aggregate bandwidth requirements for the maximum number of simultaneous users.
Determine the intermediary network segments, routers, and switches between the clients and the clusters that are unable to support the aggregate bandwidth requirements.
Modify your design to increase the available bandwidth, based on the information in Table 8.22.
|
Available Bandwidth Limited By |
Increase Bandwidth by One or More of These Methods |
|---|---|
|
Network segment available capacity |
Increase the data rate of the network segment. (Upgrade from Integrated Services Digital Network (ISDN) to digital subscriber line (DSL) orT1.)
Include additional network segments, and distribute the network traffic across the network segments.
|
|
Switch capacity |
Increase the data rate of the switch and the devices that are connected to the switch. (Upgrade from 10BaseT to 100BaseT or 1000BaseT.)
Include additional switches, and distribute the computers that are connected to the original switch across the switches.
|
|
Router capacity |
Increase the data rate of the router and the devices that are connected to the router. (Upgrade from 10BaseT to 100BaseT or 1000BaseT.)
Include additional routers, and create redundant routes to load balance the network traffic between the routers.
|
An organization provides VPN remote access to the organization's users through the Internet. The design includes Network Load Balancing to eliminate any application outages and to improve performance. The VPN remote access servers, which run Routing and Remote Access and Windows Server 2003, reside in the organization's perimeter network, which is located between the Internet and the organization's private network.
Pilot testing of the VPN remote access solution indicates the need for an increase in remote access client performance. Figure 8.15 illustrates the Routing and Remote Access VPN design to be tested.
Figure 8.15: VPN Solution Pilot Test Environment
Table 8.23 lists the results of the pilot test for each portion of the design that is illustrated in Figure 8.15.
|
Design Portion Tested |
Results |
|---|---|
|
Network infrastructure |
Router-01 was saturated with client traffic.
Switch-01 was saturated with client traffic.
The network segment between Switch-01 and Router-01 was saturated.
The connection to the Internet was saturated.
|
|
Cluster hosts hardware |
Individual cluster hosts lacked sufficient memory to handle the required number of simultaneous users.
The total number of cluster hosts was insufficient to handle total number of simultaneous users.
|
After the pilot test, the organization modifies the VPN remote access design. Figure 8.16 illustrates the modified version of the VPN design.
Figure 8.16: Revised VPN Remote Access Design
The organization made the following design decisions to improve scalability for the cluster:
Add Firewall-02 and Router-02 to provide additional network bandwidth to the Internet and to solve the saturation problem on Router-01.
Add Switch-02 to provide additional network bandwidth to the Internet and to solve the saturation problem on Switch-01.
Add memory for all cluster hosts to ensure sufficient system resources for the hosts.
Add VPN-07 and VPN-08 to support the maximum number of simultaneous users.