Documentation for Intellect 4.11.0-4.11.3. Documentation for other versions of Intellect is available too.

Previous page Configuring operation of distributed architecture in the failover mode  Configuring Failover service Next page


On the page:

Purpose and features of the Failover mode

Distributed architecture can operate in the failover mode. If the connection with one of distributed system Servers fails, then this mode enables transferring the configuration created under the Server to a Standby Server. A Standby Server temporarily becomes a video server and records archive in accordance with the settings of the Computer object that corresponds to a Standby Server (see Selecting the disks for video archive storage). When the connection is restored, the configuration is restored on the main Server.

Note

Video image update on Client Video Surveillance Monitors can take several seconds after configuration transfer, as the update is performed sequentially every 3 seconds. Video is displayed as usual after the update. If more than 64 cameras are added to the monitor, the update does not occur while the System Settings dialog box is open. The update period can be decreased by the monitor_refresh_delay registry key – see Registry Keys Reference Guide.

Note

When moving configuration to the backup Server and getting it back to the main Server the Failover service object generates START and STOP events. These events can be used in scripts for flexible system configuration. For examples, see Examples of scripts in the JScript language section of The Script object. Programming using the JScript language.

The configuration transfer time after losing connection with the main Server depends on many factors including but not limited to the following:

  1. Computer capacity.
  2. Data storage system speed.
  3. The value of the FastIndex key in the registry (see Registry keys reference guide). It is recommended to set the key value to 1.
  4. The system objects tree (the more subsystems and modules there are, the slower the configuration transfer).

Example

The following migration time is confirmed in both directions (i.e. from the main Server to the standby Server and vice versa):

  1. 100 cameras are transferred in less than 20 seconds;
  2. 200 cameras are transferred in less than 30 seconds.

The archive size tested was more than 5 TB and the Servers hardware as follows:
Main Server: Intel Core i5-8500, 16 GB RAM.
Standby Server: Intel Core i5-8400, 16 GB RAM.

Examples of Failover system organization

1 main Server + standby Server

If the main Server + standby Server operation scheme is in use (see the figure below), it is possible to configure both main and standby Servers for recording on the same network resource or several resources (see Using network disks). In this case, the archive is always available no matter which Server operates with cameras.

N main Servers + standby server

If the N main Servers + standby server operation scheme is in use (see the figures below), it is impossible to create a unified archive. In this case the main Servers perform recording on different logical drives (sections, partitions), local or network. If these drives are specified for archive recording on the standby Server, then the archives from different main Servers will mix.

The AxxonPlayer.exe utility can be used to access the archive created by the standby Server on NAS or local drive (see The Axxon Player utility for viewing and converting the video archive). Alternatively, the main and the backup Server archives can be synchronized through the Backup archive module (see Configuring archive synchronization of main and backup Servers).


If configuration from several main Servers is transferred to a single standby Server, you should foresee a situation where all main Servers fail and ensure that standby Server has sufficient CPU, RAM and LAN resources.

Two Servers being standby for each other

Any Server can act both as a main and as a standby at the same time given that the performance of the Server platform allows it. Therefore, a Failover system can be organized with two video servers that are standby in relation to each other.
As in the cases described above, if both Servers record the archive to the network storage, access to the archive is available when the configuration is transferred. If the Servers record a local archive or use different network storages, the AxxonPlayer.exe utility (see The Axxon Player utility for viewing and converting the video archive) or synchronization through the Backup archive module (see Configuring archive synchronization of main and backup Servers) can be used to access the archive created by the standby Server on NAS or on local drive.

Limitations of the Failover mode

The Failover mode is configured using the Failover service objects created on the basis of the Computer objects corresponding to backup servers in the Hardware tab of the System settings dialog box.

If the quantity of cameras is bound to specific Servers in the security key, then the license becomes invalid when cameras are moved to the backup Server. In this case the system gives 50 days to restore the failed Server in order to move the cameras back and the license to become valid again. Otherwise, Intellect will unload on the backup Server because the hardware limit is exceeded (see Features of the Intellect software operation when the object limit is exceeded). The time (in days) remaining for restoring the main Server is displayed on the settings panel of the Failover service object:

If Intellect is normally shut down on the main Server, the configuration is not transferred to the standby Server.

In case of manual shutdown of the main Server, the configuration is also not transferred to the standby Server.

The number of failover services running on each computer simultaneously can be limited. The Manager of failover services object is used for this. It is created on the basis of the Computer object that is not the Client (see Role-assignment in distributed system).

If the number of failed Servers exceeds the specified limit, the configuration from the new failed Servers will be transferred to the corresponding backup Server as the previously failed Servers become operational.

  • No labels