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…