Migrating custom files

There are several files that will need to be migrated from the existing Perform console to the new machine. The most common files to migrate are:

• Manager definition files (*.vcmds)
• Analyze commands files (*.an)
• Domain files (*.dmn)
• User hardware table ($BEST1_HOME/local/setup/best1user.hrw)
• Console configuration/customization files ($BEST1_HOME/local/setup/*.*)

The Manager, Analyze, and Domain files do not have a standard default location so they may be anywhere on your existing Gateway Server console. It will be necessary to locate those files and then move them to your new console.  The paths to them will be available in the *.vcmds files associated with active Manager runs.

One best practice recommendation is to build a directory structure that contains all of those files outside of the $BEST1_HOME directory and separate the files used as part of the nightly Manager runs from the files used in ad hoc Manager runs.

The default and best location for files for nightly runs are:
  /usr/adm/best1_workspace/automation - Input files such as the *.vcmds, *.an, and *.dmn files
  /usr/adm/best1_workspace/repository - The console UDR data repository directory
  /usr/adm/best1_workspace/results - The Manager Output directories

It can then be useful, but not required, to create a parallel directory structure for ad hoc runs.

For example:
Another option is to leave the files in the same directories, but clearly name them to make it obvious which ones are associated with nightly Manager runs and which are associated with ad hoc Manager runs.

Migrating Manager runs

Let's start by assuming that Manager runs have been submitted using Agent List files.  This means that under Administration -> Gateway Manager -> Gateway Servers -> [Select the Gateway Server].  Note the Agent List names as those will be used to define the Manager run.

One can obtain a list of the currently scheduled Manager runs using the 'listManagerRuns.pl' command:
 

In the above sample output there are 5 unique Manager runs scheduled (assuming the use of Agent List files to define the Manager run). The first column in the output is the Manager Commands File (the *.vcmds file) and the second column is the associated Manager Output Directory.  One can then find the Domain (*.dmn) files and Analyze commands (*.an) files that are referenced by the run by looking in the *.vcmds file.

When an Agent List file has been used to define a run if there are more computers contained in the Agent List than can fit within a single Manager run then additional Manager runs will be scheduled with a number being appended to the VCMDS file name.  So, for example /usr/adm/best1_workspace/automation/tsco2002labs.vcmds gets split into separate runs tsco2002labs.vcmds, tsco2002labs1.vcmds, tsco2002labs2.vcmds.
  
Once the list of scheduled runs is known, copy all those files to the new machine and either maintain the same directory path or update all the Manager runs to point to the new locations of the files, and then re-submit the runs via the GUI.  NOTE: For Agent List Manager runs split into multiple scheduled Manager runs you only need to copy the main *.vcmds file and when you submit that Manager run the AutoNodeDiscovery command will automatically split the Agent List into multiple Manager runs.

Although not necessary, it can be useful to update the 'Start Date' of the run to 'today' and confirm the 'End Date' of the runs remains in the distant future.

There are two different ways that runs can be migrated:
  (A) Resubmitting the Manager runs via the Gateway Manager UI to the new Gateway Server
  (B) Via the Gateway Server command line

Resubmitting the Manager runs via the Gateway Manager UI to the new Gateway Server

For Agent List Manager runs, when resubmitting the Manager runs via the Gateway Manager UI, the only files that need to be copied to the Gateway Server are the *.an files that have been specified as the workload characterization files in the Manager VCMDS file.  When you resubmit the Manager run it will ask for the Agent List to be specified and it will use whatever properties have been set in the default VCMDS as the properties to use to resubmit the run (beyond the few properties you are allowed to set when submitting a Manage run via the Gateway Manager UI.

Resubmitting the Manager runs via the Gateway Server command line

This process should work if the file paths are going to be the same on the new machine as the old machine.  If you need to change file paths then the process will be move involved.

Migration steps:
  (1)    Copy all files associated with the definition of the nightly Manager run (*.vcmds, *.dmn, *.an) from the existing TSCO Gateway Server to the new TSCO Gateway Server
  (2)    Copy the $BEST1_HOME/local/manager/run/AgentAutoDiscovery.csv file from the original machine to the new machine (This is basically moving the AutoNodeDiscovery ‘Agent List’ registration from the old machine to the new machine)
  (3)    Either copy the $BEST1_HOME/local/setup/collectManager.cfg and dataProcessing.cfg files from the old machine or update the configuration on the new machine to ensure the same throttling properties.

Now that the files are in place you need to submit all the Manager runs.

That can be done with the following command:
  $BEST1_HOME/bgs/scripts/best1manager -p manager.vcmds

where 'manager.vcmds' is the name of the Manager run to start.

Migrating AutoETL runs

Contract Technical Support for more details on how to best migrate the ownership of the nightly Manager runs from an existing set of AutoETL runs associated with the existing TSCO Gateway Server to new AutoETL runs associated with the new TSCO Gateway Server.  There isn't a documented process available to adjust the configure of the existing ETLs to point to the new TSCO Gateway Server so it will be necessary to register a new set of ETLs for the new TSCO Gateway Server.

The basic outline is:
  (1)  Add the new Gateway Server via Gateway Manager
  (2)  Let AutoETL create the new ETLs
  (3)  Let the ETLs run at least 1 day so they take ownership of the existing entities
  (4)  You can now delete the old ETLs

The key point is that you don’t want to delete the old ETLs before letting the new ones run (otherwise you’ll need to reconcile the entities).

Terminating runs on the old console

Once the run migration is complete, one can check the manager runs via the following commands:

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

• $BEST1_HOME/bgs/bin/udrCollectStat -D -d `date +%m-%d-%Y` -f "%v %r %d %n: %s, %ch, %ce, %ces %gc"   ---That will list the status of the collection requests (so listing all of the computers that this run has started collection for).

Note that it is important that once the runs have been migrated successfully to the new console they must be stopped on the old console (as described above). That can either be done by:

• (A) putting a 'run.quit' file in each of the Manager Output Directories on the old console

            - or -

• ( B ) Killing the running 'udrCollectMgr' processes on the old console and removing the 'pcron' job from cron.

Option (A) is preferred but can be annoying if an environment has a lot of Manager runs that need to be stopped on the old console.

The steps listed above will work as long as you don't try to clear the 'pending' data collection requests. The new console will issue duplicate collection requests to the existing pending data collection requests and the remote node will collect the data as expected. The pending data collection requests don't really care which console issued the collection request since they just relate to the parameters of data collection - the console handles data transfer separately in Manager.

If there is some reason to clear the pending collection requests (such as one of the collection parameters needs to be changed (the sample rate, the spill interval, the daily collection start time, or the daily collection end time) then would be be necessary to clear the active collection requests. If you need to clear the pending collection requests (which typically isn't necessary) then you'll need to do things a little differently.

Terms:

• Console A -- The original console being replaced
• Console B -- The new console being set up
• Day X -- The day the new console is intended to pick up data collection, transfer, and processing.

Step 1

On day X, you clear the pending collection requests registered on the remote node from console A.

The easiest way to do that would be a script that issued the following command console A as the user under which the Manager runs are scheduled:
You can get a list of the remote nodes via the following command run on console A:
Where MM-DD-YYYY is the current date such as 06-02-2009.

Note that this will stop the active data collection request on the machine, so during this transition period there won't be any active UDR data collection happening on the machine.

Step 2

Start the Manager runs on console B with a Start Date of today, and End Date way in the future, and with the normal Begin/End times for collection (00:00 - 23:59).

Step 3

On console A (the old console):

1. Stop the previous Manager runs by creating a 'run.quit' file in each active Manager Output Directory.
2. On day X+1 remove the call to 'pcron' from the Manager user's crontab

Alternately, you can:

1. Kill the running udrCollectMgr processes
2. Remove the 'pcron' call from the Manager user's crontab
3. Delete or rename the files in the $BEST1_HOME/bgs/pcron/repository/ directory

 
Step 4 After the runs were initiated on the new console in Step 2 you should have active data collection requests on all the remote nodes which are writing into the UDR data files that were being written at the beginning of the day by the collection requests issued from the old console. The UDR Collection Manager (UCM) Status Reports on the new console should be properly updated and list active data collection on each of the remote nodes.

At this point you are done. The new console should transfer the data from the remote nodes and process it that night.