共用方式為

Walkthrough: Validating Load Balancers for Edge Servers

  • 發行項

上次修改主題的時間： 2009-07-14

Before using test clients to validate the newly configured load balancers, it is a good practice to use telnet to confirm that the load balancer is at least listening on the virtual IP (VIP) and directing connections to both Front End Servers. To do this, perform the following steps:

  1. On each Edge Server, run Netmon (or a similar protocol analysis tool) and add a filter to only display traffic coming in on the external Access Edge Server interface on Transmission Control Protocol (TCP) ports 5061 and 443.
  2. From a test client on the Internet, telnet to the Access Edge Server VIP on port 5061 and then again on port 443.
  3. Close the telnet session and reestablish these telnet sessions several times.
  4. On the Edge Server, the Netmon trace should show TCP connections in an alternating fashion.
  5. Repeat the previous steps for the Web Conferencing Server interface using TCP port 8057.
  6. Repeat the previous steps for the A/V Edge Server interface using TCP port 443.
  7. Repeat the previous steps for the internal VIP of the Edge Server.

To validate the load balancer configuration using test clients, we will employ similar hosts file configuration changes that were used to validate the Edge Server’s installation. The only difference is that the load balancer is now configured, so we can point the pool fully qualified domain name (FQDN) to the load balancer VIP. This simulates the behavior that occurs when the pool FQDN is updated in the production Domain Name System (DNS) server.

To perform this testing, first add a temporary host file entry on your Office Communications Server test pool, pointing the FQDN of the internal Office Communications Server Edge Server to the IP address of the particular Edge Server you want to test first. For example, in our sample topology:

  1. On ocsstd.contoso.com, add a hosts file entry that resolves to ocsedge.contoso.com to 172.24.0.40.
  2. On ocsstd.contoso.com, configure ocsedge.contoso.com as the Access Edge Server, webconf.contoso.com as the Web Conferencing Edge Server, and av.contoso.com as the A/V Edge Server.
  3. In a command window, run ipconfig /flushdns to clear the DNS cache.
  4. Restart all services on the Front End Server to ensure they use the updated IP address.

Next, prepare three test workstations with the Office Communicator, Outlook, and Live Meeting clients, and then perform the following:

  1. Add hosts file entries on each client resolving sip.contoso.com to 128.95.0.40, webconf.contoso.com to 128.95.0.50, av.contoso.com to 128.95.0.60, and ocsedge.contoso.com to 172.24.0.40.
  2. In a command window, run ipconfig /flushdns to clear the DNS cache.
  3. In Office Communicator, configure connection settings to Manual, specifying ocsstd.contoso.com as the internal server name and sip.contoso.com as the external server name.
  4. In the Live Meeting Client, configure the Office Communications Server to Manual, specifying ocsstd.contoso.com as the internal server name and sip.contoso.com as the external server name.
  5. Using the test clients homed on a combination of the Internet and the Corporate Network, login to Office Communicator using some test accounts homed on the Standard Edition server and verify all peer-to-peer (P2P) and conference modalities work. This includes instant messaging (IM), voice, video, and desktop sharing.
  6. Using one of the test clients, use the same test clients to schedule a Live Meeting conference using Outlook. Join the meeting and verify that all Live Meeting conference modalities work.

At this stage, you have validated the functionality of the newly added Edge Server load balancers. This provides confidence for doing the actual cut over in the production DNS. Before proceeding, take some time to simulate failure of an Edge Server or reverse proxy server (for example, stop the Front End service or pull the network cable), identify the client behavior, and document the procedure for responding to such a situation. Typically clients use their inbuilt keep-alive mechanisms, client retry logic, and server reconnection randomizations to detect when their Front End Server goes down and then will connect seamlessly to another Front End Server that is available behind the load balancer.

The final step is to remove the test settings that you configured are as follows:

  1. On ocsstd.contoso.com remove the hosts file entry that resolved ocsedge.contoso.com.
  2. In a command window, run ipconfig /flushdns to clear the DNS cache.
  3. Restart all services on the Front End server to ensure they use the updated IP address.
  4. On the test clients, remove the hosts file entry that resolved sip.contoso.com, webconf.contoso.com, av.contoso.com, and ocsedge.contoso.com.
  5. In a command window, run ipconfig /flushdns to clear the DNS cache.
  6. Reset Office Communicator and Live Meeting clients to use automatic server lookup.
  7. Restart the test clients to ensure they do not use any cached DNS entries.

請參閱

概念

Scale to a Load Balanced Edge Server Walkthrough