High Availability for IQService

High Availability for IQService

Sources in IdentityNow only support configuring a single host name and port number for communicating with an IQService instance.  IQService agents can be configured for HA (high availability) through the use of a load balancer configured to route the TCP/SSL traffic from IdentityNow virtual appliances to IQService instances.  The recommended deployment is for a "primary" and "secondary" configuration, where traffic is routed to the primary IQService instance preferentially as long it is online, and then routed to the secondary IQService instance only in circumstances where the primary does not accept an incoming TCP connection.

When deploying this configuration, configure the load balancer to listen for TCP/SSL traffic on port 5050 or whatever port you have configured in the source in IdentityNow.  The load balancer should then be configured to point to 2 hosts running IQService on port 5050 (or whatever the chosen site-specific port for IQService is). The load balancer should be configured to send traffic to the primary host as long as the TCP socket on the primary host accepts traffic.  If the primary host fails to accept TCP traffic on the port then requests should be sent to the secondary host until the primary host starts accepting traffic again.  This is basically “prefer primary but use secondary if primary is not available” failover configuration.

When using multiple IQService instances care must be taken to deploy the same IQService version on both the primary and secondary hosts and be certain the same pre/post provisioning scripts are available on both hosts.  When upgrading IQService agent versions be certain to upgrade both the copy installed on the primary agent host and the copy installed on the secondary agent host.

The following diagram illustrates a recommended HA configuration for IQService agents.

Screen Shot 2017-10-27 at 1.08.55 PM.png

For more information about IQService, see IdentityNow IQService Administrator's Guide (vMarch-2019)​.

Labels (1)

Which ports are to be used on the LB so that the VA can interact with it?




We have configured two IQService servers behind a load balancer with a health probe that checks TCP/5050 every 5 seconds. However, we have found that the health check causes an error in the IQService logs every time it probes the servers. We know it's from the health probe because the message is printed every 5 seconds. The error message is (ip/port redacted):


04/28/2021 20:49:59 : RpcHandler [ Thread-12 ] ERROR : "Malformed request received from client - <IP>:<PORT>. Received header length as - Error in parsing - Input string was not in a correct format."


Is there a configuration change we need to make on the IQService or load balancer to make this error go away? The load balancer is working -- if we stop the IQService on one of the two servers we do see the LB point to the other IQService server as expected. Note that these are all Azure-hosted resources and we are on IIQ 8.1p2.

If there aren't any changes we can make either to the IQService or the LB, then I think this is a bug in the IQService. It should be able to handle health probes from an Azure load balancer without adding a bunch of noise to the logs.

We are seeing the same issue with the health probe from our load balancers (F5).   Has anyone had any luck working around this issues with the malformed health checks?


can IdentityIQ or Cloud Gateway support redundant IQ Service hosts using some other mechanism except load balancers? For example by using DNS round robin for client side failover, or by configuring multiple hosts on client side?


We would like to deploy IQ Service (and Cloud Gateway) in completely segregated infrastructure without ANY shared components like LBs, providing resiliency even in case of complete loss of site or connectivity.


Furthermore using LBs to just do simple fail over seems like an unnecessarily complex architecture, prone to issues like described above.

We are also getting the malformed error. Does anyone know how to avoid this?

Thank you

Version history
Revision #:
1 of 1
Last update:
‎Mar 13, 2019 07:52 AM
Updated by: