Terms and definitions
Refer to the following list of terms and definitions to learn about important concepts in the IBM® Tivoli Application Dependency Discovery Manager (TADDM).
- access collection
- A collection that is used to control the access to configuration items and permissions to modify configuration items. You can create access collections only when data-level security is enabled.
- asynchronous discovery
- In TADDM, the running of a discovery script on a target system
to discover systems that cannot be accessed directly by the TADDM
server. Because this discovery is performed manually, and separately
from a typical credentialed discovery, it is called
asynchronous
. - business application
- A collection of components that provides a business functionality that you can use internally, externally, or with other business applications.
- CI
- See configuration item.
- collection
- In TADDM, a group of configuration items.
- configuration item (CI)
- A component of IT infrastructure that is under the control of configuration management and is therefore subject to formal change control. Each CI in the TADDM database has a persistent object and change history associated with it. Examples of a CI are an operating system, an L2 interface, and a database buffer pool size.
- credentialed discovery
- TADDM sensor scanning that discovers detailed information about
the following items:
- Each operating system in the runtime environment. This scanning is also known as Level 2 discovery, and it requires operating system credentials.
- The application infrastructure, deployed software components, physical servers, network devices, virtual systems, and host data that are used in the runtime environment. This scanning is also known as Level 3 discovery, and it requires both operating system credentials and application credentials.
- credential-less discovery
- TADDM sensor scanning that discovers basic information about the active computer systems in the runtime environment. This scanning is also known as Level 1 discovery, and it requires no credentials.
- Data Management Portal
- The TADDM web-based user interface for viewing and manipulating the data in a TADDM database. This user interface is applicable to a domain server deployment, to a synchronization server deployment, and to each storage server in a streaming server deployment. The user interface is very similar in all deployments, although in a synchronization server deployment, it has a few additional functions for adding and synchronizing domains.
- discover worker thread
- In TADDM, a thread that runs sensors.
- Discovery Management Console
- The TADDM client user interface for managing discoveries. This console is also known as the Product Console. It is applicable to a domain server deployment and to discovery servers in a streaming server deployment. The function of the console is the same in both of these deployments.
- discovery server
- A TADDM server that runs sensors in a streaming server deployment but does not have its own database.
- domain
- In TADDM, a logical subset of the infrastructure of a company or other organization. Domains can delineate organizational, functional, or geographical boundaries.
- domain server
- A TADDM server that runs sensors in a domain server deployment and has its own database.
- domain server deployment
- A TADDM deployment with one domain server. A domain server deployment
can be part of a synchronization server deployment.In a domain server deployment, the following TADDM server property must be set to the following value:
com.collation.cmdbmode=domain - launch in context
- The concept of moving seamlessly from one Tivoli® product UI to another Tivoli product UI (either in a different console or in the same console or portal interface) with single sign-on and with the target UI in position at the proper point for users to continue with their task.
- Level 1 discovery
- TADDM sensor scanning that discovers basic information about the
active computer systems in the runtime environment. This scanning
is also known as credential-less discovery because it requires no
credentials. It uses the Stack Scan sensor and the IBM® Tivoli® Monitoring
Scope sensor. Level 1 discovery is very shallow. It collects only
the host name, operating system name, IP address, fully qualified
domain name, and Media Access Control (MAC) address of each discovered
interface. Also, the MAC address discovery is limited to Linux on
System z® and Windows systems. Level 1 discovery does not discover
subnets. For any discovered IP interfaces that do not belong to an
existing subnet that is discovered during Level 2 or Level 3 discovery,
new subnets are created based on the value of the
com.collation.IpNetworkAssignmentAgent.defaultNetmaskproperty in the collation.properties file. - Level 2 discovery
- TADDM sensor scanning that discovers detailed information about each operating system in the runtime environment. This scanning is also known as credentialed discovery, and it requires operating system credentials. Level 2 discovery collects application names and the operating system names and port numbers that are associated with each running application. If an application has established a TCP/IP connection to another application, this information is collected as a dependency.
- Level 3 discovery
- TADDM sensor scanning that discovers detailed information about the application infrastructure, deployed software components, physical servers, network devices, virtual systems, and host data that are used in the runtime environment. This scanning is also known as credentialed discovery, and it requires both operating system credentials and application credentials.
- multitenancy
- In TADDM, the use by a service provider or IT vendor of one TADDM installation to discover multiple customer environments. Also, the service provider or IT vendor can see the data from all customer environments, but within each customer environment, only the data that is specific to the respective customer can be displayed in the user interface or viewed in reports within that customer environment.
- Product Console
- See Discovery Management Console.
- script-based discovery
- In TADDM, the use, in a credentialed discovery, of the same sensor scripts that sensors provide in support of asynchronous discovery.
- SE
- See server equivalent.
- server equivalent (SE)
- A representative unit of IT infrastructure, defined as a computer system (with standard
configurations, operating systems, network interfaces, and storage interfaces) with installed server
software (such as a database, a web server, or an application server). The concept of a server
equivalent also includes the network, storage, and other subsystems that provide services to the
optimal functioning of the server. A server equivalent depends on the operating system:
Operating system Approximate number of CIs Windows 500 AIX 1000 Linux 1000 HP-UX 500 Network devices 1000 - storage server
- A TADDM server that processes discovery data that is received from the discovery servers and stores it in the TADDM database. The primary storage server both coordinates the discovery servers and all other storage servers and serves as a storage server. All storage servers that are not the primary are called secondary storage servers.
- streaming server deployment
- A TADDM deployment with a primary storage server and at least
one discovery server. This type of deployment can also include one
or more optional secondary storage servers. The primary storage server
and secondary storage servers share a database. The discovery servers
have no database.
In this type of deployment, discovery data flows in parallel from multiple discovery servers to the TADDM database.
In a streaming server deployment, the following TADDM server property must be set to one of the following values:com.collation.taddm.mode=DiscoveryServercom.collation.taddm.mode=StorageServer
For all servers except for the primary storage server, the following properties (for the host name and port number of the primary storage server) must also be set:com.collation.PrimaryStorageServer.hostcom.collation.PrimaryStorageServer.port
If the com.collation.taddm.mode property is set, the com.collation.cmdbmode property must not be set or must be commented out.
- synchronization server
- A TADDM server that synchronizes discovery data from all domain servers in the enterprise and has its own database. This server does not discover data directly.
- synchronization server deployment
- A TADDM deployment with a synchronization server and two or more
domain server deployments, each of which has its own local database.
In this type of deployment, the synchronization server copies discovery data from multiple domain servers one domain at a time in a batched synchronization process.
In a synchronization server deployment, the following TADDM server property must be set to the following value:com.collation.cmdbmode=enterpriseThis type of deployment is obsolete. Therefore, in a new TADDM deployment where more than one server is needed, use the streaming server deployment. A synchronization server can be converted to become a primary storage server for a streaming server deployment.
- TADDM database
- In TADDM, the database where configuration data, dependencies,
and change history are stored.
Each TADDM server, except for discovery servers and secondary storage servers, has its own database. Discovery servers have no database. Storage servers share the database of the primary storage server.
- TADDM server
- A generic term that can represent any of the following terms:
- domain server in a domain server deployment
- synchronization server in a synchronization server deployment
- discovery server in a streaming server deployment
- storage server (including the primary storage server) in a streaming server deployment
- target system
- In the TADDM discovery process, the system to be discovered.
- utilization discovery
- TADDM sensor scanning that discovers utilization information for the host system. A utilization discovery requires operating system credentials.