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. 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:

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.