Deploying Network Load Balancing

(1)

After completing the design for the applications and services in your Network Load Balancing cluster, you are ready to deploy the cluster running the Microsoft® Windows® Server 2003 operating system in your pilot and production network environments. A successful deployment ensures that your Network Load Balancing cluster meets or exceeds the specifications in the design. In addition, you must ensure that the deployment of your Network Load Balancing cluster does not disrupt the operation of any existing applications or services.

In This Chapter

Overview of the NLB Deployment Process ... 566

Selecting the Automated Deployment Method ... 568

Implementing a New Cluster... 571

Upgrading Existing Clusters... 587

Migrating Existing Clusters... 597

Additional Resources... 610 Related Information

u For more information about the Network Load Balancing design process, see “Designing Network Load Balancing” in Planning Server Deployments of this kit.

u For more information about designing server clusters, see “Designing and Deploying Server Clusters” in Planning Server Deployments.

Deploying Network Load

Balancing

(2)

Overview of the NLB Deployment Process

A Network Load Balancing cluster comprises multiple servers running any version of the Windows Server 2003 family of operating systems, including Microsoft® Windows®

Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; Windows®

Server 2003, Datacenter Edition; and Windows® Server 2003, Web Edition.

Clustering allows you to combine application servers to provide a level of scaling and availability that is not possible with an individual server. Network Load Balancing distributes incoming client requests among the servers in the cluster to more evenly balance the workload of each server and prevent overload on any one server. To client computers, the Network Load Balancing cluster appears as a single server that is highly scalable and fault tolerant.

The Network Load Balancing deployment process assumes that your design team has completed the design of the Network Load Balancing solution for your organization and has performed limited testing in a lab. After the design team tests the design in the lab, your deployment team implements the Network Load Balancing solution first in a pilot environment and then in your production environment.

Upon completing the deployment process presented here, your Network Load Balancing solution (the Network Load Balancing cluster and the applications and services running on the cluster) will be in place. For more information about the procedures for deploying Network Load

Balancing on individual servers, see “New ways to do familiar tasks” in Help and Support Center for Windows Server 2003, and then click “Network Load Balancing Manager”.

NLB Deployment Process

Deploy your Network Load Balancing solution by implementing the decisions made by the design team. The process for deploying Network Load Balancing clusters is shown in Figure 9.1.

Note

As you implement your Network Load Balancing design, use the information for each cluster host recorded by your design team in the “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).

(3)

Figure 9.1 Deploying Network Load Balancing

Implement new cluster?

No

Yes

Upgrade existing cluster?

No

Yes

Implement new cluster

Upgrade existing cluster

Migrate existing cluster

Deploy more NLB clusters?

Yes

Select the automated deployment method

NLB deployment complete No

During the Network Load Balancing design process, the design team created and documented the design of the network configuration by using drawing and diagramming software (such as Microsoft® Visio®), and the “NLB Cluster Host Worksheet” job aid that your design team completed for each cluster host. (This worksheet is associated with “Designing Network Load Balancing” in Planning Server Deployments of this kit.) The Network Load Balancing design documents describe the number of Network Load Balancing clusters, the placement of the Network Load Balancing clusters in your network environment, the number of Network Load Balancing cluster hosts, and other specifications.

Before deploying Network Load Balancing in your production environment, test your

deployment solution in a lab and in a pilot deployment. For more information about testing your design, see “Planning for Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit.

(4)

After you test your design, you can use different options for deploying each Network Load Balancing cluster, based on the requirements of your organization. Table 9.1 lists deployment requirements and the corresponding options for deploying Network Load Balancing clusters. For each cluster in the Network Load Balancing design, select one of these options for deploying Network Load Balancing clusters.

Table 9.1 Deployment Requirements and Corresponding Options for Deploying NLB Clusters

Deployment Requirements Implement Upgrade Migrate Fresh installation of Windows Server 2003 is required

Clusters are to be deployed on new cluster hardware Two or more existing clusters to be consolidated into a single cluster

A corresponding cluster currently exists in the network environment Existing hardware is capable of running Windows Server 2003 Existing Windows registry settings to be retained

When your Network Load Balancing solution includes multiple Network Load Balancing clusters, you might need to use more than one method for deploying Network Load Balancing clusters. For each Network Load Balancing cluster in your solution, read the corresponding section in this chapter for the deployment method you select:

u Implementing New Clusters u Upgrading Existing Clusters u Migrating Existing Clusters

Selecting the Automated Deployment Method

Begin the deployment of your Network Load Balancing solution by determining how to automate your Network Load Balancing deployment. Automate the deployment of your Network Load Balancing solution to ensure the consistency of installation, to reduce the time required to deploy your solution, and to assist in restoring failed Network Load Balancing cluster hosts. Manually deploy your Network Load Balancing solution only if creating and testing the automation files and scripts would take more time than manually configuring the cluster. Figure 9.2 shows the process for determining the best method to automate the deployment of your Network Load Balancing solution.

(5)

Figure 9.2 Selecting the Automated Deployment Method

No

Yes

No

Yes

You can automate the deployment of Windows Server 2003 and Network Load Balancing cluster hosts by using one of the following methods:

u Unattended installation u Sysprep

u Remote Installation Services (RIS)

Table 9.2 compares the characteristics of the various automated deployment methods.

(6)

Table 9.2 Comparing Automated Deployment Methods

Deployment Characteristics Unattended Installation Sysprep RIS Uses images to deploy installation

Uses scripts to customize installation Supports post installation scripts to install applications

Deployed by using local drives on the target server

Initiated by headless servers Deployed from a network share

Depending on the requirements of each cluster, more than one method might be required to deploy all your Network Load Balancing clusters. For more information about these methods, see

“Designing Unattended Installations,” “Designing Image-based Installations with Sysprep,” and

“Designing RIS Installations” in Automating and Customizing Installations of this kit.

The unattended installation and Sysprep methods require that you create script files to automate the deployment. The Network Load Balancing–specific installation and configuration

information is required in two sections of the unattended and Sysprep script files: the [MS_WLBS parameters] and [MS_TCPIP parameters] sections.

For more information about the process for configuring the script files, see the Microsoft®

Windows® Server 2003 Corporate Deployment Tools User’s Guide (Deploy.chm). Deploy.chm is included in the Deploy.cab file in the Support folder on the Windows Server 2003 operating system CD. For more information about the parameters used by the script files, see the Windows Preinstallation Environment link on the Web Resources page at

http://www.microsoft.com/windows/reskits/webresources. There are no special considerations for automating Network Load Balancing deployment by using the RIS method.

For Network Load Balancing, you need to perform specific tasks when creating the unattended installation and Sysprep script files:

u Review the content in the Microsoft Windows Preinstallation Reference that relates to the [MS_WLBS parameters] section.

WLBS stands for “Windows NT Load Balancing Service,” the name of the load balancing service used in Microsoft® Windows NT® Server version 4.0. For reasons of backward compatibility, WLBS continues to be used in certain instances.

u Ensure that the IP addresses for the cluster and all virtual clusters are entered in the IPAddress parameter under the [MS_TCPIP parameters] section.

Typically, Network Load Balancing Manager automatically adds the cluster and virtual cluster IP addresses to the list of IP addresses. Both unattended installation and Sysprep require that you add the addresses to the IPAddress parameter under the [MS_TCPIP parameters] section of the script.

(7)

Implementing a New Cluster

Many of the mission-critical applications deployed within your organization will be new

applications, which require you to deploy new Network Load Balancing clusters. The process for implementing a new cluster involves more than installing Windows Server 2003 and Network Load Balancing on the individual application servers. Implementing a new cluster might require additional network infrastructure, network services, file services, database services, and security services. Figure 9.3 shows the steps that you must complete before and after the implementation of the new cluster.

Figure 9.3 Implementing a New Cluster

No

Yes

No

Yes

Prepare to implement the cluster

Implement the cluster

Verify the cluster and enable client access

(8)

Preparing to Implement the Cluster

Your new cluster is dependent upon the network infrastructure and other network services in your total solution. Ensure that these network infrastructure and other network services are deployed prior to implementing your cluster.

Prepare for the implementation of the new cluster by using the information documented in the

“NLB Cluster Host Worksheet” and other documentation (such as Visio drawings of the network environment) that your design team completed for a specific cluster host during the design process. Coordinate with the operations team during this step in the process to review the changes that will occur in your organization’s network environment.

To prepare for the implementation of the new cluster, complete the following tasks:

1. Implement the network infrastructure required by the cluster and by the applications and services running on the cluster.

2. Implement any networking services required by the applications and services running on the cluster.

3. Select the method for automating any additional Network Load Balancing configuration.

Implementing the Network Infrastructure

Before you implement the cluster, you must implement the network infrastructure that connects the cluster to client computers, to other servers within your organization, and to management consoles. The network infrastructure components include:

u Network cables u Hubs

u Switches u Routers u Firewalls

Note

Any references to switches in this chapter refer to Layer 2 switches.

(9)

When implementing the network infrastructure, make sure to have specifications about your current network environment available. Specifically, your hardware and software inventory and a map of network topology can be helpful. For more information about creating those documents, see “Planning for Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit.

Implementing Any Required Networking Services

Network Load Balancing is independent of the other Windows Server 2003 network services. As a result, you do not need to implement networking services for Network Load Balancing.

However, the applications and services running on the cluster can be dependent on other Windows Server 2003 networking services. For more information about requirements for implementing networking services used by the services and applications running on the cluster, see “Additional Resources” later in this chapter.

Automating Additional Configurations

In many instances, it is possible that Windows Server 2003, Network Load Balancing, or the applications and services running on a particular cluster might require additional configuration after the installation is complete. You can use any combination of the following methods for automating these additional configurations:

u Microsoft Visual Basic Scripting Edition (VBScript) u Windows Management Instrumentation (WMI) u Active Directory Service Interfaces (ADSI)

Example: Preparing to Implement the Cluster

An organization is deploying a new Web application that will be accessed by a large volume of Internet users. Because of scaling and availability considerations, the organization will deploy the new, high-volume Web application on a Network Load Balancing cluster. Figure 9.4 illustrates the organization’s network environment prior to the implementation of the new cluster.

(10)

Figure 9.4 Network Environment Before Implementing New Cluster

Segment that connects management adapters to organizations resources and operations consoles

Internet

Router-01 Router-02

DC-01 DC-02 SQLCLSTR-01

Firewall-01

To the organizations private network

To the organizations perimeter network (currently empty)

In addition to deciding that the new Web farm will run on a Network Load Balancing cluster, the design team also made the following configuration decisions:

u No single router, switch, or Internet Information Services (IIS) Web farm server failure will prevent users from running the Web application.

u Web application will store data in a clustered SQL server running Microsoft^® SQL Server™

2000 on a server cluster.

u Web application executables Active Server Pages (ASP), Hypertext Markup Language (HTML) pages, and other executable code will be stored on a file server running on a server cluster.

u Accounts used for authenticating Internet users will be stored in Active Directory^® directory service.

(11)

As the first step in the organization’s deployment of the Web application, the IIS 6.0 Web farm, and Network Load Balancing, the organization must restructure the network infrastructure to support the new Web farm and cluster. Figure 9.5 illustrates the organization’s network environment after preparing for the implementation.

Figure 9.5 Network Environment After Preparing to Implement a New Cluster Internet

Router-01 Router-02

Firewall-01

To the organizations private network Segment that connects

management adapters to organizations resources and operations consoles

Firewall-02 Firewall-03

Switch-01

belongs to VLAN-01 Switch-02

belongs to VLAN-01

FILECLSTR-01 To the organizations

perimeter network (currently empty)

Table 9.3 lists the deployment steps that were performed prior to the implementation of the new cluster and the reasons for performing those steps.

(12)

Table 9.3 Deployment Steps Prior to Implementation of the New Cluster

Deployment Step Reason

Add Firewall-02 and Firewall-03 Provide redundancy and load balancing.

Add Switch-01 and Switch-02 Provide redundancy and load balancing.

Add network segments on Switch-01 and Switch-02 Connect the IIS 6.0 Web farm to the network.

Configure Switch-01 and Switch-02 to belong to the same VLAN

Provide load balancing of client requests by using Network Load Balancing.

Add SQLCLUSTR-01 Provide database support for the Web application on a Microsoft server cluster.

Add FILECLUSTR-01 Provide secured storage for the Web application executables and content on a Microsoft server cluster.

Add DC-01 and DC-01 Provide storage and management of user accounts used in authenticating Internet users.

Implementing the Cluster

To implement the new cluster, complete the following tasks:

1. Install and configure the hardware and Windows Server 2003 for each cluster host.

2. Install and configure the first Network Load Balancing cluster host.

3. Install and configure additional Network Load Balancing cluster hosts.

Note

When your Network Load Balancing solution includes multiple Network Load Balancing clusters with round robin DNS, complete these tasks for each Network Load Balancing cluster in the solution. For more information about combining multiple Network Load Balancing clusters with round robin DNS, see “Scaling NLB Solutions” in “Designing Network Load Balancing” in this book.

(13)

Installing and Configuring the Hardware and Windows Server 2003

The first step in performing the implementation of the new cluster is to install and configure the hardware and Windows Server 2003 for each cluster host. Install and configure all cluster host hardware at the same time to ensure that you eliminate any configuration errors prior to installing and configuring the Network Load Balancing cluster.

To install and configure Windows Server 2003 on the cluster host hardware, you must be logged on as a user account that is a member of the local administrators group on all cluster hosts. Install and configure the cluster host by using the information documented in the “NLB Cluster Host Worksheet” that your design team completed for that host during the design process.

To install and configure the hardware and Windows Server 2003 on each cluster host in the new cluster, complete the following tasks:

1. Install the cluster host hardware in accordance with the manufacturer’s recommendations.

2. Connect the cluster host hardware to the network infrastructure.

3. Install Windows Server 2003 with the default options and specifications from the worksheet for the cluster host.

4. Install any additional services (such as IIS 6.0 or Routing and Remote Access) by using the design specifications for the service.

For detailed instructions on installing additional services, see the resources related to the corresponding service in “Additional Resources” later in this chapter.

5. Configure the TCP/IP property settings and verify connectivity for the cluster adapters.

6. If a separate management network is used, configure the TCP/IP property settings and verify connectivity for the management adapter.

Although not required, it is recommended that you use a separate management network adapter to provide a communication path that is isolated both from the cluster adapter and from the clients. For more information on the benefits of including a management network adapter in your design, see “Selecting the Number of Network Adapters in Each Cluster Host” in “Designing Network Load Balancing” in this book.

7. Configure each server to be a member server in a domain created specifically for managing the cluster and other related servers.

Although not required, creating a domain for management of the cluster provides a

centralized method of controlling security to the cluster. Management of clusters installed in a workgroup is more difficult and time-consuming. When the cluster resides in a perimeter network, create a separate forest for the exclusive purpose of managing servers (including cluster hosts) in the perimeter network.

Caution

Configure the dedicated IP address at this time. The cluster IP address and any virtual IP addresses for port rules are added later in the deployment process through Network Load Balancing Manager.

(14)

Installing and Configuring the First Cluster Host

After you have installed and configured the hardware for the cluster, you are ready to install and configure the first cluster host. The first cluster host acts as a master copy when you use an image-based deployment method (such as RIS, Sysprep, or a third-party product) to deploy the remaining cluster hosts.

An image-based deployment is faster and ensures consistency when implementing the remaining cluster hosts, by reducing or eliminating manual configuration. In addition, the same image- based deployment method can be reused after the deployment to restore failed cluster hosts.

Depending on the type of image-based deployment, different methods are used to customize the cluster host after the image has been restored. For example, Sysprep can allow you to

interactively customize the image or use a configuration file — sysprep.inf — to customize the image. For more information on customizing the restored image, see “Designing Unattended Installations,” “Designing Image-based Installations with Sysprep,” and “Designing RIS Installations” in Automating and Customizing Installations of this kit.

Perform the following task on the first cluster host by using the “NLB Cluster Host Worksheet”

that your design team completed for the first cluster host:

1. If you did not use the automated installation process to create the new cluster, start Network Load Balancing Manager and create a new cluster.

2. Install the applications and services on the first cluster host.

Examples of Windows Server 2003 services to be installed at this time include IIS or Terminal Services. For more information about installing Windows Server 2003 services, see the chapters that discuss those services in the Microsoft® Windows® Server 2003 Deployment Kit.

Examples of applications to be installed at this time include, Web applications or Windows applications that run on Terminal Services. For more information about installing the applications running on your cluster, see the documentation that accompanies your application.

3. Enable monitoring and health checking on the first cluster host.

A Microsoft Operations Manager (MOM) Management Pack exists for Network Load Balancing. When your organization uses MOM to monitor and manage the servers within your organization, include the MOM Management Pack for Network Load Balancing on the cluster hosts.

For location of additional information about monitoring and health checking the applications and services running on the cluster, review the resources in “Additional Resources” later in this chapter.

Tip

You can start Network Load Balancing Manager by running Nlbmgr.exe.

(15)

4. Verify that the first Network Load Balancing cluster host responds to client queries by directing requests to the cluster IP address.

Test the first cluster host by specifying the cluster IP address or a virtual cluster IP address in the client software that is used to access the application or service running on the cluster. For example, a client accessing an IIS application would put the cluster IP address or virtual cluster IP address in the Web browser address line.

Installing and Configuring Additional Cluster Hosts

After you have installed and configured the first cluster host, you are ready to install and configure the remaining cluster hosts in the cluster. The first cluster host acts as a master copy when you use an image-based deployment method (such as RIS, Sysprep, or a third-party product) to deploy the remaining cluster hosts.

Perform the following tasks on the remaining cluster hosts by using the “NLB Cluster Host Worksheet” that your design team completed for each cluster host:

1. Create an image of the first cluster host that has just been deployed (discussed in the previous section) as required by one of the following image-based automated installation methods:

u Sysprep

For more information about creating Sysprep images, see “Designing Image-based Installations with Sysprep” in Automating and Customizing Installations of this kit.

u RIS

For more information about creating RIS images, see “Designing RIS Installations” in Automating and Customizing Installations.

u Third-party products

For more information about creating images with third-party products, see the documentation provided with the third-party image deployment software.

2. Restore the image of the first cluster host (created in step 1) to one of the remaining cluster host, following the directions provided in the documentation for the image-base installation method you used.

3. Configure any computer specific information (such as computer name and IP address) on the newly deployed cluster host.

Important

Create an entry in DNS for the cluster only after you have completed the deployment of the entire cluster. Prematurely publishing the applications and services in DNS might result in overwhelming the cluster hosts before all cluster hosts are installed

(16)

4. Enable monitoring and health checking for the additional cluster host.

Use the same methods as described for the first cluster host.

5. Verify that the additional cluster host responds to client requests.

Use the same methods as described for the first cluster host.

6. Complete steps 2 through 5 for each remaining cluster host in the Network Load Balancing cluster.

7. Ensure that the cluster is load balancing requests across all cluster hosts (based on the port rules of the cluster).

The time required to create and test the images used in an image-based deployment can be prohibitive. It might take you less time to install and configure the remaining cluster hosts in the same way that you installed and configured the first Network Load Balancing cluster host. For example, you could deploy a cluster that consists of three cluster hosts. If you decide to deploy the cluster hosts using a method other than image-based deployment, you must ensure that you can restore a failed cluster host.

Example: Implementing the New Cluster

The organization mentioned in “Example: Preparing to Implement the Cluster” earlier in this chapter is now ready to implement the new IIS 6.0 Web farm that uses Network Load Balancing for load balancing and fault tolerance. The network infrastructure and additional networking services have been deployed in preparation for the implementation.

In this step, the organization installed and configured the first cluster host as a model for the remaining cluster hosts. Then the organization deployed the remaining cluster hosts by using an image-based deployment method. Figure 9.6 illustrates the network environment after the implementation of the new IIS 6.0 Web farm and Network Load Balancing.

(17)

Figure 9.6 Network Environment After Installing the New Cluster

Firewall-01

To the organizations private network Switch-01

belongs to VLAN-01

FILECLSTR-01

IIS-01 IIS-02 IIS-03 IIS-04 IIS-05 IIS-06 IIS-07 IIS-08

NLBCluster-01

Internet

Router-01 Router-02

Table 9.4 lists the deployment steps that were performed to implement the new cluster and the reasons for performing those steps.

(18)

Table 9.4 Deployment Steps for Implementing the New NLB Cluster

Add IIS-01, IIS-02, IIS-03, IIS-04, IIS-05, IIS-06, IIS-07, and IIS-08 server hardware.

Server hardware needs to be connected to network infrastructure in preparation for Network Load Balancing deployment.

Install Windows Server 2003 and Network Load Balancing on IIS-01 by using unattended installation.

Unattended setup is chosen because of the limited number of hosts to be deployed.

Create an image of IIS-01 to use as a model for RIS deployment.

RIS allows the servers to be reimaged in the event of a server failure.

Deploy the image on IIS-02, IIS-03, IIS-04, IIS- 05, IIS-06, IIS-07, and IIS-08.

Image deployment ensures a consistent configuration on all servers in the Network Load Balancing cluster.

Verify the Web farm responds to client requests. Verification ensures that the Web farm is properly configured and that Network Load Balancing is load balancing.

Verifying the Cluster and Enabling Client Access

The final step in implementing your new Network Load Balancing cluster is to ensure that you have properly implemented and configured your cluster. In “Installing and Configuring the First Cluster Host” earlier in this chapter, you verified your implementation of individual servers. Now you must ensure that the entire cluster is secure and is properly monitored and health checked.

To verify the cluster and enable client access, complete the following tasks:

1. Verify the cluster host restoration process.

2. Verify that identified security threats are mitigated.

3. Perform monitoring and health checking on the complete cluster.

4. Verify proper operation of applications and services running on the cluster.

5. Enable client access to the cluster.

(19)

Verifying the Cluster Host Restoration Process

Before placing the cluster into a pilot or production environment, you need to verify cluster host restoration to ensure that you can properly restore a cluster host that has failed.

To verify the cluster host restoration process, complete the following tasks:

1. Remove a cluster host from the cluster by performing a drainstop on the cluster host.

A drainstop prevents a cluster host from handling new client requests. While draining, a cluster host continues to complete any outstanding requests and remains in the cluster until all active requests are completed. Then the cluster host stops all cluster operation.

2. Remove all disk volumes and disk partitions on the cluster host.

3. Restore the cluster host based on the installation method selected earlier in the deployment process.

4. Restart the cluster host.

5. Verify that the System event log of each cluster host contains no errors and that the restored cluster host responds properly to client requests.

Verifying That Identified Security Threats are Mitigated

You need to verify that all the identified security threats are properly handled in your new Network Load Balancing solution.

To verify that the identified security threats are mitigated, complete the following tasks:

1. Connect a client computer to the network such that the clients access the cluster by using the same route path that a typical client computer would use to connect to the cluster.

For example, when clients connect to the cluster through a series of firewalls and routers to connect to the cluster over the Internet, ensure the client computer used for testing connects to the cluster through the same firewalls and routers.

2. Log on to the client computer with the user rights identified in your security threats.

3. For each identified security threat, reproduce the steps that result in the security compromise of the cluster.

4. Document the results and report the findings to the design team.

5. With the assistance of the design team, resolve any outstanding security issues.

Important

Resolve all security threats before proceeding further in the deployment process.

(20)

Monitoring and Health Checking the Complete Cluster

Your next step in completing the implementation of your new cluster is to enable monitoring and health checking on the entire cluster. In “Installing and Configuring the First Cluster Host” and

“Installing and Configuring Additional Cluster Hosts” earlier in this chapter, you enabled monitoring and health checking on individual cluster hosts. However, in this step you are ensuring that the cluster is monitored as a complete unit. Enable monitoring and health checking on the cluster before allowing users to access the cluster in a pilot or production environment.

As clients begin to access the applications and services in your cluster, continue to provide monitoring and health checking as described in “Installing and Configuring the First Cluster Host” earlier in this chapter. Verify that the cluster performs as expected with live client traffic.

After the deployment process is complete, ensure that your operations staff continues the monitoring and health checking process in their long-term operations processes as part of your ongoing operations.

Verifying Proper Operations of Applications and Services

Before placing the complete cluster into a pilot or production environment, you need to verify that applications and services are running correctly on the cluster.

To verify proper operations of applications and services on the new cluster, complete the following tasks:

1. Temporarily connect a client computer to the same switch used by the cluster.

2. From the client computer, verify that the applications respond to client requests as expected.

3. Disconnect the client computer from the switch.

Enable Client Access to the Cluster

Your last step in the implementation of your new cluster is to allow clients access to the applications and services running on the cluster. Be sure that you successfully complete all previous steps in the process before enabling users to access the cluster in a pilot or production environment.

(21)

Enable client access to the applications and the services in the cluster by creating DNS entries.

Users will access your applications and services by using user-friendly names or Uniform Resource Locaters (URLs), such as http://www.microsoft.com, which correspond to the individual applications or services on the Network Load Balancing cluster. The DNS entries allow the translation of the user-friendly name to at least one IP address. When round robin DNS is used for load balancing between clusters, you must create a DNS entry for each cluster.

Table 9.5 lists the criteria for determining the number of DNS entries required for your new cluster.

Table 9.5 Criteria for Determining the DNS Entries for Your Cluster Solution Includes One of the Following Required DNS Entries Only one Network Load Balancing cluster. A DNS entry for the cluster and a DNS entry for

each virtual cluster.

More than one Network Load Balancing cluster with client traffic distributed across Network Load Balancing clusters by using round robin DNS.

A round robin DNS entry for each cluster and a round robin DNS entry for each virtual cluster.

Example: Verifying the Cluster and Enabling Client Access

The organization mentioned in the examples earlier in this chapter is now ready to complete the implementation of the new IIS 6.0 Web farm. The Web farm servers are implemented and basic connectivity is provided to the Web farm. The organization has verified that Network Load Balancing is distributing client traffic evenly and that all cluster hosts are servicing client requests.

In this step, the organization verifies that the Web farm and the cluster function as a whole.

Although operation of each cluster host was verified during the implementation process, now the organization must ensure that the new Web farm meets or exceeds the design specifications established by your design team before enabling client access to the applications.

Figure 9.7 illustrates the network environment after the implementation of the new IIS 6.0 Web farm and Network Load Balancing.

(22)

Figure 9.7 Network Environment After Implementing the New Cluster

Firewall-01

To the organizations private network Switch-01

belongs to VLAN-01

FILECLSTR-01

IIS-01 IIS-02 IIS-03 IIS-04 IIS-05 IIS-06 IIS-07 IIS-08

NLBCluster-01

Internet

Router-01 Router-02

Table 9.6 lists the deployment steps that were performed to verify the new cluster and enable client access.

(23)

Table 9.6 Verifying the New Cluster and Enabling Client Access

IIS-03 taken off line. Automatic failover to other Web servers must be proven.

IIS-02 restored. Restoration process for Web servers must be proven.

Client attached to the Internet and security attacks performed.

Mitigation of security threats must be proven.

Monitoring and health checking enabled on IIS- 01, IIS-02, IIS-03, IIS-04, IIS-05, IIS-06, IIS-07 and IIS-08.

Proper operation of the IIS 6.0 Web farm must be verified during and after the implementation process to ensure that load balancing is occurring and that system resources are adequate for client requests.

A DNS entry created for the cluster IP address of NLBCluster-01.

Clients must have a DNS entry to access the Web applications running on the cluster.

Upgrading Existing Clusters

If your organization has applications and services that currently run on the Windows NT 4.0 or Microsoft® Windows® 2000 operating systems, you can upgrade your existing WLBS or Network Load Balancing clusters to take advantage of the improved security and performance of Windows Server 2003 and Network Load Balancing. Figure 9.8 shows the process for upgrading an existing cluster.

(24)

Figure 9.8 Upgrading an Existing Cluster

No

Yes

No

Yes

Prepare to upgrade the cluster

Upgrade the cluster

The Network Load Balancing upgrade process assumes the following conditions:

u Your applications are running on an existing IIS 4.0 (on Windows NT 4.0) or IIS 5.0 (on Windows 2000).

u You are upgrading the operating system and services running on your existing application servers.

u The system resources of the computers in your existing application farm are sufficient, or can be upgraded, to support Windows Server 2003 and IIS 6.0.

(25)

You can upgrade a cluster by taking the entire cluster offline and upgrading all the hosts, or you can leave the cluster on line and perform a rolling upgrade. A rolling upgrade entails taking individual cluster hosts offline one at a time, upgrading each host, and returning the host to the cluster. You continue upgrading individual cluster hosts until the entire cluster is upgraded. A rolling upgrade allows the cluster to continue running during the upgrade.

The decision to use rolling upgrades is based on the applications and services running on your existing cluster. If the applications and services support rolling upgrades, then perform a rolling upgrade on the existing cluster. Otherwise, perform the upgrade process recommended for the applications and services running on the cluster. For more information on the upgrade process for the applications and services running on your cluster, see “Additional Resources” later in this chapter.

Upgrade the cluster by using the information documented in the “NLB Cluster Host Worksheet”

that your design team completed for each cluster host during the design process.

Preparing to Upgrade the Cluster

Network Load Balancing runs independently of other networking services provided by Windows Server 2003. On the other hand, the applications and services running on the cluster can be dependent upon the network infrastructure and other network services in your existing environment. Prior to upgrading the existing cluster, deploy any network infrastructure

components or networking services that are required by the applications and services running on the cluster.

Prepare to upgrade the cluster by performing the following tasks:

1. Verify that applications and services running on the cluster are compatible with Windows Server 2003.

2. Upgrade the network infrastructure as required by the applications and services running on the cluster.

3. Upgrade any networking services as required by the applications and services running on the cluster.

Verifying Applications and Services Are Compatible with Windows Server 2003

Before you upgrade the existing cluster, ensure that the applications and services running on the cluster are compatible with Windows Server 2003. For help in determining if your application is compatible with Windows Server 2003, use the Windows Application Compatibility Toolkit. To download the toolkit, see the Windows Application Compatibility link on the Web Resources page at http://www.microsoft.com/reskits/webresources.

(26)

Upgrading Necessary Network Infrastructure

Before you upgrade the existing cluster, ensure that the final configuration of the cluster can be supported by the network infrastructure that connects the cluster to client computers, to other servers within your organization, and to management consoles. Perform only the network infrastructure upgrades required by the applications and services running on the cluster. Avoid performing upgrades to the network infrastructure for other reasons at the same time that you are upgrading the cluster. This minimizes the number of changes to the environment and reduces the likelihood of problems occurring during the upgrade process.

The network infrastructure to upgrade includes the following components:

u Network cabling u Hubs

u Switches u Routers u Firewalls

Upgrading Any Required Networking Services

Network Load Balancing is independent of the other Windows Server 2003 network services. As a result, no networking services upgrades are required for Network Load Balancing.

However, the applications and services running on the cluster can be dependent on other Windows Server 2003 networking services. For more information about requirements that the services and applications running on the cluster might have for upgrading networking services, see “Additional Resources” later in this chapter.

Example: Preparing to Upgrade the Cluster

An organization is upgrading their existing virtual private network (VPN) remote access solution.

The existing solution has a VPN remote access server farm that supports Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). Currently the VPN remote access server farm is running WLBS on Windows NT 4.0. Figure 9.9 illustrates the organization’s network environment prior to preparing for the upgrade of the existing WLBS cluster that hosts the VPN remote access server farm.

Note

When performing this step, make sure to have specifications about your current network environment available for use. Specifically, your hardware and software inventory, and a map of network topology can be helpful. For more information about creating those documents, see “Planning for Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit.

(27)

Figure 9.9 Network Environment Before Preparing to Upgrading the Cluster

DC-01 DC-02

Firewall-03 Switch-01

VPNNLB-01 VPN running Windows NT 4.0 VPN-01

VPN-02

VPN-03

VPN-04

VPN-05

VPN-06

VPN-07

VPN-08

Router-01 Router-02

Internet

Switch-02

As the first step in upgrading the existing VPN remote access server farm, the organization installs any networking services required by the VPN remote access server farm. No networking infrastructure or networking services upgrades are required for the upgrade.

In the future, the organization plans to deploy Internet Authentication Service (IAS) servers to provide centralized management of remote access policies. However, the deployment of IAS is scheduled to occur after the upgrade to Windows Server 2003 to prevent any unnecessary complications during the upgrade process.

(28)

Upgrading the Cluster

The upgrade of your existing cluster can be done one cluster host at a time (a rolling upgrade) or by taking the cluster offline to upgrade all the hosts at the same time (a nonrolling upgrade). It is recommended that you perform a rolling upgrade. Otherwise, perform the upgrade process recommended for the applications and services running on the cluster. For more information on the upgrade process for the applications and services running on your cluster, see “Additional Resources” later in this chapter.

Determine if you can perform a rolling upgrade in your lab prior to your pilot or production deployments. If you can perform rolling upgrades, ensure that you perform the post-upgrade processes described in this section for each individual cluster host.

To perform a rolling upgrade on existing WLBS or Network Load Balancing clusters, complete the following tasks:

1. Prevent clients from accessing the cluster host to be upgraded by performing a drainstop on the cluster host.

2. Monitor client activity on the cluster host until all client activity ceases.

3. Upgrade the cluster host.

4. Verify that the applications and services are running correctly on the upgraded cluster host.

5. Add the cluster host back to the cluster.

6. Upgrade the remaining cluster hosts by performing steps 1 though 5 for each cluster host.

Preventing Clients From Accessing the Cluster Host

Before you upgrade a cluster host, you must ensure that no clients have active sessions running on the cluster host. During the upgrade process, the cluster host is still connected to the network infrastructure.

However, to prevent new clients from starting sessions or applications on the cluster host, perform a drainstop on the cluster host to be upgraded. Performing a drainstop prevents new clients from accessing the cluster while allowing existing clients to continue until they have completed their current operations.

(29)

In addition, configure the Default state of the Initial host state to Stopped. Configuring the cluster host in this manner ensures the cluster host cannot rejoin the cluster during the upgrade process. Because the upgrade process requires the cluster host to restart, you need to verify that the upgrade completed successfully before adding the cluster host back to the cluster.

For more information about performing a drainstop on the source cluster and changing the Default state of cluster host, see “Create and Manage Network Load Balancing Clusters” in Help and Support Center for Windows Server 2003.

Monitoring Client Activity on the Cluster Host

After you run the drainstop on the cluster host, monitor client activity on the cluster host to determine when clients are no longer using the cluster host. The method for determining when clients are no longer using the cluster host is specific to the applications and services running on the cluster host.

For example, for a VPN remote access solution, monitor for active VPN connections to the cluster host. When there are no active VPN connections, the cluster host is ready to be upgraded.

For more information about monitoring the applications and services running on the cluster for client activity, see “Additional Resources” later in this chapter.

Upgrading the Cluster Host

After you ensure that no clients are accessing the cluster host, upgrade the cluster host to Windows Server 2003. Ensure that during the upgrade process you apply the latest service packs and hotfixes.

After the upgrade is complete, check the upgrade logs (Setuperr.log in the windir folder of the system volume) to identify any problems that occurred during the upgrade process. Many applications and services running on the cluster have log files that identify problems that occur during the upgrade process. For example, IIS 6.0 creates a separate log that documents the upgrade process for IIS components. Make certain that you review any upgrade logs for the applications and services running on the cluster.

For more information about these upgrade logs, see “Additional Resources” later in this chapter.

Tip

You can configure the Initial host state through Network Load Balancing Manager or the property settings of the cluster network adapter.

(30)

Verifying the Applications and Services are Running Correctly

After the upgrade of the cluster host is complete, you need to verify that the applications and services are running correctly on the cluster host. You need to do this before starting the cluster service again in order to allow the cluster host to rejoin the cluster. The process presented here is specific to Network Load Balancing. This process might apply to the applications and services running on the cluster, however, the applications and services running on the cluster might have a different verification process. For more information on the verification process for specific applications and services running on the cluster, see “Additional Resources” later in this chapter.

To verify that the applications and services are running correctly after you upgrade the cluster host, complete the following tasks:

1. Temporarily connect a client computer to the same switch used by the cluster.

2. From the client computer, verify that the applications respond to client requests as they did prior to the upgrade.

3. Verify that the identified security threats are mitigated.

The only action you need to take to mitigate Network Load Balancing–specific security threats is to ensure that unauthorized clients cannot remotely administer the cluster. Unless the network infrastructure, including firewalls or routers, changed significantly since the start of the upgrade, the Network Load Balancing security threats should still be mitigated.

However, you must mitigate security threats that are unique to the applications and services running on the cluster. For more information about mitigating security threats for specific applications and services running on the cluster, see “Additional Resources” later in this chapter.

4. Enable monitoring and health checking, if they are not already enabled.

A Microsoft Operations Manager (MOM) Management Pack exists for Network Load Balancing. When your organization uses MOM to monitor and manage the servers within your organization, include the MOM Management Pack for Network Load Balancing on the cluster hosts.

For more information about monitoring and health checking the applications and services running on the cluster, see “Additional Resources” later in this chapter.

5. Disconnect the client computer from the switch.

(31)

Adding the Cluster Host Back to the Cluster

After you complete the upgrade and verify that the applications and services are running correctly, add the cluster host back to the cluster. Because the cluster host is still connected by cable to the existing network infrastructure, adding the cluster host back to the cluster requires you to start Network Load Balancing on the cluster host.

To add the cluster host back to the cluster, use Network Load Balancing Manager to start the Network Load Balancing service on the cluster host. In addition, configure the Default state of the Initial host state to match the setting that existed prior to the upgrade process. Configuring the cluster host in this manner ensures that the clients accessing the applications and services running on the cluster do not encounter problems when you restart the cluster host and return it to the cluster.

The reason to configure the cluster host with the same settings, instead of selecting Started, is that Network Load Balancing loads very early in the operating system boot process. The cluster host can join the cluster before other services are running. This means the cluster host might receive load before other services, such as IIS, are started. Allowing Network Load Balancing to start before other services could result in the denial of service to users until the service starts.

You can use management software, such as MOM, to monitor the services running on the host and to start Network Load Balancing when the appropriate services are running. Using management software to start Network Load Balancing is recommended to prevent users from experiencing outages in service.

For more information on performing a drainstop on the source cluster and changing the Initial host state of cluster host, see “Create and Manage Network Load Balancing Clusters” in Help and Support Center for Windows Server 2003.

Example: Upgrading the Existing NLB Cluster

The organization mentioned in the examples earlier in this chapter is now ready to upgrade the existing VPN server farms. In this step, the organization performs a rolling upgrade on each cluster host in the VPN remote access server farm.

Each of the VPN remote access servers were upgraded in turn until the entire VPN remote access server farm was upgraded. Figure 9.10 illustrates the organization’s network environment after the upgrade of the cluster.

(32)

Figure 9.10 Network Environment After Upgrading the Cluster

VPNNLB-01 VPN

running Windows Server 2003 VPN-01

VPN-02

VPN-03

VPN-04

VPN-05

VPN-06

VPN-07

VPN-08

Router-01 Router-02

Internet

Switch-02

DC-01 DC-02 IAS-01 IAS-02

(33)

To upgrade the VPN remote access server farm, the following tasks were performed:

1. Prevented client access on the VPN-01 cluster host by performing a drainstop on VPN-01.

2. Monitored client activity on VPN-01 until all client activity ceased.

3. Upgraded VPN-01.

4. Verified that the applications and services are running correctly on VPN-01.

5. Added VPN-01 back to the cluster.

6. Performed steps 1 through 5 on the remaining VPN remote access servers.

Migrating Existing Clusters

Your organization might have applications and services that currently run on Windows NT 4.0 or Windows 2000 clusters. If you want these applications and services to take advantage of the improved security and performance of Windows Server 2003, and if you also want to run these applications on newly installed Windows Server 2003 servers, you can migrate the applications and servers from existing clusters to newly installed Network Load Balancing clusters.

The migration process is appropriate in the following situations:

u You want to migrate one WLBS or Network Load Balancing cluster to a target Network Load Balancing cluster.

u You want to consolidate multiple WLBS or Network Load Balancing clusters onto a target Network Load Balancing cluster.

Migrating WLBS clusters from Windows NT 4.0 or Network Load Balancing clusters from Windows 2000 requires only minimal effort for Network Load Balancing. The majority of the migration effort involves the applications and services running on the cluster. The process for migrating an existing cluster to a target Network Load Balancing cluster running Windows Server 2003 is shown in Figure 9.11.

(34)

Figure 9.11 Migrating Existing Clusters

No

Yes

No

Yes

Implement the target cluster

Migrate to the target cluster

Migrate your WLBS or Network Load Balancing cluster by using the information documented in the “NLB Cluster Host Worksheet” that your design team completed for each cluster host during the design process.

(35)

Network Load Balancing Migration Assumptions

The Network Load Balancing migration process to Windows Server 2003 assumes the following conditions:

u Your applications and services are running on an existing cluster running WLBS (on Windows NT 4.0) or Network Load Balancing (on Windows 2000).

u You are installing a new Network Load Balancing cluster as the target cluster.

u Your applications and services are compatible with Windows Server 2003.

In addition to compatibility with Network Load Balancing, the applications and services must be compatible with Windows Server 2003. For help in determining if your application is compatible with Windows Server 2003, use the Windows Application Compatibility Toolkit on the Windows Server 2003 Deployment Kit companion CD.

For information about the migration process for the application or service running on your cluster, see “Additional Resources” later in this chapter.

Network Load Balancing Migrations and Consolidations

In addition to migrating an existing cluster to the target cluster, you can use the Network Load Balancing migration process to consolidate multiple existing clusters to the target cluster. The consolidation process is identical to the migration process, except that, for each migration, you are migrating applications and services that formerly ran on multiple clusters onto a single target cluster.

As a part of consolidation, the port rules and cluster virtual IP addresses from all the source clusters must be created on the target cluster. For each cluster that you migrate, you must create port rules on the target cluster that handle the client traffic in the same manner as the traffic was handled on the source cluster. For more information about the migration of port rules, see

“Migrating to the Target Cluster” later in this chapter.

(36)

Implementing the Target Cluster

The first step in the migration process is to implement the target Network Load Balancing cluster. If the target Network Load Balancing cluster already exists, proceed to the next step in the process, described in “Migrating to the Target Cluster” later in this chapter

The process for implementing the target is identical to the process for installing a new Network Load Balancing cluster. Complete the process described in “Implementing a New Cluster” earlier in this chapter. Ensure that implementing the target cluster does not disrupt applications running on the source cluster. For example, avoid modifying the network infrastructure that actively connects to the source cluster and avoid modifying DNS entries that direct clients to the source cluster.

Example: Implementing the Target Cluster

Contoso Pharmaceuticals is consolidating existing IIS Web farms onto a new IIS 6.0 Web farm.

There are four independent IIS Web farms that need to be migrated. Two of the Web farms are running IIS 4.0 and WLBS on Windows NT 4.0. The other two Web farms are running IIS 5.0 and Network Load Balancing on Windows 2000.

During the migration, Contoso plans to consolidate the separate Web farms into one Web farm that supports all of their Web applications. Figure 9.12 illustrates Contoso’s network

environment prior to the migration of the existing WLBS and Network Load Balancing clusters that host the IIS Web farms.

(37)

Figure 9.12 Network Environment Before Migrating the IIS Web Farms

Router-01

Firewall-02

Firewall-01

FILECLSTR-01 IISNLB-01

IISNLB-02

IISNLB-03

IISNLB-04 Internet

As the first step in Contoso’s migration of the Web application server farm, Contoso restructured the network infrastructure to support the new IIS and Network Load Balancing deployment.

Additional networking services were deployed in preparation for the implementation.

Then Contoso installed and configured the first server in the Web farm as a model for the remaining servers. Contoso deployed the remaining servers by using an image-based deployment method. Figure 9.13 illustrates Contoso’s network environment after the implementation of the target IIS 6.0 Web farm (Network Load Balancing cluster).

(38)

Figure 9.13 Network Environment After Installing the Target Cluster

DC-01 DC-02

Router-02 Router-04

Switch-02

SQLCLSTR-01 FILECLSTR-01 Router-01

IISNLB-01

IISNLB-02

IISNLB-03

IISNLB-04

IIS-01 IIS-02 IIS-03 IIS-04 Internet

IISNLB-05 Web farm running Windows Server 2003

(39)

During the implementation of the new target cluster, the existing clusters were not affected.

Clients continued to access the applications and services running on the existing cluster during the implementation of the target cluster.

Migrating to the Target Cluster

As discussed in “Implementing the Target Cluster” earlier in this chapter, the only part of Network Load Balancing to be migrated is the port rules. All other aspects of the migration of the cluster are specific to the applications and services running on the cluster. For more information on migrating applications and services running on the cluster, see “Additional Resources” later in this chapter.

Because the number of port rules on a cluster is small, the existing port rules can be easily recreated on the target cluster. If you are consolidating multiple clusters to a target cluster, the creation of port rules is slightly different from the creation of port rules if you are migrating a single cluster to a target cluster. Primarily, when consolidating, you need to ensure that consolidated port rules do not conflict with one another.

Migrate or consolidate the port rules on the source cluster to the target cluster by completing the following steps:

1. Document the port rules on the source cluster.

2. Identify any differences between port rules that exist on the target cluster and the port rules on the source cluster.

3. Create the port rule on the target cluster, as required, with new or different virtual IP addresses.

4. Migrate the applications and services running on the source cluster.

5. Enable client access to the applications on the target cluster.

(40)

Documenting Port Rules on the Source Cluster

Document the port rules on the source cluster by completing the following steps:

1. View the port rules in Network Load Balancing Manager or by running Nlb.exe at a command prompt.

To view port rules in Network Load Balancing Manager:

a. Start Network Load Balancing Manager.

b. On the Host menu, click Properties.

c. On the Port Rules tab, view the port rules in the Defined port rules box.

To view port rules by running Nlb.exe, in the command prompt, type Nlb display cluster_IP_address (where cluster_IP_address is the cluster IP address of the source cluster), and then press Enter.

For more information about viewing port rules in Network Load Balancing Manager or by using Nlb.exe, see “Create and Manage Network Load Balancing Clusters” in Help and Support Center for Windows Server 2003.

2. Record the port rules on the job aid “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).

Identifying Differences Between Port Rules

When migrating a source cluster to a target cluster, create port rules that are identical to the source cluster. When consolidating two or more clusters to a target cluster, create port rules that are identical to the source cluster unless port rules exist on the target cluster that specify the same TCP/UDP port number that is specified by a port rule on the source cluster.

During consolidation, two clusters might have port rules that relate to the same TCP/UDP port number, but have different affinity or load weight. In these situations you must differentiate between the different affinity or load weight behaviors by associating each of the source port rules with a different virtual cluster.

For example, you are migrating two clusters, Cluster A and Cluster B, to the same target cluster.

Cluster A has a port rule for HTTP (TCP port 80) traffic that specifies no affinity, while Cluster B has a port rule for HTTP traffic that specifies Single affinity. The applications on these servers expect the affinity behavior. To ensure these applications behave as they did on the source servers, specify a port rule, with unique virtual IP address, for each of the affinity behaviors.