Dans le monde hyper-connecté d’aujourd’hui, les consommateurs s’attendent à avoir accès aux services instantanément, à tout moment et en tout lieu. En outre, vous devez réfléchir à la durée d’attention – savez-vous que vous avez environ 30 secondes pour capter l’attention d’un consommateur avant qu’il ne passe à autre chose ? C’est pourquoi il est crucial de mettre en œuvre la haute disponibilité (HA) sur vos applications. Dans cet article, je vais définir la haute disponibilité, expliquer les différents composants d’une architecture de base et examiner comment construire une infrastructure simple pour une application web.
Qu'est-ce que la haute disponibilité ?
Tout d’abord, définissons la disponibilité : le pourcentage du temps total pendant lequel un système informatique est accessible pour une utilisation normale. En d’autres termes, la disponibilité décrit dans quelle mesure un système est en ligne et accessible. On peut supposer que la disponibilité optimale est de 100 %, mais c’est impossible.
C’est là qu’intervient la haute disponibilité. Les systèmes HA sont ceux dont la disponibilité en ligne varie entre 99,9 et 99,999 % du temps. Un HA idéal à viser est de 99,999 % – « cinq neuf » – ce qui représente environ cinq minutes d’indisponibilité par an.
Les concepteurs du système s’efforcent d’atteindre le niveau d’HA le plus élevé possible. L’HA peut être augmenté grâce à la tolérance aux pannes. Cela implique la mise en place de différentes caractéristiques du système qui permettent un fonctionnement continu en cas de défaillance du système. La redondance et la réplication sont des exemples de caractéristiques de tolérance aux pannes.
Comment fonctionne la haute disponibilité ?
Il existe de nombreuses caractéristiques qui permettent de construire un système de haute disponibilité idéal. Ces composants doivent être intégrés ensemble, surveillés en permanence et capables de se rétablir rapidement. Parmi celles-ci, on peut citer
- la redondance des instances,
- l’équilibrage des charges,
- le basculement du matériel et des logiciels entre des composants disparates,
- la réplication des données, et
- mise à l’échelle automatisée.
Comment évaluer la disponibilité de votre système ?
Vous souhaitez déterminer la disponibilité de l’infrastructure de votre cloud ? Elle se base sur trois critères :
- sa taille et sa portée
- l’inclusion de composants matériels
- une mise à l’échelle anticipée pour répondre à la demande future
Après évaluation, vous pouvez décider de réviser votre infrastructure. Je vous conseille de réviser chaque critère séparément d’abord, puis collectivement.
Comment l'équilibrage des charges affecte-t-il l'HA ?
L’équilibrage de charge répartit intelligemment le trafic entrant sur un ou plusieurs serveurs. Ces outils sont conçus pour être « réglés et oubliés ». Ils permettent d’ajouter ou de supprimer des serveurs dorsaux de manière transparente sans que les utilisateurs finaux ne subissent de temps d’arrêt.
Un équilibreur de charge typique surveille une adresse IP pour les demandes entrantes et l’analyse pour détecter toute surcharge ou défaillance. S’il est détecté, il suit des règles configurées (y compris un basculement IP assigné) pour envoyer le trafic vers un serveur plus accessible. De cette façon, le trafic est réparti de manière égale et les utilisateurs finaux ne rencontrent pas d’interruption de service.
Presque toutes les applications peuvent bénéficier de l’équilibrage de charge. Il s’agit d’un élément clé pour faire évoluer les utilisateurs tout en assurant la redondance.
Qu'est-ce que le Failover exactement ?
Le basculement est la pierre angulaire des systèmes HA. Avec le failover, les tâches sont automatiquement redirigées vers un serveur secondaire ou tertiaire en cas d’arrêt planifié ou accidentel.
Le basculement comprend des solutions matérielles et logicielles, comme l’ajout de serveurs de base de données en miroir à un cluster, ou la configuration d’une adresse IP de manière à ce qu’elle achemine le trafic vers le serveur le plus disponible.
Comment fonctionne la réplication des systèmes de fichiers ?
Dans un cluster HA, chaque serveur (par exemple, application, base de données, système de fichiers) sera configuré pour être le miroir d’autres serveurs, les données stockées étant répliquées automatiquement parmi tous les autres serveurs de l’architecture. Les requêtes entrantes pourront accéder aux données, quel que soit le serveur sur lequel elles se trouvent. Il en résulte une expérience transparente pour l’utilisateur final.
Les logiciels NFS (Network File System) comme GlusterFS, LizardFS et HDFS peuvent regrouper différents types de serveurs en un seul système de fichiers réseau parallèle. En cas de défaillance d’un serveur, le logiciel NFS réachemine automatiquement les demandes qui lui sont adressées vers un serveur en ligne, dont les fichiers et les données ont été mis en miroir et synchronisés.
Qu'en est-il de la base de données ?
L’objectif est d’obtenir une réplication synchrone : vos données sont copiées en permanence d’un serveur de base de données à un autre. Il en résulte une distribution uniforme des données aux utilisateurs finaux, sans perturbation. Vous pouvez y parvenir grâce aux plateformes logicielles suivantes, dans n’importe quelle combinaison :
Mise à niveau sans interruption ?
Vous devez faire évoluer votre système et être à l’écoute des utilisateurs finaux. Chaque système est différent, il n’existe donc pas de plate-forme unique et universelle permettant de mettre à l’échelle un système tout en conservant l’HA. Vous devez choisir la plateforme de déploiement distribué qui vous convient. En voici quelques exemples :
- Kubernetes (communément appelé « K8s ») est un système open source qui vise à fournir une « plate-forme permettant d’automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d’application sur des clusters de serveurs ». Il fonctionne avec toute une série de technologies de conteneurisation, et est souvent utilisé avec Docker.
- Chef est un logiciel qui écrit des recettes de configuration du système en Erlang ou Ruby
- Puppet est un logiciel qui gère la configuration des systèmes de type Unix et Microsoft Windows
Voyons un exemple
Pour aider à mettre les choses en perspective, nous avons établi une liste de mesures que nous pourrions prendre pour atteindre l’HA. Cela implique de concevoir un système avec un seul équilibreur de charge, trois serveurs web/applications et deux serveurs de base de données. Veuillez noter qu’au moins deux serveurs de base de données sont nécessaires pour établir le quorum des données dans les architectures HA.
- Une fois le cluster assemblé, configurez les serveurs web/applications pour reproduire les données du site en utilisant le NFS de votre choix.
- Cela activera l’équilibreur de charge et répartira le trafic entre les trois serveurs web/applications, en supprimant automatiquement les serveurs qui ont échoué.
- Créez une configuration MySQL Master-Master à l’aide de Percona XtraDB.
- Désignez une IP privée flottante, gérée par Keepalived, pour fonctionner comme basculement .
- Dirigez tous les serveurs web/applicatifs vers l’IP privée flottante, afin qu’elle se déplace automatiquement vers un serveur de base de données en ligne au cas où un serveur de base de données tomberait en panne.
Et voilà ! Cela entraînera une perturbation minimale pour les utilisateurs finaux car l’accès au serveur reste disponible, malgré tout point de défaillance.
Conclusion
Vous voulez donc mettre en place un système haute disponibité ?
Il est important de savoir que cela nécessite une planification minutieuse. Tout d’abord, vous devrez calculer le coût réel des temps d’arrêt. Celui-ci varie selon l’organisation et jouera un rôle clé dans la détermination de la quantité de temps d’arrêt acceptable pour une année donnée. Cette information est essentielle pour déterminer la bonne combinaison de configuration matérielle, d’outils logiciels et de maintenance du système.
L’ajout de composants matériels à un système peut entraver l’HA. Le fait d’attacher un serveur à votre cluster de serveurs augmente en fin de compte le risque de défaillance, il faut donc bien faire les choses.
C’est vrai – une architecture de système simplifiée est, eh bien, plus simple. Mais elle n’est pas sans compromis. Ce type de système doit être mis hors ligne pour chaque patch ou mise à niveau du système d’exploitation. Cette interruption sporadique affaiblira la disponibilité du système. Il en va de même pour les logiciels. Une seule erreur, comme une faute de frappe stupide ou une mauvaise installation, compromettra l’HA.
Le système HA idéal – qui reste en ligne plus de 99,999 % du temps – intègre la redondance, le basculement et la surveillance, tout en adaptant le matériel, le réseau, le système d’exploitation, le middleware et les correctifs et mises à niveau des applications en ligne, en temps réel, sans perturbation pour l’utilisateur final.
Layer 7 peut mettre en œuvre pour votre entreprise ce type de solution pour vous. Visitez notre page d’Infrastructures Cloud gérées pour en savoir d’avantage ou contactez-nous!
