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 validation

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

High availability validation

  • As described in the Solution Architecture, a key element of this design is to provide high availability for every application. Since VxRail, VMware, and our partner solutions all offer features for implementing high availability, there are many possible implementation design patterns. We present only one of the many possible approaches to HA in this section but there are many more options that can be explored based on the specific needs of your environment.

    The following high availability features were tested against our design:

    • VxRail high availability
    • VMware vSphere vMotion (for the BriefCam VS Server service)
    • VMS and CV application high availability

    VxRail high availability

    VxRail provides a seamless, curated, and optimized hyperconverged experience based on the joint engineering efforts of Dell and VMware. This deep integration combined with the simplicity of VxRail provides an ideal platform for implementation across most core, edge, and cloud environments. ​The VxRail HCI System Software coupled with the performance of next-generation PowerEdge servers offers an industry-proven scale-out high-performance platform. Our CV for Transportation platform design uses a 5-node VxRail cluster that was validated through the execution of simulated workloads. We demonstrated previously in our Performance Testing sections that the system scales horizontally by adding additional nodes. For more information, see the Sizing the solution section.

    Planned downtime validation

    Description This test simulates the scenario where a hardware node of the VxRail cluster must be taken offline for maintenance.
    Steps
    • The Ipsotek application VM running on the affected node uses a GPU in passthrough mode and therefore must be manually shut down since it cannot be migrated to another node in the cluster.
    • An administrator changes the node state to "Maintenance Mode" using the vCenter console.
    • Migrate any eligible workloads off the affected host.
    • Perform maintenance on the affected host, such as patch and reboot.
    • Exit maintenance mode and return the VxRail cluster to normal operation.
    Expected results Any workload that can migrate is redistributed across the cluster. All services that cannot migrate but are protected by application-level high availability continue to provide services with zero downtime.
    Results
    • After the host was successfully put into Maintenance Mode using the vCenter console, all active VMs were migrated to other hosts in the cluster with capacity.
    • The host that was shut down contained:
      • 3 x Genetec Recorders
      • 1 x Backup Genetec Directory Server
      • 1 x Genetec Primary Database
      • 1 x BriefCam Processing Node
      • 1 x Ipsotek Management Node
      • 1 x Ipsotek Processing Node (not migrated)
    • Zero alerts on the Genetec Directory server. All cameras continued processing as normal.
    • Zero Events on the BriefCam Admin Console. All cameras continued processing as normal.
    • Zero alerts on the Ipsotek Management console. All cameras continued processing as normal.

    Unplanned downtime validation

    In the unlikely event that there is an unplanned outage of a VxRail node, it is important that the system continues to operate with minimal disruption to services.

    Description This test simulates a hardware failure of a node in the VxRail cluster.
    Steps
    • Simulate a failure by forcing the shutdown of a selected VxRail host.
    • Use the Dell iDRAC interface to log in and forcibly shut down one host at the hardware level.
    • This test procedure ensures that the system has no opportunity to offload any workload to another host before the shutdown occurs.
    Expected results
    • All VMs that are residing on the failed node should be migrated automatically to an available location on the cluster.
    • This process involves a latency that must be measured and to avoid this latency Application HA must be configured.
    Results
    • The Host-02 VxRail node was forcibly shut down using iDRAC.
    • vCenter displayed an error showing Host-02 offline .
      • All VMs showed their status as "Disconnected".
      • VMs were not operational at this time.
    • The VxRail HCI system auto migrated the VMs assigned to Host-02 to another host with capacity in the cluster.
    • After migration, the VMs were powered on automatically.
    • The Ipsotek VM was not able to migrate since it does not support vGPU. This VM stayed in a down state with the error "vSphere HA virtual machine failover failed".
      • When the original host (Host-02) became available the Ipsotek VM was rebooted and continued processing as expected.
    • All migrated hosts were rebooted after 2 minutes and were processing workload a minimum of 5 minutes after the failure.
    • The specific VMs that were part of this test were:
      • BriefCam Processing Node
        • No issues as part of a Cluster. See BriefCam validation below.
      • BriefCam Web Node
        • No issues as part of a Cluster or can be unavailable during the outage.
      • Genetec DB
        • No issues as part of a SQL Server Failover Cluster with replication.
      • Genetec Recorders 6, 7, 8
        • These recorders stopped processing for a minimum of 5 minutes.
        • Backup Archivers can be configured if this is a concern in an extremely rare Hardware failure scenario.
      • Ipsotek Processing Node
        • This cannot migrate. It remained down for the duration of the outage.
        • This is expected behavior due to no vGPU support and has been built in to the Ipsotek architecture.
      • VxRail Manager
        • This is a system VM and was migrated automatically to another host in the VxRail cluster.

    Application high availability

    The primary applications that were part of the validation are:

    • Genetec 5.10
    • BriefCam 6.1
    • Ipsotek 11.7

    Each application was setup following the vendor recommendations. Additional HA validations were performed in addition to the VxRail HA tests.