Simplifying WebSphere application Server management with Profiles _websphere

Http://www.ibm.com/developerworks/cn/websphere/techjournal/0505_wang/0505_wang.html

What is a profile.

WebSphere application Server V6 introduces the concept of a profile to physically separate product binaries (binaries) from user data and enables users to define multiple sets of user data.

Prior to the 6th edition of WebSphere Application server, product binaries and user data are located in the WebSphere installation directory: The end-user process can read the WebSphere Application Server product binaries , but it cannot be modified.
Binaries can be modified only through product maintenance updates (such as fix packages and ifixes) and other installers that extend the WebSphere platform product (also considered to be a type of product maintenance). End users have user data and can write to it.
Typically, user data includes configuration files, deployed applications, log files, and temporary workspaces, but is not limited to these.

Before, product installers often place product binaries and WebSphere default configurations under the installation directory, and users customize configuration and deploy applications through various system management tools provided by the product. In other words, the previous product binaries and user data are mixed together, and only one set of user data can be defined through a specific WebSphere installation.

On the other hand, the profile can obtain a set of user data on disk and the associated Run-time execution Environment: the WebSphere application Server V6 profile consists of the set of files that are owned by the end user, and the end user can write to the set of files. And the process is executed as an end user.

On UNIX® and linux® Systems, the group and owner permissions for all files and directories in the profile that are created are the same as the users who execute the utility to create the profile. You can think of the WebSphere profile as a "user data partition," equivalent to the home directory of the user in the Unix/linux operating system environment.

The WebSphere application Server V6 Product installer places the files created in two separate environments: one for installing the product binaries and the other for creating the initial profile. The location where the initial profile is created is separate from the installation location of the product binaries and can be configured by the end user. Users can also create additional profiles after the installation is complete. All profiles created through the WebSphere application Server installation share the same product binaries, and these product binaries cannot be modified.

V6 profile and V5 instance connection

If you have used the Wsinstance utility before, you will be somewhat familiar with the concept of the profile. The Wsinstance utility, introduced in the WebSphere application Server V5.1, allows users to create multiple configuration instances of a product installation. A profile is an extension, enhancement, and substitution of this feature.

Although it may seem similar, there are a number of important differences between the two functions: version 6 does not support the initial default configuration and the product binaries directory mix. All operating environments for WebSphere application Server V6 are described by a profile, and the same logic is created for creating the initial profile and then creating all the profiles afterwards. In version 5, the initial product installation generates several directories: the config directory, the logs and Tranlog directories, the TEMP and wstemp directories directly under the installation root, which is the initial user area and is a sibling of the Lib, Java, Bin, and classes directories Recorded. While this is logical, this structure can be difficult for users when they create a read-only file system that holds system files, while maintaining the ability to read and write these files for both configuration and production runtimes. Version 6 explicitly separates the product binaries from all the user data instances and encapsulates them in one or more profiles. The profile feature also provides a profile management tool that integrates with all other system management tools to make it more mature and sophisticated than the Wsinstance utility.

Create your first profile

Create your first profile after installation
If you did not create your first profile when the product was installed, you can use the PCT tool to create it after the product is installed. The tool is an executable file named Pct<platform> located in the <was_install_directory>/bin/profilecreator directory; For example, the executable file on the windows® platform will be called Pctwindows.exe. You can also use it to create multiple profiles.

As mentioned above, the WebSphere application Server installer places all product binaries under the user-specified installation directory. Setup invokes the GUI profile creation tool (PCT) to create an initial profile. The PCT Wizard will help you create the initial profile.

Figure 1 is a screenshot of the PCT tool. The figure shows the name of the profile, the directory in which the profile resides, the node name, the host name, and other relevant information. The tool also provides a set of default ports for profiles that can be modified if necessary, and the default ports cannot be assigned to profiles that are already in use by WebSphere application Server on the same server to avoid conflicts with any other ports. The tool also does not provide the ports used by services other than WebSphere application Server. Figure 1. Profile Creation Tool

By default, the profile created is located under the <WAS_INSTALL_DIRECTORY>/profiles/<PROFILE_NAME> directory, and you can customize the location of the profile at the PCT prompt. Profiles can be located anywhere in the file system, as long as the end user has sufficient permissions to create directories and files in that location.

If you are using WebSphere application Server Network Deployment (ND), you will also receive a prompt to select one of the three predefined profile types. Two of these types are available only for ND environments. (We will later describe how to use these three types of profile type to establish a ND environment). Profile type definition Application Server for WebSphere Application server, WebSphere application server--express, and WebSphere application The server network deployment defines a stand-alone application server environment. The profile contains the default application server definition. The deployment Manager defines the deployment manager environment. This profile type contains the default manager definition and is available only for WebSphere application Server ND. The customization defines an empty management node that does not contain an application definition. When you create a profile, the profile creation tool gives you an option to automatically connect the custom profiles that you have created to the Deployment Manager as the management node, so that users can add resources and custom server definitions to the node.
Using the WebSphere profile

To use the profile created earlier, you need to invoke the command provided in the <profile_directory>/bin directory. The command in this directory is the same as the command name in the <was_install_directory>/bin directory. If you have previously used a WebSphere application Server V5 product, you are not unfamiliar with these commands. You can use the commands in the <profile_directory>/bin directory in the way you used to in V5-the only difference is that these commands can only be used on this specified profile. For example, to start the application server defined by this profile on Windows, you can use the StartServer command:

<profile_directory>\bin\startserver.bat Server1

Similarly, if you want to stop using the server, you can use the Stopserver command:

<profile_directory>\bin\stopserver.bat Server1

(See the WebSphere Application Server Information Center for more details on these commands.)

After you start the server from the Admin console and install the application on that server, you may not yet know where the log files and installed applications are. To answer these questions, we can first examine the directory structure of the profile: in the profile directory you can see a list of subdirectories other than the bin subdirectory. The table details these subdirectories and their contents: subdirectory contents bin the group command can be used on the profile created. These commands are the same as the command names under the <was_install_directory>/bin directory, but they can only be used on this profile. Config is a set of configuration documents that are used by the WebSphere application Server process, which is executed with the help of this profile. If the profile is a Deployment Manager profile, it will contain the entire unit's configuration document. It may also contain the configuration of other profiles that are attached to the deployment Manager. Databases cloudscape® database. The ETC key files and certificates (including at least the initial key files and certificates bundled with the product). Installableapps can install the default location of the application. Installedapps installed and extended application binaries installedconnectors the installed JCA Resource Adapter Library. Logs all types of log files, such as SystemOut.log, Tranlog, FFDC, Activity.log, and so on. Properties a variety of property files that contain the same property files in V5, but these properties file only apply to the current profile. Temp Temporary working directory tranlog default transaction log directory. Wstemp Configure a modified temporary workspace. As in version 5, the configuration modifications on the profile are made in a temporary workspace before the user decides to save the configuration changes to the configuration repository. The directory will save temporary configuration modifications to the current profile before the modifications are saved.

These subdirectories will get the full contents of the profile instance. When an end user enables any command defined in the Profile Bin directory, the process that is enabled modifies only the user data for that profile, and does not change any product binaries or user data for other profile instances.
Setting up network deployment environment with profile

In WebSphere application Server V5, it takes several steps to establish a network deployment environment. For ease of comparison, the general steps are now described below: Set up the Deployment Manager, which will be completed during the installation of the WebSphere application Server ND product. Start the deployment Manager. Set up the node, which is done by installing the WebSphere application Server product on the same or different hosts. When the nodes are on the same host, the installation directory should be different from the installation directory of the deployment Manager because they are two different product installations. In other words, the Deployment Manager and the node cannot share the same product binaries, even if they differ slightly. Connect the node to the deployment Manager through the AddNode command. This step establishes the basic ND environment and makes the node part of the ND environment. After that, you can repeat steps 3 and steps 4来 add additional nodes, customize the configuration, and deploy the application to the network deployment environment.

In the WebSphere application Server V6, the basic steps for setting the ND environment are approximately the same, but support through the profile is more efficient and convenient. To establish a Deployment manager, you need to install WebSphere application Server ND before. Then: Enable the PCT tool described earlier. In the first step of the PCT Wizard, select the profile type. Select the Deployment Manager profile type, and the remaining steps follow the same steps as in V5. Note the port used by the Deployment Manager profile, because after that you will need the number of ports to add additional nodes to the deployment Manager. Now that you are creating a new profile, the content described in the previous section is applicable here. To enable the deployment Manager that you have created, go to the <dmgr_profile_directory>/bin subdirectory and execute the startmanager command. For example, on the Windows platform, you can perform

<dmgr_profile_directory>\bin\startmanager.bat

Command.

In version 5, WebSphere Application Server ND creates only the deployment manager, while the WebSphere Application Server Base or Express creates nodes. In version 6, ND can create deployment managers and application servers without the need for additional setup programs. In version 6, you can use the same product installation to create multiple instances of the same profile type (or different profile types). This allows you to share product binaries between the Deployment Manager node and other nodes. The most economical way to build a node, then, is to enable the PCT tool again, create the application server profile with the application server type, and then execute the addNode command to connect the new node to the Deployment Manager profile.

It is also important to note that you also need to invoke the AddNode command in the node profile bin directory, such as <node_profile_directory>\bin\addnode.bat. If you execute the commands in the <install_directory>/bin directory, the results may be unexpected. Next, we will specify how to properly invoke the AddNode command under the <install_directory>/bin directory when there are multiple profiles under the same installation directory.

If you do not want to share product binaries between nodes and deployment managers, or if you need to add nodes from another host, you can also create nodes in other product installations. You can do this by first installing WebSphere application Server ND, as described above for version 6.

Except that the custom profile type does not contain any server definitions, it is very similar to the Application Server profile type. Therefore, this profile type cannot be used independently and should be joined to the ND unit after it is created.
Make your profile the default profile

At this point, you can set up a single server and ND environment and have a better understanding of the profile. However, if in most cases you create a profile only under a specific installation directory, and you do not think of other directory-level invoke commands, you can use the default profile.

When you create a profile, you can mark it as the default profile under the installation directory, as shown in Figure 1. That is, when the <install_directory>/bin directory is lowered with commands, they are automatically executed on the default profile that you define. This makes it easier for you to invoke commands, which can be a great convenience. All user data for the profile is still stored in the profile directory.

However, when you have more than one profile in the same installation directory, this is not a good idea, even if you can still apply the default profile. Because there can be only one default profile for the entire product installation. If you mark another profile as the default file, the file will overwrite the initially marked profile and the original settings will be canceled. When multiple profiles coexist, tracking which file is the default profile can cause confusion.
Using multiple profiles

If you often switch back and forth between multiple profiles under the same product installation, you may be tired of changing your current working directory from the bin directory of one profile address to another. At this point, you can call the commands in the <installation_directory>/bin directory and explicitly specify the profile for the operation through the ProfileName option.

For example, if you want to start a MYPROFILE1 profile-defined server on a Windows platform, as well as a MYPROFILE2 profile-defined server, you can use the following command:

<installation_directory>\bin\startserver.bat server1-profilename myProfile1

<installation_directory >\bin\startserver.bat Server1-profilename MyProfile2

Manage Profiles

In addition to the GUI PCT Wizard, WebSphere application Server V6 provides command-line tools for profile management, called Wasprofile. Not only can you use the Wasprofile utility to create additional profiles, you can also manage multiple profiles under the installation of a product. This command is located in the <installation_directory>/bin directory, and you can find the complete command reference information in the WebSphere application Server Information Center. Also provides examples of commands that can be used in a variety of different modes and options. The Help options are also available on the command line, as shown in the following illustration:

. \wasprofile.bat-help the
available modes are:create, augment, delete, unaugment,
DeleteAll, Listprofiles, GetName, GetPath, Validateregistry, Validateandupdateregistry, help-for-detailed help on each
mode enter:-< Mode>-help.
for example,-create-help.
Command line arguments are case-sensitive.

The basic syntax for the Wasprofile command is:

. \wasprofile.bat-<mode>-<option> Value-<option> value

The first parameter is usually a pattern. The following parameters are schema-specific options and their values. These options are in no order, so you can specify them in any order. You can get the right options for a specific pattern and understand their syntax with the Help option, which applies to any pattern. For example, to get detailed options for the "create" mode, you can use:

. \wasprofile.bat-create-help

The patterns you may often need to use include: create--Create profiles, and feature and profile creation tools are the same. delete--deletes a specified profile. deleteall--deletes all profiles under the product installation. listprofiles--lists all the profiles. getname--Gets the profile file name when given the profile location. The getpath--feature and GetName, in contrast, get the location of the profile when given the profile file name.

If you are interested, there are other modes: WebSphere application Server uses the registry to keep track of all profiles under the product installation. If the execution of the Wasprofile command fails unexpectedly, the registry can sometimes terminate in an inconsistent state. This is rare, but if you are concerned that this is the case, you can use the Validateregistry mode to check when the profile registry is in a consistent state. If Validateregistry reports any inconsistencies, you can use the Validateandupdateregistry mode to resolve them. The patterns you won't use include augment and unaugment. These patterns are only used by other WebSphere products.

When the Wasprofile command is executed, the command places the log file in the <install_directory>/logs directory and typically names it xxx_<profile_name>.log. In the <profile_directory>/logs directory, you will also find additional log files.
Replication profile Configuration

The WebSphere application server V6 can replicate configurations between application server profiles. You can use this feature between two application server profiles in the same or different host environments, or under different product installations. In general, you can use this feature to replicate profile configurations between different platforms-as long as you do not add os-specific system properties to the configuration. The exception is that if the configuration of z/OS is incompatible with the distributed platform profile, you cannot replicate the configuration between these platforms. Another limitation is that the performance only takes effect on the application server profile and not for the ND profile.

To replicate the profile configuration, you need to: Perform the Exportwasprofile command in Wsadmin and export the application Server profile configuration to the configuration profile. For example, the command shown in the following illustration illustrates how to export the configuration of the current profile to the configuration profile C:\work\myProfile1.car:

Wsadmin> $AdminTask exportwasprofile {-archive C:\work\myProfile1.car}

Perform the Importwasprofile command in Wsadmin to import the profile file into another application server profile. If the target profile does not exist, it needs to be created first. To execute the importwasprofile command, first start the wsadmin on the target profile. For example, if you want to import configuration to profile MyProfile2, first use the

<install_directory>\bin\wsadmin.bat-profilename MyProfile2

command to start Wsadmin. After you start Wsadmin, execute the importwasprofile command to import the configuration. For example, you can use the JACL command:

Wsadmin> $AdminTask importwasprofile {-archive C:\work\myProfile1.car}

To import the previously exported configuration profile.

The Importwasprofile command can replicate all configuration of the source profile. These configurations include server configuration and applications deployed on the server. Instead of merging the configuration in the profile with the target profile, the command replaces the entire configuration of the target profile. It only describes information related to an existing target profile, such as the installation directory, host name, server name, and port. This command replicates only the WebSphere application Server configuration. If your application relies on products other than WebSphere application Server (such as databases or messaging products), you will need additional steps to replicate these environments.

Like other wsadmin script commands, the exportwasprofile and Importwasprofile commands are also available in Jython. The WebSphere application Server Information Center has more information about the AdminTask script commands and the above two specific commands.

Replication Server Configuration

In the WebSphere application Server V6, you can also replicate custom server configurations between multiple profiles (without deploying applications on them). Similar to the replication profile configuration, you can use this feature in the same or different host environments, different or identical product installations. In general, you can use this feature to replicate server configurations between different platforms as long as the os-specific system properties are not added to the server configuration. The exception is that if z/OS and distributed platform profiles are incompatible, you cannot replicate server configurations between these platforms.

Although there is a similarity between the two replication features, there are still some differences: when replicating a configuration, server configuration replication does not include applications deployed on the server. The server configuration replication function is equally valid for application servers and ND profiles.

To replicate the server configuration: Perform the Exportserver command in Wsadmin and export the server configuration to the configuration profile. For example, the commands in the following illustration illustrate how to export the configuration of the current profile to the configuration profile C:\work\myServer.car in JACL. (When performing this operation on a single server profile, there is no need for nodename and serverName options.) ）

Wsadmin> $AdminTask exportserver 
  {-nodename mynode-servername myserver-archive C:\work\myServer.car}

Use the Importserver command in Wsadmin to import the profile file into another profile. To execute this command, first start the wsadmin on the target profile. For example, if you want to import a server MyServer configuration into the profile myProfile2, you can use the

<install_directory>\bin\wsadmin.bat-profilename MyProfile2

command to start the wsadmin. When the Wsadmin is started, execute the importserver command to import the configuration. For example, you can import the exported server configuration to a node named Anothernode in the MyProfile2 profile by using the JACL command shown below. If you do not use the ServerName option, the server name in the configuration profile will be used as the name of the imported server.

Wsadmin> $AdminTask importserver 
  {-node anothernode-servername mynewserver-archive C:\work\myServer.car}

The Importserver command can create a new server from a custom configuration based on the server configuration defined in the profile. This command differs from the Importwasprofile command that overrides the server configuration. Because you do not have the ability to create a new server for the application server profile, you can execute the exportserver command on the application server and the ND profile, but the Importserver command is available only for the ND profile.

Again, as with other wsadmin scripts, these commands are equally valid in Jython. See the WebSphere Application Server Information Center for more related details.
Conclusion

WebSphere application Server V6 introduces the concept of a profile, physically separating product binaries from user data; A profile consists of a set of user data and its run-time execution environment. This article describes how to create, use, and manage profiles in the underlying application server and in the network Deployment (ND) environment, and how to copy configurations between profiles. Although the concept of a version 6 profile is brand new, users may experience difficulties in learning, but profiles can make it easier and easier for users to use WebSphere products more efficiently and easily. This paper tries to help readers to solve the difficulties in the learning process, so that readers quickly grasp the profile features and implement them in the environment.