Albert Leigh's Weblog: Sun IBM WebSphere Solution Architect

This blog entry clarifies the recommendation of Solaris network tuning discussed in WAS v6.1 on Solaris 10 Redbook (Ch 2.2 p.25) and WAS v6.1 ND Tuning Guide.

[Read More]

Keeping your WebSphere application environment on Solaris updated with the recommended Fix Packs and Service Releases from IBM and Solaris update releases and patches is a key to better performance and reliability. For example, if you have WebSphere Application Server v6.1 with Fix Pack 5, you may find slowness in the garbage collection process using the throughput collector (ParallelGC).[Read More]

Service Management Facility (SMF), introduced in Solaris 10, enables a unified model for services and service management on each Solaris system. It is a core part of the Predictive Self-Healing technology available in Solaris 10, which provides automatic recovery from software and hardware failures as well as administrative errors.

One of my colleagues at Sun, Bob Netherthon, has a very nice slide deck on SMF here.

Since many of our customers asked, I have created a basic service manifest and simple instructions for WebSphere Application Server (WAS) as an example.

Instructions:

1. Put the service manifest file named "was61.xml" to a temporary directory /tmp.
2. Put the service method file named "svc-was61" in /lib/svc/method/svc-was61.
3. Edit this service method file to reflect the correct WAS path information, etc.

Follow the steps below.

    bash-3.00# chmod 755 /lib/svc/method/svc-was61
    bash-3.00# svccfg import /tmp/was61.xml
    bash-3.00# svcadm enable was61
    bash-3.00# svcs -l was61
    fmri         svc:/application/was61:was_server1
    name         WebSphere Application Server v6.1
    enabled      true
    state        online
    next_state   none
    state_time   Thu Jun 14 18:23:17 2007
    logfile      /var/svc/log/application-was61:was_server1.log
    restarter    svc:/system/svc/restarter:default
    contract_id  1819
    dependency   require_all/error svc:/milestone/network:default (online)
    dependency   require_all/none svc:/system/filesystem/local:default (online)
    dependency   optional_all/error svc:/system/filesystem/autofs:default (online)

Once you do "svcadm enable was61", WAS should start if the configuration is valid. The log file is located at: /var/svc/log/application-was61:was_server1.log.

If the service need to be removed, do the following:

    bash-3.00# svcadm disable was61
    bash-3.00# svccfg delete was61

Commentary:

Note that in the manifest, the exec_method was defined using the service method (e.g. external shell script: exec="/lib/svc/method/svc-was61 start"). This could be a WAS command itself (e.g. exec="/opt/IBM/WebSphere/AppServer/profiles/AppSvr01/bin/startServer.sh start"). The service method is a good way to separate the WAS start up/shutdown commands because if you need to change the profile or WAS location for this application service, you just need to modify in the service method script rather than having to re-configuring the service manifest.

In the case you have multiple WAS profiles, applications or versions, this manifest can also be used as a template to create new service manifests (e.g. was61_tradeapp1, was602_storeapp1, etc.).

You can also add other dependencies in the service manifest that the WAS services rely upon (e.g. another standalone application that your application requires to be co-located on the same system or a JMS provider that must be started before the WAS services, etc.).

Another good practice is to have the WAS processes to be started by a non-root user, which you can configure accordingly like this example for Apache.

Best of all, look at OpenSolaris website for:

• SMF Community
• Documentation
• Contributed Service Manifests and Methods

Finally, you should include useful and concise comments in the service manifest and methods for ease of maintenance.