Profile concepts


 

+

Search Tips   |   Advanced Search

 

Profiles define the runtime environment and can be created using...

Use manageprofiles to delete a profile.

The PMT creates cell profiles in one step. The manageprofiles command requires two separate invocations.

 

Core product files

The core product files are the shared product binaries, and are shared by all profiles. Core product files do not change unless you install a refresh pack, a fix pack, or an interim fix.

Default installation locations...

APP_ROOT/profiles is the default directory for creating profiles.

When you want binaries at different service levels, use a separate installation of WAS for each service level.

Appserver configs are defined under $APP_ROOT/profiles unless otherwise specified. We can put a profile anywhere on the machine or system, provided enough disk space is available.

Do not create a profile in the installation root directory, as a risk exists that the profile might be affected by the installation of a service fix that applies maintenance to the folder.

We can run PMT or manageprofiles to create a new profile on the same machine as an existing profile if we define unique characteristics, such as profile name and node name. Each profile shares...

 

Profile types

Templates for each profile type are available...

$ cd APP_ROOT/profileTemplates
$ ls -CF
cell/ default/ dmgr/ managed/ management/ secureproxy/

The directories can be used as values for -templatePath

Types of profiles...

Management profile with a deployment manager server

The basic function of the dmgr is to deploy applications to a cell of appservers, which it manages. Each application server that belongs to the cell is a managed node.

If we create the profile with manageprofiles, specify...

APP_ROOT/profileTemplates/management

...-templatePath parameter and...

DEPLOYMENT_MANAGER

...for the -serverType parameter.

Management profile with an administrative agent server

Provides a single interface to administer multiple unfederated appservers.

For -templatePath use...

APP_ROOT/profileTemplates/management

For -serverType...

ADMIN_AGENT

Management profile with a job manager server

The basic function of the job manager is to provide a single console to administer multiple base servers, multiple dmgrs, and do asynchronous job submission.

We can create the profile using the PMT or manageprofiles.

If we create the profile with manageprofiles, specify...

APP_ROOT/profileTemplates/management

...for the -templatePath parameter and JOB_MANAGER for the -serverType parameter to create this type of management profile.

Application server profile

Use the appserver to make applications available to the Internet or to an intranet.

An important product feature is the ability to scale up a standalone appserver profile by adding the appserver node into a dmgr cell. Multiple appserver processes in a cell can deploy an application that is in demand. We can also remove an appserver node from a cell to return the node to the status of a standalone application server.

Each standalone appserver can optionally have its own admin console application, which you use to manage the appserver. We can also use the wsadmin scripting facility to perform every function that is available in the admin console application.

No node agent process is available for a standalone appserver node unless you decide to add the appserver node to a dmgr cell. Adding the application server node to a cell is known as federation. Federation changes the standalone appserver node into a managed node. You use the admin console of the dmgr to manage the node. If we remove the node from the dmgr cell, then use the admin console and the scripting interface of the standalone appserver node to manage the process.

You can create the profile using the PMT or manageprofiles. If we create the profile with manageprofiles, specify...

APP_ROOT/profileTemplates/default

...for the -templatePath parameter to create this type of profile.

Cell profile

Use the cell profile to make applications available to the Internet or to an intranet under the management of the dmgr.

Creation of a cell profile generates a deployment manager and a federated node in one iteration through the PMT. The result is a fully functional cell on a given system.

To create a cell profile using manageprofiles command, create two portions of the profile: the cell dmgr portion and the cell node portion. Additionally, we can have only one cell dmgr and one cell node associated with each other when creating a cell. The initial cell profile created with manageprofiles is equivalent to the cell profile you create with the PMT. After you create the initial cell profile, we can create custom profiles or standalone profiles and federate the profiles into the deployment manager.

On manageprofiles, specify...

APP_ROOT/profileTemplates/cell/dmgr

...for the -templatePath parameter for the dmgr and...

APP_ROOT/profileTemplates/cell/default

...for the -templatePath parameter for the cell node.

After you create the two portions that make up the cell profile, we have a dmgr and federated node. The federated node contains an appserver and the default application, which contains the snoop servlet, the HitCount application, and the HelloHTML servlet.

Custom profile

Use the custom profile which belongs to a dmgr cell, to make applications available to the Internet or to an intranet under the management of the dmgr.

The dmgr converts a custom profile to a managed node by adding the node into the cell. The dmgr also converts an appserver node into a managed node when you add an appserver node into a cell. When either node is added to a cell, the node becomes a managed node. The node agent process is then instantiated on the managed node.

The node agent acts on behalf of the dmgr to control appserver processes on the managed node. The node agent can start or stop appservers, for example.

A deployment manager can create multiple appservers on a managed node so long as the node agent process is running. Processes on the managed node can include cluster members that the dmgr uses to balance the workload for heavily used applications.

Use the admin console of the dmgr to control all of the nodes that the dmgr manages. We can also use the wsadmin scripting facility of the dmgr to control any of the managed nodes. A custom profile does not have its own admin console or scripting interface. We cannot manage the node directly with the wsadmin scripting facility.

A custom profile does not include default applications or a default server like the application server profile includes. A custom profile is an empty node. Add the node to the dmgr cell. Then, we can use the administrative interface of the dmgr to customize the managed node by creating clusters and appservers.

We can create the profile using the PMT or manageprofiles. If we create the profile with manageprofiles, specify...

APP_ROOT/profileTemplates/managed

...for the -templatePath parameter to create this type of profile.

Secure proxy profile

Use the secure proxy server to take requests from the Internet and forward them to appservers. The secure proxy server resides in the DMZ.

We can create the profile using the PMT or manageprofiles. If we create the profile with manageprofiles, specify...

APP_ROOT/profileTemplates/secureproxy

...for the -templatePath parameter to create this type of profile.

 

Default profiles

Profiles use the concept of a default profile when more than one profile exists. The default profile is set to be the default target for scripts that do not specify a profile. Use the -profileName parameter with most of the scripts to enable the scripts to act on a profile other than the default profile.

The default profile name is <profile_type><profile_number>:

Addressing a profile in a multiprofile environment: When multiple profiles exist on a machine, certain commands require that specify the -profileName parameter if the profile is not the default profile. In those cases, it might be easier to use the commands in the bin directory of each profile. When you issue one of these commands within the bin directory of a profile, the command acts on that profile unless the -profileName parameter specifies a different profile.

 

Security policy for appserver profiles

In environments where you plan to have multiple standalone appservers, the security policy of each application server profile is independent of the others. Changes to the security policy in one appserver profile are not synchronized with the other profiles.

 

Installed file set

You decide where to install the files that define a profile. The default location is in the profiles directory in the installation root directory. We can change the location on the PMT or in a parameter when using the command line tool. For example, assume that you create two profiles on a Linux platform with host name devhost1. The profile directories resemble the following example if we do not relocate them:

/IBM/WAS/AppServer/profiles/AppSrv01 /IBM/WAS/AppServer/profiles/AppSrv02

We can specify a different directory, such as /opt/profiles for the profile directory using manageprofiles command. For example:

manageprofiles.sh -profileName AppSrv01 -profilePath /opt/profiles

manageprofiles.sh -profileName AppSrv02 -profilePath /opt/profiles

Then the profile directories resemble the directories shown in the following example:

/opt/profiles/AppSrv01
/opt/profiles/AppSrv02

The following directories exist within a typical profile...




Subtopics


Profiles: File-system requirements