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
Physical architecture
Virtualized infrastructure
Computer vision applications
Validation Sizing the solution Backup and restore operations Monitoring the solution Troubleshooting recommendations Summary and conclusions References

Computer vision applications

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

Computer vision applications

  • The primary goal of developing and testing this solution design was to determine if a single-converged platform could be used to virtualize VMS and CV applications from multiple vendors. The initial applications that were used for validation include Genetec VMS, Ipsotek, and BriefCam.

    Genetec VMS

    The VMS system software and versions tested were:

    • Windows Server 2019 Operating System
    • Genetec 5.10
      • Directory Servers
      • Expansion Nodes
      • SQL Server Databases

    BriefCam CV

    The BriefCam solution software and versions tested were:

    • Windows Server 2019 Operating System
    • BriefCam 6.1
      • PostgreSQL Database
      • BriefCam Processing Servers (with GPU)
      • BriefCam Web Services

    Ipsotek CV

    The Ipsotek solution software and versions tested were:

    • Windows Server 2019 Operating System
    • Ipsotek 11.7
      • Database Nodes
      • Ipsotek Management Nodes
      • Ipsotek Processing Nodes (with GPU)

    Genetec architecture

    Genetec offers a scalable VMS that lets customers easily expand their security systems as they grow. The Genetec VMS comes in four different packages: Compact, Standard, Pro, and Enterprise. This project tested the Enterprise solution that supports an unrestricted number of cameras and clients. Customers have reported they value Genetec's large-scale live monitoring capability and the availability of various integrations with third-party systems ( Gartner 2019).

    Genetec has designed the Security Center platform to unify data management, security policy management, monitor events, and run investigations. There are extensive ecosystem partners that can be used to expand your systems with a mix of technologies that allow organizations to meet their emerging threats. The Security Center web client along with a full set of developer APIs offer a platform that is flexible enough to accommodate new types of data and applications in a seamless single user interface (UI).

    Configuration best practices

    The following Genetec guidelines are based on previous internal testing and reports from customer field experience. None of these guidelines were exceeded during testing.

    CPU
    Do not assign more vCPUs to your VMs than the number of physical cores on the host machine.
    Memory
    Assign at least 16 GB of RAM to each VM and keep 16 GB of RAM unallocated for the hypervisor. The total amount of memory allocated to the VMs and the hypervisor should not exceed the total amount of physical memory available from the host.
    Storage
    • Install Microsoft Windows and Microsoft SQL databases on a dedicated, high-performance drive, usually on an SSD or a Storage Area Network (SAN) with SSD or hybrid storage. This is achieved by using the VxRail V670f which uses all flash storage.
    • Do not use the OS drive for archived video.
    • Make the OS partition at least 120 GB.
    • For archived video, configure Archiver video disks inside one of the following:
      • A PowerScale NAS share, such as the A2000.
      • Raw Device Mapping (RDM) for fiber channel.
    Networking
    • Isolate video traffic on a different VLAN from storage traffic.
    • 40 GbE is the preferred configuration or at least 10 GbE network cards for shared traffic (management, video, and storage) with a Virtual Switch.
    • Otherwise, dedicate a 1GbE network card per VM for video traffic.
    Note:
    • In-Guest iSCSI networks with other configurations might result in degraded performance.
    • Alternate network configurations might result in multicast traffic being sent to all hosted VMs simultaneously. Depending on the host or its configuration, this might impact the overall performance.


    Security Center
    When provisioning multiple archiving VMs on a host, do not exceed the following data transmission rates:
    • 300 Mbps for incoming and outgoing video on each VM.
    • 1200 Mbps for incoming video and outgoing playback on each host.

    High availability

    It is critical to design a high availability deployment of Genetec to avoid loss of camera stream data during an unplanned outage.

    Database

    Security Center does not handle the failover of role databases. For roles that connect to a database, the database servers must be hosted on a VM separate from the servers hosting the role. All role servers must have read and write access to the database servers. To protect your data, perform regular backups of the role database.

    If you are installing SQL Server Standard or Enterprise edition, you must purchase it from Microsoft, and download the installation package. The installer for SQL Server Express is included in the Security Center installation package. SQL Server Express only works on 64-bit operating systems.

    When using multiple SQL Servers, there are three database failover modes supported for the Directory database:

    Backup and restore
    The Directory Manager protects the Directory database by regularly backing up the primary database instance (source copy). During a failover, the latest backups are restored to the backup database that is next in line. Two schedules can be defined: one for full backups, and another for differential backups.
    Mirroring
    Database failover is taken care of by Microsoft SQL Server and is transparent to Security Center. The Principal and Mirror instances of the Directory database are kept synchronized at all times. There is no loss of data during failover.
    SQL AlwaysOn
    Use this failover mode if you are using the Windows feature SQL AlwaysOn as your high availability and disaster recovery solution.

    Genetec recommends using SQL AlwaysOn for database high availability and this approach was used during our testing.

    Genetec roles

    The Genetec system is made up of multiple roles and some of the critical roles for video management are:

    Table 3. Genetec roles for video management
    Role Supports role failover Comments
    Directory Yes Can run simultaneously on up to five servers. Supports Load Balancing. Also supports Directory database failover.
    Archiver Yes Can have up to two Auxiliary Archivers assigned to an Archiver role. Each server requires its own database, hosted locally or on a separate computer.
    Note: Failover and redundant archiving are not supported on Archiver roles that are used for wearable (or body-worn) cameras.

    VM designs

    This section details the VMs that the different roles will reside on:

    Table 4. VMs where roles reside
    VM name Cores Memory GPU Storage OS Role
    genetec-db-1 4 16GB None 200GB Win Server 2019 Directory SQL Server Database
    genetec-db-2 4 16GB None 200GB Win Server 2019 Directory SQL Server Database 2
    genetec-dir-1 8 16GB None 200GB Win Server 2019 Main Directory Server
    genetec-dir-2 8 16GB None 200GB Win Server 2019 Backup Directory Server


             genetec-rec-1 to genetec-rec-9
            

    		 4 16GB None 200GB Win Server 2019 Expansion Server/Archiver (with PowerScale folder mapping)

    High level architecture

    The distribution of Genetec VMs across the VxRail cluster was as follows:

    Figure 2. Genetec VMs across the VxRail cluster

    BriefCam architecture

    The BriefCam Computer Vision system is implemented using a microservices architecture that supports feature deployment and licensing flexibility. The features of the solution are packaged into a set of seven server roles that can be deployed in an all-in-one server configuration for proofs-of-concept or various multiserver configurations to meet performance and HA goals. BriefCam recommends deploying the application using an HA architecture to ensure business continuity even when some components fail.

    A combination of well-known HA technologies is available for adding redundant nodes to a system that prevents a single point of failure (SPOF). However, adding redundant nodes does require extra hardware resources and increases deployment complexity. Designing the right solution for your production environment requires balancing cost, complexity, and the level of risk from a system outage.

    Configuration best practices

    BriefCam is driven by a microservices architecture, enabling scalability, flexibility, and redundancy. The full microservices implementation is described in the BriefCam® Microservices Architecture white paper. To obtain copies of BriefCam manuals, reach out to your BriefCam representative. The implementation developed for this design guide was a single-site environment. The following 14 microservices were enabled on servers configured for the design. However, not all were used during testing, such as LPR matching.

    Table 5. BriefCam microservices
    Microservice Description
    Alert Processing The Alert Processing service is responsible for real-time video processing. The service must be hosted on a GPU-enabled processing machine.
    Face Recognition The Face Recognition service is responsible for the following activities:
    • Monitoring the external watchlist folders for new face images
    • Providing the aggregated status of the faces' feature-vector extraction process to the user, when uploading faces to a watchlist from the web UI
    Fetching The Fetching service is responsible for fetching the video footage from the VMS, storing it in the storage and making it available for BriefCam's Processing Server. By default, BriefCam's Fetching service uses two workers to fetch the videos from the VMS. The workers fetch five-minute video chunks.
    Filtering The Filtering service is responsible for handling in-memory object filtering for various scenarios in all the modules (REVIEW, RESPOND, and RESEARCH).
    Face Recognition Matching The Face Recognition Matching service is responsible for processing faces to find matches for filtering in the REVIEW module and for RESPOND alerts.
    Maintenance The Maintenance service is responsible for running BriefCam's automatic maintenance processes. For more information about maintenance, see the Maintenance and Data Retention section of the BriefCam Administrator Manual.
    Lighthouse The Lighthouse service is the seed node of BriefCam's Akka cluster. Its main roles are:
    • Registering new services that join the cluster
    • Providing service-discovery capability for all the other services in the cluster
    BriefCam's Akka cluster consists of the following services:
    • LPR Matching
    • BI Face Recognition
    • Face Recognition Matching
    • Filtering
    LPR Matching The License Plate Recognition (LPR) Matching service is responsible for processing license plates to find matches for filtering in the REVIEW module and for RESPOND alerts.
    Notification The Notification service is responsible for managing all aspects of notification and message delivery between the client application and server-based components.
    Outbound API Gateway This Hub service collects RESPOND alerts from the sites and if needed, sends them to a third-party service.
    Rendering The Rendering service is responsible for:
    • Generating visual and video artifacts for the web client, such as rendering the synopsis videos and visual layers, exports and original videos.
    • Validating uploaded video files before processing.
    Video Streaming Gateway The video streaming gateway is responsible for streaming the video artifacts back to the client.
    VS Server The VS Server service is responsible for various maintenance and monitoring related activities:
    • Watchdogs the RESPOND tasks in case of a task failure
    • Creates new RESPOND tasks when a rule is created or modified by the user
    • Provides a live image for the RESPOND task configuration wizard
    • Provides the list of cameras for the Web Admin's camera activation dialog
    • Creates the scheduled RESEARCH tasks
    • Sends the outbound alerts to the outbound API and also sends alerts to the VMS clients that have real-time alerts integration (level 2a or above)
    • Triggers the data maintenance activity
    • Clears inactive sessions
    Web Applications BriefCam Web Services drive the main functionality for the web client and APIs. The service is stateless in nature, using the database and shared storage as its stateful backend. There are multiple web services provided by the component for both end users and administrators.

    Server roles

    There are seven core server roles that are required for a BriefCam multi-server solution:

    Table 6. BriefCam server roles
    Server type Description High availability
    Web Services Provide functionality required for the web client and developer APIs. These are stateless services that use the PostgreSQL database and shared storage to manage the application state. Active/active stateless clustering that can have multiple active instances to scale out request demand and enable seamless failover using a NGINX load balancer.
    Research Service Using Qlik Optionally deployed in a multi-node architecture with shared access to a shared folder that contains application data. Active/active. Failover should be configured based on Qlik's recommendations. A load balancer can be deployed to distributed load for seamless scale-out performance and high availability.
    Processing Service Also referred to as on-demand mode processing. This service is responsible for video decoding, rendering, object extraction, and classification that require one or more GPU cards. Active/active. Multiple servers can be deployed at a single site to scale video processing requirements and provide high availability. All nodes in the solution are clustered. An application-level load balancing algorithm/policy determines the preferred node for a given session.
    Alert Processing Service Also referred to as real-time processing mode. This service supports the delivery of proactive responses to critical events for increased safety and security, with customizable alerts, alert reporting, and browser notifications. Active/active. Multiple servers can be deployed at a single site to scale video processing requirements and provide high availability. All nodes in the solution are clustered. An application-level load balancing algorithm/policy determines the preferred node for a given session.
    Fetching Service The Fetching service is responsible for fetching the video footage from the VMS. This service can be installed on multiple hosts to provide high availability.
    Video Streaming Gateway Service (VS Server) Used for camera management, VS service is responsible for starting, stopping, and managing additional BriefCam services Active-Passive is the only deployment model for the VS Service. A second VS Service must be deployed on a different server and keep it on standby by making sure the service is stopped and not in use. The primary instance must be monitored to detect if it goes down. The standby instance must then be started either manually or automatically on the redundant server. Once the service starts, it connects to the database and continue where the failing service left off.
    PostgreSQL Database Service As BriefCam processes video, it detects and recognizes objects, along with information about their type and attributes. Objects are then classified according to different classes, attributes, color, dwell time, size, and speed. BriefCam processes the video stream once and then stores all metadata in the database.

    PostgreSQL offers various ways to archive and replicate the primary database for backup, high availability, and load balancing scenarios.

    BriefCam recommends implementing a trigger-based master-standby replication.

    High availability designs

    An HA deployment requires additional virtual machines for redundancy, marked in the following diagram with yellow borders. A completely isolated HA installation for all critical services requires at least 15 virtual machines. In practice, more than one service can run on a single VM.

    Figure 3. BriefCam HA architecture

    High availability for microservices

    The following BriefCam services were designed for HA, and therefore, do not require a third-party load balancer for clustering and redundancy. Their architecture natively supports one of the two redundancy models described in the following table:

    Table 7. BriefCam services for HA
    Service type Services HA redundancy model
    Stateless


             Rendering Face Recognition Fetching BI Rules Engine Alert Processing Maintenance Processing
            

    		 These services support redundancy using a queue-based architecture. Service instances pull tasks directly from the database. There is no communication between services and each service that you add increases the system's capacity. When a single service fails, the system continues to work under reduced capacity.
    Akka


             LPR Matching BI Face Recognition Face Matching Filtering LIghthouse
            

    		 These services use a service-mesh architecture provided by Akka.Net that automatically constructs failover clusters as more instances are added to the system. There is no need for load balancing or any additional configuration and each service that you add increases the system's capacity. When a single service fails, the system continues to work under reduced capacity. To construct a failover cluster, all you need to do is deploy multiple instances for each of these services.

    VM designs

    This section details the resources allocated to each VM in our validation lab. These configurations do not reflect supported configurations for an enterprise-class production environment. Sizing a solution depends on many environment-specific parameters and should always be reviewed with BriefCam Professional Services before implementation.

    This following table details the VMs where the different roles will reside:

    Table 8. VMs where roles reside
    VM name Cores Memory GPU Storage OS Role
    briefcam-db-1 16 64 GB None


             2 Disks c:\ 200GB d:\ 500GB
            

    		 Win Server 2019 PostgreSQL Database


             briefcam-ps-1 to breifcam-ps-3
            

    		 16 140 GB


             1 x A40 vGPU per VM
            

    		 200GB Win Server 2019 Alert Processing Services
    breifcam-svr-4 16 128 GB None 200GB Win Server 2019 Web Services
    briefcam-web-1 4 16GB None 200GB Win Server 2019 Management Consoles

    High level architecture

    The distribution of BriefCam VMs across the VxRail cluster was as follows:

    Figure 4. BriefCam VMs across the VxRail cluster

    Ipsotek architecture

    The Ipsotek VISuite Computer Vision platform extracts metadata from RTSP video streams allowing you to improve response times, drive operational efficiencies, and generate new revenue streams. This intelligent capability produces alarms for specific behaviors and events, allows operators to perform forensic searches, and generates dynamic dashboards.

    Airports operate under strict government and aviation health safety guidelines which all staff must adhere to. VISuite supports multiple airport-specific workflows (use cases) and can automatically generate alerts for operators to manage and log. Examples include intrusion into aircraft-only zones, driving violations, and speeding. Alerts can be displayed on dynamic dashboards and updated according to the airport's operational requirements. VISuite can also be integrated with an email system to notify managers when certain events have occurred.

    Configuration best practices

    The following guidelines are based on previous internal testing and reports from customer field experience. None of these guidelines were exceeded during testing.

    Virtual Machines
    • Each VM is configured to the specifications provided by Ipsotek.
    • Each processing node is presented a full A40 card as a vGPU.
    • Uses a Maximum of two processing nodes per VxRail node.
    CPU
    • Do not over allocate vCPUs.
    • The underlying CPUs are the faster 3 GHz model.
    Storage
    • All Ipsotek nodes leverage the VxRail vSAN storage for operating system and auxiliary drives.
    • Data is protected with a RAID 1 storage policy to provide maximum performance and protection with the trade-off of reduced available capacity.
    Networking
    • No network limits for Ipsotek. Sufficient bandwidth is needed at the processing nodes to consume the camera streams.

    High availability

    It is critical to design a high availability deployment of Ipsotek to avoid loss of alerts during an unplanned outage.

    HA options

    It is possible to configure Ipsotek in two modes:

    • N:N architecture
    • N+1 architecture
    Ipsotek N:N architecture

    The N:N Architecture involves provisioning a full clone of all VMs in the Ipsotek system. This involves a full duplication of all servers in the cluster running on separate hardware. One cluster acts as the primary and both clusters have connectivity to the camera streams.

    When running two identical clusters, Ipsotek has logic to ensure that configuration and alarms are synchronized to avoid duplication. This architecture should be used when full redundancy is required.

    Ipsotek N+1 architecture

    The Ipsotek N+1 Architecture provides high availability within a single cluster. In this configuration multiple management VMs are created and multiple Processing nodes are configured as a cluster.

    With this approach, the processing nodes automatically join the cluster when they are booted. Once they join the cluster, the Processing nodes start to process camera streams. The camera streams are load balanced by the Management cluster to allow an even distribution of workload across the cluster.

    This architecture was used for our testing.

    Ipsotek roles

    The Ipsotek system is made up of multiple roles and some of the critical roles for CV are:

    Table 9. Ipsotek system roles
    Role Supports HA Comments
    Management Node Yes Central administration of the Ipsotek Cluster. Multiple nodes run in an Active/Passive manner using a Windows failover cluster.
    Processing Node Yes Node where CV analytics is performed. Multiple processing nodes exist across the cluster. Workload is balanced across the nodes.
    Database Node Yes Storage location for all Ipsotek config and metadata. Multiple nodes can be added together to form a cluster.
    Note: A minimum of three data nodes is required to form a cluster. Only one was used for this testing.

    The recommended approach for Ipsotek in a virtualized environment is to enable a GPU as a passthrough device. This means that it is not possible to easily migrate an Ipsotek processing node across the VxRail cluster. To combat this requirement, all four active nodes in the VxRail cluster must have a processing node configured. It is critical not to overload the four nodes and to allow enough capacity so that one of the nodes can become unavailable and the workload is still being processed. This is discussed further in the High availability validation section.

    VM designs

    This section details the VMs that the different roles reside on:
    Table 10. VMs where roles reside
    VM name Cores Memory GPU Storage OS Role
    ipso-mgmt-1 8 34GB None 200GB Win 2019 Server Ipsotek Management Node
    ipso-mgmt-2 8 34GB None 200GB Win 2019 Server Ipsotek Management Node
    ipso-db-1 16 64GB None 200GB Win 2019 Server Ipsotek Database Node


             ipso-ps-1 to ipso-ps-4
            

    		 8 64GB


             1 x A40 per VM
            


             2 Disks c:\ 200GB d:\ 400GB
            

    		 Win 2019 Server Ipsotek Processing Nodes

    High level architecture

    The distribution of Ipsotek VMs across the VxRail cluster was as follows:

    Figure 5. Ipsotek VMs across the VxRail cluster