Partage de sessions cluster Apache/PHP (Sharedance?)
Bonjour à tous, Je suis entrain de revoir le partage de sessions sur un cluster web Debian/Apache/PHP qui actuellement fonctionne de la façon suivante : Filer1 (master) : « Tmpfs de 2 Go » > NFS (vip) > Nodes (Keepalived) Filer2 (slave) : « Tmpfs de 2 Go » > NFS (vip) > Nodes Suite à différentes bascules ça ne fonctionne pas toujours très bien (freeze du montage, ). Je suis entrain de regarder ce quon pourrait faire pour améliorer ça, jai lu pas mal de choses sur Sharedance, je lai testé ça fonctionne plutôt pas mal du tout, mais dur de lévaluer en conditions de prod. De plus il ny a pas de nouvelles versions depuis 2006, traduction cest super fiable/mature ou ce nest plus développé ? Autre question le fait de redéfinir la gestion des sessions dans PHP via un auto_prepend_file, ça ne pose pas de soucis sur certaines applications ? Jai regardé un peu PHPDance qui permettrait de faire de la redondance de Sharedance, pour le moment mes tests ne sont pas très concluants. Si quelquun a une expérience de Sharedance ou une meilleure solution ;) Bonne journée, Benjamin SCHILZ WHD-RS SARL
Le 09/12/2010 09:40, [WHD-RS] Benjamin SCHILZ a écrit :
Bonjour à tous,
Je suis entrain de revoir le partage de sessions sur un cluster web Debian/Apache/PHP qui actuellement fonctionne de la façon suivante :
Filer1 (master) : « Tmpfs de 2 Go » > NFS (vip) > Nodes
(Keepalived)
Filer2 (slave) : « Tmpfs de 2 Go » > NFS (vip) > Nodes
Suite à différentes bascules ça ne fonctionne pas toujours très bien (freeze du montage, ...).
Je suis entrain de regarder ce qu'on pourrait faire pour améliorer ça, j'ai lu pas mal de choses sur Sharedance, je l'ai testé ça fonctionne plutôt pas mal du tout, mais dur de l'évaluer en conditions de prod. De plus il n'y a pas de nouvelles versions depuis 2006, traduction c'est super fiable/mature ou ce n'est plus développé ?
Autre question le fait de redéfinir la gestion des sessions dans PHP via un auto_prepend_file, ça ne pose pas de soucis sur certaines applications ?
J'ai regardé un peu PHPDance qui permettrait de faire de la redondance de Sharedance, pour le moment mes tests ne sont pas très concluants.
Si quelqu'un a une expérience de Sharedance ou une meilleure solution ;)
Bonjour, j'ai créé un billet concernant Sharedance, après avoir testé plusieurs solutions : http://www.duchatelet.net/blog/?post/2008/06/19/Session-PHP%3A-Le-choix ou je le test avec du trafic de prod et des sessions de 1.2Mo au lieu des 3ko habituels. Depuis, il était en prod sur un vieux serveur (le moins puissant qu'on ait). Ce serveur donnant des signes de fatigue, et Sharedance ne consommant vraiment que très peu de ressource, je l'ai déplacé sur un serveur MySQL pour gagner 1A ... Au passage, ma solution est d'avoir un tmpfs pour stocker les fichiers sharedance, un heartbeat entre 2 serveurs, les 2 ayant Sharedance qui tourne. Le heartbeat ne gère qu'une VIP et un cron qui fait un rsync toutes les minutes. Ainsi, en cas de bascule je ne perds que les sessions de la minute en cours... Son principale problème, c'est qu'il ne gère pas les locks, et je crois que c'est le cas de tous les systèmes non natif PHP. Donc si vous avez plusieurs frames, webservices qui modifient la session, il y a des pertes selon le temps d'execution de chaque scripts... Il faut que les dev fassent attention à ça. Ou gérer les locks avec le memcached... Il ne lui manque que ça. S'il n'est plus développé, c'est qu'il fonctionne et n'est pas buggué :) mais il est toujours utilisé pour de gros sites webs (skyblog...) -- Greg
j'ai créé un billet concernant Sharedance, après avoir testé plusieurs solutions : http://www.duchatelet.net/blog/?post/2008/06/19/Session-PHP%3A-Le-choix ou je le test avec du trafic de prod et des sessions de 1.2Mo au lieu des 3ko habituels.
Javais déjà consulté, très instructif dailleurs.
Au passage, ma solution est d'avoir un tmpfs pour stocker les fichiers sharedance, un heartbeat entre 2 serveurs, les 2 ayant Sharedance qui tourne. L heartbeat ne gère qu'une VIP et un cron qui fait un rsync toutes les minutes. Ainsi, en cas de bascule je ne perds que les sessions de la minute en cours... Son principale problème, c'est qu'il ne gère pas les locks, et je crois que c'est le cas de tous les systèmes non natif PHP. Donc si vous avez plusieurs frames, webservices qui modifient la session, il y a des pertes selon le temps d'execution de chaque scripts... Il faut que les dev fassent attention à ça.
Le problème cest que dans notre cas on ne gère pas les applicatifs déployés et il y en a beaucoup
Perso j'avais déjà utilisé memcached. Gros avantage c'est le délai de mise en place. L'inconvénient c'est que si ça prends de la place, il te faut beaucoup de RAM. session.save_handler = memcache session.save_path = "tcp://127.0.0.1:11211" Et c'est réglé. Le 127.0.0.1 dans ton cas devra être le serveur partagé. Je pense que niveau perf tu vas être content. Tu dois faire une petite règle (fw) pour éviter qu'on te squatte ton serveur memcache, mais sinon ça tourne du tonerre. J'ai eu quelques problèmes d'incompatibilité sur des CMS qui veulent forcer leurs méthodes, mais si c'est du fait maison normalement aucun soucis. Le 09/12/2010 09:40, [WHD-RS] Benjamin SCHILZ a écrit :
Bonjour à tous,
Je suis entrain de revoir le partage de sessions sur un cluster web Debian/Apache/PHP qui actuellement fonctionne de la façon suivante :
Filer1 (master) : « Tmpfs de 2 Go » > NFS (vip) > Nodes
(Keepalived)
Filer2 (slave) : « Tmpfs de 2 Go » > NFS (vip) > Nodes
Suite à différentes bascules ça ne fonctionne pas toujours très bien (freeze du montage, …).
Je suis entrain de regarder ce qu’on pourrait faire pour améliorer ça, j’ai lu pas mal de choses sur Sharedance, je l’ai testé ça fonctionne plutôt pas mal du tout, mais dur de l’évaluer en conditions de prod. De plus il n’y a pas de nouvelles versions depuis 2006, traduction c’est super fiable/mature ou ce n’est plus développé ?
Autre question le fait de redéfinir la gestion des sessions dans PHP via un auto_prepend_file, ça ne pose pas de soucis sur certaines applications ?
J’ai regardé un peu PHPDance qui permettrait de faire de la redondance de Sharedance, pour le moment mes tests ne sont pas très concluants.
Si quelqu’un a une expérience de Sharedance ou une meilleure solution ;)
Bonne journée,
Benjamin SCHILZ
WHD-RS SARL
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut Benjamin, Personnellement j’ai déjà testé Memcached + repcached qui fonctionnait pas mal. http://memcached.org/ http://repcached.sourceforge.net/ Le principe, tu mets un daemon sur 2 serveurs (au choix sur les frontaux PHP ou sur les back MySQL) et tu mets en place une réplication croisée entre les 2. Tu fais ensuite pointer tes sessions PHP sur les 2 serveurs memcached. En revanche, pas de nouvelle version de repcached depuis pas mal de temps. Le support s’est arrêté à la version 1.2 de Memcached. Enfin, quelque soit la solution choisie, tu sera toujours embêté par les framework PHP qui redéfinissent eux même la gestion des sessions. Et il y en a pas mal qui le font… Florian From: frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] On Behalf Of [WHD-RS] Benjamin SCHILZ Sent: Thursday, December 09, 2010 9:41 AM To: frsag@frsag.org Subject: [FRsAG] Partage de sessions cluster Apache/PHP (Sharedance?) Bonjour à tous, Je suis entrain de revoir le partage de sessions sur un cluster web Debian/Apache/PHP qui actuellement fonctionne de la façon suivante : Filer1 (master) : « Tmpfs de 2 Go » > NFS (vip) > Nodes (Keepalived) Filer2 (slave) : « Tmpfs de 2 Go » > NFS (vip) > Nodes Suite à différentes bascules ça ne fonctionne pas toujours très bien (freeze du montage, …). Je suis entrain de regarder ce qu’on pourrait faire pour améliorer ça, j’ai lu pas mal de choses sur Sharedance, je l’ai testé ça fonctionne plutôt pas mal du tout, mais dur de l’évaluer en conditions de prod. De plus il n’y a pas de nouvelles versions depuis 2006, traduction c’est super fiable/mature ou ce n’est plus développé ? Autre question le fait de redéfinir la gestion des sessions dans PHP via un auto_prepend_file, ça ne pose pas de soucis sur certaines applications ? J’ai regardé un peu PHPDance qui permettrait de faire de la redondance de Sharedance, pour le moment mes tests ne sont pas très concluants. Si quelqu’un a une expérience de Sharedance ou une meilleure solution ;) Bonne journée, Benjamin SCHILZ WHD-RS SARL
Salut Benjamin, Salut
Je répond aux autres remarques en même temps ça évitera de vous spammer ;) Pour redéfinir un peu le contexte on ne maitrise pas du tout les applicatifs déployés, ça va du PHP maison au gros framework en passant par les CMS ... Les sessions sont relativement critiques et je ne souhaite pas créer un SPOF sur le réseau. La volumétrie est d'environ 1/2 million de sessions en période de pointe.
Personnellement j’ai déjà testé Memcached + repcached qui fonctionnait pas mal. Pas mal effectivement notamment sur la gestion de la réplication, car PHPDance avec ShareDance ça me semble pas mal buggé.
Enfin, quelque soit la solution choisie, tu sera toujours embêté par les framework PHP qui redéfinissent eux même la gestion des sessions. Et il y en a pas mal qui le font…
Le problème est la je pense, dans un environnement ou on ne maitrise pas du tout l'applicatif déployé, la seule solution potable est d'utiliser la solution traditionnelle des fichiers à plat avec de la bidouille éventuellement (nfs sur tmpfs ...) ?
Le problème est la je pense, dans un environnement ou on ne maitrise pas du tout l'applicatif déployé, la seule solution potable est d'utiliser la solution traditionnelle des fichiers à plat avec de la bidouille éventuellement (nfs sur tmpfs ...) ?
Il n'y a pas grand-chose à faire contre ceux qui réécrivent leur propre mécanisme de session. Même avec nfs sur tmpfs, tu ne te prémunies pas contre ceux qui écrivent leur sessions dans un répertoire local au site web. Il me semble, par exemple, que le framework CodeIgniter à un système bien à lui de gestion des sessions à base de cookie uniquement. L'exemple n'est pas bon car dans ce cas cela ne cause aucun problème, mais c'est pour montrer qu'on trouve de tout comme pratique en la matière. Peut-être que tu devrais commencer par regarder quels sites redéfinissent la variable "session_set_save_handler" dans leur code et considérer qu'en mettant en place memcached + repcached de manière générique sur tes serveurs, tu protège plus de XX% de tes clients et tu soulages ton serveur NFS. Et tant pis pour ceux qui redéfinissent leur propre mécanisme de gestion des sessions. Sinon, tu peux essayer d'interdire l'utilisation de "ini_set()" avec le paramètre "disable_functions". C'est un peu sauvage, je te l'accorde :) Florian
Personnellement : tous nos clusters fonctionnent à base de Memcache avec Repcached pour répliquer les données, si y a un soucis, bascule sur l'autre Memcache qui est en passif. En ce qui concerne les clients qui veulent écrire dans le répertoire local : ils le feront quoi qu'il advienne, la seule solution serait de mettre le sticky en place sur la session de l'utilisateur qui se connecte au serveur, de la sorte il a toujours la même session en cours et ça résout tous les problèmes de stockage car au final on veut juste que l'utilisateur ait accès à ses données de session, peu importe le storage qui est derrière. On peut aussi envisager de regarder du côté de GlusterFS sur un TmpFS. Ca permet d'avoir du répliqué, juste un peu lourd à installer ... Lilian Le 09/12/10 11:02, Florian Coulmier a écrit :
Le problème est la je pense, dans un environnement ou on ne maitrise pas du tout l'applicatif déployé, la seule solution potable est d'utiliser la solution traditionnelle des fichiers à plat avec de la bidouille éventuellement (nfs sur tmpfs ...) ?
Il n'y a pas grand-chose à faire contre ceux qui réécrivent leur propre mécanisme de session. Même avec nfs sur tmpfs, tu ne te prémunies pas contre ceux qui écrivent leur sessions dans un répertoire local au site web. Il me semble, par exemple, que le framework CodeIgniter à un système bien à lui de gestion des sessions à base de cookie uniquement. L'exemple n'est pas bon car dans ce cas cela ne cause aucun problème, mais c'est pour montrer qu'on trouve de tout comme pratique en la matière.
Peut-être que tu devrais commencer par regarder quels sites redéfinissent la variable "session_set_save_handler" dans leur code et considérer qu'en mettant en place memcached + repcached de manière générique sur tes serveurs, tu protège plus de XX% de tes clients et tu soulages ton serveur NFS. Et tant pis pour ceux qui redéfinissent leur propre mécanisme de gestion des sessions.
Sinon, tu peux essayer d'interdire l'utilisation de "ini_set()" avec le paramètre "disable_functions". C'est un peu sauvage, je te l'accorde :)
Florian
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Personnellement : tous nos clusters fonctionnent à base de Memcache avec Repcached pour répliquer les données, si y a un soucis, bascule sur l'autre Memcache qui est en passif.
Je vais faire un test de cette solution, le mécanisme failover de repcached a l'air très efficace et ça évite la surcouche keeepalived/nfs/... Merci pour vos conseils ;)
Le Thu, Dec 09, 2010 at 03:20:59PM +0100, [WHD-RS] Benjamin SCHILZ:
Personnellement : tous nos clusters fonctionnent à base de Memcache avec Repcached pour répliquer les données, si y a un soucis, bascule sur l'autre Memcache qui est en passif.
Je vais faire un test de cette solution, le mécanisme failover de repcached a l'air très efficace et ça évite la surcouche keeepalived/nfs/...
Merci pour vos conseils ;)
mais c'est deja une surcouche!:p Tu devrais aussi tester Redis qui inclut du master/slaves.
Le 10 décembre 2010 04:20, eldre8 <eldre-m@afturgurluk.org> a écrit :
mais c'est deja une surcouche!:p Tu devrais aussi tester Redis qui inclut du master/slaves.
Bonjour, D'autant plus que l'extension phpredis (https://github.com/owlient/phpredis) possède dorénavant un session_handler transparent, "à la memcache". Bonne journée. -- Guillaume Plessis
Très bon produit Redis : rapide + les données sont persistantes. +1 pour la solution. Le 10 déc. 2010 à 07:54, Guillaume Plessis a écrit :
Le 10 décembre 2010 04:20, eldre8 <eldre-m@afturgurluk.org> a écrit :
mais c'est deja une surcouche!:p Tu devrais aussi tester Redis qui inclut du master/slaves.
Bonjour,
D'autant plus que l'extension phpredis (https://github.com/owlient/phpredis) possède dorénavant un session_handler transparent, "à la memcache".
Bonne journée.
-- Guillaume Plessis _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Je préconise cette solution :) mais comme on partait sur du Memcached ;) Je vais, je pense, sou peu tester le client redis, on va voir ce que ça donne :) Le 10/12/10 08:43, JF Bustarret a écrit :
Très bon produit Redis : rapide + les données sont persistantes.
+1 pour la solution.
Le 10 déc. 2010 à 07:54, Guillaume Plessis a écrit :
Le 10 décembre 2010 04:20, eldre8 <eldre-m@afturgurluk.org <mailto:eldre-m@afturgurluk.org>> a écrit :
mais c'est deja une surcouche!:p Tu devrais aussi tester Redis qui inclut du master/slaves.
Bonjour,
D'autant plus que l'extension phpredis (https://github.com/owlient/phpredis) possède dorénavant un session_handler transparent, "à la memcache".
Bonne journée.
-- Guillaume Plessis _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, J’ai testé la solution et ce n’est pas très concluant ;) Côté REDIS Server : - La réplication est effectivement très simple à mettre en place (master/slave), par contre en cas de panne du master passer le slave en master puis gérer la remise en ligne de l’ancien master n’est pas évidente, pas documentée, et pas très fiable au niveau de la cohérence des données. Côté PHPRedis : - Le session_handler est complètement bugué , la « doc » précise qu’on peut faire une configuration multi-serveurs de la manière suivante : session.save_path = "tcp://host1:6379?weight=1, tcp://host2:6379?weight=2, tcp://host3:6379?weight=2" Le code source nous apprend qu’on peut aussi ajouter un paramètre timeout, mais dans tous les cas ça ne fonctionne pas. Avec un poids identique, seul un serveur est contacté... Avec un poids différent, un seul serveur est contacté, et si il ne répond plus même après le timeout le deuxième n’est jamais contacté et les sessions ne fonctionnent plus. Solution utiliser un seul serveur via une VIP, mais on en revient aux problèmes de REDIS Server. - Lors de la création d'une session aucun paramètre d'expiration n'est placé (via EXPIRE ou SETEX au lieu de SET), la session n'expire donc jamais... et impossible ensuite de savoir depuis combien de temps elle est la. En conclusion ça me semble encore jeune comme projet et pas prêt pour la prod. Bonne journée, De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Guillaume Plessis Envoyé : vendredi 10 décembre 2010 07:55 À : French SysAdmin Group Objet : Re: [FRsAG] Partage de sessions cluster Apache/PHP (Sharedance?) Le 10 décembre 2010 04:20, eldre8 <eldre-m@afturgurluk.org> a écrit : mais c'est deja une surcouche!:p Tu devrais aussi tester Redis qui inclut du master/slaves. Bonjour, D'autant plus que l'extension phpredis (https://github.com/owlient/phpredis) possède dorénavant un session_handler transparent, "à la memcache". Bonne journée. -- Guillaume Plessis
Salut Benjamin,
J’ai testé la solution et ce n’est pas très concluant ;)
As-tu essayé la solution Memcached ?
Côté REDIS Server : - La réplication est effectivement très simple à mettre en place (master/slave), par contre en cas de panne du master passer le slave en master puis gérer la remise en ligne de l’ancien master n’est pas évidente, pas documentée, et pas très fiable au niveau de la cohérence des données.
Avec Memcached, tu peux te placer dans la configuration suivante : - Serveur A, avec memcached actif en maître et réplication sur le serveur B avec repcached. - Serveur B, avec memcached actif en maître et réplication sur le serveur A avec repcached. Ensuite, le session_handler te permet de spécifier 2 serveurs Memcached, celui du serveur A et celui du serveur B. Ainsi, en cas de perte d'un serveur, pas de problème. Le session_handler désactive automatiquement le memcached inactif, et toutes les sessions sont bien enregistrées dans celui qui reste actif. Lorsque le memcached tombé revient en activité, repcached réplique automatiquement toutes les sessions pour le remettre à niveau. Solution déjà testée en production et fonctionnelle (après quelques galères et tests quand même). ++ Florian
C'est ce que l'on utilise sans soucis, par contre on met une VIP dessus car Repcached on lui fait pas trop confiance en terme de concurrence des accès aux clés ... Lilian Le 15/12/10 15:04, [WHD-RS] Benjamin SCHILZ a écrit :
Salut,
As-tu essayé la solution Memcached ? Je suis entrain de tester memcached/repcached et effectivement la réplication croisée est pas mal du tout. D'autant que la partie cliente dans PHP semble très fiable. Je continue mes tests ;)
A+
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 9 déc. 2010 à 09:40, [WHD-RS] Benjamin SCHILZ a écrit :
Je suis entrain de regarder ce qu’on pourrait faire pour améliorer ça, j’ai lu pas mal de choses sur Sharedance, je l’ai testé ça fonctionne plutôt pas mal du tout, mais dur de l’évaluer en conditions de prod. De plus il n’y a pas de nouvelles versions depuis 2006, traduction c’est super fiable/mature ou ce n’est plus développé ?
Si quelqu’un a une expérience de Sharedance ou une meilleure solution ;)
Le critère numéro un est déjà de savoir quel degré de fiabilité doivent avoir tes sessions : critique (ex : panier de commerce électronique) ou basse (cache de données utilisateur stockées en base, CAPTCHA occasionnel). De mon côté, je ne gère quasiment que du basse criticité, et je stocke ça généralement dans du memcached. - parce qu'on connait ça, et qu'on a du memcached par ailleurs (même si cela peut être intéressant de ne pas mutualiser les démons avec ceux qui gèrent du cache). - parce que c'est méga performant, - parce que c'est vraiment bien maintenu, - parce que le client est en C (et non en PHP pur). L'inconvénient est que, par défaut, memcached stocke ses sessions en RAM et, s'il a besoin de mémoire, peut virer des sessions (=> bien dimensionner sa RAM). Pour garantir la dispo de tes sessions, il est toujours possible de mettre en place de la réplication (duplication des sessions sur plusieurs serveurs) et de mettre en place de la persistance sur le serveur (via par ex le fork memcachedb). Sharedance ne m'a jamais emballé, d'une part pour la maintenance. Mais c'est utilisé par Skyblog, qui est quand même un gros site, et sans doute bien développé (par Frank Denis, auteur aussi de pureftpd). Ceci étant dit, le fait qu'il n'y ait pas de mise à jour peut aussi vouloir dire que le soft n'a pas de bug... La deuxième raison étant que le client est (était quand j'avais regardé) en PHP pur. JFB
participants (8)
-
[WHD-RS] Benjamin SCHILZ -
eldre8 -
Florian Coulmier -
Greg -
Guillaume Plessis -
JF Bustarret -
Lilian RIGARD - Devclic -
ml＠admin-serv.net