The Server Labs Blog Rotating Header Image

cluster

Full Weblogic Load-Balancing in EC2 with Amazon ELB

This is the latest post in the series on deploying a Weblogic cluster in Amazon EC2. Previous posts have shown how to create and configure a weblogic cluster using either standard Amazon EC2 images or RightScale ServerTemplates and RightScripts.

In the first post in the series, I explained how to deploy a load-balanced two-node Weblogic cluster in Amazon EC2. If payday loans online you want to deploy a cluster with more than two nodes in it, you need to introduce a proxy server to the mix. This will keep track of which Weblogic sessions are registered with which Weblogic nodes in the cluster (a maximum of two) and therefore will be capable of redirecting each request to a Weblogic node that has a session for the user.

Ideally, you want two proxy servers in case one goes down – we don’t want a single point of failure – and you want some kind of load balancer to direct requests to one of the two proxy server instances. In summary, you want an architecture such as that shown below, with an Amazon Elastic Load Balancer directing requests to one of two Apache instances acting as the proxy servers which, in turn, redirect requests to one of the nodes in the Weblogic cluster – I’ve shown 3 here but there could be many more nodes in the cluster.

fully-load-balanced-ec2-22

Such an architecture is the ideal in terms of load balancing and high-availability and this post will explain how to achieve it in Amazon EC2.

Configuring the 3 Oracle Weblogic Cluster Nodes

Follow the steps outlined in the following sections of the first post in the series to create the Oracle cluster nodes. The only variation is that you should create 3 nodes instead of 2, naming them Server-0, Server-1 and Server-2:

  • Launching the instances
  • Creating the Weblogic domain
  • Starting the Weblogic Administration Server and configuring the cluster
  • Copying the managed server configuration
  • Checking that the servers work OK

Make sure you configure the cluster to work with the Weblogic proxy. To do this, in the Weblogic Administration console, click on Clusters and then cluster-0. In the General > Configuration tab, expand the “advanced” option and tick the “WebLogic Plug-In Enabled” option.

At this stage, you should have 3 EC2 machines running which we will refer to as [machine-0] [machine-1] and [machine-2]. Each machine should be running a weblogic server and a weblogic admin server should also be running on machine-0.

Configuring the Apache Servers

We will use two instances of the Apache Web Server as proxy servers for the weblogic cluster members. In EC2, start two machines based on the Alestic Ubuntu Server 9.04 32-bit (ami-bf5eb9d6) image. We will refer to these machines as [machine-3] and [machine-4].

SSH into machine-3 and run the following commands to install Apache 2.2:

apt-get update
apt-get install apache2

Download the Oracle Weblogic Apache plugin bundle to your local machine. To find it, go to this page and download the item marked “Apache Plug-ins zip”. Open the ZIP file and just extract the Apache 2.2 Linux module which you can find at /linux/i686/mod_wl_22.so. Upload this file from your local machine to machine-3 using SCP. How you do this between Windows and Linux users. Below is the Linux command, in which you will need to substitute [machine-3] for the public DNS address of machine-3:

scp mod_wl_22.so root@[machine-3]:/usr/lib/apache2/modules/mod_wl_22.so

Now that we have uploaded the Weblogic proxy plugin, we need to configure it. On machine-3, create a new file called /etc/apache2/mods-enabled/weblogic.load and add the following content:

    LoadModule weblogic_module /usr/lib/apache2/modules/mod_wl_22.so

On machine-3, create a file called /etc/apache2/mods-enabled/weblogic.conf and add the following content, substituting [machine-*] with the relevant public DNS address:

    
      WebLogicCluster [machine-0]:7002,[machine-1]:7002,[machine-2]:7002
      MatchExpression /clustered-webapp/*
      Debug ON
      DebugConfigInfo ON
      WLLogFile /tmp/weblogic.log
    

This is the core Apache configuration for the Weblogic proxy plugin. The first two lines are the most important – they tell the plugin which nodes are in the cluster and which URL patterns it should match against to proxy requests to the cluster. Note that I believe you don’t have to specify all the nodes in the cluster – the proxy should be capable of finding all nodes in the cluster by asking just one member – although here I’ve specified all 3.

Now reload Apache so it picks up the changes:

/etc/init.d/apache2 reload

Go to http://[machine-3]/clustered-webapp and check that you get a screen saying something like “Hello World! This machine’s IP Address is: ip-10-250-10-63/10.250.10.63”. This shows that the Proxy running in the Apache server has connected to the cluster and is proxying requests to it. Given that we specified the “DebugConfigInfo” option in the configuration earlier, we can easily get debug information by accessing the following URL: http://[machine-3]/clustered-webapp/?__WebLogicBridgeConfig. The screen you should see is something like that shown below:

Weblogic proxy debug screen

Weblogic proxy debug screen

This screen is very useful for debugging problems with the proxy configuration but, as you can probably guess, it’s not a good idea to make this information publically available in a production system. The output above indicates that the proxy has correctly identified the cluster and the 3 servers available within it.

Now that one Apache server works ok, configure machine-4 in exactly the same way so that there are two apache servers (machine-3 and machine-4) which act as proxies to the 3 weblogic servers in the cluster.

Configuring the Elastic Load Balancer

To complete the organization proposed in the introduction, we have to introduce an Amazon Elastic Load Balancer which will balance requests to the two Apache web servers. If one goes down, the load balancer should be able to redirect all requests to the remaining server, signifying no drop in availability for end users.

If you have not already installed the Amazon load balancer command line tools, follow the steps below:

  1. Configure your machine to use the Amazon command line tools if you have not already done so
  2. Download and unzip the Amazon Elastic Load Balancing API Tools from http://developer.amazonwebservices.com/connect/entry.jspa?externalID=2536&categoryID=88
  3. set an environment variable $AWS_ELB_HOME to point to where you unzipped the tools to.
  4. add $AWS_ELB_HOME/bin to your path.

Run the following on your local machine to create the load balancer. My instances are in us-east-1b (you can find this out from the “zone” attribute when you click on a running instance in the AWS Management console). Note the DNS name that you are given when the command finishes – let’s call this [elb-dns]. This command configures the load balancer to listen on port 80 (standard HTTP port) and redirect all traffic to port 80 on each of the two Apache web servers which we will register with the load balancer.

local:-$ elb-create-lb Test --availability-zones us-east-1b --listener "protocol=http,lb-port=80,instance-port=80"

Register your instances with the Load Balancer. Use the AWS Management console to discover your instance IDs.

local:-$ elb-register-instances-with-lb Test --instances [instance-id-machine-3] [instance-id-machine-4]

Configure the health check. This specifies that the load balancer should access the URL /clustered-webapp/ on port 80 on each of the Apache Web Server instances registered with the load balancer every 5 seconds. It should wait up to 3 seconds for a response from each instance and if it gets 2 response failures, it won’t send any requests to that instance. When it gets 2 successful responses from an instance, it starts sending requests to it again.

local:-$ elb-configure-healthcheck  Test --target "HTTP:80/clustered-webapp/" --interval 5 --timeout 3 -unhealthy-threshold 2 --healthy-threshold 2

Now, when you go to http://[elb-dns]/ you should get the same page as you got when you accessed each Apache web server separately. The IP address should change, depending on which Weblogic server the load balancer uses to serve the request.

Proving High availability

This deployment architecture should enable the system to cope with the failure of an Apache proxy server and at least one Weblogic server with no apparent consequences for the end user. Let’s prove it!

Go to the URL http://[elb-dns]/clustered-webapp/sessionCounter and you should see a HTTP page that says how many times you have accessed the page. Click refresh a few times so that the number is greater than 1 and keep this page open in your web browser.

On your local machine, run the elb-describe-instance-health command to show the health of the two instances that the load balancer is balancing requests against. The output should show both Apache servers “InService”:

$ elb-describe-instance-health Test
INSTANCE-ID  i-4320782a  InService
INSTANCE-ID  i-21346c48  InService

Now, in the SSH console for machine-3, shut down Apache by executing the following:

/etc/init.d/apache2 stop

Go back to the Session Counter web page in your browser and click refresh. The number of times you have accessed the page should not be reset to 1 – it should keep rising each time you click refresh. This proves that the failure of one Apache server does not affect the end user. To prove that the apache service is down, on your local machine, run the elb-describe-instance-health command again, which should give you results similar to these:

$ elb-describe-instance-health Test
INSTANCE-ID  i-4320782a  OutOfService
INSTANCE-ID  i-21346c48  InService

Leave the Apache service shut down and terminate the Weblogic server running on machine-1 by pressing ctrl-c in the console window. Return to the Session Counter web page which is displayed in your browser. Click refresh a few times to prove that the session counter is maintained thereby proving that there is no effect on an end-user when a weblogic node fails.

How does all of this work?

There is more detailed information in the Weblogic documentation but basically when you connect to a Weblogic cluster for the first time, the node that serves your request creates a session ID cookie that contains the session ID and the IDs of two nodes in the cluster in the form [sesionID]![PrimaryNodeID]![SecondaryNodeID] e.g. 2VyWK6hdcJGjDHp3t11GKL8Pv2l6kK0V2p113Gc0Sp12Y2H0vcG8!1074248988!1767416532. The primary and secondary nodes will both contain a copy of your session.

When the Weblogic proxy running in Apache receives a request, it looks at the session ID cookie to work out which nodes in the cluster are the primary and secondary nodes that contain the user’s session. It will then try to redirect the request to the primary, only resorting to the secondary if the primary does not respond in a reasonable time. If both nodes fail at the same time – which should be an extremely rare occurrence – then the user’s session is lost. Weblogic always tries to ensure that each session is stored on two nodes in the cluser so if a node fails, Weblogic will move sessions that were stored on that machine to others.

Using RightScripts to create a Weblogic cluster in Amazon EC2

In my previous post, I described how to set up a Weblogic cluster in Amazon EC2 using the Oracle-supplied Amazon AMI image. In this post, I will describe how to create a cluster using RightScripts, an alternative technology offered by RightScale.

In Amazon EC2, you work on an AMI – installing software, configuring – until you are happy with it. Then you ‘freeze’ it, storing it in S3 so that you can create many different instances based on this AMI. Amazon give you the possibility to pass configuration data to each new instance using “user-supplied data” which allows you do differ one launched AMI from another.

RightScale offer you an alternative. Instead of doing all the installation www.diggegg.com and configuration work on an AMI and then freezing it, you capture all the installation and configuration work in scripts – RightScripts. Each time you start up an instance in RightScale, you decide which RightScripts to execute against a base operating System to construct the complete machine that you wish to deploy.

For example, if you want to deploy an Apache Web Server, you write a RightScript that downloads, installs and configures Apache. You start up a new instance (with a base operating system e.g. CentOS) and run the RightScript. Once it has finished, you have an Apache server up and running. You can even associate one or more RightScripts with a base AMI to make a RightScale Server Template.

The benefits over the use of highly personalised AMIs are:

  • It is easier to change the configuration of your machines in the future – you can just execute another RightScript ‘on the fly’
  • You are not tied to one particular cloud vendor. RightScale allow you to execute RightScripts on machines in non-Amazon clouds

This article will show you how to create a Weblogic cluster using RightScale Server Templates made up of various RightScripts. You will need some familiarity with Amazon EC2 and S3 to get the full benefits from this article and I also assume that you’ve read my previous post on this theme.

You will need to sign up for a RightScale account to follow the steps in this post.

Overview

We will create two server templates – one for the primary cluster node that runs the admin server and a managed server and one that contains just a managed server. We will create these templates from various RightScripts that completely automate the installation and configuration process and just require a few variables to be set. This should mean that we can deploy many managed server instances with just a few clicks.

Creating the RightScripts

Log into the RightScale service and click on the Design > RightScripts link in the navigation bar on the left. Click on the ‘new’ button to add a RightScript and add each of the scripts described below, naming them the same as the header:

Install Weblogic

This script installs weblogic on top of the base operating system. It relies on a tar-gzipped copy of the Weblogic installation being stored in an S3 bucket (folder) to which you have access. To create this copy (a one-off procedure), run an instance based on AMI “ami-6a917603” and execute the following commands, substituting “my-new-bucket-name” for an Amazon S3 bucket name that does not already exist e.g. [my-company-name]-[weblogic]

wget ftp://mirror.switch.ch/pool/1/mirror/epel/5/x86_64/s3cmd-0.9.9-1.el5.noarch.rpm
rpm -ivh s3cmd-0.9.9-1.el5.noarch.rpm
tar -czvf /tmp/oracle-weblogic-103.tgz /opt/oracle
s3cmd mb s3://my-new-bucket-name
s3cmd put /tmp/oracle-weblogic-103.tgz s3://my-new-bucket-name/oracle-weblogic-103.tgz

(For more information on s3cmd, see here).

You can check that the weblogic zip was uploaded correctly using a tool such as S3Fox.

Here is the RightScript. Substitute “my-new-bucket-name” for the bucket name you created in the step above.

#!/bin/bash

# NOTE: relies on AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables having been set.
echo "Using AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID"
echo "Using AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY"

# get WL zip out of S3 using the s3cmd tool that's installed by default
s3cmd get my-new-bucket-name:oracle-weblogic-103.tgz /tmp/wl.tgz

# untar WL to install it
tar -zxvf /tmp/wl.tgz -C /

# report success
exit 0

Install the Domain

When I say “install”, I really mean “extract”! Download the test_domain Domain from here and use S3Fox or another equivalent tool to copy it over to the “my-new-bucket-name” folder in S3 that you created earlier. The RightScript below retrieves this domain from S3, extracts it and places it in the /mnt/domains folder. You must substitute “my-new-bucket-name” for your S3 bucket name. This domain is a basic domain that has no servers or clusters configured – these will be configured later in RightScripts.

#!/bin/bash

# NOTE: relies on $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY environment variables having been set.

# get domain zip out of S3 using the s3cmd tool that's installed by default
s3cmd get my-new-bucket-name:test_domain.tgz /tmp/test_domain.tgz

# untar domain to install it
tar -zxvf /tmp/test_domain.tgz -C /

# report success
exit 0

Start Weblogic Admin Server

This script simply runs the admin server and redirects output to a log file. This should probably be replaced with an init.d script in a production setup.

#!/bin/bash

mkdir /mnt/logs/

# start up weblogic
nohup /mnt/domains/test_domain/startWebLogic.sh > /mnt/logs/weblogicAdmin.log 2>&1 &

Create Cluster

This script contacts the Administration server on a defined hostname and port and creates a Weblogic cluster using the Weblogic Scripting Tool (WLST).

#!/bin/bash -e

PY_FILE="/tmp/create-cluster_"`date "+%s"`.py

cat < $PY_FILE
connect('$ADMIN_SERVER_USERNAME', '$ADMIN_SERVER_PASSWORD', 't3://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT')
edit()
startEdit()

cd('/')
cmo.createCluster('$CLUSTER_NAME')
cd('/Clusters/$CLUSTER_NAME')
cmo.setClusterMessagingMode('unicast')
cmo.setClusterBroadcastChannel('')

activate()
EOF

/opt/oracle/weblogic/common/bin/wlst.sh $PY_FILE

rm -rf $PY_FILE

Add Server To Domain

This script uses WLST to connect to an admin server and create a new server in the domain. The server’s name will be that of the machine’s EC2 public DNS name.

#!/bin/bash -e

SERVER_NAME=$(eval "curl http://169.254.169.254/latest/meta-data/public-hostname")
SERVER_LISTEN_ADDRESS=$(eval "curl http://169.254.169.254/latest/meta-data/public-hostname")
PY_FILE="/tmp/create-server_"`date "+%s"`.py

cat < $PY_FILE
connect('$ADMIN_SERVER_USERNAME', '$ADMIN_SERVER_PASSWORD', 't3://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT')
edit()
startEdit()

cd('/')
cmo.createServer('$SERVER_NAME')
cd('/Servers/$SERVER_NAME')
cmo.setListenAddress('$SERVER_LISTEN_ADDRESS')
cmo.setListenPort($SERVER_PORT)
cmo.setCluster(getMBean('/Clusters/$CLUSTER_NAME'))

activate()
EOF

/opt/oracle/weblogic/common/bin/wlst.sh $PY_FILE

rm -rf $PY_FILE

Start Managed Weblogic

This script starts up a Weblogic managed server instance which connects to the admin server and downloads all the domain info required. It relies on being able to download a security file – SerializedSystemIni.dat from your “my-new-bucket-name” folder in S3. Download this file here and upload it to S3 using S3Fox or an equivalent tool. Change the “my-new-bucket-name” folder in the script below to reflect your bucket name. This should probably be replaced with an init.d script in a production setup.

#!/bin/bash

# uses $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY

SERVER_NAME=$(eval "curl http://169.254.169.254/latest/meta-data/public-hostname")
START_ROOT=/tmp
DOMAIN_HOME=$START_ROOT/servers/$SERVER_NAME/security
BOOT_FILE=$DOMAIN_HOME/boot.properties

# create the server domain directory structure
mkdir -p $DOMAIN_HOME
mkdir -p /mnt/logs

# create the boot.properties file
echo "username=$SERVER_USERNAME" >> $BOOT_FILE
echo "password=$SERVER_PASSWORD" >> $BOOT_FILE

echo "using admin URL: http://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT"

mkdir -p $START_ROOT/security
s3cmd get my-new-bucket-name:SerializedSystemIni.dat $START_ROOT/security/SerializedSystemIni.dat

# start up weblogic
cd $START_ROOT
nohup /opt/oracle/weblogic/common/bin/startManagedWebLogic.sh $SERVER_NAME http://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT > /mnt/logs/weblogicManaged-$SERVER_NAME.log 2>&1 &

Create the ServerTemplates

Now that we have the basic RightScripts to construct Weblogic instances, we can create the ServerTemplates that logically group the scripts together.

Click on the Design > ServerTemplates link in the navigation bar in RightScale. Click on ‘new’ to create a new Server Template and call the template “Weblogic Admin”. Choose “EC2 US” and “m1.small” for the cloud and instance type attributes respectively. Use the browser tool to select the image “RightImage CentOS5_2V4_1_10”. Leave the rest of the attributes as their defaults and click ‘save’.

Click on the ‘scripts’ tab in the newly-created server template and add the RightScripts that you created earlier as boot scripts, in the following order: Install Weblogic, Install Domain, Start Weblogic Admin Server, Create Cluster, Add Server To Domain, Start Managed Weblogic. As you can see, this should install a weblogic server, create the domain and start the admin server. It should also create a cluster and a server in the domain and then finally start up the server.

rs-templatescripts

Create another server template called “Weblogic Managed” with the same cloud, instance type and image attributes as “Weblogic Admin”. Add the following scripts as boot scripts in this order to the template: Install Weblogic, Add Server To Domain, Start Managed Weblogic.

rs-scripts-managed

Start the instances

In the RightScale navigation bar, go to Manage > Deployments and click on ‘default’. Click on “Add EC2 US server”. For the Server Template, select Private > Weblogic Admin. Enter “Weblogic Admin 1” as the nickname and choose the SSH key that you want to use. Use a security group that has ports 7001 and 7002 open. Leave the rest of the attributes as defaults and click “Add”.

Repeat these steps to create “Weblogic Managed 1” which uses the Weblogic Managed template. You should now have two servers configured in the “Default” deployment and it should look something like the screenshot below (note that my servers are in the EU):

Servers for "Default" deployment

Launching the servers

Click on the launch icon next to the “Weblogic Admin – 1” server and you should see a screen prompting you for some parameters. These are all the input parameters required by the RightScripts that will run at boot time. Enter the information as shown in the screenshot below and click on the ‘Launch’ button:

rs-admin-params

Wait until RightScale shows the status of the server as “operational” – this can take a while (8mins or so), so be patient! Once it’s started, click on the server name and then on the audit entries tab. The latest audit entry should have status “operational”. Click on this and you should see a list of the scripts that ran at startup and their outcomes:

Audit entries

On the info tab of the server, you should see the public DNS name of the server e.g. “ec2-79-125-41-54.eu-west-1.compute.amazonaws.com”. Go to the URL: http:://[public-dns-name]:7001/console and log in with the username/password weblogic/weblogic.

If you click on the environment > servers link, you should see an Admin server and a managed server configured in a cluster. The managed server name should correspond to the public DNS of the machine:

Weblogic console servers

Now, in the RightScale console, start up the other server – “Weblogic Managed – 1” using the following inputs (substituting “Weblogic Admin – 1” for “Weblogic EU Admin – 1”) :

Inputs for Weblogic Managed

Once the managed server has started up, hit refresh in the Weblogic console. You should see the second managed server appear and the screen should look something like my one below:

Weblogic console showing all connected servers

Summary

Using the RightScripts provided in this post, you can easily deploy a Weblogic cluster using just two server templates. Adding new nodes is simple – just create another server based on the “Weblogic Managed” template and when the node starts up, provide it with the parameters it needs to connect to the admin server. The RightScripts take care of the rest for you.

Setting up a load-balanced Oracle Weblogic cluster in Amazon EC2

Oracle recently made available a set of AMI images suitable for use with the Amazon EC2 cloud computing platform. I found the two images (32-bit and 64-bit) that contain Weblogic (along with Oracle Enterprise Linux 5 and JRockit) the most interesting of the lot. This article will explain how to set up a basic two-node Weblogic cluster using the 32-bit Weblogic image provided by Oracle with an Amazon Elastic Load Balancer (ELB). In future articles, I will demonstrate how to set up a more complicated cluster with Apache Web Server instances balancing the load between many weblogic cluster members.

You can set up a Weblogic cluster in EC2 in very little time which makes it great for testing complicated Weblogic setups without having to mess around on your local machine or trying to scrape together the necessary hardware. This type of configuration would also be suitable for deploying a production application, though you’d have to check the licensing implications with Oracle if you wanted to do this.

Note that this article assumes a basic level of familiarity with using Amazon web services.

Launching the instances

The basic setup consists of a weblogic domain that contains an admin server and 2 managed nodes on 2 separate Amazon EC2 machines. The managed nodes will be configured in a cluster. We’ll deploy a simple web application to the cluster which shows us the IP address of the machine we hit.sbiancamento denti Once this works ok, we’ll introduce a load balancer to balance the work between nodes in the cluster. Finally we’ll take one of the servers down to show that the load balancer copes ok.

In the AWS Management console, go to “AMIs” and search for 32-bit AMIs with the keyword “weblogic”. You should see “ami-6a917603” as one of the options. Right-click and select “run instance”. On the following screen, select 2 for number of instances and choose your key pair name. Click on the Launch button.

When the 2 instances finish launching, they should appear on the “Instances” tab. Open an SSH console to each of the instances. Let’s referer to them as machine-0 and machine-1. Use the AWS Management console to find out the public DNS names of the two machines – they will be something like this: root@ec2-67-202-28-94.compute-1.amazonaws.com.

In the security group that you used to run these instances, open ports 7001, 7002 and 80 to any IP address (0.0.0.0/0).

Creating the Weblogic domain

The Weblogic domain is the basic configuration building-block so one of our first steps is to create a domain.

Open an SSH session to machine-0. How you do this will depend on your environment – windows or linux/unix. On linux, I run the following to access a machine, where FirstKeyPair.pem is a keypair that I created in AWS management console and saved to my local machine (replace [machine-0] with the public DNS for machine-0]:

local:~$ ssh -i $HOME/keypair/FirstKeyPair.pem  root@[machine-0]

Once logged in, accept the Oracle license. On the jumpstart menu which appears, select option 2; Launch the WebLogic Configuration Wizard and:

  1. Enter 1 to create a new Weblogic Domain
  2. Enter 1 – “Choose Weblogic Platform components”
  3. Type “Next” on the “Application Template Selection” ‘screen’
  4. Enter weblogic for username and password
  5. Select “Development mode” when prompted
  6. Select “JRockit SDK 1.6.0_05 @ /opt/oracle/jrockit” when prompted for the “Java SDK Selection”
  7. Select No when asked “Do you want to modify any of the preconfigured settings or defaults in your template?”
  8. For the “Target Location”, select “/mnt/domains”
  9. On the “Domain Information” screen, enter “test_domain” as the domain name

Starting the Weblogic Administration Server and configuring the cluster

Now that we have a domain, we start up the administration server. This will allow us to further configure the domain using a nice web interface instead of the command line. Start up the newly created weblogic server by executing the following on machine-0:

/mnt/domains/test_domain/startWebLogic.sh

Go to http://[machine-0]:7001/console (make sure port 7001 is open in your security group) and perform the following steps to create the two Managed Servers which form the cluster:

  1. Log in with the credentials weblogic/weblogic
  2. Click on the Servers link
  3. Click on the New button
  4. For Server Name, enter “server-0”
  5. Set the server listen address to the machine-0 name i.e the Amazon public DNS for machine-0
  6. Set the port to 7002
  7. Select “Create a new cluster for this server” and click next
  8. call the cluster “cluster-0”
  9. Select messaging mode “unicast” (the default)
  10. click Finish

Create “server-1” using similar steps:

  1. Click on the Servers link
  2. Click on the New button
  3. For Server Name, enter “server-1”
  4. Set the server listen address to the machine-1 name i.e the Amazon public DNS for machine-1
  5. Set the port to 7002
  6. Select “Add to an existing cluster”, select cluster-0 and click finish

At the end of this process, the cluster and server configuration should look like this:

ec2-wls-cluster

Click on Clusters and then click on cluster-0. In the General > Configuration tab, expand the “advanced” option and tick the “WebLogic Plug-In Enabled” option. This means that we can later use the Weblogic Apache proxy plugin to do load balancing in later sections of this post.

Copying the managed server configuration

The domain configuration currently only exists in the administration server domain. We have to copy it to a separate folder on machine-0 and a new folder on machine-1. These copies of the domain configuration will be used by the Managed Servers.

Open up another SSH console window to machine-0. Pack up the domain configuration by executing:

cd /mnt/domains/
/opt/oracle/weblogic/common/bin/pack.sh -managed=true -domain=test_domain -template=test.jar -template_name="test"

Create a new domain folder on machine-0 for managed-server-0:

cd /mnt/domains
/opt/oracle/weblogic/common/bin/unpack.sh -domain=test_domain_server0 -template=/mnt/domains/test.jar

Start server-0. Supply weblogic/weblogic as the username/password when prompted.

/mnt/domains/test_domain_server0/bin/startServer-0.sh

Copy the test.jar configuration over to machine-1. To do this, I had to upload my private key from my local machine to machine-0 (how you do this will depend on your OS, instructions below for linux/unix):

local:-$ scp $HOME/keypair/FirstKeyPair.pem root@[machine-0]:/mnt

Then, on machine-0 execute:

chmod 700 /mnt/FirstKeyPair.pem
scp -i /mnt/FirstKeyPair.pem test.jar root@[machine-1]/mnt

On machine-1 execute:

cd /mnt/domains/
/opt/oracle/weblogic/common/bin/unpack.sh -domain=test_domain_server1 -template=/mnt/test.jar

Then, start up the server for machine-1 entering weblogic/weblogic as the username/password when prompted.

/mnt/domains/test_domain_server1/bin/startServer-1.sh

After a short while, you should see all the servers shown as available in the “servers” view in the weblogic admin console (http://[machine-0]:7001/console).

Checking that the servers work OK

Now that we have the servers set up, we can upload a sample application that will be deployed in the cluster. You can download the app from here and the source code from here. Upload the sample web app EAR file to the admin server. This will depend on your machine configuration. On linux the command is:

scp -i $HOME/keypair/FirstKeyPair.pem clustered-ear-1.0-SNAPSHOT.ear root@[machine-0]:/mnt

In the weblogic administration console (http://[machine-0]:7001/console), execute the following steps to deploy the application to all members of cluster-0:

  1. Click on the deployments link
  2. Click on the install button
  3. Go to /mnt/ and select the file clustered-ear-1.0-SNAPSHOT.ear and click next
  4. Select “Install this deployment as an application” and click next
  5. On the targets page, tick the “All servers in the cluster” box and click next
  6. On the following page, accept the defaults and click ‘finish’

Check that you have enabled port 7002 in the security configuration. Go to port 7002 on each of the 2 machines to check that you get the JSP welcome page:

http://[machine-0]:7002/clustered-webapp/
http://[machine-1]:7002/clustered-webapp/

You should get a different IP returned in the web page for each different server.

Adding an Elastic Load Balancer

At this point, although the machines are running in a cluster, we are accessing the two machines totally separately via different DNS names, which is not giving us high availability. We will introduce an Amazon Elastic Load Balancer (ELB) to balance requests between the two managed Weblogic servers. This means that under normal circumstances, requests will be equally distributed between the Weblogic instances. If one goes down, the other will receive all requests. This gives us high availability. Note that my instructions are based on those given in this blog post: http://serktools.com/2009/05/20/amazon-elastic-load-balancer-setup/.

  1. Configure your machine to use the Amazon command line tools if you have not already done so
  2. Download and unzip the Amazon Elastic Load Balancing API Tools from http://developer.amazonwebservices.com/connect/entry.jspa?externalID=2536&categoryID=88
  3. set an environment variable $AWS_ELB_HOME to point to where you unzipped the tools to.
  4. add $AWS_ELB_HOME/bin to your path.

Run the following on your LOCAL machine to create the load balancer. My instances are in us-east-1b (you can find this out from the “zone” attribute when you click on a running instance in the AWS Management console). Note the DNS name that you are given when the command finishes – let’s call this [elb-dns]. This command configures the load balancer to listen on port 80 (standard HTTP port) but to redirect traffic to port 7002 (the Weblogic HTTP port that we configured) on each instance.

local:-$ elb-create-lb Test --availability-zones us-east-1b --listener "protocol=http,lb-port=80,instance-port=7002"

Register your instances with the Load Balancer. Use the AWS Management console to discover your instance IDs.

local:-$ elb-register-instances-with-lb Test --instances [instance-id-machine-0] [instance-id-machine-1]

Configure the health check. This specifies that the load balancer should access the URL /clustered-webapp/ on port 7002 on each of the instances load balanced every 5 seconds. It should wait up to 3 seconds for a response from each instance and if it gets 2 response failures, it won’t send any requests to that instance. When it gets 2 successful responses from an instance, it starts sending requests to it again.

local:-$ elb-configure-healthcheck  Test --target "HTTP:7002/clustered-webapp/" --interval 5 --timeout 3 -unhealthy-threshold 2 --healthy-threshold 2

Now, when you go to http://[elb-dns]/ you should get the same page as you got when you accessed each individual server separately. The IP address should change, depending on which Weblogic server the load balancer uses to serve the request.

If you go to http://[elb-dns]/sessionCounter, you should see a simple HTTP page that displays the number of times the user has accessed the page. It stores the information in the HTTP session. You should see this counter increasing, regardless of which Weblogic server is serving the request. This indicates that the session replication between Weblogic instances is working correctly. If this is the case, you should be able to stop one of the weblogic servers (hit ctrl-c in the SSH shell running startWeblogic.sh) and see the sessionCounter page continue to work. If you query the load balancer health (on your local machine), you should see that the server you stopped is marked as “out of service”:

elb-describe-instance-health

Restart the stopped server. Wait a while and run elb-describe-instance-health until both instances are marked as “in service”. Now stop the other Weblogic server. Check that the sessionCounter page continues to work.

If you get to this point, congratulations – you have a fully functioning, load-balanced Weblogic cluster running in Amazon EC2!

This setup works fine if you have just two Weblogic instances in your cluster. In the next post I’ll explain how to work around this limitation using an Apache web server with Weblogic Proxy plugin.