PHP Session Clustering and Load Balancing in the Cloud

By February 19, 2013 HowTo 4 Comments
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

It’s often necessary to extend a PHP application across multiple servers. This is particularly crucial when your business depends on the availability of the application. High availability is necessary to prevent failed transactions, error-filled shopping carts and lost work of your users. Extending the app across multiple servers provides redundancy. This ensures that when one server fails, it doesn’t bring down the entire app. Thus no server will be a single point of failure for the app.

But it’s also important to have a scalable solution. If your application is running on different servers, you want to be able to handle session failover. Redundancy ensures that if one server dies, the remaining servers can take over the work of the dead one. But you also need to be able to add more servers as necessary to avoid overloading those remaining ones. Scalability ensures that this can happen.

Thus ensuring high availability for your app requires the related strengths of redundancy and scalability. And there is only one way to make sure this happens: a solution that adds cluster to cloud. The cluster ensures that no server can be a single point of failure. The cloud ensures that one server failure doesn’t overload the other servers.

Today we will show you how to implement such a setup. In our example, we will use memcached, two Apache servers, and an NGINX load balancer. The main use of memcached is as a distributed caching engine in a multinode environment. But for our purposes, imagine a Web session with sticky sessions running on several app servers. If one server fails, the sessions are stored for backup on a memcached node. Other servers can fetch the sessions from memcached and serve the session from then on.

phpcluster4

Here is how it works: In normal operation, after each session request is completed, the session is sent to a memcached node for backup. When the next request has to be served, the session is still available on the original application server and can be used. After the second request is finished, the session is updated in the memcached node. But if the original server dies, the next request is routed to another application server. The new server is asked for a session it doesn’t know.

When that happens, the new server will look up the session in the memcached node. It knows where to look based on an ID that was appended to sessionID when the session was created. It can then fetch the session from the memcached node. After the server answers the request, it also updates the session in the memcached node. Thus the original server’s failure causes no interruption of the app, and the failover is successfully handled. During this time, an NGINX load balancer is distributing traffic across the cluster containing HTTP resources. You can see load balancing in Jelastic using various load balancing tools. Here’s a detailed tutorial on how to do so. And here is how to use memcached to successfully handle application server failover:

Create an environment

1. Log into the Jelastic Manager.

2. Click the Create environment button:

3. In the Environment topology window choose two or more servers you want to use (for example, two instances of Apache) and Memcached node. Type the name of the environment and click Create.

phpcluster1

In a minute your environment will be created.

cluster2

Configure application servers

1. Click Config button for Apache.

2. In the opened tab go to etc > php.ini

3. Activation of the php memcached module is very simple, just add the following line to the Dynamic Extensions:

extension=memcached.so

phpcluster2

4. Memcached provides a custom session handler that can be used to store user sessions in memcached. A completely separate memcached instance is used for that internally, so you can use a different server pool if necessary. The session keys are stored under the prefix memc.sess.key., so be aware of this if you use the same server pool for sessions and generic caching.

Make these changes in the Session block of php.ini to enable sessions support:

session.save_handler = memcached
session.save_path = "< server >:11211"

memcached_session

Note: < server > is the memcached IP or URL which you can find by clicking Info button for the memcached node in your environment.

5.Save the changes, restart the Apache node, and your app will start using memcached to store the PHP sessions.

This was just a simple example. Actually such scenario is not a silver bullet, but it’s definitely worth knowing about. If one of the instances fails, the users who were on that instance get automatically switched to the other instance in this cluster. Thanks to memcached, end users never notice any change. So forget about all these long manual configurations – now you can get a high availability PHP cluster in a few minutes. Enjoy all the advantages of the cloud!

Feel free to ask any questions!

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

4 Comments

  • [...] PHP Session Clustering and Load Balancing in the Cloud [...]

  • Marek says:

    Ouch, not really. This is still not high available setup, if you memcache goes down – your application can’t access your sessions and your website is down. This method is actually adding another single-point-of-failure to your infrastructure.

    Also, this statement: “In normal operation, after each session request is completed, the session is sent to a memcached node for backup. When the next request has to be served, the session is still available on the original application server and can be used. After the second request is finished, the session is updated in the memcached node.” is not true, at least not if you are using PHP standard memcache module. Session is saved directly into memcache, not as any backup, but as the primary (and only in this setup) replica. Therefore, “session is still available on the original application server” is also amiguous, as its only copy is saved in memcache key/value store, not on the application server itself.

    Please correct me if you are using custom version of memcached module, the above comment is based on http://www.php.net/manual/en/memcached.sessions.php and source code analysis on github (yes, this module can be used for high-available sessions, but not in the way described here).

    • Tetiana Fydorenchyk says:

      Hi Marek,
      Thanks for your feedback and let me react a bit.

      As for Memcached, it is fully isolated from the load (the load is directed to the app servers) and that’s why there is a very little possibility that it will be down.

      As for your statement “Session is saved directly into memcache..,” that is not really so. The sessions are saved in the RAM of the app servers. We tested this and you can check it also by setting the environment with Memcached and Apache. In this case if you disable Memcached the sessions still remain as they are saved in the memory. By the way we do not use any custom versions of memcached module.
      Best regards,
      Tetiana

  • Ben says:

    This is absolutly not a HA setup, for HA you need memcached on multiple servers. If you lose your single memcached node as shown here, you have lost your sessions.

Leave a Reply

Contact Jelastic for More Information CONTACT
%d bloggers like this: