The SimManager system can be fully integrated with advanced job scheduling and queuing software, such as:
• AM (MSC Analysis Manager)
• LSF (Platform Load Sharing Facility)
• SGE (Sun Grid Engine)
For installation and access to the required job scheduling and queuing software, consult your internal systems administrator. To configure the SimManager system for use with LSF or other job scheduling and queuing systems, see the MSC SimManager Enterprise Configuration and Deployment Guide.
MSC Analysis Manager
Quick start installation and configuration guide
MSC Analysis Manager is a client-server based job-submission software package for unix/linux and Windows operating systems. It supports job submit, monitor and abort capabilities. MSC Analysis Manager (AM) must be installed on all machines involved in the job flow, from submit machine to execute machine(s) and one scheduler machine (which can be the same machine as the others). Once installed, the single scheduler machine needs configuration files and runs a QueMgr scheduler process.
All other client machines do not need any configuration files, but they do need the AM install directory tree with all the AM binaries. All client machines also must run an RmtMgr remote access process.
To install, execute the appropriate installer program:
• aminstall-<version>.exe - for Microsoft Windows operating system
• aminstall-<version>.sh - for all unix/linux operating systems Running this install program will do the following:
1. Check for root or Administrative privileges.
If you do not have required permissions you may still install the AM software but some steps will not be performed. Those steps are the installation of the QueMgr and/or RmtMgr processes to the /etc/rc* boot up scripts on unix/linux machines; and the installation of the QueMgr and/or RmtMgr services on Windows machines.
2. Prompt for the <am-install-path> directory.
3. Check for a pre-existing AM installation in this <am-install-path> dir.
If a previous AM installation is found then you can continue to install and this will become an upgrade where the AM binaries are updated to those in the installer package, but the configuration files presently found will remain as is.
4. Ask if this is the QueMgr scheduler machine.
If so then more questions will be asked for information to create the configuration files.
5. Prompt for any additional QueMgr and/or RmtMgr start up arguments
6. Setup execution path for RmtMgr for running SimXpert batch scripts from SimManager (optional)
7. Start QueMgr and/or RmtMgr.
Depending on if this is a scheduler server machine (QueMgr) or if this is a client machine which runs jobs or submits (RmtMgr)
An example of the installation script output is shown below. Text in bold specifies data entered by users.
Press <Enter> (carriage return) where specified or no input is required.
C:\> .\aminstall-2005.1.41.exe MSC AnalysisManager Installer
Enter MSC AnalysisManager 2005.1.41 install dir : c:\MSC.Software\MSC.AnalysisMgr
Installing AM in c:\MSC.Software\MSC.AnalysisMgr ...
Are you sure ?
Please answer [y]es or [n]o : y
Is this the master scheduler (QueMgr) host for the entire network
?
(Do you want to create the AM config files now ?) (config files are only needed on the QueMgr host)
Please answer [y]es or [n]o : y
Enter hosts and arch types where analysis jobs can run:
host and arch separated by spaces, Press <Enter> after each entry blank line to end list
possible arch types:
WINNT WIN8664 LX86 LX8664 LXIPF HP700 HPIPF RS6K SUNS SGI5:
For example:
host arch:
---host1 WINNT
Enter AM admin username (amuser) : Press <Enter>
Enter the master scheduler (QueMgr) port (default = 2900) : Press
<Enter>
QueMgr cmd-line args:
usage: C:\MSC.Software\MSC.AnalysisMgr\bin\WINNT\QueMgr.exe
Enter additional QueMgr cmd-line args (leave blank for none) : Press <Enter>
installed service MSCQueMgr2005.1.41 ...
cmdline: C:\MSC.Software\MSC.AnalysisMgr\bin\WINNT\QueMgr.exe started service MSCQueMgr2005.1.41 ...
Argument Description
-port < > - port number to use for QueMgr on this host (2900)
-rmgrport < > - port number to use for all RmtMgrs on all machines (2800)
-path < > - AM install path on this host (for bin and org) (<am-install-dir>) -orgpath < > - AM install path (for only org) (if different than -path <arg>) -ipaddr < > - specific IP address (1.2.3.4 format) if this machine is multi-homed -port_start < > - starting port number in range
-org < > - specific org name to use - if different than "default"
-log < > - specific log file to use
-nodefaultuser - don’t allow processes to run as admin user if requested user does not exist -queue_only - submits allowed to only queues / groups and not to individual AM hosts
RmtMgr cmd-line args:
usage: C:\MSC.Software\MSC.AnalysisMgr\bin\WINNT\RmtMgr.exe
Enter additional RmtMgr cmd-line args (leave blank for none) :
<Enter>
installed service MSCRmtMgr2005.1.41 ...
cmdline: C:\MSC.Software\MSC.AnalysisMgr\bin\WINNT\RmtMgr.exe started service MSCRmtMgr2005.1.41 ...
AM_HOME=C:\MSC.Software\MSC.AnalysisMgr
AM_HOME is added to the system-wide env settings.
If this env var is not set in the current cmd/shell/window, start a new cmd/shell/window before using AM.
The scheduler machine (QueMgr) installation is complete. Installation of AM on the client (RmtMgr only) machine is similar. When the installer program asks if this is the master scheduler (QueMgr) host - answer no. Then answer two more questions when prompted:
Enter the master scheduler (QueMgr) host : host1
Enter the master scheduler (QueMgr) port (default = 2900) :
<Enter>
The client machine (RmtMgr) installation is then complete.
The unix/linux AM installer is very similar except instead of automatically installing the QueMgr and/or RmtMgr services it creates the boot up /etc/rc* scripts as appropriate for the current platform and then Note: If any remote job execute hosts are Windows based it is suggested to run the AM
addamuser utility on this host to enter a fallback user account.
Argument Description
-port < > - port number to use for RmtMgr on this host (2800)
-path < > - AM install path on this host (for bin and org) (<am-install-dir>) -orgpath < > - AM install path (for only org) (if different than -path <arg>) -ipaddr < > - specific IP address (1.2.3.4 format) if this machine is multi-homed -nodefaultuser - don’t allow processes to run as SYSTEM if requested user does not exist -port_start < > - starting port number in range
asks if you want to start each daemon process up now. If yes is selected, these processes will be started now and then on each reboot these will be started automatically.
To uninstall AM run:
Windows:
<am-install-path>\bin/WINNT\uninstall.exe or
<am-install-path>\bin\WIN8664\uninstall.exe UNIX/Linux:
<am-install-path>/uninstall.sh
Note: The AM uninstaller will REMOVE all files in the AM installation directory, so do not put other non-AM related files in the <am-install-path> directory or they will be removed when you uninstall AM.
Directory Structure
The <am-install-path> directory tree contains these files and directories:
Figure 4-1 Directory Structure
where: <arch> dirs include the directories of WINNT, WIN8664, LX86, LX8664, LXIPF, HP700, HPIPF, RS6K, SUNS, SGI5. On Windows platforms only the WINNT and WIN8664 dirs are installed. On unix/linux platforms you can select at install time the bin dirs you need to install.
To enable the path additions for SimXpert job submissions, create a file called "path.cfg" that you can optionally have in the <am-install-dir>. This file execution paths in this file will get added to the PATH every time a Analysis Manager job is run. The format of this file is simply a list of paths to append, either one per line or all on a single line separated by the appropriate character (: for unix/linux) (; for windows).
For example:
c:\MSC.Software\SimXpert/WINNT\bin;d:\some\other\dir c:\another\dir\to\add
The proj directory is a temporary storage area when jobs are first started, before they move to the scratch directory as specified in the disk.cfg file. The log directory is where the QueMgr writes the QueMgr.log file.
For a server host, which runs the QueMgr, three AM config files must be created and then the QueMgr started. This is done automatically by the AM installer. There is usually only one QueMgr for an entire network, so you select only one host for this step, whereas RmtMgr runs on all hosts in the network that
actually execute jobs. If there is a close-coupled cluster involved then typically the QueMgr would be run on the head node so it can 'see' the cluster client nodes as well as any submit client hosts.
The config files are in <am-install-path>/default/conf directory and are called host.cfg, disk.cfg and msc.cfg. The exec-on-que method is shown below.
The QueMgr will bind to port 2900. You can change this with the -port <> cmd-line option. The QueMgr cmd-line options are:
The host.cfg file describes each host and application combination, (called an am-host).
For exec-on-que apps the application is $JOBFILE – the script/program you actually are submitting.
An example of the host.cfg file is:
#---# MSC AnalysisManager host.cfg file
-rmgrport < > - port number to use for all RmtMgr(s) on all machines in AM config -path < > - AM install path on this host (for bin and org)
-orgpath < > - AM install path (for only org) (if different than -path <arg>) -ipaddr < > - specific IP address (1.2.3.4 format) if this machine is multi-homed -port_start < > - starting port number in range
-org < > - specific org name to use - if different than "default"
-log < > - specific log file to use
-nodefaultuser - don’t allow processes to run as admin user if requested user does not exist -queue_only - submits allowed to only queues / groups and not to individual AM hosts -version - print AM version
#---The disk.cfg, msc.cfg, and org.cfg files are automatically generated by the AM installer program from the data you provide.
The disk.cfg file describes the file systems each app/host can use.
An example disk.cfg file is:
#---# MSC AnalysisManager disk.cfg file
#---#
#A/M Host File System Type (nfs or blank)
#---remote_exec_host1 C:\TEMP
#---The msc.cfg file defines queues (or groups) of am-hosts from the host.cfg file.
An example msc.cfg file is:
#---# MSC AnalysisManager msc.cfg file
#---#
SORT_ORDER: free_tasks cpu_util last_job_time avail_mem free_disk
#
#---GROUP: all_hosts
AM_HOSTS: remote_exec_host1 MIN_DISK: 20
#---An org.cfg file should also be generated on every host in the <am-install-path>, which contains the info for a client program to contact the QueMgr.
An example of the org.cfg file is:
#---# AnalysisManager org.cfg file
#---#
# Org Master Host Port #
#---default host1 2900
#---The default org name of "default" can be used unless you want to include more than one org in your site.
The default port for QueMgr is 2900, unless you want to include more than one org in your network. See above cmd-line options for how to change the QueMgr port number.
There is also an optional sepusers.cfg file in the default/conf config dir. In this file is the list of user accounts (one per line) that AM will allow a user to become, if not the same as the submitting user. An asterisk ‘*’ is allowed to match any separate user specified at submit time.
The RmtMgr will bind to port 2800. You can change this with the -port <> cmd-line option. The RmtMgr cmd-line options are:
If you have a firewall and need to control the range of ports AM uses, you can create a port.cfg file in the
<am-install-path> dir, which contains the starting port number to use. AM programs will only bind to new ports starting at that value and try to use as few ports as possible increasing in value from there. If many jobs are active at the same time however, the number of ports in use could increase.
If any changes are made to the config files after QueMgr is already running then the QueMgr needs to be restarted. This can be done either by stopping the QueMgr process/service and then starting it up again, or via the TxtMgr interactive admin command, which asks the QueMgr to reconfigure itself. For Windows there are also utilities in the bin/<arch> directory for this: stop_server.bat,
Argument Description
-port < > - port number to use for RmtMgr on this host -path < > - AM install path on this host (for bin and org)
-orgpath < > - AM install path (for only org) (if different than -path <arg>) -ipaddr < > - specific IP address (1.2.3.4 format) if this machine is multi-homed -admin < > - admin user - override of ADMIN: setting in configuration (host.cfg) -port_start < > - starting port number in range
-nodefaultuser - don’t allow processes to run as admin user if requested user does not exist
-version - print AM version
stop_client.bat, start_server.bat, star_client.bat. For unix/linux you can manually kill the QueMgr process.
Now that the AM config files are created and the QueMgr started and all RmtMgrs started the actual client program (TxtMgr) can be run.
For submitting, monitoring and aborting jobs the client AM program TxtMgr is used. All the TxtMgr arguments are:
Note: Unix /Linux Do not ever kill –9 the QueMgr or RmtMgr daemon processes unless there is no other way to get them to stop. A kill command with no signal number should be used as this is received by the QueMgr and RmtMgr processes and allows them to do clean up of any open sockets, shared memory segments and to properly close the ports they are using cleanly, so these port numbers can be used again immediately.
Argument Description
-qmgrhost < > - set to QueMgr hostname -qmgrport < > - set to QueMgr port number -rmgrport < > - set to RmtMgr port number -timeout < > - set to change default timeout -org < > - set to QueMgr org
-ans <y|n> - set to change default batch submit answer (yes) -orgpath < > - set to change default orgpath
-auth < > - set to license file -app < > - set to application name
-rcf < > - set to runtime-configuration file
-jobnum < > - set to job number (for use with -wait or -choice) -amhome < > - set to change default am home path
-choice < > - set to menu number selection for batch mode -[no]wait - do [not] wait for batch job to complete
-ipaddr < > - specific IP address (1.2.3.4 format) if this machine is multi-homed -project < > - set to change default project
-port_start - starting port number in range -listapps - list all installed applications by name -env - print out the configuration
-envall - print out the complete configuration -envf < > - print out the configuration to a file
TxtMgr also needs to know the <am-install-path> at startup. This is determined several different ways, if the AM_HOME env var is set, it is used. On Windows, the Registry may contain a software key, and lastly, if none of these, then the AM installation directory determined from the full-path line. You can also manually override any prior AM_HOME setting with the –amhome < > command-line option.
An example of a typical submit cmd would be:
TxtMgr [–app <app-name>] –submit ++ <cmd-to-run> [-+- <any addl args>]
You can specify a specific queue to submit to with the –queue
<queue-name> option. Queues are configured in the msc.cfg file (see above)
An example of a typical monitor cmd would be:
TxtMgr –choice 3 or
TxtMgr –status –jobnum <job-id>
An example of aborting a job would be:
TxtMgr –choice 2 –jobnum <job-id>
You can also use the TxtMgr interactively without supplying any arguments, in which case you use the menu options. The menu options are:
-envfall < > - print out the complete configuration to a file -useenv - export the local env on the run host
-nocon - do not connect to QueMgr on startup
-lst < > - list-file of needed files to copy (generic apps only) -version - print the am version
-sepuser < > - set to change user who runs job
-submit - submit job with -nowait option (same as -choice 1 -nowait) -mem - memory setting (default units)
-nproc - number of cpus to allocate for submit
-status - print queue/running/completed job stats for job specified (-jobnum req)
-queue | -amhost - am queue name to use for submit -input < > - input file/cmd to submit
-extra < > - optional extra arg(s) to append to cmd
[file | args] - optional input file or extra args to submit (last arg(s))
Enter selection:
1. submit a job 2. abort a job 3. monitor a job
4. show QueMgr log file 5. show QueMgr jobs/queues 11. submit series of jobs 12. quit
There is also an rcf file capable of changing the default values for many AM settings. You can view all these settings with the command:
TxtMgr –env
You can run TxtMgr with the –rcf <rcf-file> cmd-line option or place a system-wide rcf file named “<am-install-path>/default/amgrrc” which would be read automatically at startup.
For example changing the default user for all submitted jobs could be done with this line in the system-wide rcf file:
unv_config.separate_user = <new-submit-username>
If this file were named “<am-install-path>/default/amgrrc” then all jobs would attempt to be run as this <new-submit-username> instead of the current user.
AM will attempt to become the submitting user when running jobs on remote machines. How it does this is complicated with many different possibilities depending on what user the RmtMgr is running as, the access rights assigned to the RmtMgr user, the submit host and execute host platforms and if there is a AM usr db file present with a username match or fallback user. On Windows, access to network shares by the client process that runs the job on a remote host can also be an issue. The most effective means to Note: Whenever an explicit separate user is specified, either on the TxtMgr cmd-line or in
a AM rcf file with the “unv_config.separate_user” method, the separate user listed must already be in the
<am-install-path>/default/conf/sepusers.cfg file. See above for more info.
ensure RmtMgr has the best chance to run as the correct user on Windows is to either run RmtMgr as a domain user with the following access rights:
• Act as a part of the operating system
• Bypass traverse checking
• Log on as a batch job
• Log on as a service
• Increase quotas
• Replace a process level token
Or run RmtMgr as LocalSystem (the default at install time) as this account has all these access rights by default. It’s also important to have a AM usr db file present with the submitting username (or fallback user) information in it when executing job on remote machines. addamuser is a menu based interactive AM program with these options:
Or run RmtMgr as LocalSystem (the default at install time) as this account has all these access rights by default. It’s also important to have a AM usr db file present with the submitting username (or fallback user) information in it when executing job on remote machines. addamuser is a menu based interactive AM program with these options: