High Availability with Zend ServerRead the white paper: "Session Clustering in PHP" »
In order to provide a truly highly available PHP application, you need to distribute it across a cluster of multiple servers, ensuring that a given server isn't a single point of failure. Redundancy is a significant aspect of high availability, and Zend Server helps make it easy to scale your application across a cluster.
However, redundancy and failover are not enough by themselves. When one of the servers in a cluster fails, the PHP sessions stored on that machine must be available to the other servers. Otherwise, the end-user may find their transactions broken, their shopping carts empty, or their work lost. Obviously, this is unacceptable for a highly available application.
Zend Server provides built-in PHP session clustering capabilities that are optimized for business-critical applications. Should a different server handle a given user's requests, the session will seamlessly fail over, and the end-user won't see any degradation of service.
How Zend Session Clustering Works
Each new PHP session is stored in two locations: a master server and a backup server. When a new session is created, the server on which the request to start a new session was received is designated as the master, and the session clustering daemon will find a backup server by picking the least-loaded server in the cluster.
The internal identification of both the master and backup server is encoded into the Session ID given to the user. This allows each server in the cluster to find both the master and the backup servers by simply looking at the Session ID token provided by the client, and there is no need to perform any hash-table lookups or querying in some central database (as is necessary in some other session clustering techniques, which can have consequences for both speed and scalability).
Should a future request be handled by a server that is neither the master nor the backup – whether due to load balancing or to machine failover – the Session ID identifies to that new server where to look for the session data. If the master is available, then the session data is made available to the new server. If the master is not available, the session data will be requested from the backup, and the backup then re-designates itself as the master and picks a new backup.
Scaling and High Availability
Session Clustering was designed with transparent, linear scalability in mind. As you add new servers to the cluster, your capacity for linearly handling additional sessions grows. Zend Server takes care of updating configuration on all cluster members, so that they are made aware of the new server. Traffic coming in to the new server will create new sessions, and the algorithm used for selecting backup servers will ensure that session load distribution between all servers will eventually (and usually within minutes) become even.
Scaling down following a high-traffic period is just as easy, as Zend Server provides a graceful shutdown mechanism. When a server is removed from the cluster, it will find and designate one of the other members of the cluster as a replacement server, and will transfer all active sessions to that server. During this time the server being removed will no longer accept new sessions. After the transfer is complete (this process normally takes between a few seconds to a minute, depending on the storage backend, number of sessions and network throughput), the removed server will notify all cluster members that it has been replaced.
Read the white paper: "Session Clustering in PHP" »