Common Liberty profile environment topologies

Previous | Home | Next

Common Liberty profile environment topologies

As well as stand-alone Liberty profile servers, used for example by developers, the Liberty profile can also be used in more complex configurations in support of production environments.

Use multiple Liberty profile servers
Although the Liberty profile does not participate in usual WAS ND clustering, additional components can be used to achieve web application clustering and failover.

Example of a multiple Liberty profile server topology
To achieve such a topology, multiple Liberty profile servers are installed. The inbound traffic to the applications is spread by the HTTP servers, which are configured with the Liberty profile servers using the HTTP server plug-in. To distribute incoming requests, a load balancer is also used (for example, a hardware appliance or IBM WAS Edge Components).
Notice that a database is used for session persistence to allow failover of stateful HTTP sessions. For this purpose, the sessionDatabase-1.0 feature is used.
To improve the administration aspect of such a topology, the WebSphere ND job manager profile is used to deploy and manage all of the Liberty profiles using the WebSphere centralized installation manager component. This reduces the time needed to manage all the Liberty profile servers because it can be automated and done remotely.
To ensure the Liberty profile servers run with the same resources, a global configuration file can be made available for all instances, for example, using a shared file system or remote HTTP server. All Liberty profile servers read the shared server.xml configuration file but keep their local bootstrap.properties file where their environment configuration is kept. This process allows the Liberty profile servers to be installed on different operating systems. The same method can be used to configure applications, where they are placed in a single, shared directory available to all server instances.

Use WebSphere eXtreme Scale for session persistence

WebSphere eXtreme Scale (WXS) is an elastic, scalable, in-memory data grid. The data grid dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers. With WXS, we can get qualities of service, such as transactional integrity, high availability, and predictable response times.
Liberty profile does not come by default with the WXS support, and you need to download it and configure it to use it in your Liberty profile server. We can obtain the WXS V8.5 packages.
Example of a topology where the WXS implementation on a DataPower XC10 appliance is used as the session persistence layer.

WXS comes as a hardware Datapower XC10 appliance or a software product based on WAS. To configure Liberty profile servers to use WXS, we can use the eXtremeScale.web-1.0 feature. Sample configuration for the Liberty profile server to extend its capability of replicating the session.
<server description="WXS enabled Web Server">
    <featureManager>
        <feature>eXtremeScale.web-1.0</feature>
    </featureManager>
    <com.ibm.ws.xs.web.config />
</server>
Use Liberty as the runtime for WXS Grid
Another example of using the features of WXS is to use the Liberty profile servers as hosts for the WXS containers. The Liberty profile can run a grid container just like the WAS full profile, and its lightweight nature makes it an even better choice for such a purpose.

Grid members are configured in the Liberty profile...
<server description="WXS server">
    <featureManager>
        <feature>eXtremeScale.server-1.0</feature>
    </featureManager>
    <com.ibm.ws.xs.server.config />
</server>
Sample grid controller configuration based on Liberty profile
<server description="WXS Server">
    <featureManager>
        <feature>eXtremeScale.server-1.0</feature>
    </featureManager>
    <com.ibm.ws.xs.server.config />

    <xsServer catalogServer="true" 
              domainName="MyDomain" />

</server>
To configure the WXS client...
Sample WXS client configuration based on Liberty profile
<server description="WXS Client">
    <featureManager>
        <feature>eXtremeScale.client-1.0</feature>
    </featureManager>
    <com.ibm.ws.xs.client.config />
</server>
Managing a multiple Liberty profile servers configuration
Each Liberty profile server uses its own configuration file. Admins can create a globally accessible file share to store configuration files. Each server would have access to this file share, and use it as the main configuration repository. We can also use file shares for applications, so only one version of the application is used by all Liberty profile servers.
Using globally accessible file shares allows the administrator to control the server runtime configuration from a single place. For environments where there are multiple administrators with different roles who manage different aspects of the server, the configuration of the server can be placed in separate files. Each file contains configuration fragments dedicated to a given administrator and is referenced by the main configuration file using the include tag.
Authorization to the configuration files can be achieved on the operating system level. For example, a deployer has access to use a shared applications directory and has permissions to write to apps.xml. Similarly, the configuration of the user registry can be dedicated to a separate user who is authorized to ldapRegistry.xml.

The Liberty profile configuration, including passwords, is kept in text files. We can encode passwords using...
$LIBERY_PROFILE/bin/securityUtility.sh

Working with JDBC datasources

The Liberty profile allows users to configure multiple JDBC data source parameters.
To enable additional logging when using a Derby DB, configure the following trace setting in server.xml:
<logging traceSpecification="com.ibm.ws.logging.trace.specification=*=audit=enabled:com.ibm.ws.derby.logwriter=all=enabled"/>

Configure the following in the dataSource tag:
supplementalJDBCTrace="true"

After you update the configuration file, we can view trace logs generated by the Derby JDBC driver without a server restart.

Classloaders and shared libraries

The Liberty profile classloaders hide the classes that make up the Liberty profile runtime from Java Enterprise Edition applications and only exposes the public API. This feature isolates the applications from the internal libraries used by the Liberty profile. For example, one of the Open Source libraries the Liberty profile V8.5.0.0 uses is the SLF4J version 1.5.6 library.
If an application needs to use a different version of the same library, the Liberty runtime copy does not interfere with the application's copy. This resolves the problem of accidental usage of the internal server libraries.
The following types of libraries can be configured with classloaders: ibm-api (IBM APIs), spec (standardized APIs) and third-party. The default behavior of the Liberty profile is to hide the third-party APIs. Configuration of a sample ITSOWebCustomerCredit application where only standardized APIs are available, and all IBM or third-party APIs are hidden.
<application location="ITSOWebCustomerCredit.war" type="war">
    <classloader apiTypeVisibility="spec" />
</application>
The Liberty profile classloaders allow for sharing the class instances from libraries between applications or using them privately within the scope of an application. These two models are called the common library and private library. Sample configuration of both libraries for the same sample application.
<application location="ITSOWebCustomerCredit.war" type="war">
    <classloader commonLibraryRef="mySharedLib" privateLibraryRef="myITSOLib" />
</application>

<library>
    <fileset dir="${server.config.dir}/mySharedLib" includes="*.jar"/>
</library>

<library id="myITSOLib">
    <fileset dir="${server.config.dir}/ITSOLib" includes="*.jar"/>
</library>
The listing defines two shared libraries: mySharedLib and myITSOLib. Class instances from libraries located in the mySharedLib can be shared with other applications that include mySharedLib as a commonLibraryref.
Instances of the myITSOLib are dedicated to the applications that reference them. There can be as many copies of myITSOLib as applications that need those resources.
Liberty profile supports the older method of overriding the default behavior of the classloader configuration that uses the profile runtime classes. This configuration can be done using the delegation attribute. The default value of this attribute is parentFirst. If we use parentLast, the specified shared classes are loaded with the application, overriding the server libraries.
Configuration of delegation mode in the Liberty classloader for the sample application
<application location="ITSOWebCustomerCredit.war" type="war">
    <classloader commonLibraryRef="mySharedLib" delegation="parentLast" />
</application>
Configure dynamic updates

The Liberty profile can be configured for dynamic updates, changes to the server configuration, and adding, updating, and removing applications. For all deployed applications, we can configure server.xml to specify if application monitoring is enabled and how often to check for updates to applications. We can also change the default dropins directory.
To configure to only look for updates that are done through the JMX mbeans (this method is used by the WebSphere Developer Tools) and to disable the dropins directory:
<applicationMonitor updateTrigger="mbean" 
                    dropinsEnabled="false"/>
To allow only updates to the application files, we can use polled trigger values:
<applicationMonitor updateTrigger="polled" 
                    pollingRate="5000ms" 
                    dropins="C:\xyz"/>
Additionally, the pollingRate value specifies the changes are picked up every five seconds instead of the default value of half of a second. The default dropins directory was changed to monitor c:\xyz directory.
To disable auto detection of the changes in the applications:
<applicationMonitor updateTrigger="disabled"/>
Similarly, we can disable monitoring changes to any configuration change using the config tag:
<config updateTrigger="disabled"/>
We can also specify the interval of the configuration monitoring. In the following example, it is done every 10 minutes and 30 seconds, and it ignores any errors in the configuration file.
<config updateTrigger="polled" 
        monitorInterval="10m30s" 
        onError="IGNORE"/>
Create a dump of a Liberty profile server

To capture state information of a Liberty profile server, use the dump command. It can be useful for problem diagnosis of a Liberty profile server. The result file the dump command generates contains server configuration, log information, and details about the deployed applications. It also can be used against a running or stopped server; however, if the server is running, additional information is gathered:

State of each OSGi bundle in the server
Wiring information for each OSGi bundle in the server
Component list managed by the Service Component Runtime (SCR)
Detailed information of each component from SCR

Example...
server dump server1 --archive=/tmp/server1_dump.zip

We can also create a dump of the Liberty profile server using the WebSphere Developer Tools from the context menu

Monitor the Liberty profile runtime

The Liberty profile does not come with any dedicated tools to monitor its runtime, such as the Tivoli Performance Viewer available in the WAS full profile console. To monitor the Liberty runtime characteristics, administrators and developers can use standard tools for Java runtimes, such as Jconsole.
The Liberty profile offers the monitor-1.0 feature, which allows users to track information about the Liberty profile server runtime, such as JVM, web applications, and the thread pool.
To enable this monitoring, add the monitor-1.0 feature to the server.xml configuration, so the following MXBeans are available:

WebSphere:type=JvmStats
WebSphere:type=ServletStats,name=*
WebSphere:type=ThreadPoolStats,name=Default Executor

Jconsole is shipped as a part of the Java Runtime package. To run Jconsole against the Liberty profile, start it from the command line.
/IBM/WAS/AppServer/java/bin$ jconsole.exe

When Jconsole launches, a welcome window is displayed. Connect to the Java process that runs the Liberty profile. The Jconsole process must run under the same operating system userID and using the same Java runtime as the server. In this case, we can choose the local server process.

To monitor a specific application, and you know that application's process ID, then we can also start JConsole so that it connects to that application. This application must be running with the same user ID as JConsole.
% jconsole processID

In the command above processID is the application's process ID (PID). We can determine an application's PID in the following ways:

UNIX or Linux systems, use ps to find the PID of the java instance that is running.
Windows systems, use the Task Manager to find the PID of java or javaw.

Use the jps command-line utility to determine PIDs.

For example, if you determined the process ID of the Notepad application is 2956, then you would start JConsole with the following command.
% jconsole 2956

The Jconsole loads all runtime information into the tool, including the characteristic of the Java runtime, heap size, or processor usage.

Using Jconsole we can trigger mbeans operations under the mbeans tab. For example, issuing a restart operation on the ITSOWebCustomerCredit application.

If we enabled the monitoring infrastructure in Liberty, we can also access additional MXBeans, such as JvmStats.