Fil RSSComment ça marche : la haute disponibilité web
Par netking,
jeudi 19 janvier 2006 à 22:48
::
Devzone
Pour gérer des milliers ou des millions d'utilisateurs, un site web se doit de mettre en place un certain nombre de technologies afin que les visites des utilisateurs soient garanties et agréables. En termes techniques, on parle de redondance et de répartition de charge (load balancing en anglais). L'association de ces deux paramètres permet d'atteindre ce qu'on appelle la haute disponibilité : en gros un service qui ne peut pas tomber en panne et qui peut facilement monter en charge.
Vous vous en doutez, aucun serveur n'est assez puissant pour gérer un gros site web, et, de toute façon, il pourrait tomber en panne.
Alors, comment font les éditeurs de sites web ?
Pour obtenir la redondance, les serveurs sont répliqués, c'est à dire qu'il coexiste plusieurs serveurs, au contenu identique. Ainsi, en cas de panne d'une machine, les autres assument la charge supplémentaire le temps de la réparation
Pour ce qui est de la charge, le principe est simple : le load balancer (qui peut être un serveur ou un dispositif hardware dédié) envoie toute requête entrante au serveur le plus disponible. Si tous les serveurs saturent, la solution est simple : on ajoute une machine.
Il y a des dizaines de configurations possibles, mais nous allons prendre un exemple assez commun, qui démontre bien la mise en oeuvre de ces principes à tous les niveaux de l'architecture d'un service web haute disponibilité sous linux.
Premier niveau : l'arrivée des requêtes sur la tête de plateforme
Quand votre requête ("je veux telle page web") arrive sur l'architecture, elle passe d'abord par un firewall. Ce dernier vérifie qu'elle est bien autorisée par l'architecture. En gros, c'est la même chose que votre pare-feu Windows. Sous Linux, le programme chargé de ce travail se nomme IP Tables (anciennement IP Chains).
Ensuite, si la requête est autorisée, elle est passée au load balancer (LVS soit Linux Virtual Server) qui décide quel serveur va répondre (en principe le moins chargé, mais de nombreux réglages sont possibles). Le load balancer envoie la requête au serveur web. A votre niveau c'est transparent : vous n'avez aucun moyen de connaître la machine qui va vous répondre.
A ce niveau, les deux serveurs sont redondés : ils ont un clone qui attend sagement, prêt à prendre le relais. Chaque serveur est relié à son clone via un petit logiciel (Heartbeat) qui pingue régulièrement le serveur en ligne pour s'assurer de sa disponibilité. A la moindre défaillance, le clone prend le relais et emet une alerte à l'administrateur pour intervention.
Deuxième niveau : le traitement des requêtes sur les serveurs frontaux
Votre requête arrive finalement sur le serveur web (appellé "frontal", car c'est lui qui renvoie la page directement sur le web). Le serveur web (Apache en général sous Linux) exécute votre demande : il exécute le code php, interroge la base de donnée, insère les variables dans la mise en page HTML et vous renvoie le tout sous la forme d'une page statique.
D'ailleurs, la plupart des serveurs vous renvoient effectivement une page statique précalculée par un système de cache : les pages les plus fréquemment demandées sont stockées "en dur" (en html) et ne sont recalculées que périodiquement, soulageant ainsi le processeur des serveurs web et évitant l'accès à la base de donnée. Le recalcul de la page peut intervenir soit après un certain délai, soit après un certain nombre d'affichages. C'est notamment le cas pour les pages dont le contenu change peu fréquemment : pages de catalogue par exemple.
Dans notre exemple, ce sont également les serveurs frontaux qui vous renvoie les images associées à la page, mais le plus souvent celles-ci font l'objet d'un stockage séparé et partagé entre les frontaux. Ce stockage est effectué sur des périphériques dédiés (SAN) aux disques durs ultra-redondants (RAID 5). Il est également courant de faire appel à un CDN (Content Delivery Network). Ces réseaux (comme Akamai) disposent de milliers de serveurs répartis sur l'ensemble de la planète. En répartissant votre contenu statique (images, médias, html) sur leur réseaux, ils permettent de délivrer l'information au plus près de l'internaute, améliorant grandement les performances des sites à audience mondiale.
Troisième niveau : la base de données
La base de données pose un problème un peu différent. Il est très difficile de gérer des écritures et lectures sur plusieurs serveurs (sauf technologies de clustering, mais restons dans une architecture simple). En effet, une base de donnée qui doit se mettre à jour simultanément sur plusieurs serveurs pose des problèmes techniques hors du spectre de cet article. Mais comme la plupart des sites web ont un rapport lecture/écriture de l'ordre de 90/10, voire 95/5, une solution alternative très simple existe : l'architecture maître-esclave (aussi appellée replication).
Le principe est simple : un seul serveur (le maître) assure les opérations d'écriture (commandes SQL INSERT, UPDATE et DELETE), tandis que les esclaves assurent uniquement les opérations de lecture (commande SQL SELECT). La synchronisation entre le maître et les esclaves est quasi instantanée. Il est donc possible d'obtenir une information ancienne (avant la mise à jour par le maître) mais ce risque concerne un nombre très minime de requêtes et reste acceptable dans la plupart des cas.
La replication apporte également l'avantage de la redondance : en cas de défaillance du maître, il suffit d'activer les opérations d'écriture sur un esclave pour disposer d'un nouveau maître.
Bien d'autres dispositifs de sécurité existent au niveau hardware des serveurs eux-mêmes (double alimentation, redondance des disques en RAID, double cartes réseau...) et bien entendu du datacenter (sécurité incendie, alimentation electrique ondulée, générateurs de secours, connexions multi-opérateurs).
L'ensemble des ces dispositifs crée la haute-disponibilité, garante d'un accès permanent à vos sites web favoris.
Vous vous en doutez, aucun serveur n'est assez puissant pour gérer un gros site web, et, de toute façon, il pourrait tomber en panne.
Alors, comment font les éditeurs de sites web ?
Pour obtenir la redondance, les serveurs sont répliqués, c'est à dire qu'il coexiste plusieurs serveurs, au contenu identique. Ainsi, en cas de panne d'une machine, les autres assument la charge supplémentaire le temps de la réparation
Pour ce qui est de la charge, le principe est simple : le load balancer (qui peut être un serveur ou un dispositif hardware dédié) envoie toute requête entrante au serveur le plus disponible. Si tous les serveurs saturent, la solution est simple : on ajoute une machine.
Il y a des dizaines de configurations possibles, mais nous allons prendre un exemple assez commun, qui démontre bien la mise en oeuvre de ces principes à tous les niveaux de l'architecture d'un service web haute disponibilité sous linux.
Premier niveau : l'arrivée des requêtes sur la tête de plateforme
Quand votre requête ("je veux telle page web") arrive sur l'architecture, elle passe d'abord par un firewall. Ce dernier vérifie qu'elle est bien autorisée par l'architecture. En gros, c'est la même chose que votre pare-feu Windows. Sous Linux, le programme chargé de ce travail se nomme IP Tables (anciennement IP Chains).
Ensuite, si la requête est autorisée, elle est passée au load balancer (LVS soit Linux Virtual Server) qui décide quel serveur va répondre (en principe le moins chargé, mais de nombreux réglages sont possibles). Le load balancer envoie la requête au serveur web. A votre niveau c'est transparent : vous n'avez aucun moyen de connaître la machine qui va vous répondre.
A ce niveau, les deux serveurs sont redondés : ils ont un clone qui attend sagement, prêt à prendre le relais. Chaque serveur est relié à son clone via un petit logiciel (Heartbeat) qui pingue régulièrement le serveur en ligne pour s'assurer de sa disponibilité. A la moindre défaillance, le clone prend le relais et emet une alerte à l'administrateur pour intervention.
Deuxième niveau : le traitement des requêtes sur les serveurs frontaux
Votre requête arrive finalement sur le serveur web (appellé "frontal", car c'est lui qui renvoie la page directement sur le web). Le serveur web (Apache en général sous Linux) exécute votre demande : il exécute le code php, interroge la base de donnée, insère les variables dans la mise en page HTML et vous renvoie le tout sous la forme d'une page statique.
D'ailleurs, la plupart des serveurs vous renvoient effectivement une page statique précalculée par un système de cache : les pages les plus fréquemment demandées sont stockées "en dur" (en html) et ne sont recalculées que périodiquement, soulageant ainsi le processeur des serveurs web et évitant l'accès à la base de donnée. Le recalcul de la page peut intervenir soit après un certain délai, soit après un certain nombre d'affichages. C'est notamment le cas pour les pages dont le contenu change peu fréquemment : pages de catalogue par exemple.
Dans notre exemple, ce sont également les serveurs frontaux qui vous renvoie les images associées à la page, mais le plus souvent celles-ci font l'objet d'un stockage séparé et partagé entre les frontaux. Ce stockage est effectué sur des périphériques dédiés (SAN) aux disques durs ultra-redondants (RAID 5). Il est également courant de faire appel à un CDN (Content Delivery Network). Ces réseaux (comme Akamai) disposent de milliers de serveurs répartis sur l'ensemble de la planète. En répartissant votre contenu statique (images, médias, html) sur leur réseaux, ils permettent de délivrer l'information au plus près de l'internaute, améliorant grandement les performances des sites à audience mondiale.
Troisième niveau : la base de données
La base de données pose un problème un peu différent. Il est très difficile de gérer des écritures et lectures sur plusieurs serveurs (sauf technologies de clustering, mais restons dans une architecture simple). En effet, une base de donnée qui doit se mettre à jour simultanément sur plusieurs serveurs pose des problèmes techniques hors du spectre de cet article. Mais comme la plupart des sites web ont un rapport lecture/écriture de l'ordre de 90/10, voire 95/5, une solution alternative très simple existe : l'architecture maître-esclave (aussi appellée replication).
Le principe est simple : un seul serveur (le maître) assure les opérations d'écriture (commandes SQL INSERT, UPDATE et DELETE), tandis que les esclaves assurent uniquement les opérations de lecture (commande SQL SELECT). La synchronisation entre le maître et les esclaves est quasi instantanée. Il est donc possible d'obtenir une information ancienne (avant la mise à jour par le maître) mais ce risque concerne un nombre très minime de requêtes et reste acceptable dans la plupart des cas.
La replication apporte également l'avantage de la redondance : en cas de défaillance du maître, il suffit d'activer les opérations d'écriture sur un esclave pour disposer d'un nouveau maître.
Bien d'autres dispositifs de sécurité existent au niveau hardware des serveurs eux-mêmes (double alimentation, redondance des disques en RAID, double cartes réseau...) et bien entendu du datacenter (sécurité incendie, alimentation electrique ondulée, générateurs de secours, connexions multi-opérateurs).
L'ensemble des ces dispositifs crée la haute-disponibilité, garante d'un accès permanent à vos sites web favoris.
Tutoriaux WI
