In a standard IVX cluster, the designated broker node acts as a single point of failure. If this node fails, the entire cluster stops receiving files and becomes unusable until that node is restored. To prevent this service disruption, IVX Server introduces a Virtual IP (VIP) address for the cluster to create a High Availability (HA) environment. This ensures that if the active broker node goes down, another broker automatically takes its place. It uses the same virtual IP address to continue receiving traffic, maintaining uninterrupted file analysis without any manual intervention.
Note
The Virtual IP provides High Availability for receiving files from TIE, IPS, SWG, ICAP clients, or direct API submissions, but it is not used for sensor submissions because sensors already have built-in failover logic to automatically route traffic to other broker nodes if a broker goes down.
How automatic failover works?
Automatic failover with a virtual IP is based on the following process:
You select a unique IP address which is not used anywhere on your network and assign it as virtual IP.
Once assigned, one broker node owns the virtual IP, and all other brokers in the cluster are notified. These other brokers then begin monitoring the availability of the VIP owner.
When the broker node holding the VIP goes down, one of the monitoring brokers automatically assigns the VIP to itself. This new owner then takes over and begins processing and redirecting sample submissions to the other nodes in the cluster.
The time required for the virtual IP to switch to a new broker depends on the number of nodes in the IVX cluster.
If you have a 2-node cluster (with both nodes acting as brokers) and the VIP owner fails, it will take the remaining broker 4 to 6 minutes to acquire the VIP and resume sample submissions.
In a cluster with three or more nodes (recommended), the virtual IP reassignment is fast and usually happens within 30 to 60 seconds.
Note
VIP reassignment typically occurs within 30 to 60 seconds. However, due to conditions such as node reboots or network instability, failover may take longer before it becomes stable.