N+1, N+M redundancy schemes in Flussonic Media Server¶

Overview of redundancy schemes¶

The use of redundancy schemes is particularly important in the IPTV industry, as it is critical to ensure the availability and reliability of the system. Downtime can result in lost revenue and customer dissatisfaction, making it essential to implement redundancy schemes to minimize the risk of failures.

Flussonic Media Server includes a cluster ingest functionality that allows for the configuration of redundancy schemes. In this article, we will discuss how to use the cluster ingest functionality to set up redundancy schemes in Flussonic, including N+1 and N+M schemes.

N+1 and N+M redundancy schemes are two common types of redundancy schemes that can be used to ensure the reliability and availability of a system. In an N+1 scheme, there is one additional device beyond the minimum number needed to perform the required tasks, while in an N+M scheme, there are M additional devices beyond the minimum number needed.

One key difference between N+1 and N+M schemes is the level of redundancy they provide. N+1 schemes provide a lower level of redundancy, as they have a single additional device that can be used as a backup in case of failure. N+M schemes, on the other hand, provide a higher level of redundancy, as they have M additional devices that can be used as backups, but if more than one of these devices fails, the system will still be at risk of failure.

Another difference between N+1 and N+M schemes is the cost and complexity of implementation. N+1 schemes tend to be more cost-effective and simpler to implement, as they require only a single additional device. N+M schemes, on the other hand, require M additional devices, which can increase the cost and complexity of the system.

So, when should you use an N+1 scheme versus an N+M scheme? It really depends on your specific needs and requirements. If you are looking for a high level of redundancy and are willing to pay a higher price and accept a more complex system, an N+M scheme may be a good choice. On the other hand, if you are looking for a more cost-effective and simpler solution, an N+1 scheme may be a better fit.

In addition to N+1 and N+M redundancy schemes, there are several other types of redundancy schemes that can be used to ensure the reliability and availability of a system. These include:

Hot standby: In a hot standby system, one device is used as the primary device, and a second device is used as a backup. The backup device is kept in a standby state, and is ready to take over if the primary device fails. This type of redundancy scheme is often used in critical systems where it is important to minimize downtime and ensure that the system can continue to operate without interruption.
Cold standby: In a cold standby system, a backup device is kept in a dormant state, and is activated only in the event of a failure of the primary device. This type of redundancy scheme is typically less expensive to implement than a hot standby system, as the backup device is not kept in a standby state and does not require as much maintenance or resources. However, it may take longer to activate the backup device in the event of a failure, which could result in longer downtime.
Clustering: In a clustering system, multiple devices work together to perform the same tasks, and can automatically take over if one of the devices fails. This type of redundancy scheme is often used in systems where it is important to ensure high availability and the ability to continue operating even if one of the devices experiences a failure.

Introduction to the cluster ingest functionality in Flussonic and how it can be used to set up redundancy schemes¶

The cluster ingest functionality in Flussonic Media Server allows for the configuration of multiple Flussonic servers or Flussonic Coder appliances that work together as a cluster to perform the same tasks. Each server in the cluster is referred to as a "peer," and each peer can be configured to perform specific tasks, such as transcoding, recording, or pushing video to other servers.

If one of the peers in the cluster fails, the streams that were being processed on that peer will be automatically distributed among the remaining peers. This helps to ensure that the system continues to operate smoothly even if one of the peers experiences a failure.

The cluster ingest functionality can be used to set up various types of redundancy schemes, including N+1 and N+M schemes. In an N+1 scheme, there is one additional device beyond the minimum number needed to perform the required tasks, and in an N+M scheme, there are M additional devices. By configuring multiple peers in a cluster and using the cluster_ingest and capture_at options, you can set up an N+1 or N+M redundancy scheme in Flussonic.

Detailed examples of setting up an N+1 and N+M redundancy scheme using Flussonic's cluster ingest functionality¶

To set up a redundancy scheme using Flussonic's cluster ingest functionality, follow these steps:

Configure a cluster of servers in Flussonic. To do this, you will need to specify the same cluster key in the configuration file for all of the servers in the cluster, and specify a list of the other servers in the cluster for each server.
Use the cluster_ingest option in the stream configuration to indicate that the stream should be processed by a cluster of servers.
Use the capture_at option to specify the primary server for the stream. If the primary server fails, one of the other servers in the cluster will automatically take over and assume its role.

Here is an example configuration that sets up an N+1 redundancy scheme using Flussonic's cluster ingest functionality:

cluster_key abcd;
peer transcoder1;
peer transcoder2;
peer transcoder3;

stream mystream1 {
    url rtmp://source.com/live/mystream1;
    cluster_ingest;
    capture_at transcoder1;
}
stream mystream2 {
    url rtmp://source.com/live/mystream2;
    cluster_ingest;
    capture_at transcoder2;
}

This configuration is setting up an N+1 redundancy scheme using Flussonic's cluster ingest functionality. In this configuration, there are three servers in the cluster: transcoder1, transcoder2, and transcoder3. Each of these servers is configured to process all of the streams in the system.

The cluster_key option is used to specify the same cluster key for all of the servers in the cluster. This key is used to establish communication between the servers and ensure that they are able to work together as a single unit.

The peer options are used to specify the other servers in the cluster for each server. This allows the servers to communicate with each other and coordinate their activities as a single unit.

The stream options are used to specify the streams that should be processed by the cluster. The cluster_ingest option indicates that the stream should be processed by a cluster of servers, and the capture_at option specifies the primary server for the stream. If the primary server fails, one of the other servers in the cluster will automatically take over and continue processing the stream.

It is important to note that this configuration should be identical on all of the servers in the cluster. This ensures that all of the servers are properly configured to work together as a single unit and are able to communicate with each other.

In this configuration, two streams are being processed by the cluster: mystream1 and mystream2. Each stream is being processed by a specific primary server, as specified by the capture_at option. For example, mystream1 is being processed by transcoder1, and mystream2 is being processed by transcoder2.

If one of the primary servers fails, one of the other servers in the cluster will automatically take over and continue processing the streams that were being handled by the failed server. For example, if transcoder1 fails, it is most likely that transcoder3 will take over and continue processing mystream1, as transcoder2 is already busy processing mystream2.

It is important to note that this example uses only two streams for simplicity, but the same concept applies to any number of streams. In a real-world system, there could be hundreds or even thousands of streams being processed by the cluster, split between dozens of servers. The key principle is that each stream is being processed by a specific primary server, and if that server fails, one of the other servers in the cluster will automatically take over and continue processing the stream.

By using Flussonic's cluster ingest functionality, you can easily set up a redundancy scheme to ensure the reliability and availability of your streams, regardless of the number of streams or servers in the system.

Tips for troubleshooting and debugging issues with the redundancy scheme¶

When setting up a redundancy scheme using Flussonic Media Server, it is important to be prepared for potential issues and know how to troubleshoot and debug them. Here are some tips for troubleshooting and debugging issues with the redundancy scheme:

Check the logs: Flussonic Media Server logs detailed information about its activities, including any errors or issues that may occur. By reviewing the logs, you may be able to identify the cause of any problems and take steps to resolve them.
Test the failover process: To ensure that the failover process is functioning properly, you can simulate a failure by shutting down one of the servers in the cluster and verifying that the other servers take over and continue processing the streams as expected.
Check the network configuration: Make sure that the servers in the cluster are properly configured and can communicate with each other over the network. This is especially important if you are using different network interfaces or VLANs for the cluster.
Review the configuration: Make sure that the configuration for the cluster and the streams is correct and matches the desired redundancy scheme. Double-check the cluster_key, peer, and capture_at options to ensure that they are set correctly.
If you are unable to resolve the issue on your own, consider reaching out to Flussonic technical support for assistance. They can provide expert advice and guidance to help you resolve the issue. You can find more information on how to contact Flussonic technical support at Support page.

By following these tips, you can effectively troubleshoot and debug any issues that may arise with the redundancy scheme in Flussonic Media Server.

Summary of the key points and best practices for configuring a redundancy scheme using Flussonic¶

Here is a summary of the key points and best practices for configuring a redundancy scheme using Flussonic Media Server:

Configure a cluster of servers in Flussonic by specifying the same cluster key in the configuration file for all of the servers and specifying a list of the other servers in the cluster for each server.
Use the cluster_ingest option in the stream configuration to indicate that the stream should be processed by a cluster of servers.
Use the capture_at option to specify the primary server for the stream. If the primary server fails, one of the other servers in the cluster will automatically take over and assume its role.
Make sure that each server in the cluster has a complete and accurate list of the other servers in the cluster. This is necessary for the servers to communicate and work together as a single unit.
Choose the appropriate redundancy scheme based on your needs and the requirements of your system. Options include N+1, N+M, cluster and hot standby (1+1).
Test and monitor your redundancy scheme to ensure that it is functioning properly and providing the level of reliability and availability you need.

By following these best practices, you can effectively configure a redundancy scheme using Flussonic Media Server to ensure the reliability and availability of your streams.