Redundancy

The most important feature of any Audio/Video recording system is the reliability of the recording itself: Material may not be lost due to any hardware failure. This fact ánd the knowledge that any hardware part can fail, were important factors for the design of the LogDepot architecture.

The Logger applications (Audio and Video backend) have been designed só that there only task is capturing and digitizing the incoming AV signals, convert them to the required, native media formats and store these on their local hard disk. The backends are not aware of the rest of the system, neither the AV server, nor the network, nor the users. This is the only way to warrant that network and/or server failures will not affect the basic recording process: Even when the whole network stops working, the loggers will continue to record.

The Fetcher process on the AV server is responsible for the gathering of recorded material onto the central storage. The Fetcher “knows” what it needs (e.g. Room 517) and where to get it (on Logger #3 or on Logger #4). It will attempt to fetch the media files from Logger #3, and if this fails try to fetch from Logger #4. If both (or better: all) attempts fail, it will retry after a while and continue to do so, until the attempt succeeds.

This means that LogDepot can be designed completely redundant, when used in mission critical environments, which means that all encoders are mirrored. If an encoder fails, the server will automatically detect the problem, and will switch over to the mirrored counterpart. Failure of an encoder will not lead to any loss of video material.

The encoders have local buffers to keep a few days (typically) of media recordings. This can overcome a few days of network or server failure.

Apart from mirroring the Loggers, it is also possible to mirror the LogDepot server and storage (typically in another geographical location).