Néanmoins, la redondance et le basculement ne suffisent pas. Lorsque l'un des serveurs d'un cluster tombe en panne, les sessions PHP stockées sur cet ordinateur doivent rester accessibles aux autres serveurs. Sinon, l'utilisateur final verra ses transactions interrompues, ses paniers d'achat vidés et son travail perdu. Une telle situation est évidemment inacceptable sur une application à niveau élevé de disponibilité.

Zend Server Cluster Manager propose des capacités intégrées de clustering de session PHP, optimisées pour les applications stratégiques. Si un serveur différent gère les demandes d'un utilisateur donné, la session bascule en toute transparence et l'utilisateur final ne remarque aucune dégradation du service.

Comment le clustering de sessions Zend fonctionne-t-il ?

Chaque nouvelle session PHP est stockée sur deux emplacements : un serveur maître et un serveur de sauvegarde. Lorsqu'une nouvelle session est créée, le serveur ayant reçu la demande de démarrage d'une session est désigné comme le serveur maître et le démon de clustering de session désignera le serveur le moins chargé du cluster comme le serveur de sauvegarde.

L'identification interne du serveur maître et du serveur de sauvegarde est encodé dans l'ID de session attribué à l'utilisateur. Cela permet à chaque serveur du cluster de retrouver à la fois le serveur maître et le serveur de sauvegarde en consultant simplement le jeton ID de session fourni par le client et il n'est pas nécessaire d'effectuer de recherche de table de hachage ou de requête dans une base de données centrale (comme cela se fait dans certaines techniques de clustering de session, ce qui peut avoir des conséquences sur la vitesse et l'évolutivité).

Si une demande future est gérée par un serveur qui n'est ni le serveur maître ni le serveur de sauvegarde, en raison d'un équilibrage de charge ou d'un basculement d'ordinateur, l'ID de session s'identifie au nouveau serveur dans lequel rechercher les données de session. Si le serveur maître est disponible, les données de session deviennent alors accessibles au nouveau serveur. Si le serveur maître n'est pas disponible, les données de session seront accessibles à partir du serveur de sauvegarde et ce dernier se désignera comme le serveur maître et sélectionnera un nouveau serveur de sauvegarde.

Évolutivité et disponibilité élevée

Le clustering de session a été conçu pour être transparent et d'une évolutivité linéaire. Au fur et à mesure que vous ajoutez de nouveaux serveurs au cluster, votre capacité de gestion linéaire de sessions supplémentaires augmente. Zend Server Cluster Manager prend en charge la mise à jour de la configuration sur tous les membres du cluster afin q'ils soient informés de l'existence du nouveau serveur. Le trafic sur le nouveau serveur créera de nouvelles sessions et l'algorithme utilisé pour sélectionner les serveurs de sauvegarde veilleront à ce que la distribution de charge de la session entre les différents serveurs s'égalise (en quelques minutes, en général).

Réduire le déploiement après une période de trafic intense est tout aussi simple car Zend Server Cluster Manager fournit une procédure d'arrêt progressif. Lorsqu'un serveur est supprimé du cluster, il trouvera et désignera l'un des autres membres du cluster comme serveur de remplacement et transfèrera toutes les sessions actives sur ce serveur. Pendant ce laps de temps, le serveur supprimé n'acceptera plus aucune session. Une fois le transfert effectué (ce processus dure normalement de quelques secondes à une minute, selon l'arrière-plan de stockage, le nombre de sessions et le débit du réseau), le serveur supprimé informera tous les membres du cluster de son remplacement.