Converting from a synchronization server deployment to a streaming server deployment

Size: px

Start display at page:

Download "Converting from a synchronization server deployment to a streaming server deployment"

Arabella Nicholson
6 years ago
Views:

1 Tivoli Application Dependency Discovery Manager Version 7 Release 2.1 Converting from a synchronization server deployment to a streaming server deployment

3 Tivoli Application Dependency Discovery Manager Version 7 Release 2.1 Converting from a synchronization server deployment to a streaming server deployment

4 ii Application Dependency Discovery Manager: Converting to a streaming server deployment

5 Contents Conventions used in this information.. v Converting from a synchronization server deployment to a streaming server deployment Converting a synchronization server to a primary storage server Preparing domain servers to become discovery servers Importing saved information to each discovery server 2 Adding secondary storage servers Troubleshooting Copyright IBM Corp iii

6 iv Application Dependency Discovery Manager: Converting to a streaming server deployment

7 Conventions used in this information This information uses the same conventions that are used in the IBM Tivoli Application Dependency Discovery Manager (TADDM) documentation for denoting operating system-dependent variables and paths and for denoting the COLLATION_HOME directory. Operating system-dependent variables and paths This information uses the UNIX convention for specifying environment variables and for directory notation. When using the Windows command line, replace $variable with %variable% for environment variables, 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 conventions. 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 v

8 vi Application Dependency Discovery Manager: Converting to a streaming server deployment

9 Converting from a synchronization server deployment to a streaming server deployment After you upgrade to the IBM Tivoli Application Dependency Discovery Manager (TADDM) according to the instructions in the Upgrading TADDM section of the TADDM Installation Guide, you can manually convert a synchronization server deployment to a streaming server deployment. Before you convert to a streaming server deployment, complete the following steps: 1. On Linux operating systems, run the following command to verify that the libstdc++ compatibility package is installed: rpm -a -q grep compat-libstdc++-33 If this package is not installed, run the following command to install the package: yum install compat-libstdc If you did not do so before you upgraded to TADDM 7.2.1, export the access list from each domain server, and copy the TADDMSec.properties file. To export the access list and copy the file, run the following commands: $ cd $COLLATION_HOME $./bin/authconfig.sh -d -f /tmp/auth.out $ cp etc/taddmsec.properties /tmp Converting a synchronization server to a primary storage server To convert a synchronization server deployment to a streaming server deployment, you must first manually convert each synchronization server to a primary storage server. To convert a synchronization server to a primary storage server, complete the following steps: 1. To preserve previously discovered data, perform an incremental synchronization of all domains. Because domain servers in a synchronization server deployment become discovery servers in a streaming server deployment, the change history is lost if you do not perform a synchronization before the conversion to a streaming server deployment. Update the $COLLATION_HOME/etc/sync/tables.extra file as shown in the following example: # for conversion from synchronization server deployment # to streaming server deployment *change_history_table *change_cause_table Including the character * at the beginning of the entries forces a full synchronization of the tables even when an incremental service is requested. 2. Stop the synchronization server. 3. Update the $COLLATION_HOME/etc/collation.properties file with the following changes: v Comment out the com.collation.cmdbmode property, as shown in the following example: Copyright IBM Corp

10 v #com.collation.cmdbmode=enterprise Uncomment the com.collation.taddm.mode property, and set its value to StorageServer, as shown in the following example: com.collation.taddm.mode=storageserver 4. Restart the server, which is now a primary storage server. Preparing domain servers to become discovery servers After you convert each synchronization server to a primary storage server and verify that the primary storage server is running, you must prepare the domain servers to become the discovery servers in the streaming server deployment. On each domain server, you must export and save the discovery profiles, scopes, custom server templates, custom server extensions, and encryption key file to ensure that these items are preserved in the streaming server deployment. Because TADDM does not transfer discovery schedules in the conversion from a synchronization server deployment to a streaming server deployment, the schedules must be redefined for the discovery servers in the streaming server deployment. On each domain server, complete the following steps: 1. Log in with the user ID that is used to start TADDM, and go to the$collation_home/bin directory, as shown in the following example: # su - cmdbuser $ cd $COLLATION_HOME/bin 2. Depending on how you want to export the respective items, run one of the following commands, v To export the discovery profiles, scopes, and custom server templates separately, run the following commands: $./datamover.sh -u administrator -p collation -a export -t template -f /tmp/templates.xml $./datamover.sh -u administrator -p collation -a export -t profile -f /tmp/profiles.xml $./datamover.sh -u administrator -p collation -a export -t scope -f /tmp/scopes.xml v To export the discovery profiles, scopes, and custom server templates to one file, run the following command: $./datamover.sh -u administrator -p collation -a export -f /tmp/all.xml 3. To archive the custom server extensions, run the following command: $ tar cf /tmp/cse-`hostname`.tar $COLLATION_HOME/etc/templates/commands 4. Uninstall TADDM on each domain server. Then, using the TADDM installation wizard, install TADDM on each discovery server, which is analogous to a domain server in your previous deployment. Importing saved information to each discovery server On one discovery server, you must import the information that you exported and saved on the domain server. Import the following information to the discovery server by running the respective commands: discovery profiles, scopes, and custom server templates./datamover.sh -u administrator -p collation -a import \ -f /tmp/all.xml 2 Application Dependency Discovery Manager: Converting to a streaming server deployment

11 discovery profiles./datamover.sh -u administrator -p collation -a import \ -f /tmp/profile.out scopes./datamover.sh -u administrator -p collation -a import \ -f /tmp/scopes.xml custom server templates./datamover.sh -u administrator -p collation -a import \ -f /tmp/templates.xml access list./authconfig.sh -m -f /tmp/auth.out -k /tmp/taddmsec.properties Rules that TADDM applies in importing the files TADDM applies the following rules in importing the files: v If an access list entry or custom server template has the same name on more than one domain server, the last item that is imported to the discovery server overwrites the existing items of the same name. If the items with the same name differ in some way (for example, in the user name, password, or scope restrictions for access list entries), you might want to rename them to have unique names to prevent any problems. v When you import the access list to one discovery server, it is written to one common database and is therefore known to all discovery servers. v If a scope or profile with the same name already exists on the discovery server, the imported scope or profile is renamed to name_taddm. v If a custom server template exists with the same name on the discovery server, the template is merged with the existing template. Limitations The datamover.sh command cannot be used to copy or restore custom server extensions. The custom server extensions are stored on the file system of each discovery server. You can copy the file that contains the extensions from one discovery server to the other discovery servers. The following example shows how to archive the file on four discovery servers: ds1$ scp /tmp/cse-`hostname`.tar ds1:/tmp ds1$ scp /tmp/cse-`hostname`.tar ds2:/tmp ds1$ scp /tmp/cse-`hostname`.tar ds3:/tmp ds1$ scp /tmp/cse-`hostname`.tar ds4:/tmp... repeat for the rest of the servers... After you copy the files to all discovery servers, you must extract the custom server extensions on each discovery server, as shown in the following example: ds1# for i in /tmp/cse*tar >do > tar xf $i > done Adding secondary storage servers If you want to add secondary storage servers to a streaming server deployment, use the TADDM installation wizard to install them. Converting from a synchronization server deployment to a streaming server deployment 3

12 Troubleshooting This information describes some problems that you might have in converting from a synchronization server deployment to a streaming server deployment and provides possible solutions. TADDM cannot successfully run a Level 3 discovery after conversion Problem After the conversion from a synchronization server deployment to a streaming server deployment, TADDM cannot successfully run a Level 3 discovery. Before the upgrade from TADDM 7.2 to TADDM 7.2.1, when TADDM 7.2 was running, configuration data was partly synchronized with the Enterprise Domain Server (known as the synchronization server in the synchronization server deployment), but the data was never used. However, after the conversion to the streaming server deployment, that configuration data must be available for use. Solution For the initial startup of one discovery server in the streaming server deployment, set the following property to true: com.collation.forcetemplatereload=true The configuration data is then rebuilt. After the server starts, remove this property from the collation.properties file. Generic server sensor times out during discovery Problem After the conversion from a synchronization server deployment to a streaming server deployment, including the import of custom server templates using the datamover command, default templates might not be fully migrated. The symptom of this problem is that the generic server sensor (GenericServerSensor is the name that is used in the GUI and logs) times out during discovery, and the sensor logs contain the following information: ERROR template.templatematcher - [TemplateMatcher.E.4] The list of filters for the template <e.g. OracleAppServer> is empty. Solution To fully migrate the default templates, run the following commands: On UNIX systems: $COLLATION_HOME/bin/template-upgrade.sh On Windows systems: %COLLATION_HOME%\bin\template-upgrade.bat 4 Application Dependency Discovery Manager: Converting to a streaming server deployment

14 Printed in USA

Tivoli Application Dependency Discovery Manager Version 7.3. Sensor Reference IBM

Tivoli Application Dependency Discovery Manager Version 7.3 Sensor Reference IBM Tivoli Application Dependency Discovery Manager Version 7.3 Sensor Reference IBM Note Before using this information and