Scaling edge/origin deployments

Edge/origin server configurations improve performance by distributing the server load among many computers on a network (see Figure 1). With an edge/origin deployment strategy, all connection requests from clients are redirected to an edge server. The configuration also lets you maximize your network if you are supporting a large local network. By placing edge servers in remote office locations, the edge servers will cache media files locally so each stream does not need to access the origin (host) server for each stream.

Figure 1. Edge/origin architecture

Typically edge/origin deployments are best used with one-way streaming services. When using custom server-side applications to enable real-time communication, the edge server strictly handles the requests on behalf of the origin server. Client connections then make round trips to the origin server to run the application.

In FMIS, edge-level support for bandwidth detection and stream length detection has been integrated. The first server in the chain (edge or origin) receiving a stream call will also handle the bandwidth check and stream length check without calling the origin server script layer. This feature is compatible with the FLVPlayback component for Flash 8 or Flash CS3.

When a client request is received, the edge server will handle the tasks it can, and then make a connection to the origin server for any additional data required. When the origin server fulfills the request, the data is sent back to the edge server, and then on to the client. To the client, it appears that the connection is made directly to the application running on the origin server.

The edge server serves as a "traffic cop" handling connection overhead, authentication, and other administrative duties, freeing up valuable system and network resources for the origin server. Every connection, and connection attempt, consumes resources over and above the actual stream data flowing through the connection. As the number and frequency of connections increase, the load can be excessive, adversely affecting server performance. The edge server greatly reduces this load by aggregating connections. The edge multiplexes the connections from a large number of clients into one connection to the origin server. All communications between edge and origin servers are transparent to clients.

The edge server also stores the prerecorded media content received from the origin server in a cache, which is then made available to other clients that connect to the edge server. Caching static content further reduces the load on the origin server.

Deployment strategies

The simple way to distribute load among edge servers is to assign users in a geographical region or other delineation to a specific edge server. For example, one edge server may aggregate and forward requests from clients in London, while another may handle requests from Tokyo.

A typical networked Flash Media Server deployment can involve multiple edge servers, deployed either individually or in clusters. Edge servers can also be chained, allowing even further distribution of traffic.

To enable the edge/origin feature, you can configure any server in your cluster as your origin server(s), and the rest as your edge servers. All editions in an edge/origin configuration must be the same (for example, you cannot mix FMSS and FMIS editions in a cluster).

Large-scale FMS deployments are supported with the FMS edge/origin configuration. For an introduction to FMS edge/origin, please refer to the documentation, Using Flash Media Server edge servers. For instructions for setting up an edge server, refer to "Configuring edge servers" (p. 5) in the Flash Media Server Configuration and Administration Guide.

Edge servers are also referred to as proxy servers. There are four ways to configure an FMS edge (or proxy) server:

• Client auto discovery proxy
• Server auto discover (reverse proxy)
• Explicit URI
• Implicit URI (recommended)

Typically, the last configuration (implicit URI) is the recommended setting because it is the most secure and requires the least amount of communication. It can hide the origin server URI and is the easiest to set up.

All of these methods are described in the documentation, Using Flash Media Server edge servers. This article explores implicit URI configuration.

Configuring proxy (edge) servers using implicit URI

In typical large-scale deployments, your business could deploy the implicit URI method.

The following settings define the virtual host as a proxy (edge) server:

<Proxy>
  <Mode>remote</Mode>
  <Anonymous>false</Anonymous>
  <CacheDir enabled="true" useAppName="true">d:\fmsCache\</CacheDir>
  <LocalAddress></LocalAddress>
  <RouteTable protocol="">
    <RouteEntry>edge1.fms.com:*;192.168.110.150:1935</RouteEntry>
  </RouteTable>
</Proxy>

This configuration will allow the client to connect with the edge server without exposing the proxy server.
The connection string would look like this:

rtmp://edge1.fms.com/ondemand/

Flash Player would connect to the edge server and not expose the origin server at 192.168.110.50 (see Figure 2).

Figure 2. Edge server using a single origin server

You can configure edge servers to create proxy clusters. In Figure 3 notice how an edge server (e1) can proxy the edge server (e0) in its RouteEntry tag. e0 would proxy the FMS origin. This type of configuration will allow you build FMS edge clusters that could be geographically balanced.

Figure 3. Edge server cluster using a master edge and a single origin

The RouteEntry for the cluster members would point to a main edge server:

<RouteTable protocol="">
  <RouteEntry>edge1.fms.com:*;edge0.fms.com:*;</RouteEntry>
</RouteTable>

The RouteEntry for the main proxy (edge server) in the cluster would point back to the origin server:

<RouteTable protocol="">
  <RouteEntry>edge0.fms.com:*;origin.fms.com:*;</RouteEntry>
</RouteTable>

Page 2 of 4

Previous Page

Next Page