Clustering Use cases
The following sections describe several use cases for utilizing clusters.
A most common use case for small productions and events is to have one Origin and one Edge. The Origin is included in the round robin and because of that, both servers receive subscribers.
Both the Origin and Edge cluster.xml files are edited to show
The Edge is also configured with the Origin IP. The Edge initiates the connection and reconnection if the Origin becomes unavailable.
Stream providers use the Origin IP as the server to connect to. The streams are then repeated at the Edge.
Subscribing clients use the Origin IP to call the round robin service and receive either the edge or the Origin IP. They then subscribe to the stream at the provided host IP.
Another common use case is to have multiple Edges and one Origin where subscribers are given only the Edge IP.
The Origin cluster.xml file is edited to show
true. This removes it from round robin sequencing. Edges are all set so
The Edges are configured with the Origins IP, and they will initiate the connection to the Origin and reconnection if the Origin becomes unavailable.
Stream providers use the Origin IP as the server to connect to. The streams are then repeated at the Edges.
Stream consumers use the Origin IP for calling the round robin servlet. They then subscribe to the stream at the provided host IP.
After setting up three Edges and One origin as described, you can add another Origin. All Edges are given two Origin IPs in the cluster.xml configuration file.
Restart the Edges and the new Origin.
Publishers can use either origin and all streams will be received by all edges.
Subscribers can use the round robin service at either Origin and receive an active Edge IP.
If the broadcasters are in one geographic region and subscribers in another one very far removed, then one might want to set up a server cluster with intermediary servers between the Edge and Origin servers. In this case, the first intermediary server would be set up as an Edge server referencing the Origin server in its cluster.xml configuration file. The next intermediary server would reference the previous intermediary as an Origin server in its cluster.xml configuration file; and the final link in the chain would reference the previous intermediary server as its Origin in its cluster.xml configuration file.