Haute disponibilité
Une panne ne doit pas devenir une interruption
Un serveur tombe toujours un jour. La question est de savoir si votre service tombe avec lui. Nous construisons des architectures où la défaillance d’un élément est absorbée par un autre, sur notre infrastructure nantaise.
- Reprise automatique en cas d’avarie sur un nœud
- Deux datacenters unifiés pour les besoins les plus exigeants
- Cluster, cœur de réseau 10 Gbps, AS et adresses IP en propre
- Architecture dimensionnée après étude, pas sur catalogue
Le principe
La disponibilité n’est pas une option qu’on coche
Ce qui tombe, et ce qu’on en fait
Un disque lâche, un nœud de calcul s’arrête, un lien réseau coupe, une base se verrouille. Aucune de ces pannes n’est évitable ; toutes sont absorbables, à condition que l’architecture ait prévu qui prend le relais.
C’est la seule question qui compte : pour chaque élément de votre chaîne, il faut savoir ce qui se passe quand il disparaît. Un hébergement haute disponibilité, ce n’est pas un serveur plus solide — c’est un ensemble où aucun élément n’est seul à faire ce qu’il fait.
Trois étages, selon l’exigence
Le cluster. Nos machines virtuelles reposent sur une technologie de cluster : en cas d’avarie sur un nœud de traitement, un autre reprend l’exécution de votre machine. La haute disponibilité y est native, sans que vous ayez à la configurer.
Les deux datacenters. Pour les besoins les plus exigeants, deux datacenters physiques sont unifiés virtuellement pour n’en former qu’un. Les machines bâties sur cette architecture survivent alors à la perte d’un site entier, et pas seulement d’une machine.
L’application. Au-dessus, la disponibilité se joue dans votre logiciel : répartition de charge devant plusieurs serveurs web, base de données répliquée, sessions sorties de la mémoire d’un serveur unique. C’est le travail d’architecture, et c’est là que se gagne ou se perd la vraie continuité.
Ce que nous ne vous vendrons pas
Un chiffre de disponibilité sans architecture derrière. « 99,99 % » ne veut rien dire tant qu’on n’a pas dit de quoi on parle : du serveur, du réseau, de l’application ? Un serveur redondé qui attaque une base unique n’est pas hautement disponible, il déplace simplement le point de rupture.
Nous partons donc de votre chaîne réelle, nous cherchons les points qui n’ont pas de doublure, et nous chiffrons ce qu’il faut pour les couvrir. Parfois la réponse est modeste, parce qu’un seul maillon manquait.
Le socle
Ce que nous mettons en œuvre
-
Cluster à reprise automatique
Nos machines virtuelles tournent sur un cluster : à l’avarie d’un nœud, un autre reprend l’exécution. Proxmox en cluster, VMware et VSAN, Xen ou Hyper-V selon le contexte.
-
Deux datacenters unifiés
Pour les besoins les plus exigeants, deux datacenters physiques sont unifiés virtuellement pour n’en former qu’un. La perte d’un site entier cesse alors d’être un sinistre.
-
Bascule de service
KeepAlived, LVS et Pacemaker pour porter l’adresse de service d’une machine à l’autre sans intervention : c’est ce qui rend la reprise invisible depuis l’extérieur.
-
Répartition de charge
HAProxy, Nginx, LiteSpeed ou Traefik devant plusieurs serveurs applicatifs. Un serveur retiré du service n’interrompt rien, ce qui permet aussi de mettre à jour sans coupure.
-
Bases répliquées
MariaDB avec Galera, MongoDB en replica set, PostgreSQL, Elasticsearch. La base est le point de rupture le plus souvent oublié d’une architecture redondée.
-
Stockage et réseau
DRBD, iSCSI, GlusterFS, DataCore ou SAN Fibre Channel côté stockage. Cœur de réseau à 10 Gbps, AS et adresses IP qui nous appartiennent, matériel Juniper et Cisco.
Questions fréquentes
Haute disponibilité : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Quelle différence avec un serveur bien sauvegardé ?
La sauvegarde vous permet de revenir en arrière ; la haute disponibilité évite d’avoir à le faire. Une restauration prend des minutes ou des heures pendant lesquelles le service est arrêté. Une bascule prend quelques secondes et ne se voit pas depuis l’extérieur. Les deux sont utiles, et pour des raisons différentes.
Garantissez-vous un taux de disponibilité ?
Cela dépend de l’architecture retenue, et cela se calcule — pas se promet à l’avance. Un chiffre annoncé sans dire de quoi il parle n’engage à rien : un serveur redondé devant une base unique n’est pas hautement disponible. Nous chiffrons l’engagement une fois l’architecture arrêtée. Sur nos offres mutualisées, un engagement existe déjà : une garantie de temps de rétablissement de 4 heures.
Mon application doit-elle être adaptée ?
Souvent, oui, et c’est la partie qu’on découvre tard. Une application qui garde les sessions en mémoire d’un serveur, ou qui écrit des fichiers en local, ne supporte pas d’être dupliquée telle quelle. Nous le regardons avant de dimensionner quoi que ce soit : dupliquer une application qui ne s’y prête pas coûte cher et ne protège de rien.
Est-ce réservé aux gros projets ?
Non, mais cela se justifie par le coût d’une interruption, pas par la taille du site. Une boutique qui perd une journée de commandes ou un extranet dont dépendent des équipes en atelier ont un intérêt évident. Un site vitrine, rarement — le mutualisé, avec sa garantie de rétablissement, y répond mieux et pour moins cher.
Et si le besoin est surtout d’absorber la charge ?
Ce n’est pas le même problème, même s’il se traite avec des outils voisins. Encaisser un pic relève du dimensionnement et du cache ; survivre à une panne relève de la redondance. Une architecture bien faite fait les deux, mais on ne les chiffre pas de la même façon.
Que se passe-t-il si votre serveur s’arrête maintenant ?
Si la réponse vous inquiète, décrivez-nous votre chaîne. Nous cherchons les maillons sans doublure et nous chiffrons ce qu’il faut pour les couvrir.