Adobe Connect Servers and Hardware-based Load-balancing Devices

Adobe Connect Server Pools and Hardware-based Load-balancing Devices

The most robust means of employing a cluster of multiple Connect servers is with a hardware-based load-balancing device (HLD). This article offers a best-practice configuration of a Connect pool or cluster running the full suite of Connect  ?applications: Connect, Adobe Presenter, Connect Training, and Connect Events behind a high-end, application-aware HLD such as F5 BIG-IP LTM. This article does not exhaust the possible configurations, but offers a general working example.

Requirements

To complete this tutorial you will need to install the following software and files:

• Multiple Adobe Connect Servers (cluster license)
• Microsoft SQL Server 2005 SP3 or SQL 2008 SP1
• A Big-IP LTM or other high-end hardware-based load-balancing device

Prerequisite knowledge

A basic understanding of network infrastructure, routing, bridging, and Network Address Translation (NAT).

Table of contents

Configuring DNS and port assignments
Configuring the Connect server pool
Configuring application-level health monitors on the HLD/SSL accelerator
Conclusion

Configuring DNS and port assignments

The best place to start is with a basic network diagram illustrating the desired end state of a Connect server pool running behind a high end hardware-based load-balancing device (HLD), shown in Figure 1.



Figure 1: Adobe Connect server pool running Connect Meeting

Following the example in Figure 1, the virtual Internet protocol addresses (VIPs) on the HLD and the Adobe Connect server pools correspond in the following manner:

• HTTP VIP: connect.adobe.com: 10.10.10.1:80 points to Connect servers: 192.168.0.1: 80 & 192.168.0.2: 80
• RTMP VIP: meeting1.adobe.com: 10.10.10.2:1935 points to Connect server meeting1 192.168.0.1: 1935
• RTMP VIP: meeting2.adobe.com: 10.10.10.3:1935 points to Connect server meeting2 192.168.0.2: 1935

This configuration can be confusing; it may seem odd to have a single server in a server pool, but each Connect VIP on the HLD must point to a single Connect Meeting server; it is a one-to-one correspondence. The HTTP application VIP is more conventional; it points toward a two-server Connect server pool; the HTTP application pool handles failover for the RTMP meetings. Resist any temptation to attempt using a single VIP with multiple open ports. Each VIP also needs its own unique fully qualified domain name (FQDN); the configuration above requires three unique FQDNs.

• One unique FQDN for the HTTP VIP: connect.adobe.com
• One unique FQDN for RTMP VIP: meeting1.adobe.com
• One unique FQDN for RTMP VIP: meeting2.adobe.com

In the Connect server configuration wizard, the external names for each server are the same as the VIP names: meeting1.adobe.com and meeting2.adobe.com respectively; the host name is connect.adobe.com. The only host name suffix the end users will ever see is connect.adobe.com. Still, three unique FQDNs are required on the HLD: one for each VIP pointing to each Connect meeting/RTMP server and one for both of the Enterprise/HTTP servers. From the perspective of the HLD accelerator, there are actually four servers in three pools: two Connect application servers (connect.adobe.com) in one pool and two Connect meeting servers (meeting1.adobe.com and meeting2.adobe.com) each in a pool of its own with its own corresponding VIP. An application-level health monitor on the HLD accelerator should be associated with the HTTP VIP because the Connect application server will handle load balancing and failover of the meetings on the Connect Meeting servers (RTMP) while the HLD handles failover of HTTP. Make certain not to use session awareness on the HTTP VIP. The Round Robin load-balancing algorithm should be used without any sticky settings.

This configuration employs a single IP address on each server. The single IP address uses two ports: 80 for the Connect server and 1935 for the Connect Meeting server.

Note: If it is possible to route client traffic around the HLD, then you may place the meeting FQDNs to resolve directly on each Connect server in which case you would eliminate the RTMP VIPs on the HLD and only use the HTTP VIP with a Round Robin pool. Once a meeting is opened, the RTMP threads would simply bypass the HLD while the HTTP threads go though the HLD.

Configuring the Connect server pool

The next step is to properly edit the Connect server settings to match the VIP configuration on the HLD. Select Start > Programs > Adobe Connect Server 8 > Configure Connect Server 8 to open the server settings in your browser (see Figure 2).

Figure 2: Editing the Connect server settings.

The server settings depicted in Figure 2 correspond with this working example. Add the corresponding external names to match the FQDN of the Meeting VIPs on the HLD

On each Connect 8.X server, add the following to the custom.ini file in the connect directory to enable failover:

MEETING_TIMEOUT=0

MEETING_CONNECT_BACK_TIME=1

After your server settings are configured, stop the Connect services beginning with the Connect Enterprise Service, followed by the Flash Management Server (FMS) service on each Windows server in the pool (see Figure 3). If the HLD accelerator is properly configured, you will be able to browse the Adobe Connect server pool through the HLD accelerator after restarting the services.

Figure 3: Stopping and restarting the Adobe Connect Enterprise services.

Configuring application-level health monitors on the HLD accelerator

In order to make sure that the HLD accelerator performs failover in case one of the application servers should hang, you will want to make certain that the VIP that points to the application server pool is configured with an application level health monitor. If you simply probe the health of the Connect servers with a default health monitor at the level of the IP stack, then there are potential cases when the HLD might send traffic to a server with a non-responsive application that seems alive to lower-level probing mechanisms such as the packet Internet groper (PING). Always set the health monitor to probe for an actual string of content on the Connect server; all high-end HLDs offer application-level health monitoring. It may not always be intuitive how to configure the monitor because each HLD has a different interface and different means of probing an application, but the following guidance will help you get an appropriate monitor in place.
Consider that you have three server pools and three VIPs. The only VIP and pool combination that needs an application-level health monitor for failover is the enterprise/application HTTP server VIP and pool:

• HTTP VIP: connect.adobe.com: 10.10.10.1:80 points to Connect servers: 192.168.0.1: 80 and 192.168.0.2: 80

The probe or health monitor should point to a string on each Connect Enterprise server in its pool to check the health of each server. If one of the servers in the pool becomes non-responsive, the monitor will mark the server down and the HLD will redirect all traffic to the remaining server. The Connect Meeting server VIP/pool combinations do not need a health monitor because the Connect server handles failover for the Meeting rooms:

• RTMP VIP: meeting1.adobe.com: 10.10.10.2:1935 points to Connect Meeting server meeting1 192.168.0.1: 1935
• RTMP VIP: meeting2.adobe.com: 10.10.10.3:1935 points to Connect Meeting server meeting2 192.168.0.2: 1935

Because there is only one server in each pool, there is no place for the HLD to redirect meeting traffic should one of the Connect meeting servers fail to respond. The only reason to probe the Connect meeting server VIP/pool combination might be to trigger an e-mail message to an administrator to warn that one of the meeting servers is problematic.

The best string on the servers that you may point your application-level health monitor to is the testbuilder diagnostic page:

/servlet/testbuilder

The testbuilder page will send back the "status-ok" string.

It is best to point the health monitor to the testbuilder page rather than a simple HTML string, because testbuilder is actually probing the Connect database to make sure there is a healthy connection. If there is any problem with the Connect server application, then testbuilder will not report the "status-ok" string.

Each HLD has a different interface to configure these monitors and each one does the check differently. The following example works with F5 BIG-IP against testbuilder:

/servlet/testbuilder HTTP/1.0\n?
"status-ok"

If you have a problem getting a health monitor to work against testbuilder on your specific HLD, then there is another, less effective option. You can place an HTML file in the content directory on each Connect server and point to that file. This option should only be used if testbuilder is problematic with your flavor of HLD. The following example shows an HTML file called healthmonitortarget.html containing the string You are being served HTML:

common/healthmonitortarget.html HTTP/1.0\n
You are being served HTML

Conclusion

The need for redundancy, availability, and scalability is addressed by clustering Connect servers. Although it is possible to use a software-based clustering solution, the most robust solution is to use a high-end HLD. The configuration described in this article is robust.

Where to go from here

Now that you have successfully configured a Connect server pool to run behind an HLD, you may want to begin planning to incorporate Connect Edge Server clusters into your enterprise infrastructure; the Connect application suite is contagious; as your usage of it ramps up, you may find concentrations of users who could benefit from a local Connect Edge server. When your staff discovers how simple it is to collaborate through Connect meetings and how Adobe Presenter and Connect Training can convert a plethora of content into fully deployed presentations, courses, and curricula, you may find that further expansion is warranted. Watch for future tutorials describing how to integrate Connect Edge servers with HLDs and Connect server clusters.

About the author

Before joining BrightTiger/Allaire/Macromedia/Adobe in June 1997, Frank DeRienzo served with the U.S. Army Rangers and Special Forces. He is a graduate of Gordon College and holds an MBA from the University of Massachusetts. During his tenure with Adobe (and Macromedia), he has focused on high availability and scalability through website clustering and web server integration with various hardware load-balancing and content-management platforms. Currently he is a Senior Technical Account Manager on the Adobe Technical Response Team (TRT), where his primary focus is on Adobe Connect Architecture