Travail personnel
UE NFE107 – Architecture et urbanisation des systèmes d' information
La haute disponibilité
Calimet Stéphane
SOMMAIRE
Chapitre 1 : Définition
Chapitre 2 : Technique de base
Chapitre 3 : Autres processus
Chapitre 4 : Exemple d'une solution d'architecture haute disponibilité
Chapitre 5 : Conclusion et perspectives
Chapitre 1 - Définition La haute disponibilité désigne une architecture informatique, ou un service, disposant d'un taux de disponibilité convenable. On entend par disponible le fait d'être accessible et rendre le service demandé. La disponibilité est aujourd'hui un enjeu très important et qu'en cas d'indisponibilité, les répercussions en terme de coûts et de production peuvent avoir un effet catastrophique. Cette disponibilité est mesuré par un pourcentage essentiellement composé de 9. Par exemple une disponibilité de 99 % indique que le service ne sera pas disponible pendant 3,65 jours par an maximum (un tableau en dessous est fourni pour les différents taux de disponibilité). On atteint la haute disponibilité à partir de 99,9 % Attention, la haute disponibilité est souvent confondu a tort avec le plan de reprise d'activité. Il s'agit de deux tâches différentes même si complémentaire pour atteindre la disponibilité dite continue.
Source : Wikipédia
Chapitre 2 - Technique de bases Comme chacun le sait, la panne informatique d'un système peut avoir de multiples sources. Les origines peuvent être physiques (naturelle ou criminelle), d'origines humaines (intentionnelle ou non) voir opérationnelle (un dysfonctionnement logiciel par exemple). La haute disponibilité nécessite donc une architecture adaptée mais aussi des locaux abritant cette architecture prévu pour. Il est nécessaire par exemple d'alimenter les composants par une alimentation stabilisée, d'installer une climatisation sous plancher avec filtre à particule afin de maintenir les conditions d'utilisations optimum et minimiser les risques de coupures et donc d'arrêt. Un service de maintenance et éventuellement de gardiennage pour prévenir du vol ou des dégradations. Les risques d'incendies doivent aussi être pris en compte ainsi que la protection des câbles. Ceux ci doivent être enterrés et multipliés afin de prévenir tout risque de coupure volontaire ou accidentelle. Ces précautions de base sont des critères a prendre en compte des le début de l'installation de votre serveur ou du choix de votre prestataire d'hébergement. Ces précautions d'ordre externe à l'architecture sont très importantes mais ne suffisent pas à garantir une haute disponibilité. Afin de pouvoir l' atteindre, il est nécessaire de mettre en place une architecture matérielle complémentaire par la redondance des matériels ainsi que la mise en cluster. La sécurisation des données est aussi une solution indispensable pour mettre en place la haute disponibilité sur le long terme.
− La redondance matérielle La redondance est comme son nom l'indique une duplication partielle ou totale du système informatique. Il existe plusieurs types de redondance : • • • •
La redondance symétrique La redondance asymétrique La redondance évolutive La redondance modulaire
La redondance symétrique repose sur le principe de dupliquer deux choses semblables à l'identique point par point. La redondance asymétrique permet de basculer d'un type de matériel à un autre, il n'est pas forcément identique mais assure les mêmes fonctionnalités avec si possible des performances similaires. La redondance évolutive est comparable à l'asymétrique mais on isole le système défaillant lors d'une panne pour utiliser une autre partie du système. La redondance modulaire est une technique qui permet de dévier une panne d'un système sur un autre (par exemple le Free Flow Control Device).
Dans tous les cas on ne parle de redondance seulement si les composants exercent les mêmes fonctions et ce sans dépendre les uns des autres. Leur influence mutuelle se limite en général à se répartir la charge de travail ou des données. Des interactions comme la consommation électrique ou la dissipation de chaleur existent quand même. Certains composants effectuent des contrôles sur l'activité de leur voisin afin de se substituer à celui ci s'ils sont manifestement hors d'usage, ou relancer le service si cela est possible. Dans le cas de systèmes complexes, on peut dupliquer différents sous-ensemble. On travail successivement sur chaque sous-ensemble en commençant par ceux jugés les moins fiables ou étant le plus critique. Une fois dupliqué on se concentre sur le prochain sous-ensemble jugé le plus sensible ou fragile et ainsi de suite. On poursuivra ce processus jusqu'à avoir atteint le niveau de capacité, de performance et de fiabilité requis et aussi tant que le surcoût de l'installation est jugé rentable.
Source : agenceweb.com
− La mise en cluster La mise en cluster est aussi appelé grappe de serveurs ou ferme de calcul. Le principe est de regrouper des ordinateurs indépendants ainsi appelés nœuds (ou node en anglais). Cela permet de dépasser les limitations d'un seul ordinateur et ainsi de les gérer ensemble et non indépendamment. Les avantages de cette solution sont : • Augmenter la disponibilité (ce qui est quand même l'objectif principal) • Faciliter la montée en charge • Permettre une répartition des charges
• Faciliter la gestion des ressources telles que CPU, mémoire, disques etc. L'inconvénient majeur est le coût de cette solution même si cela économise l'achat d'un serveur multiprocesseur. Le principe de fonctionnement est de regrouper des serveurs indépendants afin de les faire fonctionner comme un seul et même serveur. Le client discute comme si il était connecté a une seule machine. On peut ainsi créer des grappes constituées de nœuds de calcul, de stockage voir même de monitoring. Ces nœuds peuvent être reliés entre eux par plusieurs réseaux. On associera d'ailleurs le réseau le plus lent (en terme de débit) pour l'administratif Lors d'une défaillance d'un serveur, le logiciel de clustering réagit en transférant les tâches exécutées sur le système défaillant vers les autres serveurs de la grappe. Ainsi dans le domaine de la gestion, les clusters sont utilisés pour minimiser l'impact d'une panne de serveur sur la disponibilité de l'application (avec une mise en œuvre de disques partagés)
Source : unixgarden.com
Dans le schéma, le Load balancer est installé. Il sert à la répartition des charges (qui sera vu après) ainsi que d'aiguiller les requêtes du client vers un noeud particulier du cluster. Comme il a été mentionné au début du document, afin de prévenir tout risque, il est recommandé de dupliquer le load balancer. Ce qui se traduit par le schéma suivant :
Source : Unixgarden.com
− La sécurisation des données La mise en place d'une architecture redondante ne permet que de s'assurer de la disponibilité des données mais elle ne permet pas de se protéger contre les erreurs de manipulations (des utilisateurs notamment) ou contre des catastrophes naturelles (incendie, inondations, tremblement de terre). Il est nécessaire de sécuriser les données et donc de prévoir des mécanismes de sauvegardes (idéalement sur des sites externes) afin de garantir la pérennité de celles ci. Cette fonction est double car elle permet d'archiver en même temps ces données. Il existe plusieurs types de sauvegarde, voici les principaux : • • • •
Sauvegarde totale Sauvegarde différentielle Sauvegarde incrémentale Sauvegarde à delta
La sauvegarde totale (en anglais on parle de full backup) réalise une copie conforme des données a sauvegarder sur un support séparé. Ce qui peut poser des problèmes en cas de gros volume en terme de lenteur et donc de disponibilité si les données sont modifiées en cours de sauvegarde. Elle permet toutefois d'obtenir une image fidèle des données à un instant t. La sauvegarde différentielle (en anglais on parle de differential backup) se focalise uniquement sur les fichiers modifiés depuis la dernière sauvegarde complète. Par rapport à la sauvegarde incrémentale (vu après), ce type de sauvegarde est plus lent et aussi plus coûteux en espace de stockage mais elle est plus fiable car seule la sauvegarde complète est nécessaire pour reconstituer les données sauvegardées. La sauvegarde incrémentale (en anglais on parle d' incremental backup) copie tous
les éléments modifiés depuis la dernière sauvegarde. Plus performante qu'une sauvegarde totale car elle ne sauvegarde que les éléments modifiés avec un espace de stockage plus faible mais nécessite en contrepartie de posséder les sauvegardes précédentes pour reconstituer la sauvegarde complète. La sauvegarde à delta (en anglais delta backup) est une sauvegarde incrémentale sur des éléments de données à granularité plus fine, c'est à dire au niveau de chaque bloc de données et non au niveau du fichier seulement.
Les différentes solutions de stockage (NAS Vs SAN) Le stockage en réseau NAS (de l'anglais Network Attached Storage) est un périphérique de stockage relié au réseau afin de stocker un gros volume de données en un seul endroit. Il peut être situé dans le réseau ou en point d'entrée. Ce serveur NAS doit être accessible depuis des serveurs clients à travers le réseau. Cette solution a plusieurs avantages : • Faciliter la gestion des sauvegardes des données du réseau • Les disques de grandes capacités sont de moins en moins chers • L'accès par plusieurs clients aux mêmes données stockés sur le NAS On utilise une technologie RAID afin de sécuriser les données stockées contre la défaillance d'un ou plusieurs disques. Sans rentrer trop dans le détail du système RAID, cette technologie permet de stocker des données sur de multiples disques durs. il existe 3 système de RAID : • Le RAID logiciel • Le RAID pseudo-matériel • Le RAID matériel Le RAID logiciel est intégralement assuré par une couche logicielle du système d'exploitation. Elle possède plusieurs avantages : • C'est la méthode la moins onéreuse • C'est la méthode possédant le plus de souplesse d'administration • Compatibilité entre toutes les machines équipées du même logiciel de RAID (même système d'exploitation). Par exemple les RAIDs logiciel de Microsoft Windows et de Linux ne sont pas compatibles. Ce n'est pas la solution idéale car elle possède ses inconvénients : • Le problème majeur est que cette méthode repose sur la couche d'abstraction matérielle des périphériques qui composent le volume RAID. Cette couche
n'étant pas parfaite, elle peut souffrir d'un manque de fonctionnalité. • La gestion du RAID en logiciel monopolise des ressources systèmes (principalement du bus système). • Le disque système n'accepte pas toujours l'utilisation du RAID. Le RAID pseudo-matériel est en réalité un contrôleur (souvent sur la carte mère) disposant de fonctions avancées. L'extrême majorité des contrôleurs RAID bon marché gèrent le RAID 0 et le RAID1 mais il ne s'agit pas de TAID matériel à proprement parler. D'un point de vue strictement matériel, cette solution hybride n'est pas différente d'un RAID logiciel. Ses avantages : • Permet de contourner le problème lié aux fichiers du système d'exploitation qui refuse le système RAID • Le BIOS intègre les routines en mémoire • Le pilote du contrôleur intègre les mêmes routines logicielles de gestion du RAID et fournit alors aux couches supérieurs de l'OS un accès au volume RAID qu'il émule. Les inconvénients : • Il s'agit d'un RAID logiciel camouflé et donc possède des performances limitées. • Le contrôleur gère très mal les défauts matériels et les fonctions intégrées sont assez limités. • En cas de changement de carte mère, si la nouvelle possède un jeu de puces différents, il est peut être nécessaire de reconstruire entièrement la sauvegarde. • Fiabilité à démontrer. Le RAID matériel est géré par un contrôleur dédié. Il peut être externe ou dans une baie de disques. Cette carte est composée d'un processeur spécifique et de mémoire dédiée. Le système d'exploitation considère chaque volume RAID comme un disque et n'a pas connaissance de ses constituants physiques Ses avantages : • Permet la détection des défauts des disques et leur changement à chaud (sans éteindre la machine) • Pas de surcharge pour le système Ses inconvénients : • En cas de changement de carte, il faut que la carte soit identique (même le firmware) afin de pouvoir récupérer les données. • Le contrôleur RAID est un périphérique matériel et peut donc tomber en
panne. • Les différentes marques de contrôleur ne possèdent pas les mêmes outils. Il existe différents niveaux de RAID. Les principaux RAID utilisés sont les 0, 1 et 5 qui peuvent être combinés entre eux. Le RAID 0 (aussi appelé entrelacement de disques ou stripping) permet de faire travailler n disques en parallèles. Le problème est que la perte d'un disque entraine la perte complète des données. Le RAID 0 n'apporte aucune redondance mais permet simplement d'augmenter les performances de la grappe. Le RAID 1 (appelé aussi mirroring) utilise n disques redondants. Chaque disque contient à tout moment exactement les mêmes données. Il est conseillé d'utiliser des disques de taille identique car la capacité totale est égale à celle du plus petit élément. La défaillance d'un disque n'entraine pas la perte des données (sauf si c'était le dernier disque). Lors d'une défaillance d'un disque, le contrôleur RAID désactive, de manière transparente, le disque défectueux. Une fois celui ci remplacé, le contrôleur reconstitue les données soit automatiquement ou bien manuellement. Une fois cette opération terminée, la redondance initiale est retrouvée. Le RAID 5 combine les deux procédés précédents. On utilise la technologie du stripping en répartissant les données sur les n disques à parts égales. Chaque bande est donc constituée de blocs de données et d'un bloc de parité. Ainsi en cas de défaillance de l'un des disques de la grappe, il manquera soit un bloc de données soit un bloc de parité. Si c'est le bloc de parité qui manque, ce n'est pas grave car aucune donnée ne manque. Si c'est un bloc de données, on peut deviner son contenu à partir des autres blocs de données et du bloc de parité. La grappe est donc toujours capable de fonctionner mais aussi capable de reconstituer les données une fois le disque changé. La limitation de ce système est que le RAID 5 ne supporte la perte que d'un seul disque à la fois sinon on ne pourra plus reconstituer les données et ne peut être mis en place qu'avec 3 disques durs minimum. L'avantage est d'avoir une performance aussi élevé qu'en RAID 0. Le système SAN (Storage Area Network est un réseau spécialisé dans le stockage mutualisé. A la différence du NAS, l'accès au stockage est de bas niveau. Les espaces de stockages n'apparaissent pas comme des volumes partagés. Elles sont directement accessibles en mode bloc par le système de fichiers des serveurs. Chaque serveur voit donc l'espace disque d'une baie SAN comme son propre disque dur. Avantage : • L'espace disque n'est plus limité par les caractéristiques du serveur. • Mise en œuvre de la réplication plus facile • Qualité de service importante et disponibilité très importante.
Chapitre 3 - Autres processus La répartition de charge Elle est aussi appelé l'équilibrage de charge (ou en anglais Load Balancing). Ce processus consiste a distribuer une tâche à une grappe ou un pool de machines. L'objectif est de : • De lisser le trafic réseau et ainsi mieux répartir la charge globale sur les différents équipements) • Pouvoir assurer la disponibilité des équipements en envoyant des données adaptées aux équipements. Seuls ceux pouvant répondre à la demande seront sollicités, on gagne aussi en temps de réponse. Le principal appareil pouvant permettre ce type de manipulation est le répartiteur de charge (ou load balancer en anglais). Son objectif est de distribuer le travail entre les différentes machines. Il existe plusieurs méthode pour mettre en oeuvre le load balancing : • Un commutateur de niveau 4 • Un serveur qui utilise un algorithme de type Round-Robin
− Le mode dégradé La fonctionnalité du mode dégradé est de permettre le fonctionnement des installations de manière partielle ou ralentie. Une organisation particulière permet de poursuivre l'exploitation des services jugés indispensables tout en préparant le dépannage.
Chapitre 4 - Exemple d'architecture technique haute disponibilité Pour mieux illustrer et comprendre la mise en place d'une haute disponibilité, voici un cas concret de deux entreprises et de leurs choix. 1er cas : Meetic.com Meetic est un site de rencontre en ligne fondé en 2001. Il possède 600.000 abonnés et des millions de profils enregistrés. Le trafic est d'environ 1 Milliards de pages par mois. L'architecture est assez hétérogène et les évolutions du site ont ajoutés de nouvelles technologies. Il existe une partie en plus du site en backoffice et Business Intelligence. Le site est couplé avec un CRM et un outil de gestion des contacts entrants. Cette combinaison permet de faire face au trafic généré par les visites et les différentes informations échangées. Pour le site nous retrouvons donc le couple PHP/MySQL mais aussi des grappes Oracle RAC (pour la partie abonnée). Les bases de données SQL sont utilisées pour les besoins fonctionnels plus faible comme le chat ou sur des sites périphériques. Le point d'entrée est un Load Balancer hardware (Big IP de F5 Networks). Il est en charge de la répartition et de l'aiguillage par rapport aux pays. Ensuite on retrouve du PHP mais surtout une cascade de serveurs de cache qui permettent l'exécution des requêtes frontales. Cette cascade augmente par 10 l'exécution de ces requêtes. Le moteur de recherche est basé sur une applicatif propriétaire (en non par MySQL). La mise en place de Database Accelerator, l'indexation de la base a été réalisée à partir d'un export complet de celle ci au format XML Ensuite la mise à jour dynamique est réalisée grâce à des exports partiels dirigés vers les serveurs dédiés à la recherche. Un export complet reste néanmoins nécessaire pour re-synchroniser régulièrement l’ensemble du dispositif et ce, malgré près de 100 000 modifications par jour. Il reste à traiter la synchronisation des BDD sur les datacenter. Pour les bases centralisées la redondance BDD multi-site est un élément vital, mais délicat à synchroniser. 2e cas : DayliMotion.com L’architecture de DailyMotion est assez impressionnante. Les volumes de données, le nombre de requêtes simultanées ainsi que les upload et download continuels sont un véritable défit en terme de disponibilité. Pour ce type de site les problématiques sont multiples :
- Tout d’abord la gestion d’un trafic réseau colossal : avec un backbone interne à 10Gb et des peering tout aussi impressionnant la structure du réseau et la communication entre les data center sont déjà un challenge. - Les applicatifs : plusieurs serveurs, de l’apache pour les proxys vidéo et du lighttpd pour les images, style et contenus statique. Le tout, comme d’habitude, en cluster sous PHP et MySQL. - La recherche est gérée sur des serveurs dédiés équipé de Sphinx (en version SE). Les performances de ce moteur full text sont bien plus impressionnantes que le moteur de MySql ou encore qu’un couple Lucene/Java. Mais même avec cette application ultra performante il faut 9 serveurs pour traiter le flot de recherche permanent (tout en indexant les nouveautés rapidement). - Le stockage est lui aussi gourmand, une vidéo c’est quelques dizaines de Mo, même avec la baisse drastique des coûts des disques des volumétries de cet ordre sont très couteuses. - L’encodage des vidéos qui arrivent sans cesse consomme également beaucoup de CPU. - Mais il y a aussi : Le load balancing sur le niveau réseau, le Round Robin DNS, les serveurs proxy, BDD, Search, etc. Pour cette année cette architecture va devoir traiter la livraison de plusieurs dizaines de millions de vidéos par jour, soit quelques centaines de vidéos par seconde ! Chez Google l’architecture de YouTube est assez comparable. Mais l’avantage pour YouTube c’est que la gestion de la croissance est désormais gérée avec Google, qui avec une bonne trentaine de data center et son GFS peut mutualiser une bonne partie des dépenses d’infrastructure. Mais dans les deux cas pour ce type de service les tuyaux restent un élément clef. Car au delà des problèmes commerciaux, la gestion de ces autoroutes représente des couts très important et l’empilement des clusters de serveur n’est efficace que si le trafic est correctement régulé (et cela jusque dans les couches les plus bases des réseaux)
Chapitre 5 – Conclusion et perspective La haute disponibilité est devenue indispensable pour bon nombre de service. Le matériel devient de plus en plus performant, les capacités et fonctionnalités des composants sont de plus en plus importantes. Les techniques sont de mieux en mieux maitrisées. Alors pourquoi n’atteint on pas la disponibilité de 100% ? La technique est une composante mais l’interaction humaine est aussi présente. Les nouvelles technologies et les améliorations incessantes permettent de plus en plus de monter en puissance sans arrêter le service mais il existe toujours des causes non prévisibles.
L’objectif est justement de prévoir ces imprévus et surtout de minimiser leurs causes. Sur un plan des perspectives, l’augmentation des débits et la disparition des frontières numériques permettra de généraliser cette haute disponibilité. L’objectif serait que ces serveurs applicatifs et de données consomment de moins en moins pour respecter l’environnement. Le coût écologique n’étant peu pris en compte dans les solutions mais ce n’est peut être pas pour le moment l’objectif principale, un jour peut être…