This guide is part 1 of a two-part guide detailing how to configure a WAS ND Liberty Profile Collective.
A WASND Liberty Profile cluster is called a collective. The Collective is managed by a collective controller. The term cluster is not synonymous with Liberty Profile versions, as we instead speak in terms of a collective domain. The collectiveController-1.0 feature which is available as a feature to be added to a Liberty Profile instance via the add Feature Process, which is covered later in this guide. By default a collective controller is designed to work with collective members from the following products:
- WebSphere Application Server Liberty
- WebSphere Application Server Liberty - Express
- WebSphere Application Server Liberty Core installations.
The collective controller provides for a centralized administrative control point to perform operations such as MBean routing, file transfer, and cluster management. A core role of collective controllers is to receive information, such as MBean attributes and operational state, from the members within the collective so that the data can be retrieved readily without having to invoke an operation on each individual member. The diagram below is sourced from IBM : http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/SSAW57_8.5.5/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/cwlp_collective_arch.html The set of Liberty servers in a single management domain is called a collective. A collective consists of at least one server with the collectiveController-1.0 feature enabled. Optionally, it has many collective members and exists within a set of many collective controllers. A set of collective controllers is called a replica set. There is only one replica set per collective, and all controllers must be part of the replica set. When there are more than one collective controller, each collective controller will replicate its data to the other collective controllers in the replica set to allow for high availability and data protection. The replica set is logically present even when only one controller is in use. The controllers in the replica set communicate with each other using a collaboration scheme to ensure that data is replicated across the set of controllers no matter which controller in the set receives an operation to store data. Each controller has a dedicated port for use by the replication protocol. Communication between the controllers in the replica set is always authenticated and protected with SSL. A collective member can be configured with multiple collective controller endpoints. A collective member only communicates with one collective controller at a time; however, a configuration with more than one collective controller endpoint provides failover and workload balancing. Member-to-controller communication is always in the form of MBean operations performed over the IBM JMX Rest Connector. Communication between controllers and members is always authenticated and protected with SSL.
The steps involved in this guide are outlined below:
- Installation Planning
- Downloading/Acquiring Software
- GUI Installation
- Silent Installation
These steps are covered in the document titled: WAS_ND_8.5.5.x_Liberty_InstallationGuide which can be purchased from http://www.themiddlewareshop.com
Creating a Collective
The following high-level steps outline creating a collective controller, and a collective member which are covered in this guide.
- Create a Liberty server that will be used as the collective controller
- Create the collective controller configuration and add it to the controller server.xml file
- Start the collective controller
- Create a Liberty server that will be used as the collective member
- Join the member to the collective controller
- Start the collective member
Introducing the Collective
Individual developers will typically work in single server environments, however, the Liberty profile is also suited for production. Using multiple Liberty profile servers can provide the availability and scalability for running critical applications. Liberty collectives provide a common management domain for Liberty servers. This new structure has been added to the administration options for Liberty in V8.5.5 for operational efficiency and convenience, and to introduce high availability features. A collective comprises at least one Liberty profile server configured as a collective controller and possibly one or more Liberty profile servers configured as collective members. For a member to be part of a collective, it has to join a collective controller. A member can join more than one controller for failover and workload balancing reasons, but the member only communicates with one controller at a time. The communication between the member and the controller is done over the IBM JMX Rest Controller with MBean operations. Communication between controllers and members is always authenticated and protected using SSL. The collective controller provides operational access to all members of the collective. This includes operations to start and stop servers, invoke administrative operations, and perform file transfer in support of configuration changes and application installation. All Liberty profiles can be members of a collective but only Network Deployment provides the support needed to create a collective controller. WebSphere Application Server V8.5 Administration and Configuration Guide for Liberty Profile There can be more than one controller in a collective in order to form a replica set. In a replica set, each controller replicates its data to the other controllers, thus providing high availability and data protection. There can be only one replica set per collective and all controllers must be part of it. Liberty servers in a collective can be clustered to provide scalability and availability. A Liberty profile server that is configured into a collective can join a cluster by enabling the proper feature and configuring the cluster name. All members that specify the same cluster name are members of that cluster. A web server plug-in is used to distribute work across the servers in the cluster. The image below shows collective with clustered servers.
The collective controller provides support for managing the servers in the cluster as one object, including starting and stopping the servers, updating the configuration of the servers, installing and uninstalling applications. The collective controller also provides you the capability of adding capacity to an existing cluster and generate the web server plug-in.
Planning for a Collective
To set up a Liberty collective, you need to consider the high level architecture of your environment. Consider questions such as how many members and controllers you might need and how will they be grouped on your systems in order to meet your business needs
Setting up a Collective
The first step is to create a WAS ND Liberty Profile server, which will be configured to be a collective.
Create a Collective Server
To create a Liberty server that will be used as the collective controller, use the server command with create action from the bin folder of the Liberty profile installation. The root of our installation will be as follows
We will refer to this from now on as <wasndlp_root>
- Create a server called controller1
|./server create controller1
|Server controller1 created.
Verifying the install
We run the productInfo command to validate the product integrity, compare different versions of the Liberty profile servers, and verify the current product versions.
- Run the following command(s) from the <waslp_root>/bin folder to list features
|./productInfo featureInfo --output=/tmp/featureListOutput.txt cat /tmp/featureListOutput.txt
|appSecurity-1.0 [1.1.0] appSecurity-2.0 [1.0.0] beanValidation-1.0 [1.0.0] blueprint-1.0 [1.0.0] cdi-1.0 [1.0.0] clusterMember-1.0 [1.0.0] collectiveController-1.0 [1.0.0] collectiveMember-1.0 [1.0.0] concurrent-1.0 [1.0.0] distributedMap-1.0 [1.0.0] ejbLite-3.1 [1.0.0] jaxrs-1.1 [1.0.0] jdbc-4.0 [1.0.0] jndi-1.0 [1.0.0] jpa-2.0 [1.0.0] jsf-2.0 [1.0.0] json-1.0 [1.0.0] jsp-2.2 [1.0.0] ldapRegistry-3.0 [1.0.0] localConnector-1.0 [1.0.0] managedBeans-1.0 [1.0.0] monitor-1.0 [1.0.0] oauth-2.0 [1.0.0] osgi.jpa-1.0 [1.0.0] osgiConsole-1.0 [1.0.0] restConnector-1.0 [1.0.0] serverStatus-1.0 [1.0.0] servlet-3.0 [1.0.0] sessionDatabase-1.0 [1.0.0] ssl-1.0 [1.0.0] timedOperations-1.0 [1.0.0] wab-1.0 [1.0.0] webCache-1.0 [1.0.0] webProfile-6.0 [6.0.0]
||If you do not specify a server name, defaultServer is used. Where server_name is the name you want to give your server
Now that we have created a serve we can see the following directory structure is created as displayed using the Linux tree command. (yum install tree)
- cd /var/apps/was8nd.5.5_LP/usr/servers
- Issue tree command:
|Controller1 ├── apps ├── dropins ├── server.xml └── workarea 3 directories, 1 file
We will now start the server to ensure that it will run, using the following syntax
|<wasndlp_root>/bin/server start controller1
- Start server1 using the server command
|/var/apps/was8nd.5.5_LP/bin/server start controller1
Note: There is a run command, this will be a foreground console print, then background process. The start command is always background.
There are three primary log files for a Liberty server
- Contains the redirected standard output and standard error from the JVM process, this console output is intended for direct human consumption
- The console output contains major events and errors if you use the default consoleLogLevel configuration.
- The console output also contains any messages that are written to the System.out and System.err streams if you use the default copySystemStreams configuration. The console output always contains messages that are written directly by the JVM process, such as -verbose:gc output. This file is created only if the server start command is used, and its location can be altered only by using the LOG_DIR environment variable
- Contains all messages except trace messages that are written or captured by the logging component. All messages that are written to this file contain additional information such as the message time stamp and the ID of the thread that wrote the message. This file does not contain messages that are written directly by the JVM process.
- Containing all messages that are written or captured by the product. This file is created only if you enable additional trace. This file does not contain messages that are written directly by the JVM process.
At this time (trace is not enabled), we can tail one of two possible logs. Either console.log or messages.log The example below is a cat of <server1_root>logs directory
|Launching controller1 (WebSphere Application Server 188.8.131.52/wlp-184.108.40.20630510-0831) on OpenJDK 64-Bit Server VM, version 1.7.0_75-mockbuild_2015_01_21_05_53-b00 (en_GB) [AUDIT ] CWWKE0001I: The server controller1 has been launched. [AUDIT ] CWWKZ0058I: Monitoring dropins for applications. [AUDIT ] CWWKF0011I: The server controller1 is ready to run a smarter planet.
Note: You will notice that for this server, so far we are using the default CentOS JDK. We will change this soon to use an IBM SDK, because only certain security features are available via IBM JRE.
It is possible to check a server's state with the status command option. The syntax is:
|<wasndlp_root>/bin/server status <server name>
- Run the server status command:
|./server status controller1 Server controller1 is running with process ID 15295
There is also a command to interrogate the server's version.
|./server version controller1 WebSphere Application Server 220.127.116.11 (18.104.22.16830510-0831) on OpenJDK 64-Bit Server VM, version 1.7.0_75-mockbuild_2015_01_21_05_53-b00 (en_GB)
As mentioned earlier, it is important point to note that the JRE that is being used in this Linux CentOS 7 build is an Open JDK version. Liberty can run in almost any JRE that meets the prerequisites. However the is something important to note for Liberty collectives (clusters). In order for the collective controller to perform remote operations on Windows members such as starting or stopping a member server, the collective controller must run with an IBM JRE. Third-party JREs do not contain the required security classes.
Changing the JRE for the Liberty Runtime
Since we are using Liberty ND, we are intending to run a collective. Since we may want to use all the facets of security, we will need to replace the OpenJDK with an IBM JRE. I downloaded IBM SDK 7 from the IBM Software Catalog as listed below, I then unzipped these to create repository
|WS_SDK_JAVA_TEV7.0_3OF3_WAS_8.5.5.zip WS_SDK_JAVA_TEV7.0_2OF3_WAS_8.5.5.zip WS_SDK_JAVA_TEV7.0_1OF3_WAS_8.5.5.zip
|-rw-r--r--. 1 root root 380 May 23 2013 Copyright.txt drwxr-xr-x. 3 root root 33 May 23 2013 disk2 drwxr-xr-x. 3 root root 33 May 23 2013 disk3 drwxr-xr-x. 5 root root 52 May 23 2013 disk1 drwxr-xr-x. 10 root root 4096 May 23 2013 readme drwxr-xr-x. 3 root root 20 May 23 2013 responsefiles -rw-r--r--. 1 root root 81 May 23 2013 repository.config
Note: As of 22.214.171.124 you can download and install IBM WebSphere SDK Java Technology Edition Version 7.1. This version is only available from the web via the imcl command the URL is http://www.ibm.com/software/repositorymanager/com.ibm.websphere.IBMJAVA.v71 however, this means that you would require internet access from the machine/server where you are running the IM imcl command from. So it all depends on how your needs/environment and depends on whether you have a passport advantage or software access catalog account.
Installing the IBM SDK 7
In the example that follows, we will install the IBM SDK 7, using IM, before we do so we need to first query the repository to find the installation package name.
|./imcl listAvailablePackages -repositories /var/apps/installs/IBM_SDK_7
|./imcl listAvailablePackages -repositories /var/apps/installs/IBM_SDK_7 com.ibm.websphere.IBMJAVA.v70_7.0.4001.20130510_2103 com.ibm.websphere.liberty.IBMJAVA.v70_7.0.4001.20130510_2103
We can now install the SDK Issue the appropriate imcl command for example
|./imcl install com.ibm.websphere.liberty.IBMJAVA.v70_7.0.4001.20130510_2103 -installationDirectory /var/apps/was8nd.5.5_LP -sharedResourcesDirectory /var/IM/im-shared -repositories /var/apps/installs/IBM_SDK_7 -acceptLicense -showProgress -log /var/log/ibm/install/ibmsdk7.0.xml -preferences com.ibm.cic.common.core.preferences.keepFetchedFiles=false,com.ibm.cic.common.core.preferences.preserveDownloadedArtifacts=false
Note: For installation_directory, specify the appropriate WebSphere Application Server Liberty installation path on which to install IBM WebSphere SDK Java Technology Edition Version 7.0 or 7.1. Result:
|Installed com.ibm.websphere.liberty.IBMJAVA.v70_7.0.4001.20130510_2103 to the /var/apps/was8nd.5.5_LP directory
The SDK will be installed to a folder called java. Now we can run the re-verify command and the Liberty command/scripts will now acknowledge that there is an IBM JDK in the file path and now report the use of the IBM JDK for.
- Run the server verify command
|./server version controller1
|WebSphere Application Server 126.96.36.199 (188.8.131.5230510-0831) on IBM J9 VM, version pxa6470sr4fp1ifx-20130423_02 (SR4 FP1+IV38579+IV38399+IV40208) (en_GB
The rest is continued on Part 2.
If you or your organization require support in architecture, performance tuning, automation or simply advice, then please contact me via my support site and request a conversation, where we can discuss your requirement.
Steve is a seasoned passionate technology professional, strategist and leader. An expert in technical communications, and adept in almost all forms of Internet and mobile related technology, Steve has time and time again proven his tenacity to improve systems around him and deliver. Steve has worn many hats during his career such as Chief Technical Officer, Founding Member of several business ventures, Programmer, Systems Administrator, Architect, Blogger and Published Author to name a few. Due to 20 years Industry experience in Middleware, Programming, Networks and Internet Technologies, He combines systems knowledge with efficient working methods and inter personal skills required to build effective relationship with clients and colleagues alike. Exceeding typical expectations in any role undertaken, Steve is certain to become a valuable asset within any organisation He joins.
• Leadership (Team, Project, Business, People). • Architecture (Solutions, Information, Technical, Applications). Simply, I help you deal with CANETI: Constant And Never Ending Technological Innovation
Specific IBM WebSphere skills:
WebSphere Application Server (WAS Base, WAS ND & Liberty Profile & Liberty Runtime)
Middleware Integration Skills:
.NET programming, and Architecture
Java Programming, and Architecture
SOA, SOAP and XML messaging
JBoss Fuse, WMQ, IIB, Mule
General Digital Architecture & Governance
Digital Strategy, platform stacks for example IAAS, PAAS, SAAS
Industry Qualifications & Recognition
IBM Champion 2013