User manual MACROMEDIA FLASH MEDIA SERVER 2 - USING FLASH MEDIA SERVER EDGE SERVERS

Using Flash Media Server Edge Servers Trademarks 1 Step RoboPDF, ActiveEdit, ActiveTest, Authorware, Blue Sky Software, Blue Sky, Breeze, Breezo, Captivate, Central, ColdFusion, Contribute, Database Explorer, Director, Dreamweaver, Fireworks, Flash, FlashCast, FlashHelp, Flash Lite, FlashPaper, Flash Video Encoder, Flex, Flex Builder, Fontographer, FreeHand, Generator, HomeSite, JRun, MacRecorder, Macromedia, MXML, RoboEngine, RoboHelp, RoboInfo, RoboPDF, Roundtrip, Roundtrip HTML, Shockwave, SoundEdit, Studio MX, UltraDev, and WebHelp are either registered trademarks or trademarks of Macromedia, Inc. and may be registered in the United States or in other jurisdictions including internationally. Other product names, logos, designs, titles, words, or phrases mentioned within this publication may be trademarks, service marks, or trade names of Macromedia, Inc. or other entities and may be registered in certain jurisdictions including internationally. Third-Party Information This guide contains links to third-party websites that are not under the control of Macromedia, and Macromedia is not responsible for the content on any linked site. If you access a third-party website mentioned in this guide, then you do so at your own risk. Macromedia provides these links only as a convenience, and the inclusion of the link does not imply that Macromedia endorses or accepts any responsibility for the content on those third-party sites. Jabber is a registered trademark of the Jabber Software Foundation. SorensonTM SparkTM video compression and decompression technology licensed from Sorenson Media, Inc. Copyright © 2002-2005 Macromedia, Inc. All rights reserved. This manual may not be copied, photocopied, reproduced, translated, or converted to any electronic or machine-readable form in whole or in part without written approval from Macromedia, Inc. Notwithstanding the foregoing, the owner or authorized user of a valid copy of the software with which this manual was provided may print out one copy of this manual from an electronic version of this manual for the sole purpose of such owner or authorized user learning to use such software, provided that no part of this manual may be printed out, reproduced, distributed, resold, or transmitted for any other purposes, including, without limitation, commercial purposes, such as selling copies of this documentation or providing paid-for support services. Acknowledgments Project Management: Suzanne Smith Writing: John Norton, Suzanne Smith Editing: Evelyn Eldridge, Mary Ferguson, Lisa Stanziano, Anne Szabla Production Management: Adam Barnett Media Design and Production: Aaron Begley, Paul Benkman, John Francis, Mario Reynoso First Edition: October 2005 Macromedia, Inc. 601 Townsend St. San Francisco, CA 94103 Contents Using Edge and Origin Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Introducing edge servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 How edge servers work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Caching data in edge servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Deploying edge servers in the DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Explicit and implicit proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Reverse proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Routing information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Connecting to an edge server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Detecting the presence of proxy servers . . . . . . . . . . . . . . . . . . . . . 13 Chaining edge servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Configuring edge servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Deploying a cluster of edge servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Connecting to a cluster of edge servers . . . . . . . . . . . . . . . . . . . . . . 16 Enrolling proxy servers in the cluster . . . . . . . . . . . . . . . . . . . . . . . . 16 Accessing applications through an edge cluster . . . . . . . . . . . . . . 16 Clustering reverse proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Setting up origin and proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . 18 Maintaining edge server clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Clearing the edge server cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3 4 Contents Using Edge and Origin Servers This chapter describes the various strategies for deploying Flash Media Server with edge and origin servers. Introducing edge servers Until this release of Flash Media Server, clients always connected directly to the computer where the application was running. These applications were running locally, since their execution occurred on the same computer that the clients were connected to. This release of Flash Media Server introduces the concept of remote execution of applications. Flash Media Server can now run applications locally as an origin server or remotely as edge servers. Edge servers are not a different kind of Flash Media Server, rather, they are configured to run applications remotely. Deploying edge servers in your organization offers significant benefits. Enhanced security is one benefit. Applications running on the origin server are no longer directly exposed to the Internet. All requests for Flash Media Server services are routed through known and secure connection points. These connectors are called edge, or proxy, servers; the terms are interchangeable. Administrators can monitor the traffic on edge servers. The access log files for each edge server lets administrators verify that the connections are authorized. The log files also identify unauthorized requests for connections. The edge server-origin server deployment is flexible. Edge servers let administrators scale up or redistribute access to Flash Media Server without dismantling their current deployment. Administrators can add edge servers. Administrators can reallocate edge servers to match realignments of users and sites within an organization, or changes in the flow of traffic among the sites. 5 Deploying edge servers lets administrators distribute the incoming connection requests for Flash Media Server services. Traffic between clients and the origin server uses the existing bandwidth and system resources more efficiently. More traffic occurs locally between the clients' computers and the edge server. Without edge servers, all clients have to connect to a Flash Media Server origin server, no matter where that server is located. Edge servers mediate communications traffic between the organization's trusted network and an untrusted network such as the Internet. Using edge servers does not remove the need for a firewall to manage the traffic at an IP level, but does provide an additional layer of security at the application level. How edge servers work With an edge-origin deployment strategy, all connection requests from users' computers for Flash Media Server services are redirected to an edge server. The edge server receives the request from the user's computer, but the edge server is not running the application. The edge server makes the connection to another computer, called the origin server, where the application is running. When the origin server fulfills the request for Flash Media Server services, it sends the application's data back to the edge server, which in turn forwards the data to the client (the user's computer). It may seem to the users that they are directly connected to the origin server where the application is located. The edge server does make it appear as if it is running the application. The edge server's role, however, is to mediate the communications between clients and the origin server. Edge servers authenticate the users and authorize their requests for web services. For example, when Flash Media Server is deployed solely on one computer and is running just one application instance, system and network resources may not always be sufficient when a large number of users in an organization want to connect almost simultaneously to Flash Media Server from multiple locations. Such might be the case in an enterprise-wide meeting or conference. When too many users want to access the same application at the same time, the existing bandwidth and system resources can be overwhelmed. Increased latency is another indication that resources need to be reconfigured or reallocated. Every connection into the origin server consumes resources independent of the actual data flowing through the connection. As the number of connections increase, this load can become inordinately large and adversely affect the server performance. The edge server greatly mitigates this problem by aggregating connections. The edge multiplexes the connections from a large number of clients on to one connection to the origin server. 6 Using Edge and Origin Servers Such constraints may prompt the Flash Media Server and network administrators to consider a different deployment strategy. The strategy involves configuring Flash Media Server to redistribute the load on system and bandwidth resources by running some virtual hosts as edge servers and other virtual hosts as origin servers. Rather than forwarding every request to the origin server and consuming resources for such repetitive tasks, the edge server collects the requests from a large number of clients and aggregates them into one connection to the origin server. All communications between edge and origin servers happen transparently to the users. End User End User End User End User End User Edge Server Tokyo End User End User Origin Server Chicago End User End User End User Edge Server Paris To distribute the demands on network and system resources, administrators can assign the users in a geographical region or functional area of the organization to a specific edge server. For example, one edge server might aggregate and forward requests from users in Tokyo and another might aggregate and forward requests from Paris. The edge servers in Paris and Tokyo gather the requests from their clients and forward them to the origin server located in another secured location, such as Chicago. Introducing edge servers 7 Users in these zones always access the origin server through their assigned edge servers. These edge servers receive the responses from the origin server, then distribute them back to the clients (the users' computers) in their respective zones: Paris or Tokyo. The edge also stores the data received from the origin server in a cache, and makes it available to other clients that connect to this edge server. Recycling the data is one more way that edge servers use resources efficiently. Caching static content reduces the overall load placed on the origin server. A networked Flash Media Server deployment involves multiple edge servers; these can be deployed individually or in clusters. Edge servers can also be chained, where one edge server collects and aggregates the connection requests from other edge servers and their clients, then transmits the requests to an origin server. Edge Server Client (Users) Client (Users) Client (Users) Client (Users) Edge Server Edge Server Edge Server Client (Users) Client (Users) Edge Server Edge Server Origen Server Edge Server Client (Users) Client (Users) Edge Server Edge Server Client (Users) Client (Users) Edge Server Edge Server 8 Using Edge and Origin Servers Caching data in edge servers An edge server is designed to intercept the requests for Flash Media Server services from users in a particular zone, collect or aggregate these requests, and transmit them to the origin server. The origin server returns the results to the edge server, which in turn sends the data back to the user's client computer. The edge server also stores this information in its cache, where other users or clients assigned to the same edge server can access it. In this scenario, fewer requests for services are forwarded to the origin server. The edge server caches data such as video streams and shared objects. When a user requests data that is found in the edge server's cache, it returns the data to the requesting client (the user's computer) without ever calling upon the origin server. This detour is transparent to the user. The edge server is conserving bandwidth by not connecting to the origin server. In this scenario, no demands are placed on the origin server. Deploying edge servers in the DMZ Edge servers may be deployed in the demilitarized zone (DMZ) of a corporate network. A DMZ is an isolated network placed between an organization's trusted network and the Internet's untrusted network. In this deployment, the edges function as proxy servers for all Real Time Messaging Protocol (RTMP) traffic that flows through the organization's network. Deploying edge servers in the DMZ provides one more layer of defense between the user's Internet connection and the origin server. All traffic that comes from the Internet with Flash Media Server as its destination must pass through an edge server. Introducing edge servers 9 With the edge servers sitting in the DMZ, the network operators can open access to port 1936, avoiding the system overhead and risk of HTTP tunneling. Because the edge server performs stream splitting and stream caching, it uses the connection to the origin server efficiently, reducing the Internet bandwidth cost. The user also benefits from the more reliable connectivity. Firewall, Router, Load Balancer End User End User Edge Server Cluster Origin Server 1936 End User 80, 443, 80 443 1935 End User 1935 End User DMZ End User End User Explicit and implicit proxies Edge servers are defined by the values in the configuration files. Both explicit and implicit (also called anonymous) proxies intercept and aggregate the clients' requests to connect to the applications running on an origin server. The explicit edge server prefixes its address to the origin server's Uniform Resource Identifier (URI). This configuration makes the client (the user's computer) aware of the proxy. The URI in the explicit proxy specifies the edge servers that will intercept the clients' connection requests to the origin server. The identity (the IP address and port number) of the implicit proxy is hidden from the client. The implicit proxy does not change or modify the routing information in the incoming URI before it connects the clients to the origin server. Edge servers are also defined as implicit proxies through the Flash proxy auto-detection process (FPAD). Flash Media Server and network administrators can deploy Flash Media Server and route the incoming connection requests to the origin server through one or more edge servers. These implicit edges are transparent because the client is unaware of the proxy. They are also sometimes referred to as interception proxies. This deployment strategy is useful to ISP and telco providers for optimizing the flow of RTMP traffic through their networks. 10 Using Edge and Origin Servers Administrators can explicitly specify that any connection request to an origin server be automatically routed through an edge or proxy server. For example, if your applications are running on fms.foo.com, you can redirect the connection request from the users' computers to another server (or virtual host) called fmsproxy.foo.com, which is configured to run in remote mode. Instead of making the usual connection to the applications with the following connection string: rtmp://fms.foo.com/app/inst the clients are redirected through the edge, which prefixes its protocol and hostname to an existing URI: rtmp://fmsproxy.foo.com/?rtmp://fms.foo.com/app/inst The prefix contains only the protocol, hostname, and optionally the port number. The URI must always end with a trailing slash. A question mark (?) separates the proxy's prefix from the main URI. Reverse proxies Sometimes you cannot configure the client (as is the case with mobile phones and devices) to send their connection requests for Flash Media Server services through an edge or proxy server. In these cases you might set up one or more reverse proxy servers and position them closer to the origin server. Reverse proxies are usually located within an organization's DMZ and control access to Flash Media Server resources from clients connecting through the Internet to an origin server located behind the firewall. Reverse proxies redirect incoming connection requests instead of outgoing connection requests as in the case of explicit and anonymous proxies. The reverse proxy intercepts all connection requests that arrive from clients, as well as any edge servers positioned on the outer side of a firewall, authenticates these requests, and then forwards them to the origin server. The origin server is always located on the inner side of the firewall. With a reverse proxy, you limit the access to an origin server on the trusted network. The reverse proxy blocks all traffic except what its configuration allows for. A reverse proxy also blocks any attempt to access other servers and their resources on the trusted network. A reverse edge server hides the presence and location of the origin server. Administrators can explicitly determine that connection requests to Flash Media Server be automatically routed through a reverse edge or proxy server. You can use RTMPS to configure a reverse proxy to listen on port 80 for non-secure connection requests and port 443 for secure requests. Introducing edge servers 11 For example, if your applications are running on fms-secure.foo.com, you can direct the connection requests from clients' devices or computers to the proxy server (or virtual host) called fms.foo.com, which makes the connection to fms-secure.foo.com, where your applications are running. The client is not aware that its request is being sent to another server. Routing information The Flash Media Server or network administrator specifies the routing information for a proxy or edge server in the RouteEntry tags of the Vhost.xml configuration file. Administrators use the Vhost.xml file to configure how and where to route connections to the desired destination. The protocol attribute in the RouteEntry tag specifies the protocol of the outgoing connection. This attribute must be set to either "rtmp" or "rtmps" to indicate a nonsecure or secure connection. The RouteTable container tag holds all the RouteEntry tags. For example, the RouteTable container may hold one RouteEntry tag to specify a secure outgoing connection by using RTMP, and another RouteEntry tag that specifies the nonsecure RTMP connection. If a protocol is not specified, the outgoing connection uses the same protocol as the incoming connection. For detailed information on these routing tags, see "Vhost.xml file" in Managing Flash Media Server. Connecting to an edge server Clients can explicitly connect to a specific edge server when they know it is available. You use a URI in a wrapped format to make the connection to an explicit proxy: rtmp://edge/?rtmp://origin/app You can also connect to a chain of proxies by forming a string that routes the outgoing connection requests through a sequence of explicitly identified proxies: rtmp://edge1/?rtmp://edge2/?rtmp?://edge3/?rtmp://edge4/?rtmp://origin/app As the connection moves through each edge in the chain, Flash Media Server drops the first token in the string. After making the connection to edge1, the connection string changes to: rtmp://edge2/?rtmp?://edge3/?rtmp://edge4/?rtmp://origin/app 12 Using Edge and Origin Servers Detecting the presence of proxy servers Flash Player 8 automatically detects any edge servers in its proximity. When an edge server is available, Flash Player automatically routes the connection from the client to the origin server through the proxy server. These edge servers are defined as implicit proxies since the client is generally unaware that its communication with Flash Media Server is being routed through a proxy. This use of an implicit proxy allows your current applications to continue working without any changes. Flash Player exposes the proxy information to the client only through the read-only properties on the NetConnection object. For more information on the NetConnection class, see the Client-Side Media ActionScript Language Reference. Earlier versions of Flash Player cannot automatically detect edge servers in their proximity. NO TE Chaining edge servers You can chain together any number of edges when you make connections to the origin server. The following URI shows how two explicit proxies are chained together to direct connection requests to the origin server: rtmp://proxy1/?rtmp://proxy2/?rtmp://origin/app/inst When you use URL decoration to chain proxies, Flash Player 7 and earlier versions may have problems with shared objects because of the embedded question mark (?) character in the URL. A workaround is available for clients who use earlier versions of Flash Player. You can resolve the problem by using the following function to escape the question marks from the URI before passing the URI to the shared object. function escapeURI(uri) { index = uri.indexOf(`?'); if (index == -1) return uri; prefix = uri.substring(0, index); uri = uri.substring(index); return prefix += escape(uri); } You call this function on the URI you are about to pass into the shared object, then use the result of the function instead of the original URI. Flash Player 8 resolves this problem for Flash Media Server. Introducing edge servers 13 A second problem surfaces when RTMPT is specified in the URI. You may specify this protocol only for the first prefix. The following are valid URIs: rtmpt://foo/?rtmp://bar/app/inst rtmpt://foo:443/?rtmp://bar/app/inst The following are invalid URIs: rtmpt://foo/?rtmpt://bar/app/inst rtmp://foo/?rtmpt://bar/app/inst Configuring edge servers All Flash Media Server functionalities--live streaming, on-demand streaming, messaging, shared object handling, scripting--take place as application instances. Application developers write scripts to create Flash Media Server applications, instances of which are then distributed by the Flash Media Server. A minimal application runs on the edge to perform connection aggregation, stream splitting, stream caching, and smart state management. This separation of tasks off loads to the edge server a large portion of the processing from the main application that runs on the origin server. Flash Media Server and network administrators can configure edge servers to function in different ways. The XML configuration files define how the edge servers connect clients to the origin server. These settings determine how the incoming URLs are routed between the edges and the origin server. You can have a computer run Flash Media Server in a mixed mode, in which certain virtual hosts on this system run applications locally, while others run applications remotely. To configure Flash Media Server, you edit or modify the XML tags in its configuration files. Following are some representative examples: The Anonymous tag in the Vhost.xml file configures the edge server as either an implicit (transparent) or explicit proxy. For more information, see "Anonymous" in Managing Flash Media Server. The Mode tag in the Vhost.xml file configures Flash Media Server to run as an origin or edge (proxy) server. For more information, see "Mode" in Managing Flash Media Server. The LocalAddress tag in the Vhost.xml file allows the administrator to control the network traffic by isolating incoming and outgoing traffic to separate network interfaces. For more information, see "LocalAddress" in Managing Flash Media Server. The Scope tag in the Application.xml file determines the process scope in which to run the application. Set this tag to run the applications and proxies in inst mode. Each application and virtual host has its own process. For more information, see "Scope" in Managing Flash Media Server. 14 Using Edge and Origin Servers You can find examples of the configuration files, their tag structures, detailed information about the tags, including cross references to associated tags, syntax, and examples in Chapter 3, "Configuration Files" in Managing Flash Media Server. Deploying a cluster of edge servers You can also deploy a group of connected edge servers as a cluster. Each edge server in a cluster can access the origin server. Clustering lets you distribute across the many edges in the cluster all connections to applications that are running on the origin server. The origin server always remains secure behind the edge servers. For example, Organization A deploys a cluster of edge servers on its internal network. The edge servers are defined as explicit proxies and dedicated to service specific users. When the clients or users want to connect to the origin server, the client first connects to one of the edge servers in the cluster. It is at this point where the connection requests are authorized or rejected. If the request is valid, the edge server makes the connection to the origin server, where the application is running. The origin server returns the results to the edge server, which passes them on to the requesting client. The edge server also stores the results in a cache, making it available to other servers and clients. As this organization grows or reallocates its resources, it can add more edge servers to the cluster or explicitly reassign clients to different edge servers. Organization B uses a cluster of edge servers to manage the inbound traffic from clients located outside of the network. This traffic is destined for Flash Media Server applications running on the origin server. When these users try to connect to the origin server, a load balancer positioned before the cluster routes the client's request to one of the edge servers. The edge server makes the connection to the origin server, where the application is running. The clients remain unaware of the presence of the edge servers. The origin server returns the results to the edge server, which in turn passes them to the requesting client. The edge server also stores the results in a cache, making it available to the other external clients. In this scenario, connections to applications are distributed across the many edge servers in the cluster. If one edge server in the cluster cannot access an application, another edge in the cluster handles the connection. Applications on the origin server are never directly exposed to connection requests coming through the Internet. This scenario describes how Organization B uses a reverse proxy to service incoming connections instead of outgoing connection, as was the case in the Organization A scenario. Introducing edge servers 15 Connecting to a cluster of edge servers When edge servers are configured into a cluster, the clients probably do not know that edge servers are present and servicing their connection requests. This is a secure and desirable strategy for disguising the address of the origin server. A different scheme for connecting clients to Flash Media Server is required. With a cluster of proxies in place, when the client attempts to connect to Flash Media Server, the call to the NetConnection.connect() method uses the User Datagram Protocol (UDP) to initiate a local broadcast of an FPAD message. The other edge servers in the network that receive the FPAD message respond to the client. The client automatically chooses the edge to connect to. The edge then makes the connection to the origin server. This brief scenario describes how a cluster of explicit proxies services outgoing connections to an origin server Enrolling proxy servers in the cluster Each proxy or edge in a cluster is dynamically assigned a numeric ID when it starts up. The edge broadcasts a message announcing its presence. All edges in the cluster that are currently running receive this message. Each edge responds with a message indicating its ID. The ID is assigned from a sequence of numbers: 0, 1, 2, ..., N-1, where N is the number of edges allowed in the cluster. The edge that is starting up waits for all of the responses to be received, then assigns itself the first ID not found in the sequence. When an edge server shuts down, it broadcasts a message announcing its exit from the cluster. Accessing applications through an edge cluster To maximize the conservation of network and bandwidth resources, Flash Media Server directs to the same edge in a cluster all clients that request a connection to an application. All the edge servers in the cluster automatically compute an affinity value based on the URI that the client wishes to connect to. When a client broadcasts an auto discovery process message to discover the available edges, an affinity value is returned in a message back to the client. After the client receives responses from all of the currently active edges in the cluster, it automatically selects the edge with the lowest affinity value to connect to. The affinity value is dynamic; it adjusts to the increasing or decreasing workload of connection requests and distributes the workload across edges in the cluster. For instance, consider how the notion of affinity value applies in a cluster of three edges: edge0, edge1, and edge2. As the workload on edge0 starts to peak, its connections start to spill over to edge1. Both have a computed affinity value of 1. As edge1's load increases, its connections start to spill over to edge2. Both have a computed affinity value of 2. As edge2's load increases, its connections start to spill over back to edge0. 16 Using Edge and Origin Servers When the load on an edge starts to scale down, so does its affinity value. Because the client always looks to connect to the edge with the lowest affinity value, this edge begins to take back connections that had spilled over into the next edge. The objective is to balance the number of connection requests to the available resources, and have all connections to the same application instance again pass through the same edge. The client logic remains simple: to connect to the edge with the lowest affinity value. The client only needs to know the affinity value for the different edges in the cluster to make the connection to the right edge. Clustering reverse proxies Reverse proxies are configured to redirect incoming connection requests instead of outgoing connection requests, as is the case with explicit and anonymous proxies. The client's request to connect to the desired application must first pass through the load balancer positioned before the cluster of reverse proxies before it reaches the origin server. When reverse proxies are deployed, the client's broadcast for a connection request cannot reach either an edge server or the origin server and the requested application. The URI for the proxy cluster or the origin server is not found on the client. Reverse proxying requires a different strategy for connecting clients and applications. Clustering works efficiently when all clients that request the same application instance connect to the same edge server in the cluster, where the application is cached. To accomplish this efficiency with reverse proxying requires a multistep procedure. 1. The client sends an HTTP request that includes an XML.load call to the origin server: http://origin[:]/fms/fpad?uri= 2. 3. 4. 5. 6. The load balancer on the remote network intercepts the request and routes it to one of the edge servers in the cluster. This edge server then acts as an FPAD client and broadcasts an FPAD message. The edge servers enrolled in the cluster respond with their affinity values. The broadcasting edge server chooses the edge server with the lowest affinity value. This edge server sends the required information back to the client: 10.133.192.85:1935 627539012 where the tag contains the host:ip address of the edge server to connect to. Introducing edge servers 17 7. The client then uses the information to make an explicit connection: first to the edge, then to the origin server using a wrapped URI: nc = new NetConnection(); nc.onStatus = function(info) { trace(info.code); } uri = "rtmp://yourcompany.com/app/inst"; myXML = new XML(); myXML.onLoad = function(success) { if (success) { var proxy = this.childNodes[1].childNodes[1].firstChild.nodeValue; uri = "rtmp://" + proxy + "/?" + uri; } nc.connect(uri); } myXML.load("http://yourcompany.com/fcs/fpad?uri=" + uri); The /fcs/fpad? code in the XML.load() URI tells the edge server that it needs to broadcast an FPAD message using the URI named uri, as specified. Setting up origin and proxy servers Use the following guidelines as you install and configure the origin and proxy servers. Using these guidelines helps ensure satisfactory performance and results: Make sure your Macromedia license permits you to use proxy servers or a proxy cluster. Deploy all proxy and origin servers on identical computers. Use the same operating system (Linux or Windows) on all computers to avoid conflicts with filenames. Linux uses case-sensitive filenames; filenames on Windows are case-insensitive. Install Flash Media Server on the first server. Configure this instance of Flash Media Server as an origin server. Install and configure Flash Media Server on all of the edge or proxy servers that your license permits. Make sure the fms.ini file is customized on each origin and proxy. The fms.ini file is machine-specific. Configure the origin server to listen on one port; you can configure proxies to listen on one or multiple ports. Verify that all proxies can access the origin server. 18 Using Edge and Origin Servers Locate the origin server and those edge servers nearest to it on the same subnet. If you are licensed to deploy a cluster, make sure all proxies in the cluster are configured identically. Configure the conf directory on one proxy. Place a copy of this conf directory in the same location on the other proxies. Place the load balancer between the clients and the proxies. Configure the balancer to access the proxies in round-robin mode. Do not place the load balancer immediately before the origin server. Use a load balancer when you deploy more than one proxy. To set up a cluster of edge servers: 1. Install and configure the first Flash Media Server. Use the same serial number and license file each time you install Flash Media Server. A special cluster license file is required. For more information, contact your Macromedia representative. N OT E 2. 3. 4. 5. 6. 7. Confirm that this Flash Media Server instance is working correctly. Configure the Flash Media Server instance as an origin server. Install and configure the next Flash Media Server in the cluster. Configure this Flash Media Server instance as an edge server. Make sure this edge server points to the origin server. Repeat steps 5 through 7 for each edge server that your license file allows. Your Flash Media Servers are now clustered. To expand the cluster's capacity, you may add new edge servers, if your license permits, to the cluster and configure them by following these instructions. Maintaining edge server clusters When an edge starts up, it broadcasts its presence to all other edges in the cluster. When an edge shuts down, it broadcasts that it is leaving the cluster. If an edge shuts down, all other edges in the cluster detect the change in state because the edges no longer receive the keepalive messages from that edge. The remaining edges automatically update their views of the cluster and remove the shut-down edge from their views. You only have to start and stop edges, and they automatically determine which edges are currently enrolled in the cluster. Introducing edge servers 19 Clearing the edge server cache Macromedia recommends that you create a weekly scheduled task to clear the edge server cache. To create a scheduled cache clearance: 1. Create a cache.bat file to empty the cache directory. The entry in the cache.bat file has the following syntax: del /Q /S \*.* 2. Run the cache.bat file and verify that it deletes files in the cache directory. Note that the directory structure remains; this is an expected behavior. Any files currently locked by the edge server are not deleted; this is also an expected behavior. 3. 4. Select Control Panel > Scheduled Tasks > Add Scheduled Task. Select cache.bat as the new file to run. Macromedia recommends that you schedule the task to run weekly during off hours, such as early Sunday morning. Replicate this procedure on each edge server. 20 Using Edge and Origin Servers