Imaginons une webfarm. Plusieurs serveurs Web distribuant le même contenu. Comment garder la même session d'un serveur à l'autre ? Car l'utlisateur "basculera" forcement d'un serveur à un autre.
PHP étant la technologie qui nous interesse ici (et souvent la plus utilisée pour délivrer du contenu dynamique sur le Web actuellement), a déja tout prévu: session_set_save_handler() [1].
Avec cette fonction il est possible de redefinir le comportement des sessions. C'est donc très pratique pour avoir sa petite gestion personnalisée.
La solution qui vient en premier à l'esprit (enfin c'était mon cas) est le stockage dans une base MySQL [2]. Ca semble être un moyen efficace et relativement simple à mettre en place. D'après le WP de chez MySQL c'est LA solution à tout nos problemes: performance, evolutivité, efficacité, coùt, sécurité, etc ... c'est presque la perfection absolue.
Je suis en accord avec un certains nombre de points: coùt, évolutivité (c'est un point tres important, car il faut penser à pouvoir peut être plus tard à faire une ferme de serveur de session), facilité de mise en place et d'utilisation. La sécurité est relativement simple, même si il semble possible de vérouiller quelques points avec les droits et ACM de MySQL. On nous tartine aussi un petit coup sur les procédures stockées de MySQL 5.0.
Mais au final, ca sent quand même la plaquette de vente. C'est le but, évidement. Même si le systeme reste alléchant.
Mais pourquoi exist-il alors d'autres solutions ?
Une d'elle est mcache [3]. Lui aussi nous promet un fonctionnement simple, une efficacité maximale et bien plus de souplesse que ne le permet le stockage simple dans une BDD. Il sait le faire si l'on le souhaite, en parrallèle pour évidement ne pas tout perde si la machine reboot ou etc ... On apprécira le fait qu'il gère avec efficacité les accès concurent, un point important du partage de sessions.
Mais la où personnellement ca pêche un peu c'est en terme d'évolutivité.
If your requirements are higher than about 4000~5000 full session operations a second, depending on your server hardware, mcache may not be for you.
"5000 full session operations" en une seconde, c'est certe beaucoup mais je ne trouve pas ca "hallucinant". Qu'est ce qu'on fait au delas de ce chiffre ? Est-il possible de mettre plusieurs serveurs mcache (load balancing avec systeme de fichier distribué ?) en place ?
Je me suis aussi interessé à ShareDance [4], l'exellent. Les commentaires sont tous dans un sens: il est génial. En grand fan de pureftpd je regarde un peu la doc ... et je suis aussi séduit. Reste l'évolutivité, la monté en charge et donc l'ajout en parrallèle de serveur ShareDance ? J'imagine que pour les skyblogs il n'y a pas qu'un seul serveur qui gère les sessions ... et étant donné que le systeme est une simple session TCP je me vois bien faire du LB dessus avec un système de fichier distribué derrière.
En gros, je cherche quelques retour d'expérience sur ce sujet. Comment avez vous fait de votre coté ? BDD ? mcache ? ShareDance ? Ou peut être une autre solution ?
Si vous avez utilisé ShareDance, qu'en pensez vous ? Est-il possible de faire de la balance de charge ?
Avant de monter une plate forme de test, je souhaiterais juste savoir si je ne me trompe pas de chemin :)
* [1]: http://fr2.php.net/manual/fr/function.session-set-save-handl(...)
* [2]: http://www.mysql.fr/why-mysql/white-papers/mysql_wp_sessionm(...)
* [3]: http://www.mohawksoft.org/?q=node/8
* [4]: http://sharedance.pureftpd.org/project/sharedance
# sharedance
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Mon petit doigt me dis qu'effectivement, la plateforme technique de skyblog ne doit pas se résumer à un seul serveur, et que les mecs qui y bossent, sont loin d'être des neuneu du dev web :-)
Connaissant l'auteur, Mr Jedi, (depuis.... pfiouuu, ça date : HP48, RTC-One toussa..), je ne doute absolument pas de l'excellence de l'outils, sans même l'avoir testé :-) (pureftpd par ex est une petite merveille, faut l'avouer..)
[^] # Re: sharedance
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: sharedance
Posté par atmaniak (site web personnel) . Évalué à 2.
# Sharedance is good :)
Posté par patphobos . Évalué à 4.
MySQL avec une table en MyISAM ou en HEAP n'est pas la bonne solution. La table de session complète est locké à chaque ecriture. Les mécanisme de base de donnée son trop lourd pour ce travail qui doit rester simpliste pour etre rapide.
Donc pour nous MySQL, au dela d'une certaine limite ça ne tenait plus du tout la charge...
Avec Sharedance, sur une seule machine nous gérons plus de 3Go de données de sessions (dans un tmpfs) pour une vingtaine de serveurs web php. Notre Sharedance débite jusqu'a 2 * 200 Mbps (200 Mbps entrants, 200 Mbps sortants) avec les serveurs web. load maximum : 0.7.
Si tu le souhaites tu peux quand même scaller comme tu le souhaites, il te suffit de modifier/customiser le script php qui modifie le session_handler de php. (celui que tu dois mettre en prepend_file dans php.ini)
Exemple :
Tu as 2 serveurs de session de même capacité (quelque soit la techno utilisée), tes identifiants de session sont certainement des hexadécimaux de 32 char.
Tu peux choisir le serveur en regardant le 1er caractère du session_id :
0 1 2 3 4 5 6 7 => serveur n°1
8 9 A B C D E F => serveur n°2
[^] # Re: Sharedance is good :)
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
# memcache
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
# Performances, redondance
Posté par Sébastien Koechlin . Évalué à 5.
Le premier est la performance. Si on veut enregistrer les données sur disque à chaque requête, il va sans dire qu'il faut mettre le minimum de données en session, c'est pourtant rarement l'objectif des développeurs lorsqu'ils écrivent une application, ils utilisent plutot la session comme cache des données utilisateur.
Lorsque les données sont en plus enregistré dans une base de donnée, particulièrement MySQL qui verrouille souvent au niveau de la table. L'enregistrement de plusieurs Ko de données est catastrophique.
Le partage NFS est aussi souvent utilisé; mais le verrouillage des fichiers n'est alors généralement pas géré.
Le second problème est la redondance. Si le serveur de session tombe, parce qu'il est trop chargé, ou parce qu'il y a un problème matériel sur la machine; le service est complètement coupé. On souhaite souvent avoir un mécanisme de secours, même si les sessions sont perdues, les gens doivent pouvoir en ouvrir une nouvelle. Les mécanismes à serveur unique fonctionnent mal dans ce cas. Les serveurs SQL peuvent être souvent installés en clusters, mais dans ce cas, le temps de traitement des requêtes est également augmenté; ce qui augmente les risques d'écroulement sous la charge.
La technique que j'utilise est le proxy avec affinité de session. Cela permet de distribuer en amont, avec un logiciel ou un équipement dédié, le routage de toutes les requêtes d'un même client vers le même serveur. Ainsi la session peu rester locale à l'application.
Un logiciel qui permet de faire cela est Pound http://www.apsis.ch/pound
[^] # Re: Performances, redondance
Posté par DjinnS . Évalué à 1.
C'est d'ailleurs pour ces raisons que je souhaites savoir s'il possible de rendre redondant le serveur de session. La solution de patphobos est certe interessante mais un peu trop bidouillage à mon gout. Je pense aussi que du coté des skyblog il doit y avoir une armée de serveurs pour les sessions. Dans mon cas, je gererais la balance de charge avec Keepalived, donc je me demande si ShareDance peut fonctionner au traver de Keepalived. Si c'est une connexion TCP toute simple il ne devrait pas y avoir de soucis ... Mais reste à savoir comment l'accès aux données sera géré (oui, deux serveurs accèdant aux mêmes données ...).
Car il est clair que dans une telle archi, le serveur de session devient le Single Point Of Failure ...
De plus je cherche une solution évolutive pour pouvoir gérer la montée en charge, meme si d'apres le retour de patphobos (encore lui ^^) ShareDance semble relativement balaise !
[^] # Re: Performances, redondance
Posté par patphobos . Évalué à 2.
Pour scaller/sécuriser, on peut en effet ecrire en double, et lire sur 1 seul des 2 comme le dit Mathieu.
Enfin Sharedance, ça n'a JAMAIS planté.
[^] # Re: Performances, redondance
Posté par DjinnS . Évalué à 1.
Sinon je pense mettre un heatbeat pour la dispo. Le pire sera donc de perdre les sessions courantes mais l'essentiel est, comme dit plus haut, de pouvoir ouvrir a nouveau une session sur un autre serveur.
[^] # Re: Performances, redondance
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
[^] # [HS] Re: Performances, redondance
Posté par Olivier Fraysse (site web personnel) . Évalué à 0.
# Load balancing avec maintenance de sessions
Posté par N. D. . Évalué à 1.
Sur un grande ferme de serveurs Web avec sessions, n'est-il pas plus judicieux de faire de la maintenance de sessions par le load balancer entre les serveur web ?
Typiquement, pour ne pas faire de pub, un répartiteur de charge de type Nortel Alteon sait faire de la maintenance de session par IP source ou sur un critère comme un cookie distribué par l'application. A partir de là, pour une session donnée, un utilisateur tombe toujours sur le même serveur Web.
[^] # Re: Load balancing avec maintenance de sessions
Posté par briaeros007 . Évalué à 2.
http://linuxfr.org/2006/12/05/21728.html
[^] # Re: Load balancing avec maintenance de sessions
Posté par GP Le (site web personnel) . Évalué à 1.
Suivant l'outil utilisé, tu seras en layer 3 (sur l'ip) ou layer 7 (sur le contenu genre coockie, session_id, etc.). Malheureusement, lvs semble limiter au layer 3. Mais d'autres solution, moins répandu existe.
# Synchronisation des sessions en multicast ?
Posté par Gilles Mocellin . Évalué à 1.
Mais le principe de sessions en mémoire synchronisée en multicast (de la network shared memory en fait) doit pouvoir être très performant non ?
[^] # Re: Synchronisation des sessions en multicast ?
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Ça va demander a ton serveur qui heberge apache+php d'avoir un système de stockage de session local (mis a jour via multicast et qui envoie ses changement en multicast)
Car ton script php n'est pas permanent mais lancé a chaque consulation.
En fait j'avais finis pas régler un soucis du même genre pour avoir des stats en cours de l'upload d'un fichier en php.
La seule solution trouvée était de la mémoire partagée créé par le script qui reçois l'upload avec une clef X
(c'était un module en C de php)
Et le script de stats lisait cette même mémoire partagée si elle existait.
Mon seul problème est que le nombre d'emplacement de mémoire partagée sur un système linux est largement inférieur au nombre de session possible.
Donc tu utilise un algorithme de réduction de plage et donc gare au collisions...
(sur un petit site avec 3 upload en parallèle tu t'en tape carrément, mais pour de la prod critique de site de vente ou autre c'est inacceptable)
[^] # Re: Synchronisation des sessions en multicast ?
Posté par andeus . Évalué à 1.
apc_set('var','data');
$data = apc_fetch('var');
Apparemment la version CVS permet aussi de récupérer la progression des fichiers en cours d'upload avec php5.2 :)
http://www.whenpenguinsattack.com/2006/12/12/how-to-create-a(...)
[^] # Re: Synchronisation des sessions en multicast ?
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Mais mon script permet de ne pas avoir les limites de cet exemple.
- possibilité d'utiliser mon système en cgi
- pas besoin d'apc actif
- marche en v4 et v5
Mais bon ça demande un patch qui ajoute deux parties:
- un handler en sup dans la rfcXXXX.c qui gère la reception de fichier
- un module a part qui exporte 3 fonctions :
=> réducteur d'identifiant
=> status de l'upload dont l'id est X
Bon j'ai aussi deux trois param pour ce module, notamment un paramètre pour choisir le backend (file ou mmap)
En fait mon seul soucis était de faire marcher avec le packaging standard de la mandriva 2007.0, mais je m'y suis pris trop tard. :'(
(en fait j'ai eu surtout la flemme de nettoyer le code de débug et de corriger un bug stupide, mais comme ça marchais j'ai pas touché a ce qui marche)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.