Zend Session Clustering facilitates high availability session management in cluster-based environments.
Session Clustering is a PHP session storage mechanism which uses a network of independent daemons running on frontal web servers to store and share sessions across the cluster. Session Clustering is designed to provide a fault-tolerant, high-performing session storage mechanism for PHP clusters, while maintaining linear scalability and ease of setup. It allows maximal re-use of existing hardware, and does not require any additional servers beyond the ones used as frontal web servers. If you have a sticky or semi-sticky load balancer, Session Clustering will work well with it, and in fact will perform even better with higher levels of session affinity. When a server in the cluster fails, or when the load balancer fails to maintain session affinity, the session data will still be available.
Without Session Clustering, session information resides on different servers depending on where your Load Balancer routed incoming requests (at any given time), making continuity between requests difficult to follow.
Enabling Session Clustering...
Architecture
From a high level perspective, Zend Session Clustering is composed of 3 main parts:
-
The Session Clustering Extension (or “mod_cluster“) is a PHP extension enabling the use of Session Clustering as a session save handler. The main role of this extension is to communicate with the locally installed Session Clustering Daemon.
-
The Session Clustering Daemon (SCD) is an external service that runs on each PHP server in the cluster. This daemon is the heart and brain of the Session Clustering system, and is responsible for managing PHP sessions and sharing them across the cluster. The daemons are also responsible for maintaining session redundancy by assigning backup servers for each session. SC Daemons on the cluster communicate with each other directly, without relying on a single management service.
-
The Storage Back-end is a part of the Session Clustering Daemon and this is where sessions are actually stored.
The Session Clustering Extension communicates with the local SCD using a UNIX domain socket where available, or a local TCP connection. The PHP extension does not communicate with any other daemons in the cluster. Session Clustering daemons communicate with each other over TCP for large data transfers using daemon-to-daemon connections, and UDP for sending short control messages to multiple daemons. UDP Broadcast or Unicast may be used, depending on configuration.
High Availability
Each session is saved twice, once on the master (originating) Session Clustering Daemon and one on the master's backup Session Clustering Daemon. This means that in the event that a master server fails, requests are re-routed to the backup Session Clustering Daemon. Once a request is re-routed to the backup Session Clustering Daemon, the Backup Session Clustering Daemon turns into a master Session Clustering Daemon and creates a new backup Session Clustering Daemon. A backup Session Clustering Daemon is chosen based on it activity locating the Session Clustering Daemon with the least amount of sessions and open sockets. In the event that two servers fail session information will be preserved in the backup and can be replicated if requested in its lifetime.
Regarding response time, Session Clustering will not impose more than a 10% performance degradation over the existing session clustering solution (number of session requests per second).
As mentioned earlier, all servers that need to share session information have to be associated to a cluster in Session Clustering Daemon. Session Clustering is also capable of identifying when a fallen server has been recovered and will automatically return the fallen server into service.
