Session Clustering

Contents:

Session Clustering Statistics

Session Clustering Storage Models

Session Clustering Settings

Defining Storage Models

The Importance of Session IDs

Fine Tuning Session Clustering

 

 

The Session Clustering module is designed to provide a highly scalable solution for synchronizing session data across a cluster of PHP servers. This means that PHP implementations that were not originally designed with scalability in mind, can now grow beyond a single server, to a Web Cluster.

The Session Clustering module is applied to your servers and nodes through the installation process and immediately begins to work transparently.

With Zend Platform users can define Session Clustering Settings and view Session Clustering Statistics.

What is Session Clustering?

Sessions "reside" on the machine on which they were first created. Later on, sessions are delivered from one machine to another, following requests from alternate servers to the original server. This solution is fully distributed and delivers high performance and scalability.

The session clustering module is intended for PHP applications in clusters dealing with heavy loads. This module addresses the focal point of best practices - PHP development with the intent to elevate concerns over corruption of session data and erratic application behavior.

The Session Clustering module provides a comprehensive solution for synchronizing session data across a cluster. In this module the sessions that "reside" on the server where they were first created are subsequently, delivered to other servers in the cluster. This is done by having the alternate server, request the session data from the original server. This means a fully distributed solution - delivering high performance, linearly scalable solution utilize existing hardware investment, while ensuring the ability to continue growing.

The figure below illustrates the session clustering module components:

sc_architecture.jpg

  SC Architecture

The Session Clustering module employs strong locking and data integrity mechanisms to ensure that sessions are never corrupted. Session Clustering is also tunable with two different session storage models: write through or delayed write, allowing organizations to choose their preferred storage model.

 

The Session Clustering module can be integrated into any existing PHP application that uses PHP’s native session extension - without changing any code. Session Clustering implements a native PHP session module, and switching between the existing solution and session clustering is simply a matter of changing a PHP.INI directive.

Important Note:

When deploying SC in an organization it is forbidden to change the Session ID for any reason and in any way (such as using the PHP function session_id() ).

Cluster Configuration

In a cluster configuration the SCD issues UDP broadcast messages every 30 seconds (mod_cluster.ha.broadcast_delta). Each message contains the following information:

 

msg ID

protocol ID

sender's ID

sender's port

sender's load

payload size

payload

32bit

32bit

32bit

32bit

32bit

32bit

optional

 

In general, there should be 3 ports of interest when configuring the Session Clustering:

  1. TCP port for inbound connections - mod_cluster.network.tcp_port_remote [34567]

  2. UDP port for broadcasts - mod_cluster.ha.udp_port (no relation to HA whatsoever) [45678]

  3. TCP port for the Messenger to connect to the SC daemon - mod_cluster.message_server_port

The Node should be set correctly by hostname: mod_cluster.network.hostname, and the proper IPs or IP Mask should be added to the allowed hosts in: mod_cluster.allowed_hosts.

There are four reasons behind cluster node communications in a cluster:

  1. TCP: Relaying a Session (RelayNode -> MasterNode)

  2. TCP: Relaying a Session to Backup (RelayNode -> MasterNode) if the Master does not responded properly (HA only).

  3. TCP: Sending a notification that a Session has been changed to Backup (RelayNode -> BackupNode) (HA only).

  4. UDP: "I am alive" broadcasts with load statistics (a backup is selected by Master automatically from the minimally loaded host).

Adding New Servers to the Session Clustering Environment

The following procedure describes how to add a new server to a Session Clustering environment in order to enable session sharing in a cluster.

 

 

Instructions on how to complete a procedure

To make sure that a new server will share session information:

  1. Add the new server by installing the node installation on the server

  2. Configure the new server in the Central Server (through Platform Administration in Platform | Cluster Management | Manage Servers) to be a member of the required group.

  3. If you are reallocating an existing server to a different Group, un-attach the server from its existing group and then add it to the new group.

Session Clustering will be applied to the added server.

Session Clustering and HA (High Availability)

HA is a solution that uses the SC infrastructure to provide availability and continuity of mission critical business applications.

Session Clustering HA (High Availability), is an additional safety layer for maintaining session information integrity in Web cluster environments. HA ensures that sessions will be serviced in case of a single failure.

Session Clustering HA provides all the current Session clustering functionality and is an optional feature for environments that require High Availability.

Note:

As an additional functionality layer, running HA may have a slight impact on performance in comparison to regular session clustering response time.

About HA

The HA layer preserves session information when a server fails. Each session is saved twice, once on the master (originating) SCD and one on the master's backup SCD. This means that in the event that a master server fails, requests are re-routed to the backup SCD. Once a request is re-routed to the backup SCD, the Backup SCD turns into a master SCD and creates a new backup SCD. A backup SCD is chosen based on it activity locating the SCD 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, the HA layer 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 nodes that need to share session information have to be associated to a cluster in Zend Platform (Grouped). The HA layer is also capable of identifying when a fallen server has been recovered and will automatically return the fallen server into service.