Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Design Guide—Virtualized Computer Vision for Smart Transportation with Genetec
Introduction Architecture concepts and requirements Solution Architecture Validation
Validation overview
Performance validation
Performance results and findings
Performance summary
High availability validation
High availability results and findings
High availability summary
Sizing the solution Backup and restore operations Monitoring the solution Troubleshooting recommendations Summary and conclusions References

High availability results and findings

Home > Workload Solutions > Computer Vision > Guides > Design Guide—Virtualized Computer Vision for Smart Transportation with Genetec > High availability results and findings

High availability results and findings

  • BriefCam HA results

    BriefCam supports a rich set of active/active as well as active/passive HA features. In this validation, we tested both native HA features plus some VxRail provided HA. Protecting mission-critical CV applications is becoming an increasingly important aspect of facilities management. One of our design goals is to provide the best combination of native and VMware HA to protect everything from a specific VM to the full cluster to avoid operational disruption.

    The BriefCam application has full support for the following features when building an HA solution.

    • Redundant Microservice architecture
    • Backup Management console
    • Backup Database servers

    Validation scenario 1

    Description This test simulates a failure of a machine that runs the real-time Alert Processing Service.
    Steps
    • Select any BriefCam Alert processing VM and shut it down. It must have active camera traffic.
    • Monitor camera behavior in the Web console.
    • Measure the time taken for the camera to be moved to an active node in the cluster.
    Expected results
    • When a Camera Processing VM is shut down that other nodes take over and process the camera alerts instead.
    • The time taken for the processing to switch from a failed node to an active one is measured.
    Results
    • When the Alert Processing VM was shut down, the cameras went into the status "Active (Queued)".
    • No alerts were being triggered in this state.
    • After a minimum of 5 minutes, the camera streams were picked off the database queue and launched on another processing node in the cluster.

    Validation scenario 2

    Description This test simulates a failure of a machine that runs the VS Service.
    Steps
    • Use Windows Service Manager to stop the running VS Service while active camera streams are being processed.
    • Monitor camera behavior in the Web console.
    • Measure the time taken for the streams to be processing.
    Expected results
    • HA protection for the VS Service is active/passive
    • The time taken for the processing to resume after starting the VS Service on another node is measured.

    Results
    • When the VS Service was shut down, all processing went into a queued state.
    • No alerts were being triggered in this state.
    • We followed the process for manual failover of the VS service.
    • As soon as the VS Service was started on a standby server, the camera streams were picked off the database queue and allocated to a processing node in the cluster.

    Genetec HA results

    The Genetec platform has multiple options to provide HA within a VMS system such as:

    • Backup Directory Servers
    • Backup Archiver servers
    • Backup Database servers

    Validation scenario 1

    Description This test simulates a failure of the main Directory server.
    Steps
    • Configure a secondary Directory server in the Genetec Config Tool.
    • Ensure to use a dedicated SQL Server cluster setup in failover mode.
    • During processing of Camera streams the main Directory server is shut down.
    Expected results The cameras continue to record during this simulated failure scenario, and the secondary directory server becomes the primary.
    Results
    • The primary directory server became unresponsive, and the Config Tool could not log in.
    • Cameras continued to process on the expansion nodes that had the Archiver role enabled.
    • The secondary Directory service became the primary.
    Note: During initial tests, the failover had a problem because licenses must be revalidated with Genetec once additional backup Directory servers are added. The full details are in the Security Center Administrator Guide 5.10. To access Genetec documentation, contact your Genetec representative.

    Ipsotek HA results

    Ipsotek supports additional application-level security on top of the VxRail provided HA. This security protects against an issue with a specific VM when the full cluster is still operational.

    The Ipsotek application has full support for building an HA solution. It is possible to build two fully redundant systems processing systems and also to build redundancy in to a single cluster.

    The single cluster option was used for this testing and has the following features:

    • Multiple active Camera Alert processing nodes
    • Backup Management console (active/passive)
    • Multiple Database servers (min 3-node cluster)

    Validation scenario 1

    Description This test simulates a failure of a machine that runs the core Camera Alert processing.
    Steps
    • Select any Ipsotek processing VM and shut it down to simulate failure.
    • Monitor camera behavior in the Ipsotek configuration tool.
    • Measure the time taken for the camera to be moved to an active node in the cluster.
    Expected results
    • When a Camera Processing VM is shut down that other nodes take over and process the camera alerts instead.
    • The time taken for the processing to switch from a failed node to an active one is measured.

    Results:

    • Once the VM was shut down 15 cameras went in to "Active - No Video" mode in the Management console.
    • The cameras were automatically distributed to among the remaining three active Ipsotek Processing nodes.
    • After a maximum of 30 s, all cameras were back processing alerts. A camera is reassigned to a new cluster member after 20 s downtime. The Management console refreshes the camera status every 30 s.
    • The "Processing Node Information" view on the Management console shows that one node is not part of the cluster and that the workload has been distributed among the remaining active nodes.
    • Once the Processing node was restarted, it automatically rejoined the cluster.
    Note: Once an Ipsotek Processing node joins a cluster, the cluster will not automatically rebalance to adjust the workload. This is to ensure camera availability and avoid unnecessary down time moving cameras across the cluster. If this is required, cameras can be disabled and enabled to distribute to the new nodes.