February 16, 2006

Why you need a cluster

Posted in Software at 14:37 by Graham King

If your live web application has more than a couple of users, and they don’t both sit right next to you, you need to cluster it. This is not for performance reasons - a single server can easily cope with the load on most web applications. It is not even for reliability reasons - problems are most likely to be in the application code which runs on all cluster members, than in the infrastructure. You need to cluster for upgrade and maintenance reasons.

Cluster for manageability

A dispatcher should sit on your public web address, and proxy requests to one of many (most likely two) back end servers. When you need to release a new version of your application, upgrade your server, or even your hardware, you can take that server out of the cluster. Once the server is upgraded, it goes back in the cluster and the other one comes out.

Sticky sessions instead of session clustering

If your application does not use sessions, you can let the proxy choose a different back end server for each request. If you have sessions, you could replicate the session. This means the back end servers communicate to share session data. This can be done via the database or via sockets or shared memory. This is complex to setup and slows your application. Much easier and faster is sticky sessions. A good proxy allows you to pin each session to a server, so that one users stays on one server for the duration of their session.

Front end dispatcher software

Other benefits

  • You won’t have to get out of bed if one of the servers goes down

  • Get the proxy to take care of https, meaning your back end servers don’t need to.

  • You can do last minute testing by taking a server out of the cluster, releasing the new version of your application to it, and browsing straight there to test. It’s a live, private server !

  • You can tell the security officer that your application server is not directly accessible from the outside world.

  • For extra credit, you can setup a backup proxy to do IP address takeover if your proxy goes down, using Heartbeat. Example here

    Happy clustering !

February 15, 2006

Goodbye mod_jk hello mod_proxy

Posted in Software at 14:18 by Graham King

I've been using Apache as a front end to a cluster of Tomcat servers for a while. I've always used mod_jk2 or mod_jk; I even wrote an article about it. Not any more.

The most recent Apache comes with mod_proxy, mod_proxy_balancer and mod_proxy_ajp, which do everything I used mod_jk to do.

Setup mod_proxy_balancer

First you need to make sure they are included when you compile Apache:


     ./configure --prefix=/usr/local/apache2.2 --enable-proxy --enable-proxy-ajp --enable-proxy-balancer --enable-proxy-http

Then in your httpd.conf you need:


    <Proxy balancer://myCluster>
       BalancerMember ajp://bill.darkcoding.net:8101 route=server1
       BalancerMember ajp://ben.darkcoding.net:8102 route=server2
    </Proxy>
 
    <Location /myApp>
        ProxyPass balancer://myCluster/myApp stickysession=JSESSIONID
    </Location>
 
    <Location /balancer-manager>
            SetHandler balancer-manager
 
        AuthType Basic
        AuthName "Cluster manager "
        AuthUserFile /usr/local/apache2.2/conf/.htpasswd
        Require valid-user
 
    </Location>

The above defines a cluster and adds your two servers to it. Then it proxies your app location using that cluster. Finally it defines a URL for the balancer manager. This is the replacement for jkmanager. The stickysession value needs to be the name of the session url param name or cookie. The above is correct for Tomcat. Note that the session id is case sensitive.

Finally in you Tomcat server.xml you need to include a jvmRoute to match the route defined above. This is exactly the same as when using mod_jk, so you probably already have it. It should look somewhat like this:

   <Engine name="Catalina" defaultHost="localhost" debug="0" jvmRoute="server1">

and similarly for server2.

Eh voila !

If it's not working change your LogLevel in httpd.conf to debug and restart Apache. If you get this error:

Found value (null) for stickysession JSESSIONID

then Apache is not finding your route on the session id. Check the spelling and capitalisation of the stickysession entry. Using the Firefox developer toolbar to check you Cookie. It should look something like JSESSIONID=4f39cBLAH.server1. The route is appended to the session id after a period.

There is also apparently a problem with disabled servers coming back to life. See this thread

Happy proxying !

February 1, 2006

Javascript and PHP credit card generator

Posted in Credit card, Software at 22:39 by Graham King

I have ported the credit card number generator to PHP and Javascript. The files can be found in the same ZIP as the original Python program.

Go here or follow the link under Pages on the right.

Next entries »