This really depends on what you mean by cluster and what your aim is in clustering it. For web applications the most common reasons are spreading load or high availability, so I'll base my answer on assuming you want one of those.
Spreading load
To spread load among multiple machines, the easiest way is to move your datastore (database, memcache etc...) to a different machine. If that does not help enough, you need 2 more servers: one to be a copy of your appserver and one to be a loadbalancer, balancing the load among two appservers.
Redundancy
If your aim is high availability, you need a clustered datastore (such as mysql cluster) and something like pacemaker/corosync to keep your service's IP available at all times on one of two boxes.
Combining the two
The 'spreading load' setup also provides basic high availability, you can lose an appserver and the service will remain up. For better availability, you would cluster the loadbalancers, and maybe the datastore too.
Summary
This is only a very small set of things you can do. 'Clustering' in itself is not a target, but a means to an end. What is it you actually want to achieve?