TSCO Gateway Server/BMC Performance Assurance console upgrade best practices

Version 2
    Share:|

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    BMC Performance Assurance for Servers


    APPLIES TO:

    TrueSight Capacity Optimization



    PROBLEM:

     

    What is the best way to upgrade from one release of the BMC Performance Assurance (BPA) or Gateway Server console to a newer version? What is the best way to migrate the BPA/Gateway Server console from one machine to another machine running a newer console version?

      
       
    • TrueSight Capacity Optimization Gateway Server 11.x, 10.x
    •  
    • BMC Performance Assurance for Servers  9.x
    •  
    • Unix console upgrade or migration
    •  
    • Windows console upgrade or migration

     


    SOLUTION:

     

    For simplicity this document will refer to the TrueSight Capacity Optimization (TSCO) Gateway Server and BMC Performance Assurance console (which are the same product, just different names) as the 'BPA console'.  But all concepts in this document apply equally to the TSCO Gateway Server and BPA console upgrade.

    This document is broken into multiple sections:

      
       
    • Section I: Unix console upgrade on the same machine
    •  
    • Section II: Unix console upgrade/migration to new hardware
    •  
    • Section III: Windows console upgrade on the same machine
    •  
    • Section IV: Windows console upgrade to new hardware
    •  
    • Section V: Upgrade validation for both Unix and Windows console
    •  
    • Section VI: Visualizer Database Migration
    •  
    • Section VII: Review the Release Notes
      


    In general most BPA console upgrades are relatively straight forward and result in a seamless transition from the existing product version to the new product version without any interruption in data collection and data processing.

    Even though upgrades are typically uneventful there is still the possibility that something could go wrong and require debugging. That leads to two basic upgrade recommendations:

      
       
    • Do the BPA console upgrade earlier in the week rather than later (Monday or Tuesday would be best)
    •  
    • Begin the BPA console upgrade earlier in the day rather than later
      


    If an upgrade is done Friday afternoon serious upgrade problems may not be discovered until Saturday or even worse Monday. It is best to do the upgrade early in the week and early in the day to ensure sufficient time for problem analysis should the need arrise.

      

    Section I: Unix console upgrade on the same machine

      
      The BPA console installation on Unix includes a Manager run migration script that will seamlessly migrate your Manager runs from the existing console version to the new console version. In order to use that script it is important that you do    not uninstall your existing Perform console release as part of the new console installation. The migration script requires that old console still be installed on the machine in order to be able to migrate the active Manager runs to the new console version.  
     
    When migrating to a new BPA console version on the same machine using the 'migrateManagerRuns.pl' which is installed as part of the console is the best way to do it. That script will list each of the existing Perform console version Manager runs and let you select them individually (or all at one time) and migrate them to the new console installation.  
     
      KA 000029588: In the TSCO Gateway Server/BPA console, what is the best way to migrate Manager runs to a new console version from the previously installed console version? 
     
      Note that the latest BPA console patch set should be applied to the newly installed console version before running the migrateManagerRuns.pl script since migrateManagerRuns.pl problems may require manual effort to workaround which can be avoided by applying the latest BPA Cumulative Hot Fix.  For BPA 9.5 see 000032108: Where can I obtain the latest BMC Performance Assurance version 9.5.02 and earlier agent and console patches? or for CO Gateway Server 10.0 and later see 000097159: Cumulative Hot Fixes for TrueSight Capacity Optimization (CO), CO Gateway Server, and CO Agent, and CO Perceiver 
      
      
      Some general upgrade recommendations: 
      
       
    • Don't uninstall the old BPA console version as part of the upgrade.  You'll need it to use the migrateManagerRuns.pl script to migrate your existing Manager runs to the new release.
       
    •  
    • Do follow Manager run best practices implementation recommendations.  You can use the upgrade as an opportunity to update your Manager *.vcmds files so the runs submitted under the new release are all using the best practice configuration recommendations

      000105215: TSCO Gateway Server/BPA console Manager run configuration best practices for the Unix console
       
    •  
    • Implement General Manager Lite after you implement your new TSCO 10.0 or later Gateway Server.  The reporting is useful to monitor the daily success of data collection.  The daily e-mail can be particularly useful.

      000108584: Tool which summarizes the results for all Gateway Servers (using General Manager), and gathers logs for nodes with collection errors
       
       
    • Install the latest CO 10.0 Gateway Server Cumulative Hot Fix package.

      000097159: Cumulative Hot Fixes for TrueSight Capacity Optimization (CO), CO Gateway Server, and CO Agent, and CO Perceiver
       
    •  
    • In TSCO Gateway Server version 10.7 and earlier, it is a best practice to migrate (dbmigrate) your Visualizer database schema at some point after all of your consoles have been upgraded to the new release when using Unix Populate.  If using Automator populate you can migrate the database schema as soon as you upgrade your "populator" to the latest Visualizer release.
       
    •  
    • Here are some useful commands for validating that, as expected, all data collection requests were properly migrated to the new console version:

      Command to list scheduled Manager runs:

        $BEST1_HOME/bgs/scripts/listManagerRuns.pl -p MANAGER_COMMANDS_FILE OUTPUT_DIRECTORY

      Command to list the status of today's collection requests:

      $BEST1_HOME/bgs/bin/udrCollectStat -D -d `date +%m-%d-%Y` -f "%v %r %d %n: %s, %ch, %ce, %ces %gc %gad %gan %gtd %gtn"

      If you run those commands both before and after the migration from the old console release to the new version you can compare the output and see if there are differences (particularly missing Manager runs or missing computers).
      

    Section II: Unix console upgrade/migration to new hardware

      
      If you are migrating to new physical hardware than you can't use the migration script. You'd instead need to migrate all of the Manager run related files (*.vcmds, *.an, *.dmn) to the new machine, and then submit the Manager run on the new machine. Once the run had been successfully submitted you could then go back to the original console and put a 'run.quit' file into the Manager Output Directory for the migrated run. That will stop the run on the old machine and start it on the new machine. If you use a Start Date of today on the new console for the run it will take ownership of the active collection requests started on the remote node by the old console. Then, at night it will transfer that data and process it on the new console. That will result in a seamless transition from the old console to the new console.  
      
      

    Section III: Windows console upgrade on the same machine

      
      The BPA Windows console only supports a single production installation on the machine at the same time. So, when you upgrade from, say, BPA version 9.0.00 to 9.5.00, the installation will automatically uninstall BPA version 9.0.00 product, installs the new BPA version 9.5.00 console, and migrates the Manager runs to the newly installed console version.  
      
      

    Section IV: Windows console upgrade to new hardware

      
      If you are migrating the Windows console to new physical hardware then it will be necessary to copy all of the Manager run related files (*.msf, *.an. *.plc) to the new machine and then activate the Manager runs on the new machine. Once the runs have been successfully activated ou can then stop the Patrol_Scheduler Service on the original console and set its Startup Type to 'Disabled' via the Services console panel. This will deactivate the Manager runs on the original machine and active them on the new console hardware. Activating the runs as daily Manager runs on the new Windows console will result in them starting immediately on the new console so they will take ownership of the active collection requests started on the remote node by the old console. Then, at night it will transfer that data and process it on the new console resulting in a seamless transition from the old console to the new console.  
      
      

    Section V: Upgrade validation for both Unix and Windows console

      
      If the migration has been successful the UDR Collection Manager (UCM) Status Reports for the new console installation should list each of your migrated Manager runs and list successful data collection for each node in the run.  
     
      https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=000108785 contains additional information on how to make use of the UCM reports.  
      
       Legacy ID:KA295343

     


    Article Number:

    000096505


    Article Type:

    Solutions to a Product Problem



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles