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

Performance validation

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

Performance validation

  • The goal of our performance validation was to assess whether our proposed design could produce reliable metrics for sizing a variety of small, medium, and large deployment options. Most VMS and CV applications are sized by scaling out infrastructure based on per cluster node performance metrics. Our VxRail cluster was configured with three primary mixed workload application nodes plus one node for testing failover scenarios and one node held in reserve to spread out VMS and CV workloads if needed to achieve good performance. We monitored all key OS and application-specific performance metrics to see if we could detect any signs of resource exhaustion or process blocking. Our mixed workloads included processing a large simulated camera network with a Genetec VMS while simultaneously running BreifCam and Ipostek real-time alert processing for a subset of the total camera streaming workload.

    Camera simulators

    Video camera simulation software used for testing safety and security applications, including VMS and computer vision applications, allows system designers to stress test an entire end-to-end CCTV system. Enterprise-class video camera simulators allow testers to specify bandwidth requirements, quality, quantity, encoding, and source video files.

    The camera simulation system used for testing our design needed to meet the following requirements:

    • Camera simulators run on dedicated virtualized computing nodes independent of the VxRail platform.
    • The proposed bit rate for all cameras is ~3.5 Mb/s.
    • Specific source video files have been used to test the capability of the CV tool features we are targeting.
    • Simulators connect and stream directly to the Genetec VMS using a dedicated network segment (VLAN).

    Simulators

    Due to the nature of testing in a lab environment, it is not always practical to add hundreds of real cameras to the system during testing. To enable testing we leveraged a Genetec provided, software based, camera simulator and streamed H264 videos in to Genetec.

    Hardware

    All camera simulation was performed on a 2-node ESXi cluster using 2 x 750xa PowerEdge servers. We planned to simulate 675 cameras running on this simulation cluster. Each Simulator VM simulates 75 cameras with specific video files for Face Recognition/Object detection.

    Camera mapping to Genetec

    Our starting point for this design specified three Genetec Archivers per VxRail host. Genetec recommends not exceeding 300 Mb/s of incoming camera bandwidth per VM or server. To simplify testing, we mapped one camera simulator to one Genetec Archiver.

    The following table shows how the mapping of cameras to Genetec VMs and VxRail hosts was configured:

    Table 11. Camera mapping for VxRail hosts
    VxRail host Genetec Archiver Camera simulator Camera count
    Host 01 Archiver-01 Simulator-01 75
    Archiver-02 Simulator-02 75
    Archiver-03 Simulator-03 75
    Host 02 Archiver-04 Simulator-04 75
    Archiver-05 Simulator-05 75
    Archiver-06 Simulator-06 75
    Host 03 Archiver-07 Simulator-07 75
    Archiver-08 Simulator-08 75
    Archiver-09 Simulator-09 75
    Total 675

    Placement guidelines

    It is critical to assess the layout of the applications on the solution to ensure even and reliable performance for the system. It is also important to consider the impacts of high availability protection when defining placement rules.

    Placement rules

    The rules on placement of VMs are critical for small or medium size platforms due to the limited count of nodes in the system. This is less of a concern in a large system, but the rules must still be followed. Failure to follow the rules can result in some nodes that are over allocated and not in a HA configuration.

    The following rules should be considered for placing the VMs that are described in this guide:

    • A Maximum of 4 Genetec Archivers per VxRail Host
    • A Maximum of 2 CV processing nodes per VxRail Host (assuming 2 GPUs available)
    • Primary and secondary VMs for a system must not be on the same VxRail Host:
      • Ipsotek Management VMs cannot be on the same Host.
      • Ipsotek Database nodes cannot be on the same Host.
      • BriefCam Management nodes cannot be on the same Host.
      • BriefCam Database nodes cannot be on the same Host.
      • Genetec Directory nodes cannot be on the same Host.
      • Genetec Database nodes cannot be on the same Host.
      • Genetec Backup Archivers cannot be on the same Host as the Primary Archivers.

    These rules can be implemented as DRS Affinity rules in VMware to ensure that when VMs are migrated the cluster is in the correct state afterwards.

    Placement example

    The following is an example of an initial placement of VMs across the cluster:

    Table 12. VM placement across the VxRail cluster
    Node 1 Node 2 Node 3 Node 4 Node 5
    Genetec
    • Directory SQL Server Database
    • Expansion Server/Archiver
    • Expansion Server/Archiver
    • Expansion Server/Archiver
    		Genetec
    • Directory SQL Server Database 2
    • Expansion Server/Archiver
    • Expansion Server/Archiver
    • Expansion Server/Archiver
    • Backup Directory Server
    		Genetec
    • Main Directory Server
    • Expansion Server/Archiver
    • Expansion Server/Archiver
    • Expansion Server/Archiver
    		VxRail/vCenter
    • VxRail Manager
    • VMware vCenter Server Appliance
    BriefCam
    • Processing Server (with GPU)
    • Database Server
    		BriefCam
    • Processing Server (with GPU)
    • Web Console Server
    		BriefCam
    • Processing Server (with GPU)
    • VS Server
    Ipsotek
    • Management Server
    • Processing Server (with GPU)
    		Ipsotek
    • Management Server 2
    • Processing Server (with GPU)
    		Ipsotek
    • Datastore Server
    • Processing Server (with GPU)
    		Ipsotek
    • Processing Server (with GPU)
    In this example Node 4 has available capacity to host VMs in a planned or unplanned maintenance scenario. It is necessary to provision four Ipsotek processing nodes as they require passthrough GPU allocation and they cannot easily migrate around the cluster.

    Video workload

    The testing workload was generated by 675 camera simulators using three different source videos. The details of the videos used are as follows:

    Table 13. Video source details
    Type CV workload Resolution FPS Bit rate
    Crowd Scene None 1080 20 3.5 Mb/s
    Busy Hallway Face Recognition 1080 30 3.7 Mb/s
    Isolated Stairwell Object Detection 1080 20 2.8 Mb/s