Gain visibility into applications and their IT infrastructure dependencies
An Introduction to IBM Tivoli Application Dependency Discovery Manager (TADDM)
IBM® Tivoli® Application Dependency Discovery Manager provides robust and automated discovery and application mapping for building an inventory of applications, configurations and dependencies. This software builds application maps that give you visibility into your complex application infrastructure. It helps administrators understand the structure, status, configuration and change history of their interdependent business applications.
Tivoli Application Dependency Discovery Manager:
- Effectively discovers your most critical resources. Performs agentless discovery and stores information on applications and their dependencies.
- Provides a clear view of interdependencies between servers, applications, network devices, software, configuration files, operating systems and other IT infrastructure components.
- Interoperates seamlessly with business operations tools. Rapidly isolate configuration-related application problems and speed troubleshooting.
- Helps you understand change and control its effects throughout the infrastructure.
- Creates a shared topological view of applications for use by other management applications such as incident management, monitoring and provisioning tools
Discovering your devices before moving to the cloud or consolidating data centers
How does it work?
The discovery process is driven by a discovery profile. The discovery profile defines the level of the discovery determining the details to be returned. TADDM supplies three default discovery profiles:
This discovery profile does not require any user credentials or agent. It is intended to build an IP device map of your environment and the running operating system (where possible). This type of discovery is very useful when you do not know what devices exist within your environment, possibly as a result of a recent acquisition or merger.
This discovery profile performs a shallow discovery using operating system credentials only. This will validate the operating system currently executing on the discovered devices and also return a list of the currently executing applications (processes). This type of discovery will identify a large part of your environment, with the exception of detailed information of application infrastructure.
This discovery profile performs the most detailed level of discovery and is intended for discovery of detailed application infrastructure, physical servers, deployed software, networks, etc.
In addition to the discovery profile, TADDM requires a scope to be set. The scope defines the limits of the discovery process in terms of hostname/IP address, IP address range or network subnet to be discovered. The scope set can include multiple networks or ranges as well as specifying addresses to be excluded from discovery processing.
The last part of the discovery requirements is specification of user credentials to be used during the discovery process. For a Level 1 discovery, user credentials are not required as this is an agent-less and credential-less discovery, used to build a database of IP devices on the network. For Level 2 discoveries, operating system credentials are required to allow TADDM to create a session with the target operating system. Once a session has been created, TADDM will interrogate the target system to obtain information about the currently executing processes. For Level 3 discoveries, TADDM will use all of the credentials supplied to extract information about the application infrastructure, database servers, network switches, etc. attempting to return as much information as possible. When suitably configured to use the WebSphere Application Server (WAS) client-side certificates and associated user credentials, the Level 3 discovery can perform a detailed discovery of WAS without having to reconfigure WebSphere (as was required in earlier TADDM releases).
TADDM supplies over 100 sensors out-of-the-box, covering the main stream operating systems, application servers, database servers, network switches, etc. If there isn’t an out-of-the-box sensor available to discover one of your components, TADDM can generally be configured to discover unknown components using a combination of custom server templates and custom server extensions.
TADDM uses a combination of Simple Network Management Protocol (SNMP), secure shell (SSH) and Windows Management Instrumentation (WMI) to perform the discovery. If TADDM determines a specific IP device:
- is running a version of UNIX or Linux, SSH is used for the discovery process
- is running a version of Windows, WMI is used for the discovery process
- otherwise, SNMP is used for the discovery process
If the target servers to be discovered are separated from the TADDM server by a firewall, TADDM requires that an anchor server be defined on the other side of the firewall. This is used as a communications pipe by TADDM communicating directly with the Anchor Server using SSH and the Anchor Server then performs the discovery on behalf of the TADDM server. The discovery results are then fed back to the TADDM server via the Anchor Server. The TADDM server functions by default as an Anchor Server for discovery of servers not separated by a firewall.
If any of the target servers to be discovered are Windows servers, TADDM requires a Windows Gateway to be defined. As discovery of Windows based targets is performed using WMI, the TADDM server uses the Windows Gateway server to launch the WMI based discoveries. If the Windows Servers to be discovered are separated from the TADDM server by a firewall, an Anchor Server is also required as described above. A single Windows server can be used to host both the Windows Gateway and the Anchor Server functionality, assuming that SSH is installed on the Windows server for communicating with the TADDM server. The diagram below summarises the TADDM architecture requirements.
Information returned from the discovery process is stored in the TADDM relational database (CMDB) as Configuration Items (CIs). The information is stored according to the Common Data Model (CDM) schema. The CDM defines a structure for holding objects and attributes relating to those objects within the RDBMS. It also defines criteria for describing relationships between those objects, such as database server DB2 runs on operating system AIX and operating system AIX runs on computer system object Pseries-570.
One of the primary benefits of TADDM is that it provides the ability to understand what components exist within the enterprise and how they relate to one another. After the initial discovery process has completed, it is likely that TADDM has identified a number of components that have dependencies, such as an application server and a database server. To manage these related components more easily, they can be grouped into business applications and services. This can be done manually through the TADDM console interface, semi-automatically using custom server templates or automatically using application templates. Using business applications and services definitions allows TADDM to provide a visual business application topology view showing each business application or service and how the individual components relate to one another.
TADDM records changes that have been made to each discovered component between discovery executions. This provides an audit trail of changes at the individual component level and also at the business application or service level. Changes can be displayed directly through the TADDM console or through the TADDM reporting interface.
TADDM can help ensure that computer systems throughout the enterprise are compliant. TADDM provides the functionality to compare objects that have been discovered. This functionality can be used to compare a compliant reference computer system with other systems discovered by TADDM. Built-in TADDM reports showing inventory and compliant computer systems can then be used to assist with compliance audit requirements.