We are currently in the build phase of a project and are working to make the right architectural decisions. We plan to deploy a total of four VAs: two in the primary cluster and two in the disaster recovery (DR) cluster, across two separate sites.
Regarding IQService, we are considering whether it is necessary to deploy two instances (one per site) with a load balancer that uses a primary instance and fails over to the secondary if needed, or if a single IQService instance would be sufficient.
Do you have any architecture diagrams or best practice recommendations that you could share for reference?
Thank you in advance,
(This simplified diagram is for illustration purposes only.)
It is recommended to have all 4 VAs in the same cluster. However, VAs themselves should be in different locations. e.g. Primary VAs on prem and DR VAs on cloud
With this config, you will not have to modify anything in case of a disaster. If you have 2 separate clusters, and if primary VAs go offline, you will have to change the VA cluster in each source which will also need updating the credentials as they will have to be encrypted using the Public key from the new cluster.
So I am wondering if we should have one IQService host with 2 IQServices hosted in it, or 2 different IQService hosts, each one of them in a separate site ?
I’ll be grateful for any best practices you share with us, Thank you
Usage of 4 VAs is good where you have deployed 2 VAs on Site 1 and 2 on Site 2. Also, I would recommend you to make sure that you keep all 4 VAs configured in same VA Cluster so that once the BCP is invoked and your DR VAs becomes primary, then, you don’t have to switch the VA Cluster inside your sources where you have used VA based connectors. In that way, you will be safe and sound. There are 3 approaches which SailPoint has for High Availability and DR, of which, the 1st approach of “All VAs Running” is good. Refer the below documentations for the same
On IQ Service, so 1 IQ Service instance comes with 2 sub-instances where 1 instance is PRIMARY and 2nd Instance is Secondary which you can also see in “Services” application of your windows machine where IQ Service is installed. So that below diagram which you have shown is representing that.
Also, you cannot have 2 IQ Services installed on a single windows server. Hence, if you are going for High Availability design, then, make sure you are installing 2nd IQ Service in another windows machine located at same site which has Load Balancer in front of them and those IQ Service instances eventually calls the Domain Controller.
1/Why should the second windows server be at the same site ? in case of disaster, we won’t have an IQService available ?
2/In a high-availability scenario where two IQService instances are installed on two separate Windows servers, what is the recommended placement for these servers?
Our infrastructure team is planning to install the two IQService instances on two different sites for redundancy. However, neither site is the same as the one hosting the Active Directory domain controllers. Communication between the IQService servers and the Active Directory environment would therefore go through an IPsec tunnel.
Do you see any potential issues or drawbacks with this architecture? Has anyone implemented a similar setup successfully?
Thank you in advance for your feedback and recommendations.
1/Why should the second windows server be at the same site? in case of disaster, we won’t have an IQService available?
- → From PROD perspective, I have seen one of my customers use the setup as per below flow diagram where there was a Load Balancer and then, 1 Cluster on primary site had 2 IQ Service Servers and Other Cluster on DR site had 2 IQ Service Servers. You can also go ahead with 1 Cluster containing 1 IQ Service server on primary site and 1 IQ Service server on secondary site depending upon what number of transactions you have in AD (Mostly they are very high but depends upon your identity count). The customer that I was mentioning is using the approach of “1 Cluster containing 1 IQ Service server on primary site and 1 IQ Service server on secondary site” for the SANDBOX ISC instance.
2/In a high-availability scenario where two IQService instances are installed on two separate Windows servers, what is the recommended placement for these servers?
- → I have always observed 1 IQ Service = 1 Windows Machine. Refer the above diagrams for the same. Both IQService Windows servers must be placed inside the same network segment or firewall security perimeter as the Active Directory Domain Controllers (DCs) (or other target Microsoft applications they manage).
Running IQService over an IPsec tunnel to a remote DR site can work, but there are real reasons it’s not the recommended pattern — worth calling out explicitly rather than just repeating “keep it local”:
IQService doesn’t only use LDAP — several of its operations (password reset/unlock, some attribute reads like Terminal Services/Lync attributes, and certain provisioning calls) rely on Windows-native RPC/WMI-style calls to the DC, not just LDAP/S. RPC uses a dynamic port range by default, which is painful to lock down cleanly across a site-to-site tunnel/firewall — you either open a wide port range (security concern) or have to fix the RPC port range on the DC side and mirror that in your tunnel rules.
These calls are also more latency-sensitive than a typical LDAP search. A tunnel with variable latency or occasional packet loss can cause timeouts on operations that work fine on a LAN, especially under aggregation load or bulk password operations.
Troubleshooting connectivity issues is harder across a tunnel — you’re now debugging VA → IQService → tunnel → DC, instead of VA → IQService (same segment as DC).
So my answer to “has anyone run this over a tunnel successfully”: It’s technically possible if you:
Open the specific RPC port range you’ve fixed on the DC side (not the full ephemeral range) through the tunnel firewall.
Load test aggregation and provisioning operations across the tunnel under realistic volume before going live — don’t just validate connectivity, validate throughput and timeout behavior.
Tune IQService/connector timeout settings generously to absorb tunnel latency variance.
Still put an IQService instance physically at the DR site’s own network segment (next to the DR-side DCs) rather than tunneling from primary — that’s a materially safer design than tunneling to the DC’s home site during a live DR event, since if the primary site is down, your tunnel target explanation collapses anyway.
Bottom line for the recommendation: co-locating IQService with each site’s own DCs (2 separate IQService hosts behind a load balancer, one per site) is the supported/lower-risk pattern precisely because it avoids the RPC-over-tunnel firewall complexity and removes tunnel latency as a failure mode during the DR scenario you’re actually building this for.
@aghzere in this case when you will use your DR cluster ? Probably never unless there is a DR so why don’t you go via Adhoc addition of VA 3 and VA 4 in the same cluster when there is DR event.
Also would like to know in which HYPER v you have installed the VA
HI @aghzere , For VAs the architechture provided by you and others looks good and its should work as well. But for the IQ Service I would like to mention the below given points to consider in the best practices. These are given below:
1.High Availability-Eliminates IQService as a single point of failure.
2.Disaster Recovery- Each site remains operational if the other site is unavailable.
3.Lower Latency-VAs communicate with a local IQService instance rather than traversing the WAN.
4.Simplified Maintenance- One IQService can be patched or restarted while the other remains available.
5.Scalability-Additional IQService instances can be added later if provisioning load increases.
In case of prod deployment spanning two sites with primary and DR clusters, deploy one IQService instance per site and use a load balancer or DNS-based failover. This could provides better resilience, avoids one point of failure, and aligns with common enterprise HA and DR practices.
