FlipServer implémente une véritable recherche de haute disponibilité pour cinq neufs pour les systèmes critiques dans le cloud public

Haute disponibilité (HA) dans les clouds publics

La haute disponibilité (HA) est la capacité d'un système à fonctionner en continu sans défaillance pendant une période donnée. HA veille à ce qu'un système atteigne un niveau de performance opérationnelle convenu. Dans le domaine des technologies de l'information (TI), une norme de disponibilité largement répandue mais difficile à atteindre est connue sous le nom de disponibilité cinq-neuf, ce qui signifie que le système ou le produit est disponible 99,999 % du temps.

Les systèmes hautement disponibles doivent être bien conçus et minutieusement testés avant d'être utilisés. La planification de l'un de ces systèmes nécessite que tous les composants répondent à la norme de disponibilité souhaitée. Les capacités de sauvegarde des données et de basculement jouent un rôle important pour garantir que les systèmes haute disponibilité atteignent leurs objectifs de disponibilité. Les concepteurs de systèmes doivent également porter une attention particulière à la technologie de stockage et d'accès aux données qu'ils utilisent.

Comment fonctionne la haute disponibilité ?

Il est impossible que les systèmes soient disponibles à 100 % du temps, de sorte que les vrais systèmes à haute disponibilité visent généralement cinq neuf comme norme de performance opérationnelle.

Les trois principes suivants sont utilisés lors de la conception de systèmes haute disponibilité pour garantir une haute disponibilité :

  • Points de défaillance uniques. Un point de défaillance unique est un composant qui entraînerait la défaillance de l'ensemble du système s'il tombait en panne. Si une entreprise dispose d'un serveur exécutant une application, ce serveur est un point de défaillance unique. Si ce serveur échoue, l'application sera indisponible.
  • Croisement fiable. La redondance de ces systèmes est également importante. La redondance permet à un composant de sauvegarde de prendre le relais d'un composant défaillant. Lorsque cela se produit, il est nécessaire d'assurer un croisement ou un basculement fiable, qui consiste à passer du composant X au composant Y sans perdre de données ni affecter les performances.
  • Détectabilité des pannes. Les défaillances doivent être visibles et, idéalement, les systèmes ont une automatisation intégrée pour gérer la défaillance par eux-mêmes. Il devrait également y avoir des mécanismes intégrés pour éviter les défaillances de cause commune, lorsque deux systèmes ou composants ou plus échouent simultanément, probablement pour la même cause.

Pour garantir une haute disponibilité lorsque de nombreux utilisateurs accèdent à un système, l'équilibrage de charge devient nécessaire. L'équilibrage de charge distribue automatiquement les charges de travail aux ressources système, par exemple en envoyant différentes demandes de données à différents services hébergés dans une architecture cloud hybride. L'équilibreur de charge décide quelle ressource système est la plus capable de gérer efficacement quelle charge de travail. L'utilisation de plusieurs équilibreurs de charge pour ce faire garantit qu'aucune ressource n'est surchargée.

Les serveurs d'un système HA sont en clusters et organisés dans une architecture à plusieurs niveaux pour répondre aux demandes des équilibreurs de charge. Si un serveur du cluster tombe en panne, un serveur répliqué dans un autre cluster peut gérer la charge de travail désignée pour le serveur défaillant. Ce type de redondance permet un basculement où un composant secondaire prend en charge le travail d'un composant principal lorsque le premier composant échoue, avec un impact minimal sur les performances.

Plus un système est complexe, plus il est difficile d'assurer une haute disponibilité car il y a tout simplement plus de points de défaillance dans un système complexe.

Pourquoi la haute disponibilité est-elle importante ?

Les systèmes qui doivent être opérationnels la plupart du temps sont souvent ceux qui affectent la santé des personnes, le bien-être économique et l'accès à la nourriture, au logement et à d'autres éléments fondamentaux de la vie. En d'autres termes, ce sont des systèmes ou des composants qui auront un impact sévère sur la vie d'une entreprise ou de personnes s'ils tombent en dessous d'un certain niveau de performance opérationnelle.

Exemple : Comme mentionné précédemment, les véhicules autonomes sont des candidats clairs pour les systèmes HA. Par exemple, si le capteur avant d'une voiture autonome fonctionne mal et confond le côté d'un véhicule à 18 roues avec la route, la voiture s'écrasera. Même si, dans ce scénario, la voiture était fonctionnelle, la défaillance d'un de ses composants à atteindre le niveau de performance opérationnelle nécessaire a entraîné ce qui serait probablement un accident grave.

Comment la disponibilité est mesurée

La disponibilité peut être mesurée par rapport à un système 100 % opérationnel ou jamais défaillant, ce qui signifie qu'il n'a pas de pannes. En règle générale, un pourcentage de disponibilité est calculé comme suit :
Disponibilité = (minutes dans un mois - minutes de temps d'arrêt) * 100/minutes dans un mois

Les trois mesures utilisées pour mesurer la disponibilité sont les suivantes :
Temps moyen entre pannes (MTBF) est le temps prévu entre deux pannes pour le système donné.
Temps d'arrêt moyen (MDT) est le temps moyen pendant lequel un système n'est pas opérationnel.
Objectif de temps de récupération (RTO), également connu sous le nom de temps estimé de réparation, est le temps total qu'une panne planifiée ou une reprise après une panne imprévue prendra.

Ces métriques peuvent être utilisées pour les systèmes internes ou par les fournisseurs de services pour promettre aux clients un certain niveau de service comme stipulé dans un accord de niveau de service (SLA). Les SLA sont des contrats qui spécifient le pourcentage de disponibilité que les clients peuvent attendre d'un système ou d'un service.

Les mesures de disponibilité sont sujettes à interprétation quant à ce qui constitue la disponibilité du système ou du service pour l'utilisateur final. Même si les systèmes continuent à fonctionner partiellement, les utilisateurs peuvent le juger inutilisable en raison de problèmes de performances. Malgré ce niveau de subjectivité, les métriques de disponibilité sont formalisées concrètement dans des SLA, que le fournisseur de service ou le système est chargé de satisfaire.

Si un système ou un SLA fournit une disponibilité de 99,999 %, l'utilisateur final peut s'attendre à ce que le service soit indisponible pendant les périodes suivantes : 8 heures et 45 minutes d'indisponibilité du système par an. Les temps d'arrêt avec une norme de deux neufs sont encore plus dramatiques ; Une disponibilité de 99% équivaut à un peu plus de trois jours d'indisponibilité par an.

Comment atteindre la haute disponibilité

Les six étapes pour atteindre la haute disponibilité sont les suivantes :

  • Concevez le système avec la haute disponibilité à l'esprit. L'objectif de la conception d'un système HA est d'en créer un qui respecte les conventions de performance tout en minimisant les coûts et la complexité. Les points de défaillance doivent être éliminés avec une redondance fournie, si nécessaire.
  • Définir les indicateurs de réussite. Il est nécessaire de déterminer le niveau de disponibilité dont le système a besoin et quelles métriques seront utilisées pour le mesurer. Les fournisseurs de services impliquent les clients dans ce processus via un SLA.
  • Déployez le matériel. Le matériel doit être résistant et équilibrer qualité et rentabilité. Le matériel remplaçable à chaud et enfichable à chaud est particulièrement utile dans les systèmes HA car le matériel n'a pas besoin d'être mis hors tension lorsqu'il est remplacé ou lorsque des composants sont branchés ou débranchés.
  • Testez le système de basculement. Une fois le système opérationnel, le système de basculement doit être vérifié pour s'assurer qu'il est prêt à prendre le relais en cas de panne. Les applications doivent être testées et retestées au fil du temps, et un calendrier de test doit être mis en place.
  • Surveiller le système. Les performances du système doivent être suivies à l'aide de mesures et d'observations. Tout écart par rapport à la norme doit être consigné et évalué pour déterminer comment le système a été affecté et quels ajustements sont nécessaires.
  • Évaluer. Analysez les données recueillies lors de la surveillance, puis trouvez des moyens d'améliorer le système. Continuez à assurer la disponibilité à mesure que les conditions changent et que le système évolue.

Haute disponibilité et tolérance aux pannes

Comme la reprise après sinistre, la tolérance aux pannes permet de garantir une haute disponibilité. La tolérance aux pannes est la capacité d'un système à supporter et à anticiper les erreurs dans les fonctions du système et à réagir automatiquement en cas d'erreur. Un système tolérant aux pannes nécessite une redondance pour minimiser les perturbations en cas de panne matérielle.

Pour obtenir la redondance, les organisations informatiques doivent suivre une stratégie N+1, N+2, 2N ou 2N+1. N représente le nombre, disons, de serveurs nécessaires au fonctionnement du système. Un modèle N+1 nécessite tous les serveurs nécessaires au fonctionnement du système plus un serveur supplémentaire. Un modèle 2N nécessiterait deux fois plus de serveurs que le système en a normalement besoin. Une approche 2N + 1 signifie deux fois plus de serveurs que vous avez besoin plus un de plus. Ces stratégies garantissent que les composants critiques reçoivent au moins une sauvegarde.

Il est possible qu'un système soit hautement disponible mais non tolérant aux pannes. Par exemple, si un système HA rencontre un problème pour héberger une machine virtuelle sur un serveur dans un cluster de nœuds mais que le système n'est pas tolérant aux pannes, l'hyperviseur peut essayer de redémarrer la machine virtuelle dans le même cluster hôte. Cela réussira probablement si le problème est d'origine logicielle. Cependant, si le problème est lié au matériel du cluster, le redémarrer dans le même cluster ne résoudra pas le problème, car la VM est hébergée dans le même cluster cassé.

Une approche tolérante aux pannes dans la même situation aurait probablement une stratégie N+1 en place et redémarrerait la machine virtuelle sur un serveur différent dans un cluster différent. La tolérance aux pannes est plus susceptible de garantir un temps d'arrêt nul. Une stratégie de reprise après sinistre irait un peu plus loin pour garantir qu'il existe une copie de l'ensemble du système ailleurs à utiliser en cas de catastrophe.

Bonnes pratiques en matière de haute disponibilité

Un système hautement disponible doit être capable de récupérer rapidement de tout type d'état de défaillance afin de minimiser les interruptions pour l'utilisateur final. Les bonnes pratiques en matière de haute disponibilité sont les suivantes :

  • Éliminez les points de défaillance uniques ou tout nœud qui aurait un impact sur le système s'il devenait dysfonctionnel.
  • Assurez-vous que tous les systèmes et données sont sauvegardés pour une récupération rapide et facile.
  • Utilisez l'équilibrage de charge pour répartir le trafic des applications et du réseau entre les serveurs ou d'autres matériels. HAProxy est un exemple d'équilibreur de charge redondant.
  • Surveillez en permanence la santé des serveurs de base de données principaux.
  • Répartir les ressources dans différentes régions géographiques en cas de panne de courant ou de catastrophes naturelles.
  • Implémentez un basculement fiable. En termes de stockage, une matrice redondante de disques indépendants (RAID) ou un réseau de stockage (SAN) sont des approches courantes.
  • Mettre en place un système qui détecte les pannes dès qu'elles se produisent.
  • Concevoir des pièces de système pour une haute disponibilité et tester leur fonctionnalité avant la mise en œuvre.

Haute disponibilité et cloud

Comme mentionné ci-dessus, la haute disponibilité comporte un élément subjectif. Selon le système, le temps de disponibilité nécessaire varie. Dans le cloud computing, le niveau de service est particulièrement variable.

Le service FlipServe Cloud fournit au moins 99,9% de disponibilité pour leurs services HA ; plus récemment, et il existe certaines applications où nous pouvons atteindre une disponibilité de 99,99 %. La question demeure : quelles applications ont besoin de ce niveau de disponibilité ?