Flash Communication Server Article

Clustering Flash Communication Server for Live Webcasts

Understanding the Clustering Process

One of the first things you should consider when deploying a Flash Communication Server application is hosting. There are several methods for hosting Flash Communication Server. You could have a single dedicated Flash Communication Server. Or you could have many servers, which share machine time with other web or application servers. In this tutorial, I will discuss the multiserver environment. I won't go over the specifics of how to set up each individual server, but will touch only on what you need to understand the process of creating the multiserver environment. To learn how to set up Flash Communication Server, refer the documentation that comes with the installation files.

When I first started discussing clustering Flash Communication Servers, other developers and as seen on lists like the FlashComm Mailing List, Flashkit Communication Server MX forum, and Macromedia Flash Communication Server forums, I learned that there are different schools of thought about the best approach:

• Having a dedicated master server that connects to "children” servers and serves up content to them so that content can be propagated out to clients who connect to those children (Figure 2)

  

  Figure 2. Master/child server configuration

• Having multiple servers that can act as either master or child, depending on which one accepts the connection first (Figure 3)

  

  Figure 3. Multiple master/child server configuration

• Having multiple master servers that are not tied to one another but that are each connected independently to the publisher/admin. (Figure 4)

  

  Figure 4. Multiple master server configuration

Which of these three is the best design? It depends on what type of application you are running. All of these designs will fulfill the need, which is to provide a stateless architecture that will allow for disconnections and quick reconnections of live streams, without incurring problems of syncing or losing your place in the stream. For clustering streaming events, I believe the third—having multiple master servers—is the best model. Let me explain my thinking.

Let's say for example you have an audio webcast that is expected to have a large attendance—about 1000 people. You may think to yourself, "One server could handle that load. Why do I need multiple servers?" This is a good question. And there's a one-word answer: redundancy.

Imagine that in the middle of the webcast your one server decides to take a break. What happens to your webcast? Well, it's not going to be pretty. You could end up playing banjo for coins on the street corner.

I would rather take the safe approach. Have multiple master servers, so that if one fails, then the other servers can handle things and not lose your stream. Even if you can't handle the whole webcast, at least you can offer the playback.

My team has put our servers behind a switch that does load balancing, so if one of the servers goes down, the switch balances traffic between the live servers automatically.

Ironically, we don't have our two Flash Communication servers on super high-end boxes. But because of the combined power of the OSs running on them and the Flash Communication Server software, they do surprisingly well under load. We balance between two HP Proliant DL360 G2 Dual 1.4 GB processor machines with 4 GB of RAM running SUSE LINUX Enterprise Server.

The switch we use is a Foundry ServerIron Layer 4 switch. It balances based on a least connection configuration. The switch does periodic health checks using UDP pings on the ports that the Flash Communication Server uses. If a server goes down, then the switch immediately directs all requests to the live server until the downed server comes back online. The switch is not specific to streaming protocols but works great under this design.

We have reliably served up over 900 audio streams concurrently without problems.

Page 2 of 3

Previous Page

Next Page