Installing Tivoli Common Agent Services Agent/Manager
Overview of Tivoli Common Agent Services
The Tivoli Common Agent Services component provides a way to deploy agent code across multiple end-user machines or application servers throughout an enterprise. The agents collect data from and perform operations on managed resources for Fabric Manager.
The Tivoli Common Agent Services agent manager provides authentication and authorization and maintains a registry of configuration information about the agents and resource managers in your environment. The resource managers (Fabric Manager, for example) are the server components of products that manage agents deployed on the common agent. Management applications use the services of the agent manager to communicate securely with and to obtain information about the computer systems running the Tivoli common agent software, referred to in this document as the agent.
Tivoli Common Agent Services also provides common agents to act as containers to host product agents and common services. The common agent provides remote deployment capability, shared machine resources, and secure connectivity.
Tivoli Common Agent Services is comprised of two subcomponents:
- Agent manager
- The agent manager handles the registration of managers and agents, security (such as the issuing of certificates and keys and the performing of authentication). It also provides query APIs for use by other products. One agent manager instance can manage multiple resource managers and agents. The agent manager can be on same machine as Fabric Manager or on a separate machine.
- Common agent
- The common agent resides on the agent machines of other Tivoli products. One common agent can manage multiple product agents on the same machine. It provides monitoring capabilities and can be used to install and update product agents.
- Installing Agent
‘If deployment manager is down,How can the session backup information transfered to other cluster members? Is web server necessary?
Not necessarily, no. The WAS plugin will automatically fail over requests for a down server to some other server in the same cluster. It’s up to you to configure session persistence so that the session is available to any other server in the cluster.”
here my question is -is DMGR be clusterd ?If so ,how can i check the other clusterd member of DMGR and their status ?