In this article, I will show you how to create a two-node Weblogic 12c cluster using only the command line. Oracle Weblogic (formerly BEA Weblogic) is one of the most resilient, reliable and high-performance J2EE application servers that I’ve worked with. I’ve used it to host both custom applications, as well as commercial applications that required an enterprise-grade J2EE container to serve them.

The lab topology will be as follows:

Weblogic Server	Hostname	IP Address	Port	Cluster Name
AdminServer	dolan	172.16.18.169	7001	N/A
test_managed_server_1	dolan	172.16.18.169	7002	TestCluster
test_managed_server_2	gooby	172.16.18.172	7002	TestCluster

As you can see, AdminServer only runs on a single node. Once the managed servers have been configured and started for the first time by way of the administration server, they can be restarted independently - thus the loss of the administration server does not impact the general running of the cluster. It will, however, prevent administration of that cluster (configuration, deployments, etc.) until such time as the administration server is back online. There are ways around this (bind the administration to a failover VIP provided by keepalived or similar) but for all but the most demanding usage, a single administration server will suffice.

Both dolan and gooby run CentOS 6.3 x86_64. All steps should be run on both nodes unless otherwise noted.

Filesystem Creation

First, create a logical volume on which to create a filesystem, /u01 (as per Oracle conventions), that will be used for housing the middleware.

Obviously, in a production environment you’d be assigning a great deal more than 4GB to this logical volume. Create an ext4 filesystem on the newly created logical volume:

Create a directory for the mountpoint:

Add an entry to /etc/fstab:

And mount the filesystem:

Configure Weblogic User/Group and Resource Limits

The next step is to configure a user and group for Weblogic, and configure the user environment appropriately.

First, create a group and user for Weblogic

and set a password:

Next, set correct ownership on the filesystem mountpoint we created earlier:

Now we need to increase the limits for the number of file descriptors granted to the weblogic user. I’ve found in production environments that 4096 is usually an acceptable value. You may need to increase this (8192 is not unreal on a dedicated application server) as per your requirements.

Switch user to weblogic and ensure that the limits are correct:

All remaining steps of this article will be performed as the weblogic user.

Software Installation

Two pieces of software need to be installed - a JDK and Weblogic itself. The recommended JDK for production Weblogic use is Oracle JRockit. Download the latest 64-bit Linux version of JRockit 1.6 and the generic installer for Weblogic 12c. I will presume that you have copied the appropriate installation binaries to /u01/tmp on each node.

At the time of writing, the following versions were downloaded:

JRockit - jrockit-jdk1.6.0_37-R28.2.5-4.1.0-linux-x64.bin

Weblogic - wls1211_generic.jar

As you can see, because I’m running a 64-bit operating system, and hence want a 64-bit JDK, I am unable to use the JDK bundled with Weblogic for the installation. This is my preference anyway, as I like to be in control of all software being installed and used on my systems.

First, install JRockit:

The installer will attempt to launch its GUI, fail, and drop down to console mode. Step through the text-based installer. The only thing I changed was the location to install JRockit to:

I also told the installer NOT to install examples or source code.

Once the JRockit installation is complete, create a symlink for ease of reference (and for ease of JDK upgrade):

Modify ~/.bash_profile, adding JAVA_HOME and updating PATH so that the java binary can be found on the search path:

Source the file, and check that java is now in your search path:

Check that it actually works:

Now we can use java to execute the .jar download of Weblogic 12c:

Again, work with the defaults, but specify a middleware home of

When prompted for a JDK location, ensure that your freshly installed JRockit location is selected:

I selected a Typical installation, which installed the following products:

Let the install proceed. Once Weblogic has successfully installed on both servers, you can proceed with the build and configuration of the domain, managed servers, and cluster.

Weblogic Configuration

The WebLogic Scripting Tool (WLST) is provided with Weblogic and uses a jython based command interpreter to monitor and control every aspect of your Weblogic installation. Whilst domain, managed server, and cluster configuration can all be managed via the Administration Console, WLST provides a rich scriptable interface for performing repeatable (and unattended) tasks. I have a WLST script file I use to create two node clusters. Instead of just firing the script off, I’ll run through each line interactively at the WLST prompt to give you a thorough understanding of what is happening. You can place all the commands into a single script, and have WLST execute them sequentially if you prefer. I suggest appropriate error handling be built into the script if you intend to run it unattended.

The Weblogic configuration should all be performed on the first node (where AdminServer will be running) until told otherwise.

Change directory into the server/bin subdirectory of your Weblogic 12c installation.

Source the setWLSEnv.sh to set the Weblogic user’s environment appropriately - this will include setting up the appropriate CLASSPATH to run WLST:

Next, fire up WLST. You’ll be presented with a WLST prompt:

The WLST prompt (here denoted ‘wls>‘) will change depending upon the mode you’re currently in, your location within the configuration tree, and so on. For ease of reference, here the WLST prompt will just be shown as ‘wls>‘.

First, as per the script, I set up a whole bunch of variables containing values that are used throughout the procedure. As you’re executing these commands interactively, it seems superfluous, but they are presented here so that you can create your own build_two_node_cluster.wlst script after the tutorial if you so wish. On with the variables - just enter them at the WLST prompt and hit enter after each one. Commands will be interpreted and any errors will be output. If you experience any errors, double-check your syntax and fix the error. These commands should be entered sequentially and failure of a preceding command will have knock-on effects even if not immediately apparent.

Define the variables:

Let’s step through those variables one at a time and see what they’re for:

psep - The path separator on my system - in this case - ‘/’.

jdk_location - Path to the JRockit JDK home - JAVA_HOME.

jdk_vendor - JDK Vendor name.

jdk_start_arguments - Each managed server will pass these arguments to the JVM on startup. Tune your JVM memory, garbage collection, and so on here.

weblogic_home - Path to your middleware home.

weblogic_version - The version of Weblogic as defined in the install path - in our case wlserver_12.1.

weblogic_user - The UNIX user the managed server will run as.

admin_username - Username for weblogic admin user.

admin_password - Password for weblogic admin user.

admin_server - Administration server name.

domain_name - Weblogic domain name.

server_1_hostname - Hostname of first server, must be resolvable by DNS or otherwise.

server_1_managed_server - Managed server name that will run on first server.

server_2_hostname - Hostname of second server, must be resolvable by DNS or otherwise.

server_2_managed_server - Managed server name that will run on second server.

cluster_name - Weblogic cluster name. The two managed servers will be members of this cluster.

The next three variables, domain_template, domain_path and nodemanager_path define the path to the domain template we’ll use to create our base domain (supplied with Weblogic), the path to our created domain, and the path to nodemanager. These variables all use values set previously to define the correct path to these components.

The final two variables, nodemanager_port and nodemanager_type are self-explanatory - we want an SSL-based node manager listening on port 5556 on each host.

Now that all the required variables are configured, create the domain:

Once the domain is created, start node manager:

A lot of messages will be output to STDOUT and will interfere with your WLST session. Hit enter and the WLST prompt will return. Follow the messages for errors until you see that the node manager has correctly started.

Connect to the node manager, and start the administration server:

Next, connect to the administration server, and place it into edit mode. Edit mode allows us to make changes to the Weblogic configuration as if we were logged into the web-based console.

Change “directory” into the correct context, and set all hostname verification values to perform no verification:

These values need to be set as we’re using the out-of-the-box demo SSL certificates for node manager communication. With a production setup, real digital certificates signed by an appropriate CA would be used, and these steps would not be performed - verification in that case would be desirable.

Save the changes, and activate them (blocking other edits as you do so).

Disconnect from the administration server, and restart it via node manager:

Reconnect to the administration server, and start editing once again:

Change “directory” to the root of the configuration tree, and create the first machine. A managed server is associated with a Unix machine within the Weblogic configuration:

Here, a Unix machine is created with hostname dolan, and is told to bind to user weblogic (as we’re running as the weblogic user anyway, this is not strictly required). Then, we change properties for the node manager for that machine, so that the administration server knows how to connect to it to start the managed server under its control. Perform similar steps for the second machine:

Next, create the cluster, and set unicast messaging mode. For a two-node cluster, there is no benefit in using multicast.

Now that the machines and cluster are created, continue onto creation of the first managed server:

Here, we create the test_managed_server_1 managed server, binding it to dolan:7002, and setting some parameters around failure detection and recovery; tweak these to your liking. Then, we define the JDK home, vendor and JVM start arguments defined in our earlier variable declarations. Proceed with the second managed server, test_managed_server_2:

Associate both managed servers with the cluster:

And then associate them with their respective machines:

Save and activate the changes, and exit WLST:

The entire cluster is now configured on dolan (our first server) only! There are a few ways to transfer the domain over to the second server, but the best way is to use the pack.sh and unpack.sh scripts. These scripts are provided as part of the Weblogic distribution, and will pack and unpack the domain with thorough consistency checking. Ensure you use this method to transfer the domain to the second node.

Change to the common/bin subdirectory of your Weblogic 12c installation:

Pack up the domain using pack.sh - ensuring that you use the -managed=true option to specify we want the managed server packaged with this domain (the default is to just package the domain). The pack.sh script will output a “template” file, in our case template.jar that can be transferred over to our second server gooby and unpacked using unpack.sh. Pack the domain and create the template (output shown for reference):

Transfer the template to the second node:

Log into the second node as the weblogic user, and set the user environment:

Change into the appropriate directory, and unpack the domain using unpack.sh. Note - you do not need to specify -managed=true here:

The domain is now ready to go on the second node, including an appropriately configured test_managed_server_2 managed server. Start node manager on the second node (it should already be running on the first).

As you’ve not yet started the managed servers, their full directory structure will not exist, and thus boot.properties will not be able to be created (which you need to do if you’d like to start your managed servers without supplying credentials). You can create the directory and populate boot.properties as follows:

Once this step has been performed on both servers, substituting the managed server name as appropriate, you can start the managed servers for the first time. The password in boot.properties will be encrypted within the file when it is read for the first time.

Starting Weblogic Managed Servers

The first time you start Weblogic, it MUST be done via the administration server, not the node managers. You only need the administration server for the initial start of a managed server. It can then be started/stopped independently of the administration server.

Using WLST on either node, start and shutdown the managed servers:

Ensure that each command completes successfully and no errors are noted.

Once the shutdowns are complete, and provided node manager is running, you can now connect to a managed server’s node manager and control the server, e.g.:

The cluster is complete.

Conclusion

This article has walked the user through build of a two node Weblogic 12c cluster - without even logging into the web-based console.

The power of WLST has only just been touched in this article, and I thoroughly recommend reading the reference guide for your version of WLST available from the Oracle site.