La plupart des gens ajoutent un deuxième serveur pour une bonne raison : le site a pris de l'ampleur, un client avait besoin de son propre espace, ou un serveur était surchargé. Le deuxième serveur résout le problème auquel tu es confronté. Mais ça ne rend pas forcément le système plus sûr, et en ajouter un troisième de la même manière ne fait que reproduire le même schéma.
Si tu gères plusieurs serveurs, ces cinq questions te permettront de voir quels aspects de ta configuration sont solides et lesquels ne tiennent que par habitude. Pour chacune d’entre elles, tu trouveras une vérification rapide que tu peux effectuer toi-même et une action à mettre en œuvre ce mois-ci. Si tu veux approfondir le sujet, chaque section comporte un lien vers un guide complet.
1. Est-ce que ton deuxième serveur partage la charge, ou juste le risque ?
La configuration à deux serveurs la plus courante, ce n'est pas deux serveurs qui fonctionnent ensemble. C'est plutôt que les sites sont répartis entre les deux machines : certains ici, d'autres là. Ça permet de répartir la charge, mais chaque site reste hébergé à un seul et même endroit. Si l'un des deux serveurs tombe en panne, les sites qui s'y trouvent sont également indisponibles.
Vérification rapide : dresse la liste de tous les sites et des serveurs sur lesquels ils tournent. À côté de chacun, note ce qui se passerait si ce serveur était hors service pendant une heure. Vérifie ensuite où se trouvent tes sauvegardes. Si une sauvegarde se trouve sur le même serveur qu'elle est censée protéger, elle sera également hors service en même temps que ce serveur.
Une chose à faire : choisis le site qui peut le moins se permettre d'être hors service et note comment tu le remettrais en marche si son serveur tombait en panne. Si la réponse est « restaurer à partir d'une sauvegarde et croiser les doigts », tu viens de trouver ton point de défaillance unique.
Lis le guide : « Deux serveurs, ça ne veut pas dire basculement »
2. Est-ce que ton site pourrait fonctionner sur deux serveurs en même temps dès demain ?
Faire tourner un site sur deux serveurs en même temps, avec le trafic réparti entre les deux, c’est ce qui permet aux sites de rester en ligne quand une machine passe une mauvaise journée. Mais la plupart des sites ne peuvent pas le faire, vu comment ils sont conçus aujourd’hui. Un site WordPress typique garde les images téléchargées sur le disque du serveur lui-même, stocke les sessions connectées localement et fonctionne avec une seule base de données. Ajoute un deuxième serveur web à côté, et les visiteurs commencent à voir des images manquantes et à se faire déconnecter au hasard.
Petit test : réponds à trois questions. Où sont stockés tes fichiers téléchargés ? Où sont enregistrées les sessions des utilisateurs ? Est-ce que tous tes serveurs web communiquent avec la même base de données ? Si tu réponds « sur ce serveur-là » à l'une de ces questions, un deuxième serveur web ne servira à rien pour l'instant.
Une chose à faire : commence par les téléchargements. Transférer les fichiers multimédias vers un espace de stockage partagé, c'est souvent le premier changement qui permet de tout mettre en place, et tu peux le faire sans avoir à refaire le site.
Lis le guide : Stockage d'objets pour les téléchargements sur WordPress
3. Qui peut accéder à ton serveur de base de données en ce moment même ?
Quand une base de données est déployée sur son serveur, elle doit accepter les connexions via le réseau. La façon la plus rapide de faire fonctionner ça, c'est souvent d'ouvrir le port de la base de données et d'autoriser une liste d'adresses IP. Ça marche, et après, plus personne n'y touche. Avec le temps, cette liste s'allonge, et le port reste accessible depuis Internet.
Vérification rapide : Sur ton serveur de base de données, lance la commande suivante : ss -tlnp | grep 3306. Si tu vois 0.0.0.0:3306 ou *:3306, MySQL est à l'écoute sur toutes les interfaces réseau, pas seulement sur une interface privée. Vérifie ensuite les règles de ton pare-feu concernant le port 3306 et demande-toi si tu reconnais toujours toutes les adresses de la liste.
Une chose à faire : supprime toutes les adresses autorisées dont tu ne te souviens pas. Si tes serveurs peuvent communiquer via un réseau privé, transfère le trafic de la base de données sur ce réseau et ferme complètement le port vers l'Internet public.
Lis le guide : Le port 3306 est ouvert
4. Quand tu ajoutes un serveur, est-ce que ses règles de pare-feu sont incluses ?
Quand chaque serveur a son propre pare-feu, chacun est configuré un jour différent par celui qui était là à ce moment-là. On ouvre un port sur un serveur pour régler un problème, et on ne le referme jamais. On ajoute une règle sur deux serveurs, mais on oublie de la mettre sur le troisième. Rien de tout ça ne se remarque jusqu’à ce qu’une intrusion se produise ou qu’une requête légitime soit bloquée.
Vérification rapide : exporte les règles du pare-feu de chaque serveur et compare-les côte à côte. Si tu utilises directement iptables, la commande « iptables -S » affiche l'ensemble complet des règles. Toute différence que tu ne peux pas expliquer correspond à un écart.
Une chose à faire : décide quel ensemble de règles est le bon et enregistre-le à un seul endroit, en dehors de n'importe quel serveur. À partir de maintenant, chaque serveur récupère ses règles à partir de ce fichier, et chaque modification y est d'abord enregistrée.
Lis le guide : « Firewall Drift »
5. Combien de temps ça te prend aujourd'hui pour augmenter ta capacité ?
Dans la plupart des configurations à plusieurs serveurs, augmenter la capacité, ça veut dire commander un serveur, attendre qu’il arrive, tout installer, copier la configuration d’un serveur existant et faire des tests. Ça représente souvent plusieurs jours de boulot, et c’est pour ça qu’on s’y met généralement après un ralentissement, plutôt qu’avant.
La méthode la plus rapide, c'est d'utiliser une image enregistrée : une copie prête à l'emploi d'un serveur déjà configuré comme tu le souhaites. Lancer un nouveau serveur à partir d'une image ne prend que quelques minutes, et tous les serveurs que tu lances sont identiques au départ, ce qui résout aussi le problème de dérive évoqué dans la question 4.
Petit test : chronomètre le temps qu'il a fallu pour mettre en place ton dernier nouveau serveur, depuis la décision de l'ajouter jusqu'au moment où il a commencé à traiter du trafic réel. Si ça a pris plus d'une journée, c'est le retard que tu auras la prochaine fois que le trafic va exploser.
Une chose à faire : note toutes les étapes de la dernière installation de ton serveur. Cette liste, c'est la première ébauche de l'image que tu voudrais conserver.
C'est exactement le genre de tâches dont InMotion Cloud s'occupe pour toi. Tes serveurs fonctionnent comme des machines virtuelles sur un cloud privé entièrement géré, avec un tarif mensuel fixe et des ingénieurs expérimentés inclus dans chaque formule. Découvre comment fonctionne InMotion Cloud.
Lis le guide : « Snapshots de serveur vs images de référence »
Quand l'ajout de serveurs commence à alourdir la charge de travail
Si cette liste t'a révélé plus de problèmes à régler que prévu, t'es pas en retard. La plupart des configurations multi-serveurs évoluent comme ça : une correction concrète à la fois. Passe en revue les points ci-dessus à ton rythme, en commençant par celui qui t'inquiète le plus.
Et si tu préfères que ton hébergeur réponde davantage à ces critères, n'hésite pas à contacter notre équipe pour en savoir plus sur InMotion Cloud.