Netensia

Toujours le même qui s'y colle. Malgré les promesses de mes collègues ingénieurs qui avaient été les premiers à vouloir écrire des articles dans ce blog, toujours rien. Donc, c'est moi, Marc, responsable clientèle de Netensia qui vous fait un topo sur la haute disponibilité.
Et d'abord comment définir la "haute disponibilité" ? Qu'est-ce que la haute disponibilité ? A quoi ça sert ?
Comme je n'ai pas trop de temps pour trouver une définition au top et que comme nombre d'informaticiens je suis assez fainéant, j'ai déjà commencé par taper "haute disponibilité" dans Gougle et sur Wikipedia.fr :

• Wikipédia : Je cite "La haute disponibilité est un terme souvent utilisé en informatique, à propos d'architecture de système ou d'un service pour désigner le fait que cette architecture ou ce service a un taux de disponibilité convenable." Bof, on sait que c'est un terme souvent utilisé, mais à part ça je ne trouve pas que cela fasse beaucoup avancer la compréhension.
• "Commentcamarche.net" : Je cite "On appelle « haute disponibilité » (en anglais « high availability ») toutes les dispositions visant à garantir la disponibilité d'un service, c'est-à-dire assurer le bon fonctionnement d'un service 24H/24." Bon, on apprend ici que ça vient de l'anglais "high avaibility"... Super !
  

Je me lance : la mise en oeuvre de la haute disponibilité d'une application, par exemple un site Web marchand qui doit impérativement être accessible aux internautes 24/24, permet de s'affranchir des nombreuses pannes qui peuvent s'abattre sur un système informatique :

• bogues logiciels : nos amis développeurs malgré toutes les précautions prises laissent parfois quelques bombes à retardement,
• saturation des ressources du serveur : trop d'internautes (je me rappelle de geoportail.fr les premières semaines), requêtes trop nombreuses ou mal conçues (tout le monde ne maîtrise pas le langage SQL comme il se devrait),
• sabotage intentionnel : pirates, virus ....
• erreurs humaines : "j'ai glissé chef !"
• panne matérielle du serveur : crash de disques durs, panne d'alimentation, défaillance mémoire ...
• coupure électrique du netcenter malgré les kilomètres de batteries et les 3 ou 4 générateurs. C'est déjà arrivé à de nombreux hébergeurs (dont Netensia :-() chez Redbus en 2006.
• panne du réseau Internet : saturation des liens, routeurs d'un opérateur hors service
• panne de la climatisation entrainant une surchauffe des serveurs et leur arrêt
• enfin plus rare, les séismes, incendies et autres inondations.
  

Ok, nous avons défini la haute disponibilité. Maintenant il faut la mesurer.
La disponibilité s'exprime en pourcentage : temps de disponibilité sur le temps total (généralement sur 1 an glissant). Les solutions seront choisies en fonction du taux de disponibilité que l'on souhaite pour l'application ou le service. Voici quelques de taux de disponibilités :

• 97% de disponibilité soit 11 jours d'indisponibilité potentielle (downtime en anglais)
• 98% de disponibilité soit 7 jours d'indisponibilité potentielle
• 99% de disponibilité soit 3,5 jours d'indisponibilité potentielle
• 99,9% de disponibilité soit 8 heures d'indisponibilité potentielle
• 99,99% de disponibilité soit 1 heure d'indisponibilité potentielle
• 99,999% de disponibilité soit 5 minutes d'indisponibilité potentielle
• 99,9999% de disponibilité soit 32 secondes d'indisponibilité potentielle.
  

On voit ici qu'un taux de disponibilité de 99%, ce qui semble être un taux élevé, peut permettre une absence de service pendant 3 jours et demi ! En gros c'est le temps nécessaire pour réparer un serveur et le réinstaller, voire même de le déplacer physiquement.
3,5 jours c'est long quand on est un "Pure player", c'est à dire que l'on a tout son business sur Internet.
Il me semble plus cohérent de parler du taux d'indisponibilité exprimé en jours et heures plutôt qu'en pourcentage de disponibilité. Savoir que son application peut être arrêtée pendant 3 jours est plus parlant que savoir qu'elle sera disponible 99% du temps.
A 97%, on ne peut pas parler de haute disponibilité. Il faut atteindre le taux de 99,95 % (5 heures d'indisponibilité) et au-dessus pour pouvoir le faire.
A partir de 99,95 % il faut avoir mis en oeuvre des systèmes qui permettent :

• la reprise sur incident avec par exemple un serveur de secours prêt à remplacer le serveur défaillant et au pire une restauration des données des dernières 24 heures,
• de la tolérance aux pannes : disques durs en RAID, alimentations électriques redondantes, mémoire RAM de secours à chaud
• de la redondance d'équipements, par exemple de serveurs : on duplique les serveurs et les données, si l'on perd un serveur le service continue à être fourni par les autres.
  

Mais il faut également penser à toutes les autres pannes possibles. En fait, dès que l'on a un élément qui est vital dans la délivrance du service il faut le doubler systématiquement et mettre en place un mécanisme de reprise manuel ou automatique.
Il faut éviter ce que l'on appelle en anglais les SPOF (Single Point Of Failure), littéralement « point individuel de défaillance » ! Il s'agit d'un équipement ou d'un service dont tout le système est dépendant. Par exemple, vous disposez d'une plateforme avec 2 serveurs répliqués connectés à un seul commutateur ethernet. Le commutateur est un SPOF. S'il tombe en panne, aucun de vos serveurs ne sera joignables, il faut donc installer deux commutateurs et connecter vos deux serveurs à chacun d'eux. S'il y a une panne d'alimentation, disposer de 2 serveurs sur la même adduction électrique ne sera d'aucune utilité.
Idem pour tous les éléments de la chaine qui contribuent à fournir le service. Si on va au bout de cette logique, on arrive à ce type d'architecture :


Dans cette architecture tout est doublé :

• les netcenters afin de pallier à une panne générale d'un site : alimentation électrique, climatisation, dégât des eaux, incendies ...
• des connexions au réseau internet multi opérateurs (ce que l'on appelle des peer BGP), complété par une interconnexion entre les netcenters
• les routeurs et les pare-feu
• les commutateurs ethernet, y compris des commutateurs de niveau 4 à 7 permettant de faire du partage de charge (load balancing)
• les serveurs d'applications dont les données doivent être synchronisés en temps réels; ou à défaut, plusieurs fois par jour.
  

L'architecture présentée est bien sûr celle que Netensia met à la disposition de ses clients. Cette plateforme fournie les éléments de base permettant de faire fonctionner une application en haute disponibilité, encore faut-il que celle-ci ait été développée pour fonctionner simultanément sur 2 ou plusieurs serveurs ce que l'on appelle un cluster.

Mais cela fait partie d'un autre article, que mes collègues de la technique, un jour, peut-être ...