Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments نسخه متنی

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:

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

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.

Figure 9.11: Migrating Existing Clusters

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.

Network Load Balancing Migration Assumptions

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

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

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

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.

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 "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.

Figure 9.12: Network Environment Before Migrating the IIS Web Farms

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).

Figure 9.13: Network Environment After Installing the Target Cluster

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 "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:

Document the port rules on the source cluster.





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





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





Migrate the applications and services running on the source cluster.





Enable client access to the applications on the target cluster.

Documenting Port Rules on the Source Cluster

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

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:





Start Network Load Balancing Manager.






On the Host menu, click Properties.






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.





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.

Creating Port Rules on the Target Cluster

Create the port rules on the target cluster by using Network Load Balancing Manager. Network Load Balancing Manager is recommended because it ensures that the port rules remain consistent across all the cluster hosts. Other methods require you to manually ensure that the port rules are consistent.

To create the port rules on the target cluster by using Network Load Balancing Manager:

Start Network Load Balancing Manager.





If Network Load Balancing Manager does not already list the cluster, connect to the cluster.





Right-click the cluster, and then click Cluster Properties.






Click the Port Rules tab.





Click Add.





Using the port rules documented in previous steps, specify values for the following:





Cluster IP address, which is the virtual IP address that you want this rule to apply to. Enter a specific virtual IP address to create a virtual cluster, or check All to apply the rule to all virtual IP addresses.





Port range






Protocols






Filtering mode and as appropriate, values for Affinity, and Load weight, and then click OK.








Repeat steps 5 and 6 until all port rules are created.

For more information on creating port rules in Network Load Balancing Manager, see "Create and Manage Network Load Balancing Clusters" in Help and Support Center for Windows Server 2003.

Migrating the Applications and Services Running on the Source Cluster

For information about the specific migration steps for the applications and services running on the source cluster, see "Additional Resources" later in this chapter. After you migrate the applications and services, ensure that the applications and services are running correctly before enabling client access to the applications and services on the target cluster.

Enabling Client Access to the Applications on the Target Cluster

After you have migrated the cluster port rules, applications, and services from the source cluster to the target cluster, you are ready to enable client access to the applications on the target cluster. Enable client access to the target cluster while maintaining the DNS entries to the source cluster. Over a period of time, remove the DNS entries that point to the source cluster.

Enable client access to the applications on the target cluster by completing the following steps:

Create the appropriate DNS entries for the applications running on the target cluster.

For more information on how to create DNS entries for your applications see "Managing resource records" in Help and Support Center for Windows Server 2003.





Monitor client traffic to determine if clients are accessing the target cluster.





Over a period of time, such as a few hours or a day, confirm clients accessing target cluster are experiencing normal response times and application responses.





Remove the DNS entries pointing to the source cluster.

For more information on how to remove DNS entries for your applications see "Managing resource records" in Help and Support Center for Windows Server 2003.





Prevent new clients from accessing the source cluster by performing a drainstop on the source cluster.

For more information on how to perform a drainstop, see "Create and Manage Network Load Balancing Clusters" in Help and Support Center for Windows Server 2003.





Monitor client traffic to the source cluster to determine when clients are no longer accessing the source cluster.





When clients no longer access the source cluster, decommission the source cluster hardware.

Example: Migrating to the Target Cluster

The fictitious organization Contoso, mentioned in examples earlier in this chapter, is now ready to migrate their existing applications running on the four IIS Web farms to the target IIS 6.0 Web farm (and subsequently the target Network Load Balancing cluster). Contoso's target Web farm has been installed and their applications have been verified to work with Windows Server 2003 and Network Load Balancing.

Figure 9.14 illustrates Contoso's network environment after the migration of the existing applications to the target Web farm and Network Load Balancing cluster.

Figure 9.14: Network Environment After Migrating Applications and Services

Table 9.7 lists the applications, the Web farms that run the applications, and the DNS entries that correspond to the Web applications.

In this step, Contoso creates the port rules on the target cluster based on the port rules from each of the existing clusters (IISNLB-01, IISNLB-02, IISNLB-03, and IISNLB-04). Table 9.8, Table 9.9, Table 9.10, and Table 9.11 lists the port rules for the existing clusters.

The port rules are recorded for each of the source clusters. Because each of the clusters has different port rules, virtual clusters are created to facilitate the consolidation of the applications onto the target cluster IISNLB-05. Table 9.12 lists the port rules that were created to support the applications on IISNLB-05.

The port rules on IISNLB-01 and IISNLB-02 are combined into a pair of port rules on IISNLB-05 because IISNLB-01 and IISNLB-02 support the same application. The two clusters, IISNLB-01 and IISNLB-02, were created to provide scaling in the original design. Because the application — www.contoso.com — is being consolidated onto one Web farm on a single cluster, the port rules can be consolidated as well.

The virtual clusters on IISNLB-03 are created on IISNLB-05 to provide separate virtual IP addresses for support.contoso.com and sales.contoso.com.

A virtual cluster, 10.0.0.154, was created to support the application on IISNLB-04, www.treyresearch.net.

After the applications are migrated to the target cluster, IISNLB-05, and are verified for proper operation, DNS entries are created to direct clients to the applications running on the target cluster. Table 9.13 lists the applications, the Web farms that run the applications, and the DNS entries that correspond to the Web applications that include the target cluster, IISNLB-05.

After a few days of operation, clients are experiencing no difficulty with IISNLB-05, so Contoso modifies the DNS entries to remove the original Web servers (IISNLB-01, IISNLB-02, IISNLB-03, and IISNLB-04). Table 9.14 reflects the DNS entries after the removal of the original Web servers.

To finalize the completion of the migration, Contoso performs the following tasks:

Contoso monitors the source clusters for client traffic.





After all client traffic ceases on the source clusters, Contoso decommissions the computers in the source clusters.