This release introduces an optional administrative model that enables you to implement a more flexible, scalable, and asynchronous administrative topology. This new loosely-coupled model, called "flexible management", is built around autonomous nodes that maintain local control over their configuration. Servers on a node are locally managed by an "administrative agent" that can host the administrative logic for all servers on a node, reducing their footprint. A central "job manager" process provides a single interface from which you can asynchronously submit administrative tasks to a node or group of nodes. Because it does not rely on tightly-coupled, synchronous communication, flexible management can be advantageous in situations that push the limits of the cell model, including environments with very large numbers of nodes, or topologies that include high-latency, long-distance links. Keep in mind that this new model is an option, and the cell model is still available. Many environments will still find the cell model to be the most appropriate, since it provides many services, like high-availability, that applications might require.
Two new Java processes, the administrative agent, and the job manager work together to enable the "flexible management" administrative topology. The administrative agent is responsible for the administrative logic for all servers on a node. By consolidating the management logic for all servers on the node, administrative overhead is reduced, and there is a single point of administration. After a profile has been registered with an administrative agent, the administrative console runs on the administrative agent, and not the application server. An administrative agent can only manage local servers. Multiple nodes can be administered remotely using a job manager. The job manager provides its own console, and enables you to send management jobs to registered servers through the administrative agent. Note that individual nodes retain their autonomy, and can still be managed locally, even when registered with a job manager. A job manager can also send commands to a deployment manager, providing a way to administer multiple Network Deployment cells from a single interface. The administrative agent is available as a part of all WebSphere Application Server packages, while the job manager is only available with the Network Deployment offering.
The job manager communicates with either administrative agents or deployment managers. The flexible management components enable some scenarios, like very large server farms, or a single administrative interface for separate data centers, that are not easy to manage with the traditional cell model.
A job manager is a component that provides management capabilities for multiple standalone application servers, administrative agents, and deployment managers. It brings enhanced multiple node installation options for your environment.
It is possible to encounter a senario where there might be multiple distributed environments, each managed by their own deployment manager. With multiple deployment managers, they must be administered individually and there is no way of coordinating management actions between the different distributed environments. Distributed environment administration performance is affected by low latency networks because file synchronization between the deployment manager and node agent are dependent on network communication.
The job manager can be used to administer multiple distributed environments as well as standalone servers. The job manager administers the environment asynchronously using the concept of jobs. Because jobs are submitted asynchronously, a low latency network is sufficient, which can be useful when the environment is distributed over distant geographical areas.
The job manager is available only with WebSphere Application Server Network Deployment and WebSphere Application Server for z/OS.
To administer a distributed environment, the deployment manager is registered with the job manager. To administer standalone servers, the nodes managed by the administrative agent are registered with the job manager. This relation between the job manager and the environments it can interact with is shown below:
The job manager administers the registered environments by submitting jobs that perform tasks, for example:
Start and stop servers
Create and delete servers
Install and uninstall applications
Start and stop applications
The job manager has a repository for its own configuration files, which are related to security, administration of job manager, configurations, and so on, however, it does not maintain a master repository the way a deployment manager does. Rather, the job manager allows the administrative agents and deployment managers to continue managing their environment as they would have had they not been registered with the job manager. The job manager simply provides another point of administration.
The job manager can administer multiple administrative agents and deployment managers. Conversely, each administrative agent and deployment manager can be registered with multiple job managers.
Flexible management is a concept introduced with WebSphere Application Server V7.0. With flexible management components like the administrative agent and the job manager, you can build advanced and large-scale topologies and manage single and multiple application server environments from a single point of control. This reduces management and maintenance complexity.
Administrative agent profile
The administrative agent is a new profile that provides enhanced management capabilities for stand-alone application servers. This is a new concept introduced with WebSphere Application Server V7.0.
An administrative agent profile is created on the same node as the standalone servers and can manage only servers on that node. The node configuration for each standalone server is totally separate from any other servers on the system, but it can be managed using the administrative console on the administrative agent.
To participate in flexible management, standalone base servers first register themselves with the administrative agent. When a base application server registers with an administrative agent, much of the administrative code that was in the base server is consumed by the administrative agent. This results in a significantly smaller and faster starting base server:
Unlike a node in a WebSphere Application Server Network Deployment cell, the configuration repository of a WebSphere Application Server base profile that is registered with an admin agent is not federated into a master repository. The administration services in the admin agent modify the configuration of the various registered base profiles directly. This also means the admin agent can only manage WebSphere Application Server base profiles running on the same machine:
Job manager profile
The job manager is a new server type that was added to support flexible management. A job manager is defined by a job manager profile.
To participate in flexible management, a standalone application server first registers itself with the administrative agent. The administrative agent must then register the node for the application server with the job manager. If a deployment manager wants to participate in an environment controlled by a job manager, the deployment manager registers directly with the job manager; no administrative agent is involved in this case:
The main use of the job manager is to queue jobs to application servers in a flexible management environment. These queued jobs are pulled from the job manager by the administrative agent and distributed to the appropriate application server or servers.
Both deployment manager and administrative agents retain autonomy and can be managed without the job manager.
The units of work that are handled by the flexible management environment are known as jobs. The semantics of these jobs are typically straightforward, and the jobs require few parameters. The jobs are processed asynchronously and can have an activation time, expiration time, and a recurrence indicator. You can specify that an e-mail notification be sent upon completion of a job. Additionally, you can view the current status of a job by issuing a status command.
In a deployment manager environment, there is a tight coupling between application servers and node agents and also between node agents and the deployment manager. This tight coupling can impact the scalability of the administrative run time if the runtime components are not located together in close proximity using redundant, high capacity, low latency networks.
The job manager addresses the limitations inherent in the current management architecture by adopting a loosely coupled management architecture. Rather than synchronously controlling a number of remote endpoints (node agents), the job manager coordinates management across a group of endpoints by providing an asynchronous job management capability across a number of nodes.
The advanced management model relies on the submission of management jobs to these remote endpoints, which can be either a WebSphere Application Server administrative agent or a deployment manager. In turn, the administrative agent or the deployment manager executes the jobs that update the configuration, starts or stops applications, and performs a variety of other common administrative tasks.
To create a job manager and coordinate administrative actions among multiple deployment managers and administer multiple unfederated application servers, you need to create a management profile during the profile creation phase of the installation.
The job manager can manage nodes that span multiple systems and platforms. A node managed by one job manager also can be managed by multiple job managers.
Note: The job manager is not a replacement for a deployment manager. It is an option for remotely managing a Network Deployment deployment manager or, more likely, multiple deployment managers, removing the cell boundaries.