FAQ about RA agent connectivity with Execution Server
search cancel

FAQ about RA agent connectivity with Execution Server

book

Article ID: 217000

calendar_today

Updated On:

Products

CA Release Automation - Release Operations Center (Nolio)

Issue/Introduction

Please help us to answer below queries.

1: What is the objective of having more than one supernode entries in nimi_config.xml file of agent?

2: Can we control or sequence the order in which agent will seek or connect to parent i.e. NES from available list of supernode in agent nimi_config.xml?

3: What we can do to make sure that agent connect to specific parent i.e. NES at particular point in time?

4: Can agent switch NES automatically during the day, in case of multiple supernode entries in it's nimi_config.xml file?

5: What are the configuration for latency and delay for the agent?

Environment

Release : 6.6, 6.7

Component : CA RELEASE AUTOMATION ACTION PACK

Resolution

1: What is the objective of having more than one supernode entries in nimi_config.xml file of agent?

The objective of the mentioned configuration is to make sure the agent is online most of the time. In case of any error/timeout/network outage etc. while trying to connect to one of the parent i.e. NES agent will switch to another parent i.e. NES from the available lists of supernode configured in nimi_config.xml file of agent.

2: Can we control or sequence the order in which agent will seek or connect to parent i.e. NES from available list of supernode in agent nimi_config.xml?

Unfortunately this can't be controlled as it requires complex calculation based on last active NES, NES capacity, permissible agents on NES, no of hops in path etc. This configuration only allows to configure possible parents i.e. NES an agent can seek next in case of previous parent connection failure. Also remember the objective of this configuration is to increase up time of an agent and not to control to which NES agent connects.

3: What we can do to make sure that agent connect to specific parent i.e. NES at particular point in time?

As one configuration doesn't fit all. We have mentioned some common use cases along with objectives and possible action support

    • Increase Agent up time i.e. reachable: The configuration that support this is to have multiple supernodes i.e. NES link to the single agent. The same can be done via ROC -> Administration -> Agent Management -> Select the agent (open properties) and configure Execution Servers for the agent. In this case there will be more than one supernode entry in agent nimi_config.xml file.
    • Agent connected to specific NES: This can be done manually switching agent parent from one NES to another. In this case there will be only one supernode entry in agent nimi_config.xml. This is like an agent connected to NES-A and now you are connecting it to NES-B by de-linking it from NES-A and linking to NES-B manually prior to deployment/process runs via ROC -> Administration -> Agent Management -> Select the agent (open properties) and configure Execution Servers for the agent

4: Can agent switch NES automatically during the day, in case of multiple supernode entries in it's nimi_config.xml file?

 Yes an Agent having more than one entry of supernode in it's nimi_config.xml file agent will switch NES's automatically if previous connection impacted by some possibilities listed below. (In below example we assume Agent having configuration for two NES's i.e. NES-A and NES-B)

    • The connection between Agent and active NES(previously connected NES) is broken
    • The connection between Agent and active NES(previously connected NES) timed out
    • The active NES(previously connected NES) denied/closed the connection to agent based on it's (NES nimi_config.xml) capacity and warn-capacity configuration, in case if number of agents connected to the NES is above warn-capacity.
    • Any sort of disruption in network connection between agent and active NES.

5: What are the configuration for latency and delay for the agent?

It's not a problem which can be solved completely by agent/NES configuration. As RA components relies on underlying network, in case of any network issues which were not present earlier but observant recently please make sure that those issues are resolved.

From agent configuration perspective the below are the configurations.

Please refer to below articles and guides