Building a reliable, automatic scaled-out infrastructure for your web application is not a job for the faint of heart. It often involves deep knowledge of your application servers or getting expert consulting. Sometimes both. GigaSpaces XAP application platform will let you do that, and more, with just a few easy steps and at a much lower cost.
Starting from version 6.6 m1 of GigaSpaces XAP, one can deploy not only spaces and PUs (processing unit) but also web applications (WAR files). Meaning, you can deploy many instances of your web application in order to meet heavy performance requirements. The best part is that the scaling out deployment can be done automatically and on-demand using GigaSpaces SLA configuration and based on application usage.
In this first installment I will show, from high altitude, how to deploy a web application (Spring Pet Clinic) using GigaSpaces Grid-Browser, and how to configure a load balancer (Apache HTTP server with Balancer module) in front of your multiple web application instances. In order to follow this demo please download the following:
- Sample Web Application – The sample application (Spring Pet Clinic) is part of the Spring Core distribution and can be downloaded here. It includes the WAR file and a database folder. To execute the web application with its default settings, simply start the HSQLDB instance in the “hsqldb” directory using “server.bat
- GigaSpaces XAP – Early access versions of GigaSpaces XAP can be downloaded here. GigaSpaces XAP utilizes embedded Jetty (http://www.mortbay.org/jetty-6/) as web container and together with highly optimized resources pooling between web application instances (running on the same machine) it gains excellent performance.
- Apache Configuration Files – Apache Web Server (2.2.9) and all related configuration files can be found here .
Starting the Grid
The first thing we need to do is to start our grid service. Our grid will contain one instance of a Grid Service Manager (GSM) and 2 instances of Grid Service Containers (GSC). The scripts to run the grid components can be found under the GigaSpaces XAP folder in the bin directory. To run the GSM, execute one instance the gsm script (gsm.bat for Windows or gsm.sh for Linux). To run the GSC, execute two instances of the gsc.bat gsc.bat for Windows or gsc.sh for Linux).
Starting the Grid Browser
Once the grid components are up and running, we can start our grid browser. Run the gs-ui script from the bin directory (gs-ui.bat for Windows or gs-ui.sh for Linux). Click the “Deployments, Details” tab and within a few seconds you may see a visual presentation of our grid service. It should look like this:
Deploy the web application
Now we are ready to deploy our web application. First click on “Launch->SBA Application – Processing Unit…” on the main menu. Then click the “…” button next to the “Processing Unit” and select your WAR file. Type the number 2 in the “Number of Instances” field and the number 1 in the “Per VM” field.
At this point we have two instances of our web application running on two different ports, 8080 and 8081; these ports are configured as default and are numbered according to the number of instances being deployed. However, although we have two running instances it is hardly scalable without load balancing and session stickiness (session affinity). In this section we will have our web application truly scalable in no more than a few easy steps.
First download and install Apache web server. In this demo I used Apache version 2.2.9 which can be downloaded at here .
Our first task is to configure the Apache web server to function as a load balancer. The main idea here is to define some sort of a routing table so Apache will know how to route requests. Two main Apache modules should be enabled and configured; mod_proxy and mod_proxy_balancer.
Change the Apache config file (APACHE_INSTALL_DIR/conf/httpd.conf) as follows:
- Enable modules – mod_proxy.so, mod_proxy_balancer.so, mod_proxy_connect.so, mod_proxy_http.so, mod_rewrite.so, mod_status.so
- Insert the following lines at the end of the httpd.conf file, save the file and restart the Apache web server:
ProxyPass /balancer !
ProxyPass /petclinic balancer://localhost/ stickysession=JSESSIONID nofailover=On
ProxyPassReverse / balancer://localhost
BalancerMember http://localhost:8080/petclinic route=jetty1
BalancerMember http://localhost:8081/petclinic route=jetty2
#define the balancer manager
#define the status manager
Next, create a file called jetty-web.xml in your web application war file under WEB-INF folder and insert the following lines into it. This file tells Jetty to automatically append the instance number, together with the string “jetty”, to the jsessionid parameter, which will take the form of: jsessionid=<session-id>.jetty<instance-number>. GigaSpaces deployment engine will make sure that every deployed instance will have a unique running number:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
The figure below illustrates how Apache load balancing manages sticky-session (session affinity) together with Jetty:
Web requests are directed by the Apache load balancer according to routed parameter (jetty1), which, in turn, was attached to the session id parameter by Jetty and was numbered by GigaSpaces deployment engine.
Now you are ready to scale-out our load-balanced web application. Repeat the above steps of starting the grid up until deploying your WAR file. Should everything go successfully; . As part of the Apache proxy modules functionality, there is also a nice real-time application which allow you monitor real time activity on your web application instances. This tool is especial handy when you have machines with different specs and you want to direct the Apache Load Balancer to distribute requests by weighted factor in real time.
Compared to other solutions
GigaSpaces XAP is a scalable, cost-effective alternative to traditional application servers and unlike traditional application servers, GigaSpaces XAP enables predictable application scalability on-demand. GigaSpaces XAP achieves predictable scalability on-demand by virtualizing all aspects of the application infrastructure: data, messaging, services (business logic) and deployment.
The table below lists the advantages of GigaSpaces XAP versus traditional middleware:
|Seamless Scaling||Scaling is a complex process, requiring changes to code and architecture||Seamlessly integrate with existing development platforms. Scaling is achieved simply by adding application instances on-demand.|
|Predictable Scalability||Doesn’t scale linearly; Consequently, hardware and software capacity is difficult to project leading to over- or under-provisioning||Scales linearly. Hardware and software requirements are predictable allowing just-in-time provisioning|
|Unexpected Loads||Scaling to handle unexpected loads is slow and error-prone, leading to failure (under-provisioning) or waste (over-provisioning)||Simply scales on-demand leading to optimized utilization of resources and peace-of-mind.|
|Complexity||Middleware stack made of multiple tiers that require tight integration. Not only is this expensive and error-prone, it creates a scalability and performance bottleneck.||Middleware runtime that handles data, messaging and services, using a shared clustering and deployment model that can simply scale and recover.|
There are many tweaks and configuration tuning that can be done, which are not covered here, in order to customize the balancer to your needs. However, the main idea should be clear; you can have your web application scaled out almost with no effort at all, in order to meet your heavy traffic requirements. With easier configurations you can also use GigaSpaces SLA in order to have more instances deployed automatically at peak times (the Digg affect).
Now, just as an exercise, try doing the same with WebLogic or WebSphere. I can assure you that even with the clearest manual, it will take you days to have your web application up and running, not to mention that on-demand scaling-out is not supported by any of them. At this point it is also important to mention that GigaSpaces is Amazon EC2 certified, which means that you can deploy your web application on Amazon EC2 cloud, and together with GigaSpaces SLA configuration you can be “virtually” independent of hardware when peak times demands scaling out. Taking into account the cost of such a solution you might have a winning model in your hands.
In my next installment, I will elaborate more about how GigaSpaces SLA works and how to configure it to enable on-demand scaling-out web applications.