A job manager environment consists of a job manager and the targets that it manages. The
job manager targets can be deployment managers, stand-alone application server nodes that are
managed by administrative agents, and host computers. Setting up a job manager environment involves
creating a job manager profile and any other profiles that are needed for the environment,
synchronizing the clocks on all environment computers, and then registering the targets with the job
manager.
About this task
Before you use the job manager, you must create a job manager profile and a profile for each
target node that you want managed by the job manager.
Job managers are part of the flexible management environment. Job managers can manage stand-alone
application server nodes that are registered to an administrative agent. Those nodes and
administrative agents are also part of the flexible management environment.
Ensure that the profiles in the flexible management environment either all have security enabled
or all have security disabled. Depending on your environment, you might need profiles for
administrative agents, the nodes registered to the administrative agents, deployment managers, and
the nodes federated with the deployment manager.
Job managers can manage Version 8 and Version 7 target nodes. A job manager can manage a node at
an equal or lesser version number than the job manager. For example, a Version 8 job manager can
manage Version 8 and 7 nodes. A Version 7 job manager can manage Version 7 nodes. The fix pack
portion of the version number does not matter; for example, a Version 7.0.0.3 job manager can manage
a node at Version 7.0.0.9, which is Version 7 with fix pack 9 installed.
Further, a job manager can manage a Version 8 or Version 7 deployment manager that has a Version
8, Version 7, or Version 6 federated node. A deployment manager that is registered with a job
manager can manage a mixed version cell. Using the job manager, you can submit jobs that manage any
resources in the mixed version cell, including resources on a Version 6 federated node.
- Determine the topology for your flexible management environment. Flexible management
encompasses administrative agents and job managers.
Determine which machines, targets, and target resources such as servers and applications to be in
the flexible management environment.
To manage stand-alone application servers, use an administrative agent on each computer where the
stand-alone application servers reside. For more information, see topics on the administrative agent
and Scenarios 5 in the Planning to install WebSphere Application Server
topic.
To collectively manage deployment managers and stand-alone application servers on the same or
different computers, use a job manager. The stand-alone application servers must be registered with
an administrative agent before you can manage them using a job manager. For more information, see
Scenarios 5 and 10 in the Planning to install WebSphere Application Server
topic.
- Determine the security roles needed for your flexible management environment.
Depending on your environment, you might need profiles for administrative agents, the nodes
registered to the administrative agents, deployment managers, the nodes federated with the
deployment manager, and job managers. Profiles in the flexible management environment must either
all have security enabled or all have security disabled. When you create the profiles, you can
specify security options, user names, and passwords.
You must have security roles that authorize you to work with a job manager and to manage
registered targets and resources on those targets. If the environment includes stand-alone
application server target nodes, then you must be authorized to work with an administrative agent
and its nodes.
For more information, see the job manager security topic.
- Create a management profile for the job manager.
You can use the Profile Management Tool or the manageprofiles command.
For example, in the Profile Management Tool, select the Management
environment and click Next, select the Job manager
server type, and select options that create the profile. By default, a job manager has its own
administrative console, administrative security is enabled, and the console port is 9960. To disable
administrative security, to specify a security certificate, or to change the default ports, use the
advanced profile creation option when creating the job manager profile.
By default, the first administrative agent profile in a product installation is named
JobMgr01 and its server name is jobmgr.
For more information, see the topic on creating management profiles for job managers.
For manageprofiles examples, see the topic on the manageprofiles command. For
-templatePath, specify the management template. For
-serverType, specify JOB_MANAGER.
Note: The job manager configuration includes a datasource named OTiSDataSource.
This datasource is used in the implementation of the job manager, and does not need to be configured
or otherwise managed by the administrator.
- Create profiles for any administrative agents and stand-alone application server nodes that you
intend to have in your flexible management environment. Then, register the stand-alone application
server nodes with the administrative agent.
Stand-alone nodes are also called unfederated or base application servers. They are not managed
by a deployment manager. Stand-alone application servers typically have a profile name such as
AppSvr01. An administrative agent must be on the same computer as its stand-alone nodes. Registering
the stand-alone nodes with the administrative agent enables the administrative agent to manage the
nodes.
Avoid trouble: You must register stand-alone application servers with an administrative
agent before you can register the stand-alone application servers with the job manager.
gotcha
For details on creating the profiles and registering with an administrative agent, see the topic
on setting up the administrative agent environment.
- Create profiles for any deployment managers and federated nodes that you intend to have in your
flexible management environment.
Federated nodes are managed by a deployment manager. Federated application servers typically have
a profile name such as AppSvr01, however you cannot administer them individually. You must
administer federated nodes using the deployment manager.
See topics on creating cell profiles, management profiles for deployment managers, or the
manageprofiles command.
- Synchronize the clocks on all involved systems.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
If you plan to
change the system clock, stop all the application servers, the node agent servers, the deployment
manager server, the administrative agent server, and the job manager server first. After you stop
the servers, change the system clock, and then restart the servers. If you change the system clock
on one system, you must ensure the clocks on all systems that communicate with each other and have
WebSphere
Application Server installed are synchronized. Otherwise, you might experience errors, such as
security tokens no longer being valid.
If
you plan to change the system clock, stop all the application servers, the node agent servers, the
deployment manager server, the administrative agent server, the job manager server, and the location
service daemon first. After you stop the servers and location service daemon, change the system
clock, and then restart the servers and location service daemon. If you change the system clock on
one system, you must ensure the clocks on all systems that communicate with each other and have WebSphere
Application Server installed are synchronized. Otherwise, you might experience errors, such as
security tokens no longer being valid.
- Start the job manager server.
- Run the startServer command.
For example, suppose the JobMgr01 profile has
the server name jobmgr. Run the following command from the bin
directory of the JobMgr01
profile:
startServer jobmgr
Use the Windows operating system
Taskbar. Click .
Use the START command to start the job
manager:START job_manager_proc_name,JOBNAME=server_short_name,
ENV=cell_short_name.node_short_name.server_short_name
If the job manager starts successfully, the message open for e-business displays
and is written to the job manager startServer.log file:
Server launched. Waiting for initialization status.
Server jobmgr open for e-business; process id is 1932.
For more information, see the topic on starting and stopping the job manager.
- Register stand-alone application server target
nodes with a job manager.
Registering stand-alone nodes with a job manager enables the job manager to administer
stand-alone application server nodes.
- Register deployment managers with the job
manager.
Registering a deployment manager with a job manager enables you to run job manager jobs from a
deployment manager console and enables the job manager to administer federated nodes of the
deployment manager and their resources.
- Register host computers with the job
manager.
A remote host target is not required to have any WebSphere Application Server products installed. There are no software
requirements for this host beyond its operating system. Registering a remote host with a job manager
enables the job manager to access applications, command files, and other resources on the host
computer.
To register Liberty with a job manager, use a
procedure for registering a target with a host.
- Verify that the targets are registered with the job manager.
You can use an administrative console or wsadmin scripting commands to see a list of targets that
are registered with the job manager.
- Ensure that the servers in your flexible management environment are running.
In the job manager console or deployment manager console, click . On the Target resource page, a server status of
Started shows that the server is running.
- Optional: Disable the com.ibm.otis.Audit_mm_dd_yyyy.log log file by specifying the
JVM property otis.audit.location with a value of OFF. or move the log file to a new
directory location. Job manager maintains an additional log which is in the profile logs directory by default. The
purpose of the log is to record job manager internal activity.
The name of the log file is
com.ibm.otis.Audit_mm_dd_yyyy.log, where mm,
dd and yyyy are month, date and year respectively. A new file
is created for each day if activity occurs that can be logged.
This log file can be moved to
another directory by specifying the JVM property otis.audit.location with a value
of the new directory location.
What to do next
Submit jobs using the job manager.