Because of it's simplicity, light-weight, and scalability, popularity and adoption of WebSphere Application Server Liberty Profile (WLP) server is growing. Recently, I was involved in one of the projects, that utilised the WLP Collective and Clustering capabilities. In order to share the knowledge, I'm writing a series of blog posts on How to Create and Configure WebSphere Liberty Cluster End-to-End. This particular post focuses on setting up a WebSpere Liberty Collective and a Cluster. Below listed are all the posts in this series:
- How to Create and Configure WebSphere Liberty Cluster End-to-End
- How to Deploy Application in WebSphere Liberty Cluster
- How to Setup Front-End Web Server for WebSphere Liberty Cluster
In order to explain it better, I've created an example topology of WebSphere Liberty Profile (WLP) Collective with a Collective Controller and two Collective/Cluster member servers. Example topology contains IBM HTTP Server (IHS) as a Front-End and also a Deployment/Tool server. See diagram 1.0 for details.
 |
Diagram 1.0
Example Topology: WLP Collective with Front-End & Deployment Server | | |
WLP Installation
There are several ways to install WLP. If you like to explore and compare best ways for your particular situation, take a look at
IBM Knowledge Center documentation.
Check WLP System Requirements:
First, you need to decide what version of WLP is needed for your particular situation. I'm using version 17.0.2 to implement this example topology. System requirement for WLP 17.0.2 can be found
here. For this exercise, I will be using Virtual Machines with CentOS Linux release 7.3.1611.
Note: Before proceeding with the WLP installation, make sure you have supported version of Java installed in the machine.
Here is what I have for this exercise:
Let's start with the WLP installation.
Important: first, I will install WLP in Machine: 02 by using downloaded WLP Jar installer, add all the required features and then package it and distribute to other servers.
This IBM Knowledge Center documentation explains in detail how to
download and extract the WLP installer Jar. As shown below, I'm installing it under
/opt/ibm directory:
Note: If you have multiple Java/JRE installed on your machine and you need to setup proper Java/JRE for your WLP environment, there are few ways that you can accomplished this. See Customizing the Liberty environment.
Once WLP is intalled and Java Runtime is configured, then check the version.
Install Features
Here, I'm installing features required for Collective, Cluster, SSL, restConnector, and localConnector. All the required features can be installed once or one at a time. For all available features refer to
Liberty Features at IBM Knowledge Center.
Since, all required features are installed, it's time to package the installation as server package and distribute to other servers for installation. In order to do this, I'm going to create a default WLP server and create a package. For more information about server packaging, refer to
IBM Knowledge Center documentation. Below, I'm showing server packaging as a Jar file, because it preserves (mostly) the execute permission for the scripts in bin directory.
Now, copy the generated
wlp_install.jar to other machines (
Machine: 03, and
Machine: 04 for this exercise) where WLP installation is required. Once wlp_install.jar is copied, proceed with installation. As shown below, we have copied the
wlp_install.jar into
/tmp and going to install WLP under
/opt/ibm directory.
If you need to see the installation options, you can just run the
--help as shown below:
Let's launch the installation on
Machine: 03 and
Machine: 04
Once the installation is completed, verify the version and validate the product as shown below:
Troubleshooting:
If you get message ./productInfo: line 187: /opt/ibm/wlp/java/java/bin/java: Permission denied
while executing script, check and make sure the script files have execute permission. Jar packaging usually preserves the permission, but if you have Java that is installed under ${wlp.install.dir}/java directory and packaged as part of the installer, files under /java/bin and java/jre/bin may not preserve their execute permission. So, go ahead and add execute permission.
|
Setup Collective Controller
Once the WLP is installed on all servers that will be part of WLP Collective, let's start setting up Collective Controller. If you need to understand the concept of Liberty Collective, refer to
IBM Knowledge Center article: Liberty: Collective architecture
Note: in given example topology (diagram 1.0), Collective Controller is setup on
Machine: 02.
As per our
collective create ... command,
/opt/ibm/wlp/usr/servers/wlpCntlr/wlpcntlr_include.xml is created with all required configuration for WLP Collective Controller. There are few manual updates required, before we can start our
wlpCntlr server. Here they are:
1) Open
server.xml and include
wlpcntlr_include.xml in it:
2) Open
server.xml and make sure to specify
host attribute with proper value for
httpEndPoint element. See below for example.
3) Open generated include file. In our case it is
wlpcntlr_include.xml and update
quickStartSecurity element with correct values for
userName and
userPassword.
If you need more explanation about WLP Collective Controller configuration, refer to
Configuring a Liberty collective chapter in IBM Knowledge Center.
Note: I've also added following features in WLP Collective Controller server configuration:
- adminCenter-1.0: provides Web Based GUI for collective/cluster/server and application management and monitoring. See Administering Liberty using Admin Center
- websocket-1.1: protocol that enables a client and a server application to communicate by using one full duplex connection. See WebSocker for details.
- restConnector-1.0: provides a secure JMX connector that can be used locally/remotely. Refer to Connecting to Liberty by using JMX for details.
- localConnector-1.0: provides a local JMX connector that is built into the JVM.
Below is complete listing of server.xml and wlpcntlr_include.xml for wlpCntlr (Collective Controller) server.
server.xml:
Based on from where and how you are accessing your Collective Controller server and how many firewall(s) in between, you may need to open firewall port(s) to allow communication. Below is command that I needed to run to open ports 9080 and 9443 so that CentOS allowed the incoming requests.
Start WLP Collective Controller server & Verify
Start:
Check the
messages.log. By default, it is located under
${server.config.dir}/logs directory. Make sure log file doesn't have any error and you see the message something like '
CWWKX6011I: The collective controller is ready, and can accept requests...".
If you have added feature adminCenter-1.0, you should also see a message something like '
CWWKT0016I: Web application available (default_host): http://waslibctlr01:9080/adminCenter/, in the log file
Access the Admin Center. Launch your browser and type the Admin Center URL seen on your log file. If it is http port, it will be redirected to https port automatically. Use the same userName and userPassword that you defined above in the
quickStartSecurity element. See below screen shot of Admin Center landing page
 |
| Admin Center landing page |
Create & Configure Collective and Cluster Member
You can have one or more WLP Collective and/or Cluster member server(s) in the same host (Vertical clustering/scaling) or different host (Horizontal clustering/scaling) or mix of Vertical and Horizontal clustering/scaling. In this exercise, as defined in the diagram 1.0, I'm doing Horizontal clustering/scaling with two member servers residing on two separate hosts.
Create 1st Collective and Cluster Member
Below commands are executed in Machine: 03
Troubleshooting:
If you encounter issues like one of these (below) while joining the WLP server to the Collective:
CWWKX0229E: There was a problem with the user credentials provided. The server responded with code 401 and message 'Unauthorized'CWWKX0229E: There was a problem with the user credentials provided. The server responded with code 403 and message 'Forbidden'
- Error with response code 401 is mainly because of unsuccessful authentication. Check and make sure 'user' and 'password' values specified in
collective join ... command match
with the corresponding values specified in quickStartSecurity or basicRegistry element for Collective Controller.
- Error with response code 403 comes because the authenticated user does not have required permission. In this case make sure: you are only using either quickStartSecurity or basicRegistry If you defined both, remove one).
- In case if you are using basicRegistry, make sure to provide administrator role to the user being used in
collective join .... Something like:
OR
For detail refer to Setting up BasicRegistry and role mapping on Liberty.
|
If
collective join ... commands completes successfully, (as per our command input) it generates
/opt/ibm/wlp/usr/servers/wlpSrv01/wlpsrv01_include.xml with all required configuration for WLP Collective Member. There are few manual updates required, before we can start our
wlpSrv01 server. Here they are:
1) Open
server.xml for
wlpSrv01 and include
wlpsrv01_include.xml in it:
2) Define Cluster and Cluster Member:
Open
server.xml for Collective Member server, and add the following:
For more information on setting WLP Cluster, refer to
Configuring a Liberty server cluster.
Below is complete listing of
server.xml and
wlpsrv01_include.xml for
wlpSrv01 (Collective and Cluster Member server) server.
server.xml
wlpSrv01_include.xml
Note:
1) Make sure both HTTP and HTTPS ports that server listens are open on firewall(s).
2) In order to avoid port conflict, if you have more than one WLP server running on same host, make sure listen ports are unique for each of them. Usually by default WLP assigns 9080 (http), and 9443 (https).
Create 2nd Collective and Cluster Member
Below commands are executed in
Machine: 04
Follow the same steps outlined in creating 1st Collective and Cluster Member . Here, I'm assigning name
wlpSrv02 for my 2nd server.
Below is complete listing of
server.xml and
wlpsrv02_include.xml for
wlpSrv02 (Collective and Cluster Member server) server.
Server.xml
wlpSrv02_include.xml
Note: Make sure all members in the cluster use the same LTPA keys.
For secure applications to function properly in a WLP clustered environment, each member of a given cluster must use the same LTPA key. For simplicity, Choose the LTPA key file from one of the cluster members and copy it to all of the other members in the cluster. The default LTPA key file is ${server.ouput.dir}/resources/security/ltpa.keys. For more information, refer to Creating a Liberty cluster with security considerations.
Start Member Server(s)
Make sure member servers started without any issue and joined the Collective and Cluster. Easy way to do it is to check the
messages.log. Check and make sure no errors there and verify messages something like below:
Successful start:
... A CWWKF0011I: The server wlpSrv02 is ready to run a smarter planet.
Successfully joined the Collective:
... I CWWKX8112I: The server's host information was successfully published to the collective repository.
Successfully joined the Cluster:
... CWWKX7400I: The ClusterMember MBean is available.
Once the collective member successfully join the collective and successfully started, further administrative work can be carried out using Admin Center Console.
Troubleshooting:
If you are enabling <feature>javaee-7.0</feature> which along with other services also supports Enterprise JavaBeans (EJB) Lite, and Java Message Service (JMS). You may see following errors depending upon your configuration:
1) CWWKS9582E:
... ibm.ws.transport.iiop.security.AbstractCsiv2SubsystemFactory E CWWKS9582E: The [defaultSSLConfig] sslRef attributes required by the orb element with the defaultOrb id have not been resolved within 10 seconds. As a result, the applications will not start. Ensure that you have included a keyStore element and that Secure Sockets Layer (SSL) is configured correctly.
Resolution: Define SSL config:
If using default key store ${server.config.dir}/resources/security/key.jks, configure as follows:
<keyStore password="{xor}LTovMz48OgAoNis3ACYwKi0ALz4sLCgwLTs="/>
OR, if defining custom key.jks and trust.jks, configure as follows:
<ssl id="defaultSSLConfig"
keyStoreRef="defaultKeyStore"
trustStoreRef="defaultTrustStore"
clientAuthenticationSupported="true" />
<keyStore id="defaultKeyStore" password="{xor}LTovMz48OgAoNis3ACYwKi0ALz4sLCgwLTs="
location="${server.config.dir}/resources/security/key.jks" />
<keyStore id="defaultTrustStore" password="{xor}LTovMz48OgAoNis3ACYwKi0ALz4sLCgwLTs="
location="${server.config.dir}/resources/security/trust.jks" />
2) CWWKO0221E:
... com.ibm.ws.tcpchannel.internal.TCPPort E CWWKO0221E: TCP Channel wasJmsEndpoint329 initialization did not succeed. The socket bind did not succeed for host localhost and port 7276. The port might already be in use.
Root cause: default port for JMS listener is in use. Most probably you have more than one WLP instances running on the same host and both listening on same listener port for JMS.
Resolution: Change the default wasJmsPort as follows:
<wasJmsEndpoint id="InboundJmsCommsEndpoint" host="*" wasJmsPort="9011" wasJmsSSLPort="9100" />
Refer to https://www.ibm.com/support/knowledgecenter/en/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_msg_multi_server.html for details.
3) CWWKS9580E:
... ibm.ws.transport.iiop.security.config.ssl.yoko.SocketFactory E CWWKS9580E: The server socket could not be opened on localhost:2,809. The exception message is Address already in use.
... com.ibm.ws.logging.internal.impl.IncidentImpl I FFDC1015I: An FFDC Incident has been created: "org.omg.CORBA.INITIALIZE: : vmcid: 0x0 minor code: 0x0 completed: No com.ibm.ws.transport.iiop.internal.ORBWrapperInternal 109" at ffdc_17.12.04_15.43.42.0.log
Root cause: default port for iiop is in use. Most probably you have more than one WLP instances running on the same host and both listening on same port for IIOP.
Resolution: change iiop ports as follows:
<iiopEndpoint host="*" id="defaultIiopEndpoint" iiopPort="2709">
<iiopsOptions iiopsPort="2815" />
</iiopEndpoint>
|
Next: proceed to application deployment -->
Looks like you're really interested in WebSphere Liberty Profile, see my other related blog posts below:
