Documentation for Intellect 4.10.4. Documentation for other versions of Intellect is available too.

Previous page Configuring operation of distributed architecture in the failover mode  Configuring Failover mode 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 transfering 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 section). 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 so as the update is performed sequentially once in 3 seconds. Video is displayed as usual after update. If more than 64 cameras is added no 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 JScript language section of Programming Guide (JScript).

The configuration transfer time after losing communication 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 that the key be set to 1.
  4. The system objects tree (the more subsystems and modules, 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 verca):

  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 5TB 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 flowchart is in use, it is possible to configure both main and standby Servers for recording on the same network resource or several resources (see Using network disks section). In this case, the archive is always available no matter what Server operates with cameras.

N main Servers + standby server

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

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

The N main Servers + standby server flowchart:

The N main Servers + standby server flowchart when archive is recorded to one NAS:

If configuration from several main Servers is transferred to one standby Server, then provide enough processor resources, RAM and LAN on a standby Server in case when all main Servers become disabled.

Two Servers being standby for each other

Any Server can act both as a primary 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 write the archive to the network storage, access to the archive is available when the configuration is transferred. If the Servers write 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 a standby Server on NAS or local drive.

Limitations of the Failover mode

The Failover mode is configured using the Failover service objects created under 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 license 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 faulty 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 section). Time (in days) remaining for restoring the main Server is shown on the settings panel of the Failover service object:

When you log off INTELLECT™, configuration is not transferred from main Server to a standby server.

The number of failovers running simultaneously can be limited. For this the Manager of Failover services object is used. It is created under any LOCALHOST object (that is not a Client) in the system – see Role-assignment in distributed system section). Only one Manager of Failover services object can be created in the system.

If the number of dead servers exceeds the specified limit, configuration from new dead servers will be transferred to the corresponding backup Server as previously dead servers restore.

  • No labels