Auteur original : Adam Charnock
Lien d'origine : Le guide des auto-stoppeurs sur l'équilibrage de charge PHP
Traduction : Koda
signifiait auparavant exécuter un grand serveur Web lors de l’exécution d’une grande application Web. Parce que votre application attire un grand nombre d’utilisateurs, vous devrez ajouter plus de mémoire et de processeurs à votre serveur.
Aujourd'hui, le modèle des « gros serveurs » a disparu, remplacé par un grand nombre de petits serveurs, utilisant diverses techniques d'équilibrage de charge. Il s'agit d'une approche plus réalisable qui permettra de maintenir les coûts matériels au minimum.
L'avantage de « davantage de petits serveurs » par rapport au modèle précédent de « grands serveurs » se reflète dans deux aspects :
si le serveur tombe en panne, le système d'équilibrage de charge cessera d'envoyer des requêtes au serveur en panne et distribuera la charge à d'autres serveurs fonctionnant normalement. . supérieur.
La mise à l’échelle de votre serveur est plus facile. Tout ce que vous avez à faire est d'ajouter de nouveaux serveurs au système d'équilibrage de charge. Pas besoin d'interrompre votre candidature.
Alors profitez de cette opportunité :). Le compromis, bien sûr, est que cela nécessite un peu plus de complexité dans le développement de votre application. C’est ce que cet article va couvrir.
À ce stade, vous vous demandez peut-être : « Mais comment savoir si j'utilise l'équilibrage de charge ? » '. La réponse la plus honnête, si vous posez cette question, est que vous n'utilisez probablement pas de système d'équilibrage de charge et que votre système n'a pas besoin d'en tenir compte. Dans la plupart des cas, lorsque l’application devient suffisamment volumineuse, l’équilibrage de charge doit être explicitement proposé et mis en place. Cependant, je vois parfois des sociétés d'hébergement Web effectuer cet équilibrage de charge pour les applications client, ou le faire elles-mêmes, comme décrit ci-dessous.
Avant de continuer ci-dessous, je tiens à souligner que cet article décrit principalement l'équilibrage de charge en PHP. J'écrirai peut-être sur l'équilibrage de la charge des données à l'avenir, mais pour l'instant, vous devrez attendre.
Notez que je continue de mentionner les « applications Web » plutôt que les sites Web. Ceci afin de distinguer que les « applications Web » sont des sites complexes qui impliquent souvent une programmation côté serveur et des bases de données, plutôt que des sites Web qui affichent uniquement du contenu statique simple.
1. Fichiers PHP La première question est la suivante : si vous disposez d'un grand nombre de petits serveurs, comment télécharger vos fichiers php sur tous les serveurs ? Il existe la méthode suivante pour votre référence :
téléchargez tous les fichiers sur chaque serveur séparément. Le problème avec cette méthode est le suivant : imaginez que vous ayez 20 serveurs, cela entraînera facilement des erreurs pendant le processus de téléchargement et le temps de mise à jour sera très long. rapide. Il est possible d'avoir différentes versions de fichiers sur différents serveurs.
Utilisez 'rsync' (ou un logiciel similaire). Un tel outil peut synchroniser des fichiers sur un répertoire local et des répertoires sur plusieurs hôtes distants.
Utilisez un logiciel de contrôle de version (tel que Subversion). C'est ma méthode préférée. Cela me permet de très bien maintenir mon code, et lorsque je publie mon application, je peux exécuter la commande svn update sur chaque serveur pour la synchroniser. Cette approche facilite également le basculement des serveurs vers une version précédente du code.
Utilisez un serveur de fichiers (vous constaterez peut-être que NFS est idéal pour cela). Cette approche consiste à utiliser un serveur de fichiers pour héberger votre application Web. Bien sûr, si votre serveur de fichiers tombe en panne, tous vos sites ne seront pas disponibles. À ce stade, vous devrez dépenser plus d’argent pour le restaurer.
La méthode que vous choisissez dépend de vos besoins et de vos compétences. Si vous utilisez un système de contrôle de version, vous souhaiterez peut-être planifier un moyen de mettre à jour le code sur tous les serveurs en exécutant une commande de mise à jour en même temps. Cependant, si vous utilisez un serveur de fichiers, vous devrez mettre en œuvre un mécanisme de récupération après échec pour éviter les échecs de requête en cas de panne du serveur.
2. Téléchargement de fichiers Lorsqu'il n'y a qu'un seul serveur, le téléchargement de fichiers ne pose pas de problème. Mais lorsque nous avons plusieurs serveurs, comment doivent être stockés les fichiers téléchargés ? Le problème du téléchargement de fichiers est similaire à celui du stockage de fichiers PHP entre serveurs. Voici plusieurs solutions possibles :
Stocker le fichier dans une base de données. La plupart des données permettent de stocker des données binaires. Lorsque vous demandez un téléchargement de fichier, Access Data envoie les données binaires ainsi que le nom et le type de fichier correspondants à l'utilisateur. Vous devez réfléchir à la manière dont la base de données stockera vos fichiers avant d'utiliser cette solution. Le problème avec cette approche est que si le serveur de base de données tombe en panne, les fichiers seront indisponibles.
Stockez les fichiers téléchargés sur un serveur de fichiers. Comme dans l'introduction précédente, vous devez installer un serveur de fichiers qui sera partagé par tous les serveurs Web. Après le téléchargement, tous les serveurs Web peuvent l'utiliser. Cependant, si le serveur de fichiers est en panne, des interruptions du téléchargement des fichiers image peuvent survenir.
Concevez votre propre mécanisme de téléchargement pour transférer des fichiers vers chaque serveur. Cette approche ne présente pas les inconvénients d'un serveur de fichiers ou d'une solution de base de données unique, mais augmentera la complexité de votre code. Par exemple, si le serveur tombe en panne lors du téléchargement sur plusieurs serveurs, que ferez-vous ?
Utiliser une base de données pour stocker les fichiers téléchargés mais concevoir un mécanisme de mise en cache des fichiers est une bonne solution. Lorsque le serveur reçoit une demande de téléchargement de fichier, il vérifie d'abord si le fichier existe dans le système de cache, s'il le trouve, il le télécharge depuis le système de cache. Sinon, il le lit dans la base de données et le met en cache dans le système de fichiers.
3. Séances
Si vous êtes familier avec la gestion des sessions PHP, vous savez probablement que par défaut, il stocke les données de session dans des fichiers temporaires sur le serveur. De plus, ce fichier se trouve uniquement sur le serveur sur lequel vous l'avez demandé, mais les requêtes ultérieures pourront être traitées par un autre serveur, ce qui générera une nouvelle session sur l'autre serveur. Cela fait que les sessions ne sont souvent pas reconnues, par exemple, les utilisateurs connectés sont toujours invités à se reconnecter.
Ma solution recommandée consiste soit à rétablir le mécanisme de traitement de session intégré à PHP pour stocker les données de session dans la base de données, soit à implémenter votre propre mécanisme pour garantir que la demande d'un utilisateur est envoyée au même serveur.
4.Configuration
Bien que ce sujet ne soit pas spécifiquement lié à PHP, il me semble nécessaire de le mentionner. Lors de l'exécution de serveurs en cluster, il est judicieux de disposer d'un moyen de synchroniser les fichiers de configuration entre les serveurs. Si les fichiers de configuration sont incohérents, cela peut entraîner un comportement intermittent très étrange qui peut être difficile à dépanner.
Je recommande de les gérer individuellement à l'aide d'un système de contrôle de version. De cette façon, vous pouvez stocker différents fichiers de configuration PHP pour différentes installations de projet et également synchroniser tous les fichiers de configuration du serveur.
5. Journalisation
Tout comme les problèmes de configuration, la journalisation n’est pas uniquement liée à PHP. Mais il est toujours très important de maintenir le bon fonctionnement de votre serveur. Sans un système de journalisation approprié, comment savoir si votre code PHP commence à générer des erreurs (vous désactivez toujours le paramètre display_errors lorsque le système est actif, n'est-ce pas ?)
Il existe plusieurs manières d'implémenter la journalisation :
Connectez-vous chaque serveur. C'est le moyen le plus simple. Chaque machine n'enregistre qu'un seul fichier. L'avantage est qu'il est simple et peut nécessiter très peu de configuration. Cependant, à mesure que le nombre de serveurs augmente, la surveillance des fichiers journaux sur chaque serveur devient très difficile.
Journalisation sur un partage Cette approche conserve les fichiers journaux sur chaque serveur, mais ils sont stockés sur un serveur de fichiers central via le mécanisme de partage, ce qui facilite la surveillance des journaux. Le problème avec cette solution est que si le serveur de fichiers n'est pas disponible, un simple problème d'écriture de journal finira par provoquer le crash de l'ensemble de l'application.
Journalisation sur un serveur de journalisation Vous pouvez utiliser un logiciel de journalisation tel que Syslog pour écrire tous les journaux sur un serveur central. Bien que cette méthode nécessite davantage de configuration, elle constitue également la solution la plus robuste.
phpv ajouté : Un autre point important est la gestion de la base de données, qui peut impliquer beaucoup de contenu. Par conséquent, l'auteur ne l'a pas écrit.