Backup plans are important. While we’re confident Biamp products will work properly and we have a dedicated support team in place to ensure that they do, we recognize that sometimes things happen. That’s why Tesira SERVER offers built-in redundancy functionality. Redundancy allows designers to centralize critical parts of the processing into a SERVER that can be loaded with numerous DSP cards, and have an identical SERVER with the same load-out operate as a backup. A designer can then place expanders in all the endpoints, which is a low-cost method of distributing audio around a large space. All the processing is centralized into the SERVER, and if something happens to that SERVER there’s another one that can take over.

Centralized processing offers multiple benefits, including restricting expenses to a limited number of powerful devices – in this case, Tesira SERVER with enough DSP cards to accommodate the needs of the system. However, centralized processing can be daunting. If multiple expanders are all connected to a single processing device, the entire system will fail if that processing device is lost. Redundancy is an excellent solution. Biamp-specific redundancy benefits include ease of setup, ease of configuration, and the sophisticated ability of the secondary SERVER to find all expanders. There is no manual intervention required to make a secondary device operate as expected. Redundancy isn’t limited to smaller installations or centralized processing, although the redundancy functionality is only available with Tesira SERVER (not SERVER-IO or TesiraFORTÉ). A pair of redundant SERVERs can be part of a massive system in a large enterprise organization that includes numerous Tesira SERVER-IOs and TesiraFORTÉs, and multiple redundant pairs of Tesira SERVERS can be deployed if needed. Those pairs will manage the mission-critical blocks of processing within a larger system to make it as robust as possible.

Because Biamp’s software is somewhat distinct, in that you create a system file instead of programming devices, setup for redundancy is easy. Simply tag the processing blocks you want to be redundant. When you compile the file, it will assign those to both SERVERs in the redundant pair, and then when you install the SERVERs that are paired together, one is designated as the primary and the other is designated as the secondary. The process is mostly automated. During the initial setup and commissioning, the installer or commissioning designer can manually cause a failover as a test to make sure the secondary SERVER is ready to go. The secondary SERVER watches the primary’s activities, including changes – to levels, mutes, presets, or other functions that can be altered live within a Tesira system – implemented by system operators or end users, and adapts itself in real-time to ensure that both devices remain identical. In addition, we have processing blocks that are adaptive. The secondary SERVER is also responding to those adaptive parameters as they occur in the primary. Whatever the algorithms are doing, the secondary is adapting in real-time.

With redundancy in place, if the primary SERVER fails for any reason, the secondary will take over the audio processing and proxying of any expander devices. Rather than taking over in a default state, the secondary is taking over in a state that is actually live to what the primary was doing. After it comes online, the secondary will immediately begin finding any expanders that were attached to the primary, and sending audio as quickly as it can establish connections with those expanders. The primary SERVER can be self-restoring in many cases, such as a temporary loss of AVB capability or if a cable is unplugged and plugged back in. Once the primary SERVER is back online, it will not retake control of the system. Instead, the primary will act as if it’s the secondary SERVER and will not interrupt audio to try to reassert itself. In the rare event of a hardware failure, which would require repair or replacement, the new or repaired primary unit will also not attempt to take control of the system when re-installed. Because it’s part of this pair, the primary will automatically know that the secondary is now the one running the system. This arrangement can continue indefinitely, or, if preferred, the system operator can choose to manually force a failover to return both devices to their original designations. There is no functional difference between the two units, but some system operators prefer the original primary to run the system.

Thanks to redundancy, you can feel confident that a system will continue functioning normally, with minimal disruption of the audio and without compromising any mission-critical functions – all with no human intervention.