Configuring Identity Application clustering to use TCP

As I can see from this post  IDPApps4.8.x-Configuring Permission Clustering to Use TCP  I now know what does the port_range mean (if the default port is 1000 and the range is 0 there are no additional ports, the port range number indicates the number of extra ports, so if that number is five that would mean there are 6 ports: 1000,1001,1002,1003,1004,1005). 

What I am speculating now is that on several pages of the documentation it is mentioned that IA nodes should be in the same subnet but I am speculating from documentation (https://www.netiq.com/documentation/identity-manager-48/identity_apps_admin/data/configuring-identity-applications-472-clustering-to-use-tcp-or-udp.html) this is a requirement only for clusters using UDP not TCP.

Can anyone confirm this (we do not have nodes in the same subnet if our cluster uses TCP)? Any other tips regarding clustered configuration will be appreciated.

  • 0  

    Thinking further about this configuration, a lot of questions arise:

    1. What does this actually do? (Identity Application clustering and Permission Clustering)
      1. for IA clustering I would guess all the IA configuration is transferred anything else?
    2. As I read more I presume if we have 2 IA nodes we should have at least 1 additional port to have 2 ports available for the 2 nodes?
    3. Also, the initial_hosts should be all the nodes with the bind/primary port?

      If anyone has some general tips on customizing this string it will be greatly appreciated. Looks like generally only

      • bind_addr
      • bind_port
      • initial_hosts
      • port_range

      should be customized?

    4. Verified Answer

      +1   in reply to   

      I got it working, but as you discovered the documentation is not that fantastic.

      TCP(

      bind_addr=<hostname>;

      bind_port=<somthing which will never collide with anything else>

      )

      TCPPING(

      initial_hosts=<ip of server 1[port]>,<ip of server 2[port]....

      port_range=mumber of servers + 1

      )

      As you need to use a hostname for the bind_addr you need to use /etc/hosts and add something like:

      <ip> ua_server

      on all the servers as it need that to start the cluster.

      You need to find an tcp port which is reachable between all the servers, and make sure that the firewall is open.

      'initial_hosts' is just a list of servers in the cluster and the tcp port you configured in the TCP section. I found that it works with port_range set to number of server plus 1.

      I have not changed anything else, and uses the same for the UA cluster, though with other ports.

    5. Verified Answer

      +1   in reply to   

      Oh, and I do not have all the servers in the same subnet.

    6. 0   in reply to   

      Thank you very much for this answer Grin

      If I understand correctly bind_addr=<hostname> should not be the same as the loadbalanced DNS, but something separate and special?

      port_range=mumber of servers + 1

      This is kind of interesting why number_of_servers +1 (why the plus one?)

    7. 0   in reply to   

      The <hostname> should be resolvable to the single host. It is a bit complicated, but you need to have each host locally to resolve the name you put there as the local ip address. Basically it is the listen address, but given as a hostname, and as this runs on all the UserApp servers in the cluster this is how I did it, there might be other options, which I do not know about - if you do not have it configured that way, then it fails to start on all the servers and the cluster is not running.

      As it's not documented I just did it that way, you probably could use a lower number, but when I got as far as to get it to work, I stopped trying more configurations.

      My configuration comes from a mix of the documentation, support and consulting.

    8. 0   in reply to   

      Thank you, just to clarify bind_addr=<hostname> is the same for all servers, so every server has the same <hostname> value resolvable to its own IP?

    9. 0   in reply to   

      Exactly. This way you can use the same cluster properties for all nodes so that it can be defined globally.