Tivoli Application Dependency Discovery Manager Version 7 Release 2.1. Installation Guide

Tioli Application Dependency Discoery Manager Version 7 Release 2.1 Installation Guide

Tioli Application Dependency Discoery Manager Version 7 Release 2.1 Installation Guide

Note Before using this information and the product it supports, read the information in Notices on page 111. Edition notice This edition applies to ersion 7, release 2, modification 1 of IBM Tioli Application Dependency Discoery Manager (product number 5724-N55) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation 2006, 2014. US Goernment Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents Tables............... About this information........ ii Conentions used in this information..... ii Terms and definitions........... iii Installing.............. 1 Three ways of deploying TADDM....... 1 Domain serer deployment........ 2 Synchronization serer deployment...... 3 Streaming serer deployment........ 4 Planning for installation.......... 6 TADDM serer requirements........ 7 Client requirements........... 28 Planning for security.......... 29 Planning for single sign-on with IBM Tioli CCMDB.............. 32 Planning for self-monitoring........ 33 Planning worksheet for synchronization serer deployment installation......... 33 Planning worksheet for streaming serer deployment installation......... 36 Installing TADDM............ 39 Configuring the remote database serer.... 40 Configuring for the Context Menu Serice and Data Integration Serice......... 45 Installing TADDM serers........ 49 Verifying the TADDM serer installation... 69 Installing the self-monitoring tool...... 70 Installing the Tioli Netcool Performance Flow Analyzer serer............ 74 Post-installation configuration........ 75 Post-installation DB2 for z/os configuration.. 75 Configuring Oracle RAC after installation... 79 Checking the serer status........ 79 Configuring clients for secure access..... 80 Clearing the Jaa Web Start cache...... 82 Clearing the Microsoft Internet Explorer browser cache............... 82 Upgrading TADDM........... 82 Performing prerequisite tasks....... 83 Upgrading the TADDM serer....... 85 Silently upgrading the TADDM serer.... 90 Upgrading the database manually...... 91 Conerting a 32-bit TADDM deployment to 64-bit............... 93 Rolling back the upgrade......... 94 Uninstalling TADDM........... 96 Uninstalling a TADDM serer....... 96 Uninstalling the self-monitoring tool..... 99 Uninstalling the Tioli Netcool Peformance Flow Analyzer serer.......... 100 Uninstalling IBM Tioli Monitoring workspaces and situations for TADDM........ 100 Troubleshooting installation problems..... 101 Troubleshooting upgrade problems...... 107 Notices.............. 111 Trademarks.............. 112 Copyright IBM Corp. 2006, 2014 iii

i Application Dependency Discoery Manager: Installing

Tables 1. Serers and associated databases in each deployment type........... 1 2. Serers and associated user interfaces in each deployment type........... 2 3. TADDM serer hardware requirements 10 4. TADDM serer hardware requirements 11 5. Baseline processor types........ 12 6. Processor speed........... 13 7. Processor quantity.......... 13 8. Memory.............. 13 9. Processor speed........... 14 10. Processor quantity.......... 14 11. Memory.............. 14 12. Processor speed........... 15 13. Processor quantity.......... 15 14. Memory.............. 15 15. Processor speed........... 16 16. Processor quantity.......... 16 17. Memory.............. 16 18. Number of disk dries or disk arms.... 17 19. Typical discoery rates......... 18 20. Typical discoery sensor rates...... 19 21. Example using one storage serer..... 21 22. Example using two storage serers..... 22 23. Example for discoery serers...... 22 24. Supported operating systems for TADDM serers.............. 26 25. Supported software for TADDM database serer.............. 27 26. Security features and benefits for the discoery process.............. 29 27. TADDM roles and permissions...... 31 28. Common installation settings...... 33 29. Additional settings for a custom installation. The port numbers and serer details in this table are used by the synchronization serer.. 34 30. Additional port alues. In general, change these port numbers only if you hae already assigned the default port numbers, or if you hae policies regarding port number usage. You must know these port numbers if you install IBM Tioli Change and Configuration (IBM Tioli CCMDB).......... 35 31. Settings for Oracle database. Complete this table only if you are using an Oracle domain database.............. 35 32. Ports used by the PingSensor and PortSensor to make connections. These ports must be open for discoery to work........ 35 33. Common installation settings...... 37 34. Discoery serer port alues....... 37 35. Port alues for primary storage serer... 37 36. Port alues for secondary storage serer 38 37. Settings for Oracle database. Complete this table only if you are using an Oracle domain database.............. 38 38. Ports used by the PingSensor and PortSensor to make connections......... 38 39. Tablespace storage requirements, example 1 42 40. Tablespace storage requirements, example 2 42 41. TADDM deployment types and serers 49 42. Resulting deployment type after upgrade 83 43. Order in which to upgrade the TADDM serers.............. 86 Copyright IBM Corp. 2006, 2014

i Application Dependency Discoery Manager: Installing

About this information The purpose of this PDF document is to proide the related topics from the information center in a printable format. The IBM Tioli Application Dependency Discoery Manager Troubleshooting Guide and the troubleshooting topics in the information center include information on the following items: How to identify the source of a software problem How to gather diagnostic information, and what information to gather Where to get fixes Which knowledge bases to search How to contact IBM Support Conentions used in this information This information describes the conentions that are used in the IBM Tioli Application Dependency Discoery Manager (TADDM) documentation for denoting operating system-dependent ariables and paths and for denoting the COLLATION_HOME directory. It also indicates the location of the collation.properties file, which is referenced throughout the TADDM documentation, including in the messages. Operating system-dependent ariables and paths This information uses the UNIX conention for specifying enironment ariables and for directory notation. When using the Windows command line, replace $ariable with %ariable% for enironment ariables, and replace each forward slash (/) with a backslash (\) in directory paths. If you are using the bash shell on a Windows system, you can use the UNIX conentions. COLLATION_HOME directory The COLLATION_HOME directory is the directory where TADDM is installed plus the dist subdirectory. On operating systems such as AIX or Linux, the default location for installing TADDM is the /opt/ibm/taddm directory. Therefore, in this case, the $COLLATION_HOME directory is /opt/ibm/taddm/dist. On Windows operating systems, the default location for installing TADDM is the c:\ibm\taddm directory. Therefore, in this case, the %COLLATION_HOME% directory is c:\ibm\taddm\dist. Copyright IBM Corp. 2006, 2014 ii

Terms and definitions Location of collation.properties file The collation.properties file contains TADDM serer properties and includes comments about each of the properties. It is located in the $COLLATION_HOME/etc directory. This information contains the terms and definitions for important concepts in the IBM Tioli Application Dependency Discoery Manager (TADDM). asynchronous discoery In TADDM, the running of a discoery script on a target system to discoer systems that cannot be accessed directly by the TADDM serer. Because this discoery is performed manually, and separately from a typical credentialed discoery, it is called asynchronous. business application One or more computer programs or software components that proide functionality in direct support of a specific business process or processes. business serice A group of dierse but interdependent applications and other system resources that interact to accomplish specific business functions. 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 discoery TADDM sensor scanning that discoers detailed information about the following items: Each operating system in the runtime enironment. This scanning is also known as Leel 2 discoery, and it requires operating system credentials. The application infrastructure, deployed software components, physical serers, network deices, irtual systems, and host data that are used in the runtime enironment. This scanning is also known as Leel 3 discoery, and it requires both operating system credentials and application credentials. credential-less discoery TADDM sensor scanning that discoers basic information about the actie computer systems in the runtime enironment. This scanning is also known as Leel 1 discoery, and it requires no credentials. Data Management Portal The TADDM web-based user interface for iewing and manipulating the data in a TADDM database. This user interface is applicable to a domain serer deployment, to a synchronization serer deployment, and to each storage serer in a streaming serer deployment. The user interface is ery iii Application Dependency Discoery Manager: Installing

similar in all deployments, although in a synchronization serer deployment, it has a few additional functions for adding and synchronizing domains. discoer worker thread In TADDM, a thread that runs sensors. Discoery Management Console The TADDM client user interface for managing discoeries. This console is also known as the Product Console. It is applicable to a domain serer deployment and to discoery serers in a streaming serer deployment. The function of the console is the same in both of these deployments. discoery serer A TADDM serer that runs sensors in a streaming serer deployment but does not hae 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 serer A TADDM serer that runs sensors in a domain serer deployment and has its own database. domain serer deployment A TADDM deployment with one domain serer. A domain serer deployment can be part of a synchronization serer deployment. In a domain serer deployment, the following TADDM serer property must be set to the following alue: com.collation.cmdbmode=domain launch in context The concept of moing seamlessly from one Tioli product UI to another Tioli 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. multitenancy In TADDM, the use by a serice proider or IT endor of one TADDM installation to discoer multiple customer enironments. Also, the serice proider or IT endor can see the data from all customer enironments, but within each customer enironment, only the data that is specific to the respectie customer can be displayed in the user interface or iewed in reports within that customer enironment. Product Console See Discoery Management Console. script-based discoery In TADDM, the use, in a credentialed discoery, of the same sensor scripts that sensors proide in support of asynchronous discoery. SE See serer equialent. serer equialent (SE) A representatie unit of IT infrastructure, defined as a computer system (with standard configurations, operating systems, network interfaces, and storage interfaces) with installed serer software (such as a database, a web serer, or an application serer). The concept of a serer equialent also About this information ix

includes the network, storage, and other subsystems that proide serices to the optimal functioning of the serer. A serer equialent depends on the operating system: Operating system Approximate number of CIs Windows 500 AIX 1000 Solaris 1000 Linux 1000 HP-UX 500 Network deices 1000 storage serer A TADDM serer that processes discoery data that is receied from the discoery serers and stores it in the TADDM database. The primary storage serer both coordinates the discoery serers and all other storage serers and seres as a storage serer. All storage serers that are not the primary are called secondary storage serers. streaming serer deployment A TADDM deployment with a primary storage serer and at least one discoery serer. This type of deployment can also include one or more optional secondary storage serers. The primary storage serer and secondary storage serers share a database. The discoery serers hae no database. In this type of deployment, discoery data flows in parallel from multiple discoery serers to the TADDM database. In a streaming serer deployment, the following TADDM serer property must be set to one of the following alues: com.collation.taddm.mode=discoeryserer com.collation.taddm.mode=storageserer For all serers except for the primary storage serer, the following properties (for the host name and port number of the primary storage serer) must also be set: com.collation.primarystorageserer.host com.collation.primarystorageserer.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 serer A TADDM serer that synchronizes discoery data from all domain serers in the enterprise and has its own database. This serer does not discoer data directly. synchronization serer deployment A TADDM deployment with a synchronization serer and two or more domain serer deployments, each of which has its own local database. In this type of deployment, the synchronization serer copies discoery data from multiple domain serers one domain at a time in a batched synchronization process. x Application Dependency Discoery Manager: Installing

In a synchronization serer deployment, the following TADDM serer property must be set to the following alue: com.collation.cmdbmode=enterprise This type of deployment is obsolete. Therefore, in a new TADDM deployment where more than one serer is needed, use the streaming serer deployment. A synchronization serer can be conerted to become a primary storage serer for a streaming serer deployment. For more information, see Conerting from a synchronization serer deployment to a streaming serer deployment. TADDM database In TADDM, the database where configuration data, dependencies, and change history are stored. Each TADDM serer, except for discoery serers and secondary storage serers, has its own database. Discoery serers hae no database. Storage serers share the database of the primary storage serer. TADDM serer A generic term that can represent any of the following terms: domain serer in a domain serer deployment synchronization serer in a synchronization serer deployment discoery serer in a streaming serer deployment storage serer (including the primary storage serer) in a streaming serer deployment target system In the TADDM discoery process, the system to be discoered. About this information xi

xii Application Dependency Discoery Manager: Installing

Installing Three ways of deploying TADDM You can deploy the IBM Tioli Application Dependency Discoery Manager (TADDM) in a domain serer deployment, a synchronization serer deployment, or a streaming serer deployment. The TADDM serers are different depending on the type of deployment you choose. Table 1 indicates the TADDM serers and associated databases that are present according to which deployment type you choose. The synchronization serer deployment is obsolete. Therefore, in a new TADDM deployment, use either a domain serer deployment or a streaming serer deployment. If more than one serer is needed, use the streaming serer deployment. A synchronization serer can be conerted to become a primary storage serer for a streaming serer deployment. For more information, see Conerting from a synchronization serer deployment to a streaming serer deployment. Table 2 on page 2 indicates the user interfaces that are associated with each TADDM serer. The following definitions describe the user interfaces in more detail: Data Management Portal The TADDM web-based user interface for iewing and manipulating the data in a TADDM database. This user interface is applicable to a domain serer deployment, to a synchronization serer deployment, and to each storage serer in a streaming serer deployment. The user interface is ery similar in all deployments, although in a synchronization serer deployment, it has a few additional functions for adding and synchronizing domains. Discoery Management Console The TADDM client user interface for managing discoeries. This console is also known as the Product Console. It is applicable to a domain serer deployment and to discoery serers in a streaming serer deployment. The function of the console is the same in both of these deployments. Table 1. Serers and associated databases in each deployment type Deployment type Serers Associated databases domain serer deployment one domain serer The domain serer has its own database. synchronization serer deployment one synchronization serer A synchronization serer deployment also requires one or more domain serer deployments, each of which has a domain serer. The synchronization serer has its own database. Copyright IBM Corp. 2006, 2014 1

Table 1. Serers and associated databases in each deployment type (continued) Deployment type Serers Associated databases streaming serer deployment at least one discoery serer A discoery serer does not hae a database. primary storage serer The primary storage serer has its own database. one or more optional secondary storage serers The secondary storage serers share the database of the primary storage serer. Table 2. Serers and associated user interfaces in each deployment type Deployment type Serers Associated user interfaces domain serer deployment one domain serer Data Management Portal Discoery Management Console synchronization serer deployment one synchronization serer A synchronization serer deployment also requires one or more domain serer deployments, each of which has a domain serer. Data Management Portal streaming serer deployment at least one discoery serer Discoery Management Console primary storage serer Data Management Portal one or more optional secondary storage serers Data Management Portal Domain serer deployment A domain is a logical subset of the infrastructure of a company or other organization. Domains can delineate organizational, functional, or geographical boundaries. The domain serer runs sensors that discoer data about only the respectie domain. domain serer A TADDM serer that runs sensors in a domain serer deployment and has its own database. domain serer deployment A TADDM deployment with one domain serer. A domain serer deployment can be part of a synchronization serer deployment. In a domain serer deployment, the following TADDM serer property must be set to the following alue: com.collation.cmdbmode=domain Figure 1 on page 3 illustrates the domain serer deployment. 2 Application Dependency Discoery Manager: Installing

Figure 1. Domain serer deployment Synchronization serer deployment The synchronization serer is used in large enterprise enironments, and it unifies the data from indiidual IBM Tioli Application Dependency Discoery Manager (TADDM) domains. synchronization serer A TADDM serer that synchronizes discoery data from all domain serers in the enterprise and has its own database. This serer does not discoer data directly. synchronization serer deployment A TADDM deployment with a synchronization serer and two or more domain serer deployments, each of which has its own local database. In this type of deployment, the synchronization serer copies discoery data from multiple domain serers one domain at a time in a batched synchronization process. In a synchronization serer deployment, the following TADDM serer property must be set to the following alue: com.collation.cmdbmode=enterprise This type of deployment is obsolete. Therefore, in a new TADDM deployment where more than one serer is needed, use the streaming serer deployment. A synchronization serer can be conerted to become a primary storage serer for a streaming serer deployment. For more information, see Conerting from a synchronization serer deployment to a streaming serer deployment. Figure 2 on page 4 illustrates the synchronization serer deployment. Installing 3

Figure 2. Synchronization serer deployment Streaming serer deployment If your deployment requires more than one serer, you realize the following benefits from using a streaming serer deployment rather than a synchronization serer deployment (which is obsolete): greater aailability of data, cost saings, and elimination of merging problems when consolidating data. During discoery, data flows in parallel (or streams) from multiple discoery serers to the primary storage serer, where the data is processed and stored in the database. Only the primary storage serer has a database. Discoery serers are used only for running sensors and therefore do not hae a database. This type of deployment therefore proides the following benefits: Greater aailability of data In a streaming serer deployment, data is aailable as soon as it is discoered. In contrast, in a synchronization serer deployment, the data for a specific domain is unaailable until the synchronization occurs, and data is also unaailable during the synchronization. Cost saings A streaming serer deployment requires less hardware and resources. Elimination of merging problems when consolidating data In a streaming serer deployment, data streams directly to the primary storage serer, which preents the following issues that can occur in a synchronization serer deployment: Complicated merging scenarios Problems that occur if domains oerlap 4 Application Dependency Discoery Manager: Installing

The primary storage serer is the coordinator of the storage serer pool, which is a cluster of storage serers. Each secondary storage serer registers with the primary storage serer, and each discoery serer is notified when a secondary storage serer is added to, or remoed from, the storage serer pool. If a discoery serer has problems when trying to contact a specific secondary storage serer, it tries to contact a different secondary storage serer, and it continues this process until it succeeds. When a new storage serer joins the storage serer pool, the discoery serer is notified by the primary storage serer. The discoery serer then contacts the new storage serer. In a streaming serer deployment, you use the Data Management Portal (web-based user interface) to iew discoery, topology, reporting, and analytical information. You use the Discoery Management Console (client user interface) to perform discoery-related actiities, such as the following actiities: Starting a discoery Showing the progress of a discoery Managing discoery scopes Managing discoery profiles Managing access list information discoery serer A TADDM serer that runs sensors in a streaming serer deployment but does not hae its own database. storage serer A TADDM serer that processes discoery data that is receied from the discoery serers and stores it in the TADDM database. The primary storage serer both coordinates the discoery serers and all other storage serers and seres as a storage serer. All storage serers that are not the primary are called secondary storage serers. streaming serer deployment A TADDM deployment with a primary storage serer and at least one discoery serer. This type of deployment can also include one or more optional secondary storage serers. The primary storage serer and secondary storage serers share a database. The discoery serers hae no database. In this type of deployment, discoery data flows in parallel from multiple discoery serers to the TADDM database. In a streaming serer deployment, the following TADDM serer property must be set to one of the following alues: com.collation.taddm.mode=discoeryserer com.collation.taddm.mode=storageserer For all serers except for the primary storage serer, the following properties (for the host name and port number of the primary storage serer) must also be set: com.collation.primarystorageserer.host com.collation.primarystorageserer.port If the com.collation.taddm.mode property is set, the com.collation.cmdbmode property must not be set or must be commented out. Installing 5

Figure 3 is a simple illustration of a streaming serer deployment that shows the information flow from the discoery serers to the storage serer and its database. Figure 4 proides more detail. It shows the information flow from the discoery serers, each with a Discoery Management Console, to the storage serer pool, which includes multiple storage serers and one primary storage serer. Each storage serer has a Data Management Portal, and all storage serers share one database. In a deployment with multiple storage serers, you might want to hae some storage serers dedicated solely to workload handling for the user interface, reporting, and integration. To do this, set the alue of the following TADDM serer property to true in the $COLLATION_HOME/etc/collation.properties file: com.collation.alwaysbusystorageserer=true If this alue is true, the serer does not participate in the pool of storage serers that handle the discoery workload and can therefore proide a more superior user experience. Figure 3. Streaming serer deployment Figure 4. Streaming serer deployment in more detail Planning for installation Before installing TADDM, you must decide which type of TADDM deployment you want to use. Each type has different requirements and a different installation process. You must also plan for the number of serers, the types of serer, and the type and location of the database. 6 Application Dependency Discoery Manager: Installing

If you plan to use TADDM with the IBM Tioli Change and Configuration Management Database (CCMDB), refer to the planning and installing information for CCMDB. TADDM serer requirements A TADDM deployment might require seeral types of serers, depending on the type of deployment you want to use. Number of serers The number of serers that you need depends on the estimated number of items that must be discoered. You can base your estimate on either of the following two units: 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. serer equialent (SE) A representatie unit of IT infrastructure, defined as a computer system (with standard configurations, operating systems, network interfaces, and storage interfaces) with installed serer software (such as a database, a web serer, or an application serer). The concept of a serer equialent also includes the network, storage, and other subsystems that proide serices to the optimal functioning of the serer. A serer equialent depends on the operating system: Operating system Approximate number of CIs Windows 500 AIX 1000 Solaris 1000 Linux 1000 HP-UX 500 Network deices 1000 Types of serers Domain serers TADDM domain serers discoer and track the configuration items (CIs) in your enironment. A domain serer is part of a stand-alone domain serer deployment or a synchronization serer deployment. Each domain serer, and its associated database, should be limited to approximately 10,000 SEs (or 2,000,000 CIs). If your enironment is larger than this, use multiple serers. You can also improe performance by limiting each serer to a few sources and types of discoered data. For example, you might want one serer to discoer a single type of managed software system regardless of location, rather than organizing the serers according to geography. Installing 7

Note: The synchronization serer deployment type is obsolete. If you need to install a new deployment with multiple serers, use a streaming serer deployment. Discoery serers Discoery serers discoer and track the configuration items (CIs) in your enironment. A discoery serer is part of a streaming serer deployment. Each discoery serer should be limited to approximately 10,000 SEs (or 2,000,000 CIs). If your enironment is larger than this, use multiple discoery serers. You can also improe performance by limiting each serer to a few sources and types of discoered data. For example, you might want one serer to discoer a single type of managed software system regardless of location, rather than organizing the serers according to geography. Storage serers Storage serers process the discoery data from discoery serers. A storage serer is part of a streaming serer deployment. A streaming serer deployment has at least one storage serer, called the primary storage serer; there might also be additional storage serers, depending upon the size of the enironment and the number of items that need to be discoered. If you are not sure how many storage serers you need, you can deploy TADDM with only one storage serer and then add more storage serers as needed to improe performance. Database serers The TADDM database stores the discoered information about configuration items and their relationships, represented using the Tioli Common Data Model. Each TADDM domain serer or primary storage serer has a corresponding database; in a synchronization serer deployment, the synchronization serer also has a database. For testing or ealuation purposes, you can install the TADDM database on the same system as the domain serer, synchronization serer, or primary storage serer. Howeer, in production enironments, a separate database serer is recommended. Anchors If any of the components you need to discoer are separated from the TADDM domain serer or discoery serer by firewalls, you must configure one or more anchors. To discoer components, each TADDM serer must communicate with other computer hosts and network deices. If a firewall preents direct access to certain hosts or deices, you can configure an anchor. An anchor is a TADDM serer running on a system that has direct access to the hosts or deices behind the firewall and acts as a proxy to assist in the discoery process. You do not need to configure anchors during the installation process, but you must include anchors in your installation plan and erify the system requirements for candidate systems. After the installation, you can use the Discoery Management Console to configure hosts to sere as anchors on your network. 8 Application Dependency Discoery Manager: Installing

Windows gateways If your network contains Windows systems, you must specify a Windows system to sere as a gateway serer to discoer information about the Windows systems that are running in your enironment. This gateway serer should be in the same firewall zone as the discoered Windows hosts, and must hae SSH access from the serer. All Windows gateways must be running a supported ersion of Bitise WinSSHD, the Cygwin SSH daemon, or Remotely Anywhere. For more information, see the TADDM Administrator's Guide. You do not need to configure Windows gateways during the installation process, but you must include gateways in your installation plan and erify the system requirements for candidate systems. After the installation, you can use the Discoery Management Console to configure hosts to sere as Windows gateways on your network. An anchor and a gateway can run on the same Windows system. Hardware sizing for a synchronization or domain serer deployment These guidelines can help you determine the quantity and specification of serers that you need to meet your discoery requirements in a synchronization or domain serer deployment. TADDM serer hardware requirements: Use this information to estimate the processor, memory, and disk space requirements for the TADDM serers in a synchronization or domain serer deployment. These guidelines are the minimum specifications for hardware sizing. Seeral factors, including the number of users, can affect serer use. Use the following general guidelines: Use a fast multiprocessor system for the TADDM serers. Using a small number of faster processors is generally a better solution than using a large number of slower processors. For example, a 4-way 3.6 GHz Intel implementation is preferable to an 8-way 2.0 GHz Intel implementation. DB2 and Oracle databases that TADDM uses are configured to take adantage of multiple processors and parallel operations. Note: Running a TADDM serer on irtualized hardware can cause performance problems. These guidelines assume that the TADDM serer and the database serer are on separate systems. You can install a TADDM serer with a local database, but this is not recommended for production enironments. The following table indicates how to determine the serer hardware requirements for your enironment, based on the number of serer equialents (SEs) to be discoered. Installing 9

Table 3. TADDM serer hardware requirements Serer type Processors Processor speed Memory Disk space Domain serer with < 2000 SEs Domain serer with 2000 10,000 SEs Synchronization serer with > 10,000 SEs 2 4 4 2 GHz minimum, 3 GHz recommended 2 GHz minimum, 3 GHz recommended 2 GHz minimum, 3 GHz recommended 4GB 7 GB for product installation 8GB 8GB Anchor 2 1 GHz 2 GB 5 GB Windows gateway 2 2 GHz 2 GB 2 GB 50 GB additional space (for DLA books, log and trace files, and other data) Notes: For a synchronization serer deployment, 64-bit hardware is required because 32-bit systems hae significant scalability limitations. For a domain serer deployment, 64-bit hardware is required for any domain serer that manages more than 2000 serers or 2 million CIs. On 32-bit Windows serers, the 4-Gigabyte Tuning feature must be enabled. (For more information, see http://msdn.microsoft.com/en-us/library/bb613473(vs.85).aspx.) For an anchor serer, when exchanging data you must use Secure Shell (SSH) ersion 2 protocol. Database serer hardware requirements: The processor, memory, and disk space requirements for TADDM database serers are based on the size of your deployment (small, medium, or large). These guidelines assume that the TADDM database is installed on a separate system. You can install TADDM with a local database, but this is not recommended for production enironments. Database performance is also affected by the speed of input/output operations. 10 Application Dependency Discoery Manager: Installing

Table 4. TADDM serer hardware requirements Deployment type Processors Processor speed Memory Disk space Small (< 2000 SEs) Large (2000 10,000 SEs) Enterprise (> 10,000 SEs) 1 2 GHz minimum, 3 GHz recommended 2 2 GHz minimum, 3 GHz recommended 4 2 GHz minimum, 3 GHz recommended 3GB 4GB At least 2 physical dries (3 or more recommended). Initial disk space of 160 6GB MB (required for creating the TADDM schema). Disk space for discoery data. Use either of these formulas to estimate disk space requirement (assuming Leel 3 discoery): CIs 7000 bytes SEs 5,600,000 bytes where CIs is the number of configuration items, and SEs is the number of serer equialents. Additional disk space for ongoing growth. Plan for 10% growth weekly. Hardware sizing for a streaming serer deployment These guidelines can help you determine the quantity and specification of serers that you need to meet your discoery requirements in a streaming serer deployment. These guidelines do not apply to an enironment where TADDM is running on the Linux for System z operating system. These guidelines are the minimum specifications for hardware sizing. Seeral factors, including the number of users, can affect serer use. The size of a deployment is defined in terms of the number of serer equialents (SEs). Small deployment: Less than 2,000 SEs Large deployment: 2,000-10,000 SEs Enterprise deployment: More than 10,000 SEs Use the following general guidelines: Use a fast multiprocessor system for the TADDM serers. Using a small number of faster processors is generally a better solution than using a large number of slower processors. For example, a 4-way 3.6 GHz Intel implementation is preferable to an 8-way 2.0 GHz Intel implementation. DB2 and Oracle databases that TADDM uses are configured to take adantage of multiple processors and parallel operations. For a streaming serer deployment, which is a single database system, run the database on a dedicated database serer. Installing 11

These guidelines assume that the TADDM serer and the database serer are on separate systems. The following options are examples of how you can scale your TADDM enironment as needed: Horizontally, by increasing the size, capacity, or both, of an indiidual component. For example, to run more discoery worker threads on a single discoery serer, you might want to increase the number of processors from two to four. Vertically, by adding additional components to your deployment. For example, if you hae a data center in the USA, Europe, and Japan, you might want to place a discoery serer at each location. Disk space To ensure that sufficient space is aailable for the TADDM installation and logging information, disk space requirements are proided. Alternatiely, you can use the supplied formulas to estimate disk space requirements, paying particular attention to considerations such as growth, TADDM logging, and database logging. Memory size A discoer worker thread is a thread that runs sensors. For a streaming serer deployment, 64-bit hardware is required for all storage serers and discoery serers that use more than 24 concurrent discoer worker threads. This also implies a 64-bit operating system and Jaa irtual machine. For large and enterprise deployments, a 64-bit ersion of the database software is required also. Processor speed The following table outlines the baseline processor types by platform. Table 5. Baseline processor types Platform Intel pseries Sun Baseline processor type Xeon Power6 Sparc You can compare other processor types by using industry standard benchmark data that is aailable from The Standard Performance Ealuation Corporation (SPEC) at http://www.spec.org/. Primary storage serer: The hardware specifications for the primary storage serer depend on the platform and deployment size. The primary storage serer handles topology builds, data presentation requests, and manages the storage serer pool. You must hae one primary storage serer for each TADDM deployment. You can add additional capacity by deploying secondary storage serers. 12 Application Dependency Discoery Manager: Installing

Processor speed The following table lists the minimum processor speed that is required for a primary storage serer, depending on platform and deployment size. Faster processors improe performance. Table 6. Processor speed Minimum processor speed for Platform Minimum processor speed for small deployments large and enterprise deployments Intel 2.5 GHz 3 GHz pseries 2.3 GHz 3 GHz Sparc 2.5 GHz 3 GHz Processor quantity The following table lists the minimum processor quantity that is required for a primary storage serer, depending on deployment size. Table 7. Processor quantity Deployment size Number of processors Small 2 Large 4 Enterprise 4 Memory size The following table lists the minimum memory amount that is required for a primary storage serer, depending on deployment size. Table 8. Memory Deployment size Small Large Enterprise Minimum memory 4 GB 8 GB 8 GB or more Disk space A minimum of 50 GB is needed in addition to what is required for the TADDM product installation. This additional disk space is used to store items such as DLA books, additional logging, and tracing information. Secondary storage serer: The hardware specifications for the secondary storage serer depend on the platform and deployment size. You can add additional secondary storage serers at any time without reconfiguring the discoery serers. Installing 13

Typically, secondary storage serers are used only in streaming serer deployments, but you can, in certain situations, configure secondary storage serers for use in a synchronization serer deployment. For example, you can start up and use multiple secondary storage serers to run seeral bulk loads at an off-peak time to meet elapsed load time requirements. These additional secondary storage serers are used only for this purpose and shut down when not in use. Processor speed The following table lists the minimum processor speed that is required for a secondary storage serer, depending on the platform and deployment size. Table 9. Processor speed Minimum processor speed for Platform Minimum processor speed for small deployments large and enterprise deployments Intel 2.5 GHz 3 GHz pseries 2.3 GHz 3 GHz Sparc 2.5 GHz 3 GHz Processor quantity The following table lists the minimum processor quantity that is required for a secondary storage serer, depending on deployment size. Table 10. Processor quantity Deployment size Number of processors Small 2 Large 4 Enterprise 4 Memory size The following table lists the minimum memory that is required for a secondary storage serer, depending on deployment size. Table 11. Memory Deployment size Small Large Enterprise Minimum memory 4 GB 8 GB 8 GB Disk space A minimum of 50 GB is needed in addition to what is required for the TADDM product installation. This additional disk space is used to store items such as DLA books, additional logging, and tracing information. 14 Application Dependency Discoery Manager: Installing

Discoery serer: The hardware specifications for the discoery serer depend on the platform and deployment size. Processor speed The following table lists the minimum processor speed that is required for a discoery serer, depending on the platform and deployment size. Table 12. Processor speed Minimum processor speed for Platform Minimum processor speed for small deployments large and enterprise deployments Intel 2.5 GHz 3 GHz pseries 2.3 GHz 3 GHz Sparc 2.5 GHz 3 GHz Processor quantity The following table lists the minimum processor quantity that is required for a discoery serer, depending on deployment size. Table 13. Processor quantity Deployment size Number of processors Small 2 Large 4 Enterprise 4 Memory size The following table lists the minimum memory that is required for a discoery serer, depending on deployment size. Table 14. Memory Deployment size Small Large Enterprise Minimum memory 4 GB 8 GB 8 GB Disk space A minimum of 50 GB is needed in addition to what is required for the TADDM product installation. This additional disk space is used to store items such as DLA books, additional logging, and tracing information. Database serer: The hardware specifications for the database serer depend on the platform and deployment size. Installing 15

Processor speed The following table lists the minimum processor speed that is required for a database serer, depending on the platform and deployment size. Table 15. Processor speed Minimum processor speed for Platform Minimum processor speed for small deployments large and enterprise deployments Intel 2.5 GHz 3 GHz pseries 2.3 GHz 3 GHz Sparc 2.5 GHz 3 GHz Processor quantity The following table lists the minimum processor quantity that is required for a database serer, depending on deployment size. Table 16. Processor quantity Deployment size Number of processors Small 2 Large 4 Enterprise 4 Add a processor for each additional 10,000 SEs oer 10,000, up to a total of 12. Memory size The following table lists the minimum memory that is required for a database serer, depending on deployment size. Table 17. Memory Deployment size Small Large Enterprise Minimum memory 4 GB 8 GB 8 GB or more Add 2 GB of memory for each additional 20,000 SEs oer 20,000. Disk space The following components require database disk space: System catalog Tables Indexes Logs Temporary space, for sorts and joins, for example Backup space 16 Application Dependency Discoery Manager: Installing

Disk space and disk drie requirements for a database serer are not a function of only disk capacity. The following table lists some general guidance about disk drie layout on the database serer. Table 18. Number of disk dries or disk arms Number of disk dries (RAID) or disk arms (SAN) required for the TADDM database tables Deployment size Minimum Recommended Small 2 3 or more Large 6 7 or more Enterprise 8 9 or more Place database logs on separate disk dries (RAID) or disk arms (SAN) from the TADDM database tables. Database logs are required for large and enterprise deployments. Initial amount of disk space required for TADDM database To estimate the initial amount disk space that is required for your TADDM database implementation, complete the following steps. These estimates are based on Leel 3 discoery data. Depending on the breadth and depth of data in your enironment, the disk space requirements can change. 1. Use the ci_no ariable to represent the number of CIs. 2. Use the se_no ariable to represent the number of SEs. 3. Use the ci_rds ariable to represent the amount of raw disk space for CIs without any additional disk space for growth. Allow 4000 bytes per CI. ci_rds = ci_no x 4000 4. Use the se_rds ariable to represent the amount of raw disk space for SEs without any additional disk space for growth. An SE consists of approximately 800 CIs. Allow 800,000 bytes per SE. se_rds = se_no x 3,200,000 5. Use the tds ariable to represent the total disk space, including some additional disk space for growth. Use one of the following formulas: tds = ci_rds x 1.75 tds = se_rds x 1.75 This calculation includes additional disk space for temporary space and more. 6. Use the chs ariable to represent the change history disk space. The change history disk space is the amount of space by which the database grows weekly, oer and aboe the initial disk allocation, depending on the frequency of discoery. chs = tds x 1.1 This calculation allows for an increase of 10%. The space requirements increase if additional data is discoered or loaded or if you use the TADDM ersion management feature. The following example of a disk space calculation, based on CIs, is for a large deployment: 1. ci_no = 4,400,000 2. ci_rds = ci_no x 4,000 = 17,600,000,000 Installing 17

3. tds = ci_rds x 1.75 = 30,800,000,000 4. chs = tds x 1.1 = 33,880,000,000 The following example of a disk space calculation, based on SEs, is for a large deployment: 1. se_no = 5,500 2. se_rds = se_no x 3,200,000 = 17,600,000,000 3. tds = se_rds x 1.75 = 30,800,000,000 4. chs = tds x 1.1 = 33,880,000,000 Hardware scaling guidelines: You can use the sample configurations as a guideline for selecting the components for your TADDM implementation. The guidelines assume that you are running Leel 3 discoeries. To optimize discoery throughput, the storage serers should be 100% in use. If they are not, additional discoery serers can be added or the dwcount alue can be increased on the existing discoery serers, if they hae spare capacity. If a storage serer has spare capacity, you can increase the topopumpcount alue. When the storage serers are 100% in use, to increase throughput, increase the number of storage serers. If UI performance becomes poor when running data load operations (for example, sensor discoery or bulk load), you can dedicate storage serers to UI, API, or report operations. If you want discoery serers to use other storage serers, instead of a particular storage serer when persisting results, you can set the following property alue to true on that storage serer: com.collation.alwaysbusystorageserer=true Typically, you set this property alue to true on the primary storage serer or any other storage serer dedicated to UI, API, or report operations. Discoery storage rates: You can use the discoery storage rates that are listed to help you determine the number of components that are required to meet your objecties for discoery. In a synchronization serer deployment, storage to the database is typically the main bottleneck. In a streaming serer deployment, any bottleneck in discoery throughput has moed to the sensors that are waiting for the data to be stored. The following table lists typical discoery storage rates. Table 19. Typical discoery rates Number of storage serers Number of imports (discoery serers) CI rate per second Percent improement 1 2 144 16 2 2 246 101.83 16 3 2 280 33.91 16 Number of threads used for persisting discoery results in the database (topopumpcount) 18 Application Dependency Discoery Manager: Installing

The number of imports that is listed is the number of discoery serers that are able to send enough data to the storage serers so that they are not waiting on sensor results, which means that they are storing at their maximum rate. As the number of storage serers increases, there is an increase in the CI storage rate. Discoery sensor rates: You can use the discoery sensor rates that are listed to help estimate your discoery serer configuration, based on your discoery requirements. The information in this topic was gathered when discoery testing with 96 discoery worker threads (dwcount) running on the discoery serers. This alue is three times higher than the default of 32. Higher dwcount alues can be used, increasing the number of sensors that are running concurrently and the amount of data being stored. The information uses the aerage sensor time per serer, which can ary widely depending on which sensors run, and the breadth and depth of the objects being discoered. The total sensor elapsed time is calculated in the following way: (Number of serers/dwcount) x aerage sensor time per serer The following table lists typical discoery sensor rates. Table 20. Typical discoery sensor rates Number of serers Aerage sensor time per serer (in minutes) Number of discoery worker threads (dwcount) Total sensor elapsed time (in minutes) 5,000 30 32 4,688 78 5,000 30 64 2,344 39 5,000 30 96 1,563 26 10,000 30 32 9,375 156 10,000 30 64 4,688 78 10,000 30 96 3,125 52 Total sensor elapsed time (in hours) Discoered target resources utilization footprint: The TADDM discoery process uses minimal system and network resources. Based on lab-based benchmarks, TADDM typically uses less than 10% of CPU utilization, and less than 1% of operating memory (on discoered hosts) during Leel 3 discoery. Note: Discoered target resource utilization footprint (on discoered hosts) might ary depending on the application type, or its configuration, or both. The following figures show the CPU utilization and operating memory consumption during Leel 3 discoery of WebLogic serers. Installing 19

Figure 5. CPU utilization during Leel 3 discoery of WebLogic serers. Figure 6. Free memory consumption during Leel 3 discoery of WebLogic serers. Serer configurations: You can use the serer configuration guidelines to help estimate the number of storage and discoery serers that you need, depending on the size of your deployment. Based on your discoery requirements, the number of serers you that you need might differ from the numbers that are listed. Small deployment One primary storage serer One discoery storage serer Large deployment One primary storage serer One secondary storage serer Two discoery serers Depending on the geographic location of target computers (one per data center), discoery elapsed time requirements, and so on, more or fewer discoery serers might be required. Enterprise deployment One primary storage serer Two secondary storage serers Three discoery serers Depending on the geographic location of target computers (one per data center), discoery elapsed time requirements, and so on, more or fewer discoery serers might be required. 20 Application Dependency Discoery Manager: Installing