Home > Edge > Digital Cities Edge > Dell Validated Design for Urban Mobility with ISS - Design Guide > High availability validation
This section presents an overview of the test scenarios that are performed to validate the methods that provide redundancy during unforeseen hardware failures and upgrades.
Video servers can be integrated into a failover cluster to provide additional reliability of SecurOS video analytics use cases as well as simplify the hardware upgrade process. Failover clusters represent the group of computers that can sustain server malfunction with the help of backup servers. This configuration helps maintain a high availability environment to protect against the loss of real-time results from analytics due to hardware failure.
The following figure shows the schematic view of the SecurOS cluster structure.
The cluster configuration consists of two main components:
The failover scenario is simulated in the lab using three VMs, each running as an independent host. Two active nodes are configured as a cluster setup using stand-alone virtual IP addresses, enabling the use of the third host as a standby during any failures.
The following figure summarizes the lab setup for failover scenarios:
Three host VMs are used to create the cluster using the virtual IP addresses listed (.32, .33, .34), with the cluster having its own virtual IP as well (0.35). The SecurOS application is installed on each of the three hosts along with the auto configuration.
Within the SecurOS application, two virtual nodes are created with virtual IP addresses (.36, 37) to represent the video servers for processing the video streams. Each of the nodes is designated with a preferred host to run on (.36 with .32, .37 with .33). The SecurOS server manager application is used to configure the cluster and update the settings as shown in the following figure.
The figure shows the SecurOS cluster status in a normal scenario with ISS-CLUS1 and ISS-CLUS2 being the two nodes running on their preferred hosts respectively. The third host is available in the cluster for any failure scenario to take over another node. The configuration of the SecurOS nodes in the object tree is shown in the following figure.
To simulate a hardware failure, the VM running host-2 (.33) is abruptly shut down from the VMware console. In this scenario, the SecurOS node running on this host (.37) immediately transitions to run on the failover host in the cluster (.34) with no loss of processing results. The delay observed is minimal (less than 20 seconds), and the processing is taken over by the failover host without disruption. The UI connection to the node is automatically restored without a need for reconnection using a different IP address. This scenario’s cluster status in the SecurOS server manager is shown in the following figure.
Once the host-2 is available again, the ISS-CLUS2 node automatically transitions back to it from the failover host (.34) because host-2 is designated as the preferred host for this node in the cluster configuration.
Apart from the native failover capability of the SecurOS application, high availability is ensured through various features of the hardware in the solution. This is more relevant while using the VxRail environment to run a virtual setup of SecurOS. The SecurOS nodes can run on virtual machines that are hosted on any of the available physical hosts, and the VMs can automatically migrate between hosts in the event of failures.
Additionally, VMware vSAN offers resiliency for application and database deployment storage needs. Configuring vSAN-based datastores for persistent and application data on the VMs maintains redundancy on the storage layer as well.
Redundancy is also available at the networking layer when using the VxRail cluster setup for the SecurOS deployment. All the VMs can use virtual network adapters and virtual network ports that correspond to multiple physical ports and adapters. If there is a failure with a physical NIC going offline and rendering a physical VxRail node unavailable, the VMs are moved to an available node in the three-node cluster with no impact to the SecurOS applications and databases.
These capabilities complement the native failover configuration that is enabled by SecurOS and maintain a highly available system at scale.