Quels problèmes potentiels dois-je connaître dans un environnement multi-serveurs / en cluster?
Je travaille sur un site Web avec un client depuis un certain temps et le site lui-même a acquis une popularité énorme. Nous en sommes maintenant au stade où la seule machine hébergeant le site peine à répondre aux demandes et nous avons optimisé le site lui-même aussi loin que nous pouvons (cache, etc.).
Nous en sommes maintenant au stade où nous devons ajouter un autre serveur pour supporter le fardeau supplémentaire qui me conduit à ma question: quels pièges et mises en garde potentiels dois-je connaître ou tester pour le site lors du transfert vers une batterie de serveurs Web ou un hébergement en cluster? environnement?
Il y a plusieurs mises en garde possibles:
Sessions
Si les sessions sont stockées côté serveur, (c'est-à-dire PHP), les deux serveurs devront avoir accès à un chemin de stockage de session partagé. Sinon, vous perdrez des sessions car l'équilibreur de charge envoie une demande d'un serveur à un autre, ou éventuellement (gasp) a un utilisateur avec deux sessions uniques. Cela peut être particulièrement frustrant avec AJAX. Des sessions "collantes" peuvent également être possibles, en fonction de votre équilibreur de charge.
Fichiers temporaires
Les deux serveurs doivent partager le même répertoire/tmp, si vous utilisez des fichiers temporaires pour traiter les demandes. Cela pourrait être une archive temporaire compressée pour un téléchargement, une base de données de fichiers plats qui garde une trace de quelque chose, peu importe.
Verrouillage SQLite
Si vous utilisez SQLite3, vous remarquerez peut-être des problèmes qui n’ont jamais été abordés auparavant, notamment si vous utilisez quelque chose comme NFS pour partager les fichiers de base de données entre les serveurs. NFS est lent avec cela, donc je recommande d'utiliser quelque chose d'autre. Les systèmes de fichiers distribués tels que Lustre sont faciles à configurer. Vous pouvez également utiliser GFS/OCFS2.
SSL
Vous voulez probablement que l'équilibreur de charge gère la négociation SSL, qui envoie ensuite la demande aux serveurs principaux à l'aide de tout ancien certificat auto-signé.
Quelques notes générales:
Comme indiqué, utilisez un système de fichiers haute performance pour le partage de répertoires. Tous les fichiers partagés doivent vivre sur le stockage réseau, pas sur l'un des serveurs Web. Sinon, si l'un d'eux tombe en panne, les deux sont inutiles, ce qui va à l'encontre du but recherché.
Si le site utilise un SGBDR, vous avez deux options. Exécutez-le sur les deux nœuds et utilisez une synchronisation maître-maître ou placez le serveur de base de données sur son propre site. Je recommande le second car cela donne à vos serveurs Web beaucoup plus de marge de manoeuvre.
Les équilibreurs de charge ont également besoin de redondance.
Dans la plupart des cas, vous pouvez passer d'un serveur unique à une batterie de serveurs à charge équilibrée en apportant peu ou pas de modifications au site/à l'application elle-même, mais vous devez vous assurer que tous les nœuds peuvent lire et écrire dans les mêmes fichiers. Cela peut vous obliger à ajouter une logique pour verrouiller l'application elle-même.
L'état de session (s'il s'agit d'un problème) est un problème potentiel. La plupart des appliances d'équilibrage de charge peuvent utiliser des sessions persistantes, ce qui signifie qu'un utilisateur qui démarre sur SERVER1 restera sur SERVER1, généralement via l'utilisation d'un cookie stocké dans la mémoire du navigateur. Le seul inconvénient est que, lorsque le serveur 1 est mis hors ligne pour une raison quelconque, cet utilisateur devra se reconnecter sur un autre serveur.
J'ai commencé à contourner cela sur mes applications (ce sont des applications CF) en partageant des sessions dans la batterie de serveurs. Donc, une machine en panne n'aura pas d'impact sur l'expérience utilisateur.
Le seul autre défi que j'ai rencontré pour répliquer correctement le contenu sur tous les serveurs de la batterie. Il existe des logiciels pour cela (robocopy, deux logiciels que j'ai utilisés que j'ai utilisés), mais il y a toujours des cas où la synchronisation n'a pas fonctionné à 100%.
Votre demande concerne-t-elle l'état? Si un utilisateur a une requête servie par une machine puis une autre par une autre, est-ce important? Si vous devez conserver une forme d’état entre les demandes, alors tout est plus compliqué et il existe différentes façons de traiter le problème.
Si vous n'avez pas à vous soucier de l'état, construisez votre site correctement et vous devriez être relativement à l'aise avec un proxy et quelques serveurs dorsaux.
Si vous devez conserver l'état persistant, il existe différentes manières de créer une session permanente via le proxy afin que le même serveur d'arrière-plan traite toutes les demandes d'un seul utilisateur, mais de nombreuses autres raisons rendent ces sessions difficiles à conserver. .
Vous pouvez également conserver l'état dans un support commun sur le serveur, afin que chaque serveur charge le même état pour le même utilisateur. Vous pouvez le faire avec une base de données (peut-être trop lente) ou quelque chose comme memcached .
Augmentez-vous également le nombre de serveurs de base de données? Cela soulèvera une autre série de problèmes.
Certains problèmes de session sont abordés dans le podcast Stack Overflow Podcast Number 6
Pour les tests, assurez-vous de frapper fort sur un cluster de test similaire afin de pouvoir visualiser l'état de vos demandes lorsqu'elles sont envoyées sur plusieurs serveurs, car de nombreuses demandes du même client vers différents systèmes sont susceptibles de poser des problèmes. cela se produit dans votre plan de test.
Vous pouvez également vouloir en savoir plus sur le dépassement de pile configuration résea