WAS v8.0 > Install the application serving environment > Distributed operating systems > Configure the product after installation > Manage profiles on non-z/OS operating systems


Profile concepts

A profile defines the runtime environment. The profile includes all the files that the server processes in the runtime environment and that you can change.

We can create a runtime environment either through manageprofiles.sh or the Profile Management Tool graphical user interface. We can use the Profile Management Tool to enter most of the parameters described in this topic. Some parameters, however, require you to use manageprofiles.sh. We must use manageprofiles.sh to delete a profile, for instance, because the Profile Management Tool does not provide a deletion function. We can use either the Profile Management Tool or manageprofiles.sh to create a cell profile. The Profile Management Tool creates the cell in a single step, whereas manageprofiles.sh requires two separate invocations.


Core product files

The core product files are the shared product binary files, which are shared by all profiles.

The directory structure for the product has the following two major divisions of files in the installation root directory for the product:

When you want binary files at different service levels, use a separate installation of the product for each service level.

The configuration for every defined application server process is within the profiles directory unless you specify a new directory when you create a profile. These files change as often as you create a new profile, reconfigure an existing profile, or delete a profile.

Each of the folders except for the profiles directory and a few others such as the logs directory and the properties directory do not change, unless you install service fixes. The profiles directory, however, changes each time you add, change, or delete a profile. The profiles directory is the default repository for profiles. However, you can put a profile anywhere on the machine or system, provided enough disk space is available.

If you create a profile in another existing folder in the installation root directory, then a risk exists that the profile might be affected by the installation of a service fix that applies maintenance to the folder. Use a directory outside of the installation root directory when using a directory other than the profiles directory for creating profiles.


Why and when to create a profile

The manageprofiles command-line tool defines each profile for the product.

Run the Profile Management Tool or manageprofiles.sh each time to create a profile. A need for more than one profile on a machine is common.

Administration is greatly enhanced when using profiles instead of multiple product installations. Not only is disk space saved, but updating the product is simplified when you maintain a single set of product core files. Also, creating new profiles is more efficient and less prone to error than full product installations, allowing a developer to create separate profiles of the product for development and testing.

We can run the Profile Management Tool or the command-line tool to create a new profile on the same machine as an existing profile. Define unique characteristics, such as profile name and node name, for the new profile. Each profile shares all runtime scripts, libraries, the Java SE Runtime Environment 6 (JRE 6) environment, and other core product files.


Profile types

Templates for each profile are located in...

WAS_HOME/profileTemplates

Multiple directories exist within this directory, which correspond to different profile types and vary with the type of product that is installed. The directories are the paths that you indicate while using manageprofiles.sh with the -templatePath option. We can also specify profile templates that exist outside the profileTemplates directory, if we have any.

See the -templatePath parameter description in manageprofiles.sh topic for more information.

The manageprofiles command in the WAS ND can create the following types of profiles:

Management profile with a dmgr server

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

We can create the management profile with a dmgr server using the Profile Management Tool or manageprofiles.sh. If you create the profile with manageprofiles.sh, specify WAS_HOME/profileTemplates/management for the -templatePath parameter and DEPLOYMENT_MANAGER for the -serverType parameter.

Management profile with an admin agent server

The basic function of the administrative agent is to provide a single interface to administer multiple unfederated application servers.

We can create the profile using the Profile Management Tool or manageprofiles.sh. If you create the profile with manageprofiles.sh, specify WAS_HOME/profileTemplates/management for the -templatePath parameter and ADMIN_AGENT for the -serverType parameter to create this type of management profile.

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 Profile Management Tool or manageprofiles.sh. If you create the profile with manageprofiles.sh, specify WAS_HOME/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 application server to make applications available to the Internet or to an intranet.

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

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

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

We can create the profile using the Profile Management Tool or manageprofiles.sh. If you create the profile with manageprofiles.sh, specify WAS_HOME/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 dmgr and a federated node in one iteration through the Profile Management Tool. The result is a fully functional cell on a given system.

To create a cell profile using manageprofiles.sh, create two portions of the profile: the cell dmgr portion and the cell node portion. Additionally, you can have only one cell dmgr and one cell node associated with each other when you create a cell. The initial cell profile that you create with manageprofiles.sh is equivalent to the cell profile you create with the Profile Management Tool. After you create the initial cell profile, you can create custom profiles or standalone profiles and federate the profiles into the dmgr.

On manageprofiles.sh, specify WAS_HOME/profileTemplates/cell/dmgr for the -templatePath parameter for the dmgr and WAS_HOME/profileTemplates/cell/default for the -templatePath parameter for the cell node.

After creation of the two portions that make up the cell profile, we have a dmgr and federated node. The federated node contains an application server 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 application server node into a managed node when you add an application server 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 application server processes on the managed node. The node agent can start or stop application servers, for example.

A dmgr can create multiple application servers 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 administrative 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 administrative 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, you can use the administrative interface of the dmgr to customize the managed node by creating clusters and application servers.

We can create the profile using the Profile Management Tool or manageprofiles.sh. If you create the profile with manageprofiles.sh, specify WAS_HOME/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 application servers. The secure proxy server resides in the DMZ.


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. We can 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 you specify the -profileName parameter if the profile is not the default profile. In those cases, it might be easier to use the commands that are 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 application server profiles

In environments where you plan to have multiple standalone application servers, the security policy of each application server profile is independent of the others. Changes to the security policy in one application server 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 Profile Management Tool 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 you do not relocate them: 

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01
/opt/IBM/WebSphere/AppServer/profiles/AppSrv02
We can specify a different directory, such as /opt/profiles for the profile directory using manageprofiles.sh. 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. This example assumes that the profile, AppSrv01, exists:


Related


Profiles: File-system requirements

+

Search Tips   |   Advanced Search