How to add failover to input¶

This feature solves the following problem: say, there are a few servers (up to 20), united in a group, and there are a bunch of streams that need to be ingested, not more than once on each server.

If one server fails, it is necessary to ingest streams on another server automatically.

This feature works as follows: configuration file defines all servers involved in ingesting, cluster authorization should be enabled:

cluster_key abcd;
peer flussonic:8080;
peer streamer:8081;
peer s03.myhosting.com;

Next you need to define your streams and use cluster_ingest directive:

stream cam01 {
  input file://vod/bunny.mp4;
  cluster_ingest;
}
stream cam02 {
  input file://vod/bunny.mp4;
  cluster_ingest;
}
stream cam03 {
  input fake://fake;
  cluster_ingest capture_at=streamer;
}

You can specify an explicit option to bind to a single server (capture_at). This is not a hard binding, because if the server is turned off, the stream will be started on others.

You can see the status of the servers in your cluster on the Cluster -> Overview tab.

For a sufficiently large number of streams they will be evenly distributed between the servers. Make sure to configure the load balancer to set the rules of distribution.

If the server is shut down, the streams will be automatically started on other servers. If it turns on, the streams will be restarted on the this server again. You can check current servers where the streams are running on the Streams page:

If we request a stream from any server in the cluster that does not have this stream, it will redirect you to a different server using a special code. So you can actually go to any server in this cluster, and you can be sure that you will be redirected to the currently active server.

Currently this feature can be used to capture video from a camera or in a situation where it is necessary to use a narrow channel for a large number of TV channels and distribute them among repeaters in the datacenter.

Timeouts¶

You can play with timeouts in this configuration, but you need to be very careful. Setting too small timeouts will make system unuseable.

Remember very important fact: in the network it is impossible to distinguish between connection loss and very long delay.

The example of a cluster configuration with timeouts:

cluster_key abcd;
peer flussonic1:8080;
peer streamer:8081 {
  fetch_timeout 1000;
  stale_timeout 3000;
}

This will tell Flussonic Media Server to fetch streams from peer once per 1 second (1000 milliseconds). It is VERY often, do not use it in production, but you should play with it. fetch_timeout is responsible for it.

stale_timeout 3000; will tell Flussonic Media Server to consider streams from that peer as dead after 3 seconds (3000 milliseconds) of non-response from that peer.

Thus, if that peer is overloaded and cannot respond in 3 seconds, it is considered to be dead and the cluster ingest mechanism will start its streams on local host.