· Sep 7, 2023

Question about ISCAgent Config

We are noticing some issues with the communication between our Arbiter and our servers. Looking at the following documentation to limit connections, and logging...

if I am configuring the ISCAgent on the arbiter, would we set 


to each IRIS server? Or does this mean to give it a specific NIC IP Address to use for communication? Does the ISCAgent have to be configured separate on each IRIS server?

Is there a way to limit which IP's it is communicating with an allow list? Currently we do not have a private network across the boxes, but looking to see how we can tighten down the communications.


Product version: IRIS 2022.1
Discussion (3)2
Log in or sign up to continue

That setting allows you to specify an adapter address over which arbitration traffic will flow. It's a local address for situations where the arbiter server may have multiple adapters on different networks.

The IRIS servers establish the arbiter connection rather than the other way around, and you can have multiple mirror pairs us a single arbiter instance.

The ISCAgent is normally installed by default with IRIS, but may not be activated. On my mirrored servers, it's active, but I don't remember whether that happened automatically as part of the setup process, or I did it manually.

No allow list that I'm aware of, but if you want to restrict access to ISCAgent ports, add an adapter to each host, connected to a VLAN that is not routeable from outside that network. Configure application_server.interface_address to use it. You could also use the same network for mirror journal transmission/communication, and leverage QoS to allocate a fixed minimum amount of bandwidth that would be unavailable to other network traffic.

I don't know of any other attributes, and increasing logging may turn up something but hasn't proved useful in my experience.

If your servers are reporting occasional disconnect errors, that's not necessarily a network issue, or even something to worry about. The mirror members may report disconnections due to things like snapshots/backups where one or more hosts are momentarily suspended by the hypervisor in a virtualized environment, or updates to the OS that might stop/start services as part of the update process. It's important to remember, though, that the arbiter is designed to operate optimally in a low-latency, same network, same data center scenario. If your mirrored hosts are spread across a WAN, you're asking for errors.