IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Upgrade from a previous installation > Scenario: a rolling product upgrade

IBM Tivoli Monitoring, Version 6.3 Fix Pack 2

Expected results

This section contains the expected results of the upgrade scenario.

  1. When the primary hub monitoring server is down while completing step 6:

    1. Configure the portal server to point to the newly acting hub monitoring server, and verify that expected agents and situations show up on the Tivoli Enterprise Portal client.

    2. Verify that the secondary monitoring server has taken over as acting hub, in other words, that these messages appear in its log:

      • KQM0004 "FTO detected lost parent connection"

      • KQM0009 "FTO promoted secondary as the acting HUB"

    3. Verify that the event handler your site is using (either Tivoli Enterprise Console or Netcool/OMNIbus) is still being updated, now by the secondary hub, by causing an event state to change and validating the state of all events on the remote console.

    4. Verify that attribute collection was uninterrupted by examining the history data, by varying attribute values at the agent, and by observing the change in the portal client.

    5. Ensure that the primary hub Tivoli Enterprise Monitoring Server is not restarted by the upgrade process until all remote monitoring servers and directly connected agents have successfully failed over to the secondary hub.

  2. After completing step 6, verify that the primary hub Tivoli Enterprise Monitoring Server has taken on the role of standby monitoring server: ensure its log contains these messages:

    • KQM0001 "FPO started at ..."

    • KQM0003 "FTO connected to ..."

    • KQM0009 "FTO promoted secondary as the acting HUB"

    • KQM0009 "FTO promoted primary(Mirror) as the acting HUB"

    The log for the secondary hub monitoring server should contain these messages:

    • KQM0005 "FTO has recovered parent connection ..."

    • KQM0009 "FTO promoted secondary as the acting HUB"

    Use the sitpad and taudit tools for assistance. These tools can be downloaded from the IBM Tivoli Integrated Service Management Library Web site at IBM Integrated Service Management Library.

  3. When the secondary hub Tivoli Enterprise Monitoring Server is stopped while completing step 7:

    1. Configure the Tivoli Enterprise Portal Server to point to the acting hub, the primary.

    2. Verify that the primary monitoring server has taken over as the acting hub; its log should contain these messages:

      • KQM0004 "FTO detected lost parent connection"

      • KQM0009 "FTO promoted primary as the acting HUB"

    3. Verify that either Tivoli Enterprise Console or Netcool/OMNIbus is still being updated with event information.

    4. Verify that attribute history is still being collected as in substep 1.d.

    5. Ensure that the secondary hub Tivoli Enterprise Monitoring Server is not restarted by the upgrade process until all remote monitoring servers and directly connected agents have successfully failed over to the primary hub.

  4. After completing step 7, verify that the secondary hub Tivoli Enterprise Monitoring Server is functional by examining the log/trace records of both hub monitoring servers for these messages.

    In the primary hub's log:

    • KQM0005 "FTO has recovered parent connection ..."

    • KQM0009 "FTO promoted primary as the acting HUB"

    In the secondary hub's log:

    • KQM0001 "FPO started at ..."

    • KQM0003 "FTO connected to ..."

    • KQM0009 "FTO promoted primary as the acting HUB"

    • KQM0009 "FTO promoted secondary(Mirror) as the acting HUB"

    Use the sitpad and taudit tools for assistance.

  5. When the Tivoli Enterprise Monitoring Server is stopped while completing step 11 for a given remote monitoring server, verify that either Tivoli Enterprise Console or Netcool/OMNIbus is still being updated, now by the remote monitoring server configured for each agent, and that attribute collection was uninterrupted, as in substep 1.d. Examine the log/trace records of each remote Tivoli Enterprise Monitoring Server to verify agent reporting; use the sitpad and taudit tools for assistance.

  6. After completing step 11 for a given remote Tivoli Enterprise Monitoring Server, verify that the monitoring server is operational by examining its log/trace records.

    Agents do not automatically switch back to their primary monitoring server unless the secondary server fails or the agents are manually restarted.

  7. Ensure the historical collection of attributes is unbroken, in both short-term and long-term history.

  8. Ensure situations are reported to Tivoli Enterprise Console and to Netcool/OMNIbus without interruption. Verify that always-true situations are still true after agent switching.

  9. Verify that the Tivoli Enterprise Portal client for the acting hub Tivoli Enterprise Monitoring Server shows attribute and situation data at all times.

  1. Pure events are lost when failover occurs from the primary hub to the secondary and back, as events are not replicated across the two hubs.

  2. All situations are restarted during failover, so a situation that was already raised at the primary hub will be raised once again if the situation is still true when failover occurs.

  3. A master reset is issued to Tivoli Enterprise Console when the failover occurs, with this event: "Hotstandby TEMS switched. New Primary TEMS hostname_of_newly_active_TEMS." Events raised after the failover will be resent.

  4. When a failing monitoring server is restarted, Tivoli Enterprise Console receives this event: "TEMS hostname_of_restarted_TEMS restarted."


Parent topic:

Scenario: a rolling product upgrade

+

Search Tips   |   Advanced Search