Roms BLOG

Un des principaux problèmes que l’on peut rencontrer lorsque l’on utilise une architecture LAMP dans le cadre d’un site à fort trafic est l’utilisation des sessions sur un cluster de serveurs. En effet, par défaut, chaque serveur gère ses propres sessions sur son disque, l’utilisateur se verra donc attribuer une session différente à chaque fois qu’il sera redirigé par le répartiteur de charge sur un serveur différent du cluster. Plusieurs solutions plus ou moins efficaces permettent de résoudre ce problème. Sans être un expert de ce genre de problématiques, j’ai pu rencontrer plusieurs cas lors de mes différentes missions qui comportent toutes des avantages et des inconvénients.

La première consiste à lier un utilisateur à un serveur donné du cluster. Pour cela, lors de la première page affichée, le système de répartition de charge envoie un cookie à l’utilisateur afin de garder une trace du serveur vers lequel il a été redirigé. Lors des requêtes suivantes, l’utilisateur sera toujours redirigé vers le même serveur et conservera donc sa session. Cette solution bien que très facile à mettre en oeuvre pose plusieurs problèmes.
Premièrement, elle ne fonctionne bien sûr pas si l’utilisateur a désactivé les cookies. En même temps, les sessions ne devraient pas non plus fonctionner sans cookies à moins d’activer le use_trans_sid mais chacun sait que, par défaut, cela entraîne d’importantes failles de sécurité.
Le deuxième vient de la haute disponibilité. En effet, si le serveur sur lequel l’utilisateur a sa session tombe, il sera redirigé vers un autre serveur par le système de répartition de charge et perdra donc toutes les données de sa session courante ce qui peut être très problématique dans le cadre d’un site de vente en ligne par exemple.

Une autre solution va consister à redéfinir le handler (gestionnaire) de sessions afin de le rediriger vers un espace de stockage mutualisé pour les différents serveurs du cluster. Deux grandes possibilités sont généralement utilisées :
–le partage NFS – cette solution consiste à utiliser un serveur accessible en partage réseau et de stocker les sessions de tous les serveurs dessus. Elle est efficace pour de petits clusters mais, à ce que j’ai pu voir, les montées en charge entraînent rapidement des problèmes de lecture sur disque et donc des ralentissements importants de l’application.
– le stockage des sessions en base de données – le principe est très similaire sauf que les sessions sont stockées en base de données. Pour que cette solution soit efficace, il est primordial de dédier ce serveur de base de données uniquement au stockage des sessions. Une telle solution est généralement moins rapide que les sessions natives à cause du temps nécessaire à établir la connexion avec la base de données.

La dernière solution rencontrée est la solution propriétaire proposée par Zend au travers de sa Zend Paltform. Celle-ci dispose d’un module de cluster de sessions qui vient remplacer les sessions natives de PHP et permet aux différents serveurs du cluster de partager leurs sessions. De ce que j’ai pu voir, cette solution est plutôt efficace et stable, le partage des sessions n’induit pas spécialement de différences de temps de réponse avec les sessions natives. Elle est également très facile à mettre en oeuvre, il suffit d’installer la PlatForm, tout est géré automatiquement. Solution la plus professionnelle, elle a malheureusement aussi ses inconvénients.
D’abord le coût de licence de la PlatForm. Celui-ci n’est pas très élevé en regard des services qu’elle fournit mais il s’agit tout de même d’une somme non négligeable. Cette solution très complète de pilotage d’architecture PHP ne peut donc convenir qu’à des projets commerciaux d’une certaine envergure et ne peut pas être utilisée dans le cadre de projets communautaires ou à faibles revenus.
Ensuite, le système de cluster de session n’offre pas de redondance des données (hic!). Pour le moment, les sessions ne sont toujours stockées que sur leur serveur d’origine et partagées au moment de leur appel, donc si un serveur tombe, les sessions qui sont dessus ne sont plus disponibles. D’après une conversation que j’ai eu récemment avec Zeev, des fonctionnalités de redondance devraient rapidement être introduites dans les prochaines versions de la Platform ce qui permettra de résoudre ce problème. Quoi qu’il en soit, il apparaît que cette solution est pour le moment la plus efficace et je pense qu’on devrait rapidement la retrouver sur de nombreux systèmes.

Pour finir, je dirais simplement qu’il est peut être temps que la communauté se penche serieusement sur cette problématique. Si l’on souhaite que PHP s’impose en environnement professionnel, il faut lui en donner les moyens. A ceux qui me diront « Bah t’as qu’à le faire! », je répondrais simplement « J’aimerais bien, mais je n’en ai ni le temps, ni les compétences »

Voilà, trois mois que je n’ai pas posté sur ce blog, trois mois complètement débordé par mon travail et ma vie personnelle; je viens enfin de refaire surface ce matin et de respirer une grande bouffée d’air, ouf…

Comme certains d’entre vous le savent peut être déjà, ZEND a décidé de profiter de cette année 2006 pour s’installer en France. Pour cela, ils ont choisi Anaska/Kaptive comme partenaire pour les formations et les missions de consulting/développement. Pour cela, Guillaume Ponçon, l’auteur du livre Best Practices PHP5 à rejoint notre équipe, ou plutôt va rejoindre notre équipe dés que sa période de préavis sera terminée chez son précèdent employeur.

En attendant, je me suis donc retrouvé à gérer les premières missions ZEND/ANASKA en même temps que mon travail courant, deux audits complets (environnement de dev, environnement de prod, best practices, architecture, infrastructure…) pour deux grands sites Français très connus (je suis toujours en attente de l’accord de ces sociétés pour les citer).

Ces deux missions ont été très enrichissantes pour moi.
D’abord par les intervenants avec lesquels j’ai été amené à travailler : Zeev Suraski, Chuck Hagenbuch (créateur de horde) ou encore Shahar Evron (spécialiste des produits Zend) .

Ensuite par les différents environnements de production que j’ai pu voir; d’un côté, un niveau professionnel très élevé avec plus de 70 serveurs en production, des procédures pointues de gestion et de maintenance; d’un autre côté, un environnement beaucoup plus artisanal avec une équipe obligée de s’adapter à de fortes contraintes budgétaires et n’ayant pas le temps de mettre en oeuvre des procédures évoluées de gestion.
Au final, deux environnements très différents mais permettant dans les deux cas de maintenir un site professionnel de services à destination des internautes soutenant une charge très élevée.
Nous avons émis, lors des deux missions, de nombreuses recommandations leur permettant d’atteindre un niveau d’excellence (quoi mes chevilles?) dans l’environnement de développement et de production PHP.

A part cela, nous avons été invités, Cyril (mon associé) et moi par Microsoft à l’International Technology Summit qui se déroulera à Redmond en Avril. L’occasion pour l’éditeur d’échanger avec des acteurs importants de la communauté Open Source sur leurs positions sous la forme de discussions interactives. Je vous ferai bien sûr un retour sur ce déplacement dés mon retour.

Voilà, il me reste quelques heures de répit avant de repartir en apnée, j’en profite donc pour ranger mon bureau, régler les affaires courantes et si j’ai le temps, mettre à jour WAMP