IBM Tivoli Software IBM Tivoli Software

[ Bottom of Page | Previous Page | Next Page | Contents ]


Step 5: Migrate the administration server and database to V2.1

Shows the schematic representation of the environment to be migrated, with the administration server highlighted.

The migration requires you to migrate the administration server database to V2.1, and install a V2.1 administration server to replace the old version.

Choice: do you want to use new computers or reinstall the components on the same computers?
The advantage of using new computers is that not only do you get the benefit of features like the more powerful processors, faster clock speed, and larger disk, but also you can install the V2.1 components and test them without interrupting the functioning of your existing V1.1.1 installation.

The advantage of re-using the existing computers is that not only do you save on computer resources, but also the migration procedure is a little simpler.

The differences are illustrated in the following scenarios:

Step 5 Scenario 1: all new computers
In this scenario you install the V2.1 components on new computers. You would take the following steps:
  1. Install new administration components: Install the new administration server and database on the new computers you have chosen for this purpose. This will be the permanent home for your administration server components. Either before or during this process you install the prerequisite version of DB2 on all computers, and the prerequisite version of WebSphere Application Server on the computer where the administration server is going to be.
  2. Test the configuration: Install a runtime server and database and deploy a couple of agents. Test that the administration server is working correctly and that you have configured it correctly, for example, for SSL. The runtime server can either be a production runtime server that you will want to use in the completed configuration, or it can be a test runtime server that you will uninstall after the testing is completed.
  3. Stop the administration servers: Stop both the V1.1.1 and V2.1 administration servers, and drop the test administration server database.
  4. Migrate the administration database: Migrate the V1.1.1 administration server database on the computer where it is installed.
  5. Copy the database: Copy the migrated database to the computer where you had installed the new administration server database.
  6. Choice: retain use data recorded at the runtime servers after the V1.1.1 administration server was stopped? You now have to reconnect the runtime servers to the administration server. The alternatives are:
    Reconfigure runtime servers:
    Change the runtime server's communications configuration files to point to the new administration server. This involves stopping the V1.1.1 runtime servers, reconfiguring them and restarting them. Inventory data from the agents is saved in the runtime servers' databases, but any use data in the runtime servers' memory is not saved.
    Recycle administration server's host name
    If you want to retain the continuity of this data, one way would be to disconnect the V1.1.1 administration server from the network, and give the V2.1 administration server the same host name as the V1.1.1 administration server had.
  7. Start V2.1 administration server: Restart the administration server. The next time, according to its schedule or its requirements, that a runtime server connects to the administration server, the mismatch between its catalog and the administration server's catalog causes the new catalog to be downloaded, but no other changes are made until the runtime servers themselves are migrated.

See Scenario 4.1: all new computers for full details of this procedure.

Step 5 Scenario 2: same computers
The second scenario assumes that you have the administration server and its database on separate computers, and you want to maintain them on those computers.

Take the following steps:

  1. Stop the V1.1.1 administration server:
  2. Uninstall V1.1.1 administration server database: Uninstall the administration server database, being careful not to drop the database when requested.
  3. Migrate the administration server database: Migrate the V1.1.1 administration server database on the old administration database computer.
  4. Upgrade the hardware and operating system: You will almost certainly want to upgrade the memory of the administration server database's computer, and maybe the operating system as well.
  5. Upgrade DB2. The version of DB2 that was supported by V1.1.1 (version 7.2.0 with fix pack 7) is not supported by V2.1. You will need to upgrade DB2 on the administration server database computer. You have two choices: apply a fix pack to bring DB2 up to the V2.1 supported level (fix pack 10a) or upgrade to version 8.1.4. If you choose the former, you need only apply the fix pack to the existing version of DB2; if you decide to upgrade you will need to export the Tivoli License Manager database or databases involved, and uninstall the old version before installing version 8.1.4 If you decide to migrate to version 8.1.4, you can use either the bundled prerequisite version or your own version (see the discussion in the Planning chapter of the IBM Tivoli License Manager: Planning, Installation, and Configuration, version 2.1). The migration procedure described below explains when to do this upgrade, but for detailed instructions you must refer to the original documentation for DB2.
  6. Uninstall V1.1.1 administration server.
  7. Upgrade the hardware and operating system: You will almost certainly want to upgrade the memory of the administration server's computer, and maybe the operating system as well.
  8. Upgrade WebSphere Application Server: None of the versions of WebSphere Application Server that were supported by V1.1.1 are supported by V2.1. You will need to upgrade WebSphere Application Server on the administration server computer. You can use either the bundled prerequisite version or your own version (see the discussion in the Planning chapter of the IBM Tivoli License Manager: Planning, Installation, and Configuration, version 2.1). The migration procedure described below explains when to do this upgrade, but for detailed instructions on how to upgrade, you must refer to the original documentation for WebSphere Application Server.
  9. Upgrade DB2: The version of DB2 that was supported by V1.1.1 (version 7.2.0 with fix pack 7) is not supported by V2.1. You will need to upgrade DB2 on the administration server computer. You have two choices: apply a fix pack to bring DB2 up to the V2.1 supported level (fix pack 10a) or upgrade to version 8.1.4. If you choose the former, you need only apply the fix pack to the existing version of DB2; if you decide to upgrade you will need to export the Tivoli License Manager database or databases involved, and uninstall the old version before installing version 8.1.4 If you decide to migrate to version 8.1.4, you can use either the bundled prerequisite version or your own version (see the discussion in the Planning chapter of the IBM Tivoli License Manager: Planning, Installation, and Configuration, version 2.1). The migration procedure described below explains when to do this upgrade, but for detailed instructions you must refer to the original documentation for DB2.
  10. Install V2.1 administration server: Install the V2.1 administration server, identifying the migrated administration server database when requested.
  11. Start V2.1 administration server: When you restart the administration server, the runtime servers plug in. The mismatch between their catalog and the administration server's catalog causes the new catalog to be downloaded, but no other changes are made until the runtime servers themselves are migrated.
    Note:
    If both administration server and database are on the same computer you follow the same basic procedure, but you can uninstall the components together.

See Scenario 4.2: same computers for full details of this procedure.

Whichever choice you make, at the end you will have a new V2.1 administration server and its migrated database, using the required prerequisite software.

The runtime servers of V1.1.1 are compatible with the administration server of V2.1, so you can recommence license monitoring immediately after this step.

Attention: The following restrictions to functionality should be noted while a runtime server is at V1.1.1 while its administration server is at V2.1:

You can keep this configuration with no runtime servers migrated for an indefinite period, but during that period you will not be able to take advantage of the new facilities in the V2.1 administration server.

Note:
If you have any agents at versions prior to 1.1.1, a warning message about them will be issued by the migration procedure.

[ Top of Page | Previous Page | Next Page | Contents ]