Partager via

Using Other Load Balancers

  • Article

To distribute incoming client requests, Application Center provides integration with NLB and also supports other load balancers. These third-party load balancing devices can be monitored and managed through Application Center to provide a complete cluster administration solution. With third-party load balancing integration, Application Center monitors cluster member status, sets members online and offline, and synchronizes content and configuration for all Web sites, including IP addresses bound to Web sites. To integrate these devices with Application Center, you must configure communication between the device and Application Center.

Because all members are synchronized with the cluster controller, you should ensure that all content and configuration exist on the controller before adding any members. Unpredictable behavior might result if content or configuration on members is different from the controller.

The Microsoft Application Center 2000 Resource Kit provides tools for third-party load balancing integration, including a Windows Management Instrumentation (WMI) provider that you can use to monitor your device. This provider allows your device to indicate member status, such as online and offline status or if a member encounters errors. With this provider, you can view member status from the Application Center user interface rather than from the device. This capability allows you to view all aspects of the cluster from within Application Center; you do not need to view some aspects (such as synchronization status) from Application Center, and other aspects (such as member status) from your load balancing device.

You can use .mof files to define your device's configuration, allowing Application Center to recognize and use your device. To perform administrative tasks on the device, such as setting members online and offline, you can use the command line tool for third-party load balancing.

Using Microsoft Health Monitor 2.1, the WMI provider and command-line tool for third-party load balancing, you can automate cluster administration of non-NLB clusters through Application Center. You can write scripts and batch files so that when certain events occur (such as when a member encounters errors or goes offline), you can take action on the member (such as restarting it) without disrupting the cluster.

Handling Member-specific Settings

Using IIS, you can host multiple Web sites on a single cluster by assigning each Web site a different port number, IP address, or host header name. When using other load balancers, this type of configuration is problematic because each Web site typicallly is distinguished by different IP addresses on each member. Because Application Center synchronizes all content and configuration from the controller, some members might never respond to clients because their member-specific settings were overwritten by the controller. To ensure proper functionality, you must add all settings for all Web sites on each member to the controller.

For example, a cluster comprising three members might host two different Web sites: Web site A and Web site B. Each Web site is distinguished by a different IP address for each site on each member. The following table shows an example of IP addresses for each site on each member.

Server

Web site A

Web site B

Controller

1.1.1.1

2.2.2.1

Member A

1.1.1.2

2.2.2.2

Member B

1.1.1.3

2.2.2.3

After Application Center synchronizes this cluster, the settings on Members A and B would be overwritten by those of the controller. Consequently, client requests would always reach the controller because the IP addresses of Members A and B are not bound to Web sites A and B on the controller. The following table shows the IP address bindings after synchronization.

Server

Web site A

Web site B

Controller

1.1.1.1

2.2.2.1

Member A

1.1.1.1

2.2.2.1

Member B

1.1.1.1

2.2.2.1

Client requests for Web site A would always reach 1.1.1.1 (controller) and would never reach 1.1.1.2 (Member A) or 1.1.1.3 (Member B). Likewise, client requests for Web site B would always reach 2.2.2.1 (controller) and would never reach 2.2.2.2 (Member A) or 2.2.2.3 (Member B). For Members A and B to respond, you must bind their IP addresses to Web sites A and B on the controller. The following table shows this configuration.

Server

Web site A

Web site B

Controller

1.1.1.1, 1.1.1.2, 1.1.1.3

2.2.2.1, 2.2.2.2, 2.2.2.3

Member A

1.1.1.2

2.2.2.2

Member B

1.1.1.3

2.2.2.3

After synchronization, all settings for all Web sites exist on every member. So client requests for Web site A could reach any member, since Web site A corresponds with 1.1.1.1 on the controller, 1.1.1.2 on Member A, and 1.1.1.3 on Member B. The following table shows the IP address bindings on each member after synchronization.

Server

Web site A

Web site B

Controller

1.1.1.1, 1.1.1.2, 1.1.1.3

2.2.2.1, 2.2.2.2, 2.2.2.3

Member A

1.1.1.1, 1.1.1.2, 1.1.1.3

2.2.2.1, 2.2.2.2, 2.2.2.3

Member B

1.1.1.1, 1.1.1.2, 1.1.1.3

2.2.2.1, 2.2.2.2, 2.2.2.3

While Member A might acquire IP address bindings from other members that do not actually exist on Member A, these unused IP address bindings will not impact performance. Adding these additional IP address bindings to Web sites in IIS will not result in any performance degradation because IIS only detects IP addresses that are bound to network adapters.

If you decided to add a fourth member (Member C) to the cluster where Web site A has an IP address binding of 1.1.1.4 and Web site B has a binding of 2.2.2.4, you would need to add these IP address bindings to the controller before adding the member. As the member is added to the cluster, Application Center synchronizes the appropriate IP address bindings. The following table shows these bindings for this four-member cluster.

Server

Web site A

Web site B

Controller

1.1.1.1, 1.1.1.2, 1.1.1.3, 1.1.1.4

2.2.2.1, 2.2.2.2, 2.2.2.3, 2.2.2.4

Member A

1.1.1.1, 1.1.1.2, 1.1.1.3, 1.1.1.4

2.2.2.1, 2.2.2.2, 2.2.2.3, 2.2.2.4

Member B

1.1.1.1, 1.1.1.2, 1.1.1.3, 1.1.1.4

2.2.2.1, 2.2.2.2, 2.2.2.3, 2.2.2.4

Member C

1.1.1.1, 1.1.1.2, 1.1.1.3, 1.1.1.4

2.2.2.1, 2.2.2.2, 2.2.2.3, 2.2.2.4

Do not add these additional IP addresses to any network adapters on the controller or members. Use Internet Services Manager to bind IP addresses to Web sites. Adding these IP addresses from other servers to any network adapter on the controller can result in IP address conflicts on your network.

Did you find this information useful? Please send your suggestions and comments about the documentation to acdocs@microsoft.com.