Bonjour.
J'ai un niveau basique en administration de serveurs LAMP avec Centos et WHM/CPanel et pour ce que je fais (tâches courantes en hébergement web uniquement : installation, sécurisation, sauvegardes, etc.), ça se passe bien maintenant.
Je m'intéresse maintenant à la redondance de serveurs. Auriez-vous des pistes de travail à me proposer ?
Merci pour votre aide.
Salut,
La redondance de serveurs physiques est pénible dans la mesure où chaque composant a ses propres mécanismes de redondance : une base de données a les siens, les fichiers peuvent se mettre sur un NAS (qu'il faudrait redonder aussi). Au final, l'infrastructure se complexifie très rapidement et devient sensible à maintenir (split brain, réplication qu'il faut reconstruire, répartition des requêtes…)
Le plus simple est d'utiliser des VM et se baser sur la redondance des hôtes et des NAS qui hébergent la machine. La redondance n'est pas parfaite, vu qu'elle ne gère pas une fausse manipulation. Mais elle a a l'avantage d'être triviale à mettre en place et maintenir.
Si tu veux regarder les pistes, tu peux regarder :
- GPFS
- NAS
- DRBD
- Réplication MySQL
- Cluster Galera
Pour les mails, généralement, la redondance de la base et des fichiers plats suffit généralement.
Ca te donnera une idée du travail à fournir.
Très clairement, dans la plupart des cas, le jeu n'en vaut pas la chandelle : on estime le coût d'une solution redondante au temps de panne que cette solution peut éviter sur une période donnée. Il faut ensuite retrancher tout le temps passé à maintenir cette solution… Le temps étant de l'argent, ça te donne le budget que tu peux y consacrer sur la période.
Effectivement, la haute disponibilité nécessite de complexifier l'infra ce qui engendre une augmentation du coût de gestion.
Que ce soit en compétences requises, en temps ou en matériel.
Sauf pour des sites nécessitants réellement cette haute disponibilité (e-commerce) cela n'en vaut généralement pas la peine sur le plan financier.
Tout en sachant que normalement une panne physique sur un serveur reste rare, maximum 1x par an… Et encore, sur mon expérience je serai plutôt sur 1x tous les 2 ou 3 ans…
La plupart du temps c'est un crash disque, qui se remontent en 2/3H, et encore, si la reconstruction du raid se fait en prod le downtime est encore plus court… Juste le temps qu'ovh change le disque et de reconfigurer le raid… Puis reboot… Du coup 1H maxi.
Après peut se poser la question de la répartition de charge, souvent on arrive à cumuler load balacing et failover… Mais là aussi est ce nécessaire ? Des solutions assez basiques sont à tester en premier (séparation mysql / apache, meilleur gestion des caches, optimisation du code, etc).
Après ce genre d'infra nécessite souvent un stockage centralisé, ou une réplication du contenu sur plusieurs serveurs.
Cela implique également une baisse de performance… Un stockage réseau étant moins performant qu'un stockage local.
Et en cas de réplique du contenu via drdb cela impacte également les perfs, surtout sur du master/master.
Via unison cela demande du temps cpu pour surveiller les modifs et lancer les répliques… Et cela demande aussi de gérer l'intégrité du cache, du partage de session, etc etc etc…
Bref il faut des compétences qui dépassent bien le simple fait de gérer un hébergement via un panel, cela coûte cher en temps en ressources et en compétences… Du coup il faut bien voir si le client final est prêt à payer le prix pour une telle complexité…
Et même parfois c'est la complexité d'une telle solution qui engendre des pannes… (perte de synchro sur mysql par exemple)…
Merci pour vos conseils. 