Dans cet article


Offres d'emploi

Tags

Réplication de sessions PHP d’une application distribuée (cluster PHP) par un filesystem NFS

Réplication de sessions PHP d’une application distribuée (cluster PHP) par un filesystem NFS

Description du problème d’un cluster PHP pour la réplication de session

Dans le cas ou vous avez une application PHP répliquée sur deux ou plus serveurs d’un cluster avec en amont un load balancer (NGINX par exemple) qui redistribue la charge de manière uniforme sur les noeuds (serveur, ou VM), vous pouvez avoir des problèmes pour répliquer les sessions PHP.

Le problème est que lorsque vous créé une session en PHP, PHP crée un fichier de la forme sess_**. Ce fichier sert de stockage de session, malheureusement si vous avez plusieurs serveurs, ce fichier n’est pas répliqué entre les noeuds du cluster.

Par exemple, lors d’un formulaire de connexion si vous stockez dans la session de l’utilisation des informations, lors de la réactualisation de la page, il se peut et il est fort probable que votre loadbalancer vous envoi sur un autre noeud ou ne se trouve pas votre session, le traitement ne fonctionne plus car PHP ne retrouve plus les variables de session.

Comment résoudre le problème?

Une solution efficace si votre système n’est pas trop chargé est de partager un répertoire entre vos différents noeuds du cluster et ainsi de répliquer les sessions PHP (fichier sess_****).

Nous allons voir comment procéder.

Pré-requis:

Posséder deux noeuds du cluster et un serveur de fichier (une simple machine virtuelle peut faire l’affaire).

L’objectif est de monter un répertoire du serveur de fichier vers les deux noeuds du cluster et de forcer PHP à écrire dans ce répertoire les sessions.

Créer un serveur de fichier pour les sessions PHP (avec NFS)

Le plus simple est de monter un serveur de fichier NFS.

Installer un serveur nfs sur debian se fait avec la commande:

apt-get install nfs-kerner-server

Créer le répertoire ou vont être stocké les sessions:

mkdir /home/session_php/

Ouvrer le fichier /etc/exports

vi /etc/exports

Rajouter une ligne pour activer le partage du répertoire php_session, par exemple comme ceci. Ici nous partageons le répertoire pour tous les serveurs du sous réseau 192.168.100.0/24 (tous les noeuds du cluster)

/home/session_php 192.168.100.0/24(rw,sync,no_all_squash,anonuid=1000,anongid=1000,no_root_squash)

Redemarrer le serveur NFS:

/etc/init.d/nfs-kernel-server restart

C’est tout pour le serveur

Sur chaque noeud du cluster PHP

Créer le répertoire de montage

mkdir /php_session/

Monter le répertoire réseau:

Editer le fichier /etc/fstab

vi /etc/fstab

Rajouter une ligne comme ceci (en changeant l’adresse ip par celle de votre serveur de l’étape 1)

192.168.100.21:/home/session_php /session_php nfs defaults,user,auto,noatime,intr,rw 0 0

Pour monter le fichier fstab vous pouvez effectuer

mount -a

Editer votre fichier php.ini

vi /etc/php5/apache2/php.ini

et rajouter la ligne:

session.save_path = "/session_php/"

Redémarrer votre apache

/etc/init.d/apache restart

Attention, il faut s’assurer que l’utilisation du apache existe et a les droits d’écriture sur le serveur de fichier. Par exemple www-data est bien le droit d’écriture sur le serveur NFS dans le répertoire /home/php_session/. NFS se basant sur le nom des utilisateurs ainsi que leurs GUID, il faut donc vérifer dans /etc/shadow.

C’est tout!

Vous pouvez voir les sessions se créer dans le répertoire /sessions_php/ et être corretement synchronisées entre les différents neouds du cluster.

L'équipe AXOPEN

Voir aussi les articles suivants

Introduction Lorsque l’on installe un environnement Planisware Server en cluster (plusieurs Intranet Servers) connecté à un schéma de base de données Oracle il est utile de vérifier que la base Oracle est bien configurée pour ce type de fonctionnement. En particulier lorsque l’on a un nombre important d’Intranet Server démarrés il faut vérifier que le nombre maximal de sessions autorisées sur la base de données est bien paramétré. Services Planisware et interactions avec la base de données
Lire l'article

HaProxy: JBoss EAP 6.1 et MySql Réplication

HaProxy: JBoss EAP 6.1 et MySql Réplication

Le 28/08/2013 par Pierre Liseron

Lors de l’utilisation de HAPROXY vers deux Mysql en master/slave, lors de l’arrêt d’un des deux serveurs Mysql, le serveur JBoss n’arrive pas à se reconnecer à la base de données. Etudions ici la configuration, l’installation de Haproxy et de JBoss. Versions utilisées: JBoss EAP 6.1 Mysql 5.5 Configuration de HAPROXY Dans cette configuration, nous utilisons une réplication entre un Mysql Master et un Slave. L’idée est d’avoir un failover lors de la chute du master vers le server de backup, ici le 192.
Lire l'article

Jboss 7 : Industrialisation part 1 – Cluster

Jboss 7 : Industrialisation part 1 – Cluster

Le 28/12/2012 par Pierre Liseron

Automatisation de l’installation d’un node JBOSS 7 dans un cluster Ajout du node Par exemple l’ajout d’un node sur un cluster peut être rapidement réalisé avec un script: Voici un script qui permet de télécharger directement un nouveau JBOSS 7.1, d’installer et de configurer l’instance pour se connecter au master avec son nom et son mot de passe. Les sed sont ici présent pour correctement paramètrer l’instance sans aller modifier le fichier host.
Lire l'article