Odporność na błędy w monitoringu w chmurze: wdrożenie hybrydowe, dostęp lokalny i klastrowanie serwerów multimediów

Fault tolerance of a cloud video surveillance service involves more than protecting against the failure of an individual server. Losing connectivity to the operator’s platform, losing a Mediaserver, and losing access to previously recorded video are different failure scenarios. Each requires a corresponding architectural response.

Aipix supports several complementary building blocks: on-premises and hybrid deployment, direct local access through Lokalny pulpit, and Mediaserver clustering with video-stream reservation. These capabilities should be considered together when designing the service, while keeping their responsibilities and limitations distinct.

Hybrid deployment determines where video is processed and stored. Local operation provides an access path when external connectivity is unavailable. Mediaserver clustering addresses the failure of a server responsible for video streams. None of these mechanisms, by itself, establishes complete end-to-end availability or automatic protection of every archive file.

Hybrid deployment and local storage: reducing dependence on external connectivity

Aipix can be deployed on-premises within the telecom operator’s own infrastructure. This gives the operator control over the environment hosting the platform and its service data. An operator-hosted deployment should not, however, be confused with placing video-processing and storage resources at the customer’s premises: these are different architectural decisions.

In a hybrid enterprise deployment, a Serwer multimediów can be installed inside the customer’s security perimeter, with video recording and archive storage located on the customer side. The operator’s platform continues to provide centralized management and remote-access capabilities when the necessary connections are available. Aipix describes this model for organizations that need centralized services while retaining sensitive video workloads within their own infrastructure.

For resilience planning, the important design question is whether the local video path can operate independently of the external connection. In a suitably configured deployment, cameras, the local Mediaserver, storage, and the local viewing workstation can communicate within the customer’s network. Aipix documents Mediaserver operation both as part of the VSaaS platform and as a separate product, alongside a dedicated client for direct local access. These capabilities provide the basis for such a design, but the behavior of a particular installation during disconnection must be validated.

The distinction is important: placing an archive locally changes its location and network dependencies; it does not automatically create a redundant copy.

Likewise, a hybrid deployment containing one local Mediaserver should not be considered server-redundant simply because the operator also has servers in a data center. The design must establish which server can take over, whether it can reach the cameras, and which dependencies remain available during the failure being considered.

Local operation during a cloud-connection outage

Aipix documents Lokalny pulpit, a specialized Windows client that communicates directly with a Mediaserver without interacting with the VMS platform. It supports local video monitoring and access to recording archives when an Internet connection is absent or unstable. This should be distinguished from assuming that every standard Desktop installation automatically switches to an offline mode.

Desktop Local provides dedicated Live and Archive/DVR views. Archive functions include reviewing recordings and downloading recorded segments; archive retention and recording schedules are configured on the Mediaserver.

Local access must be prepared before it is needed. The documented authorization workflow requires at least one configured video surveillance server connection, using the appropriate server address, port, and token. Multiple connections can be configured, with one selected as the default; this configuration should not be interpreted as documentation of automatic client failover between servers.

For deployment acceptance, the operator should test local access with the external connection deliberately disconnected. The test should confirm that the workstation can still reach the Mediaserver, that the cameras remain reachable locally, and that the intended live-viewing, recording, and archive-access workflows behave as required.

The scope of this capability must remain clear. Desktop Local is a simplified client, not a replacement for every function of the full platform. Its documented independence from VMS does not establish that all centralized management, remote-access, or other cloud-dependent workflows remain available during an outage.

Local operation addresses loss of external connectivity. It does not, by itself, protect against failure of the local Mediaserver, storage, network, or power supply.

The core components of fault tolerance for cloud surveillance

Serwer multimediów. Captures camera streams, processes and distributes video, and records and manages video archives. A primary server handles the assigned streams; another server can be configured to reserve a stream for fault tolerance.

Controller. Coordinates the Mediaservers and supports system stability and failure tolerance. It receives status information and events from Mediaservers, allowing it to respond to changes in server, stream, and camera states.

Media server clusters. Logically group several Mediaservers. Their documented purposes include reserving video streams on cluster servers to improve fault tolerance and enabling bulk modification of server settings.

How stream reservation works

The central mechanism is a primary/secondary Mediaserver arrangement.

The documented mechanism works as follows:

1. A stream assigned to a primary Mediaserver. This server is responsible for processing that stream during normal operation.
2. An additional server reserved. Aipix identifies the additional server in the stream management interface as the server reserved for stream backup if the primary server fails.
3. The servers organized into a cluster. A cluster is a logical combination of multiple Mediaservers, allowing streams to be reserved on servers within the cluster.
4. The secondary server takes over if the primary fails. The glossary explicitly describes automatic takeover of primary functions in a two-server setup.

The documentation establishes automatic takeover, but does not specify a universal failover time, a zero-interruption guarantee, or that every in-progress recording and client session continues without interruption.

How the Controller coordinates fault tolerance for cloud surveillance

The Controller is responsible for coordinating the system’s response to changes in Mediaserver status.

Еhe mechanism includes these steps:

1. VMS sends commands. The VMS initiates operations by sending Remote Procedure Call (RPC) commands to the Controller.
2. The Controller executes commands. It performs the requested operations on cameras, cameras with preinstalled Agent firmware, Mediaservers and Bridge devices.
3. Mediaserver reports its state. A callback mechanism provides the Controller with current information about the Mediaserver, streams and cameras.
4. The Controller receives events. Notifications can report server and stream states, camera states, reconnection to a camera and whether archive recording is in progress.
5. The Controller responds to changes. It can log events, assign camera statuses and relay information to the VMS, supporting the overall fault-tolerance mechanism.

An important technical distinction: the documentation describes status reporting and event handling, alongside the Controller’s role in fault tolerance. It does not specify that every failover triggered by a particular callback or provide a detailed failure-detection algorithm, heartbeat interval, retry policy or timeout.

How to configure server redundancy in terms of fault tolerance of cloud surveillance

The relevant configuration through the VMS administrator interface.

Step 1: Create a media server cluster

In the administrator interface, open the Media Servers section and create a cluster. Add the Mediaservers that will participate in the arrangement.

Aipix documents cluster creation, adding servers, editing cluster settings and removing clusters.

Step 2: Assign the camera streams

Configure the camera’s media server assignment. The documented options include automatic distribution, selection of a standalone Mediaserver, and selection of a media server group.

For reservation, the relevant workflow searches for a cluster containing two servers: a primary and a secondary.

Step 3: Select eligible primary and secondary servers

During automatic server selection, Aipix checks:

• Whether stream distribution is enabled on the server.
• Whether the configured limit for the number of streams would be exceeded.
• Whether the incoming bitrate would exceed the configured traffic limit.
• Whether the server’s group matches the camera’s group.
• Whether storage utilization is within the permitted threshold.

The stream-transfer documentation specifies that storage usage must not exceed 80% of total capacity during that search. The general server-selection documentation also says that a server is unavailable for distribution if each disk load exceeds 80% in the basic configuration.

Step 4: Confirm the reservation

Once the automatic search completes, an administrator can manually select a cluster. The system then searches the selected cluster for two servers, primary and secondary. When the requirements are met, their names are displayed, and the administrator confirms the transfer or assignment.

Important: Aipix distinguishes assigning a camera to a single standalone Mediaserver from assigning it to a cluster with a reserved additional server. The standalone-server option uses the primary server only and does not assign a secondary server.

How server selection supports fault tolerance of cloud surveillance?

Fault tolerance depends on assigning streams to eligible servers, rather than simply distributing them to any available machine.

Describes these checks:

The system selects the least-loaded available server, considering incoming traffic and the other configured constraints. These checks help with appropriate server allocation, but load balancing by itself is not the fault-tolerance mechanism. The reservation of streams on an additional server is the specific redundancy mechanism.

What happens to the archive when streams move?

This is an important distinction when evaluating the overall resilience of a VSaaS deployment.

When video streams are transferred to another Mediaserver:

• The archive remains on the original Mediaserver.
• The archive indexes are transferred to the new Mediaserver.
• If archive recording was not enabled, the indexes are not transferred.
• If archive playback issues occur after the move, an administrator can use Reload index to refresh the indexes.

This means that stream reservation and archive redundancy are separate considerations. The documented stream failover mechanism should not be interpreted as proof that archive files are automatically replicated to the secondary server.

The Mediaserver glossary separately defines archive duplication as creating a backup copy of archived data by moving it or writing it in parallel to long-term storage. It also describes Ceph as a distributed storage technology that supports replication and fault-tolerant storage clusters. However, these glossary definitions do not establish that every Aipix deployment uses Ceph or that archive duplication is automatically configured as part of stream reservation.

What fault tolerance of cloud surveillance does and does not mean in Aipix

Documented capabilities:

• Multiple Mediaservers organized into clusters.
• Video-stream reservation on an additional server.
• Automatic takeover of primary functions by the secondary server in the documented two-server setup.
• Controller coordination and status/event reporting.
• Server selection based on configured capacity, traffic, group and storage criteria.

Not fully specified in the documentation reviewed

• Exact failover detection and recovery times.
• Whether every live client session reconnects without interruption.
• Whether archive data is synchronously replicated between primary and secondary servers.
• Whether recordings created immediately before a failure are guaranteed to be preserved.
• Whether Controller itself has an active/standby redundancy arrangement.
• Whether failback to the recovered primary server is automatic.

These are documentation limits, not proof that the platform lacks the capabilities. Their behavior would need to be confirmed in the relevant deployment documentation or with Aipix engineering.

Technical conclusion

Aipix service resilience is best evaluated as a combination of deployment architecture, local operational access, and media-processing redundancy.

At the Mediaserver layer, the documented mechanism remains a Controller-coordinated, multiserver architecture in which video streams can be reserved on an additional server. In the documented two-server setup, the secondary automatically takes over primary functions after a primary-server failure, while server-selection rules help allocate streams to eligible resources.

Hybrid deployment adds flexibility in placing video workloads and archives, while Desktop Local provides a direct access path that does not depend on interaction with VMS. These address a different part of the resilience problem from Mediaserver clustering.

For the operator, the design objective should therefore be explicit: preserve the required local workflows during connectivity loss, restore stream processing after server failure, and protect recorded video through separately specified storage and archive mechanisms. End-to-end availability must also account for the management components, network, storage, and power infrastructure.

The strongest resilience argument is not that any one mechanism prevents every outage. It is that complementary mechanisms address different failure scenarios, with their behavior verified in the deployed system.

Build a more resilient VSaaS service by combining hybrid deployment, local video access, and Mediaserver clustering. Design your architecture around the failure scenarios your service needs to withstand—and the continuity your customers expect.

Contact Aipix to discuss your deployment options, redundancy requirements, and recovery goals.