To ensure the DMA’s can communicate well together we were asked to configure the connection strings from all to all DMA’s. However, we are not completely sure what IPs need to be used in the To field in case of a FO setup.
In the Dms.xml file we can see only VIPs configured, so we assume that the agents (FO pairs) only know each others VIP to communicate. In the documentation, it mentions to use the Primary IP, so not sure if this is also valid for FO setups. Next to this the FO pair itself has knowledge on the primary IPs of itself and his buddy as they need the ability to communicate to each other.
Is the assumption correct that the cluster communicates only with the VIP and the FO pair with the Primary IPs?
What connection strings do we need to configure in case of a FO cluster?
For example in the following FO Setup:
When the domain controller is not so reliable, we want to use local accounts to avoid auth failures. FYI: In big cluster, you can use wildcards to avoid making many connection strings if the same credentials work on all of them. (https://docs.dataminer.services/user-guide/Reference/DataMiner_Tools/SLNetClientTest_tool/SLNetClientTest_tool_advanced_procedures/SLNetClientTest_editing_connection_string.html).
Michiel, just sharing from my past usage – tuning in to receive other insights as well.
I believe it can be sufficient to define the Main-to-StandBy communication just through the Failover Configuration of the single DMA: I’d call this “intra-DMA” communication, as the two servers that share the same DMA agent id must be in nearly constant sync for the FailOver to work properly.
The type of de-synchronization (e.g. for missing files and similar) that is addressed with connection strings is across agents with different DMA id in the cluster, so I’d refer to this as “inter-DMA” (intra=within VS inter = across).
The latter (inter-DMA) is across the “active/on-line” agents of the DMS cluster, hence it would normally rely on the VIP.
So even when you need to add Connection Strings, these are just to facilitate the comms across different DMA IDs and I’d expect the VIP is used in the configuration of said connections.
Worth noting that the set-up of connection strings is required only when there are restrictions on the authentication within a DMS cluster, but if you don’t have this issue, the cluster can happily live without (less overhead to manage PW updates & cluster expansions).
HTH
Thanks for your insight Alberto, I made the same assumptions.
In our case, we will probably configure the ‘To’ as a * as the credentials will be configured the same for all DMA’s in the same DMS.
Glad to be of help – good shout about the *
See you on the dojo (;
Can I ask what is the authentication restriction is experienced to require the connection strings in the related use-case?
In most scenarios, these are not required (can also become complex to manage in big clusters, as each new DMA id added in the cluster will need a connection to all the other DMA servers)