Qu’est-ce que la haute disponibilité (HA)? Pourquoi votre entreprise doit le planifier –

De toute évidence, personne des plans pour les temps d’arrêt. Mais les problèmes sont inévitables, et si vous n’avez pas de plan en place pour les résoudre immédiatement et automatiquement, vous perdrez des revenus lorsque vos services seront interrompus. La haute disponibilité vous aidera à planifier les pires scénarios.

Qu’est-ce que la haute disponibilité?

La haute disponibilité (HA) est la pratique de minimiser tous les temps d’arrêt du serveur, idéalement jusqu’à zéro. Il intègre de nombreuses techniques, telles que la mise à l’échelle automatique, la surveillance en temps réel et les déploiements automatisés de mise à jour bleu / vert.

Le concept de base est assez simple: un serveur n’est pas un serveur. Deux serveurs sont un serveur. Plus vous prévoyez de redondance, plus votre service sera hautement disponible. Votre service ne doit pas subir d’interruptions même en cas de flamme d’un de vos composants.

Cela peut être réalisé avec quelque chose d’aussi simple qu’un groupe de mise à l’échelle automatique, que les services cloud comme AWS prennent très bien en charge. Si un serveur rencontre un problème, tel qu’une panne soudaine, l’équilibreur de charge le détecte comme ne répondant pas. Il peut ensuite détourner le trafic du serveur en panne vers les autres serveurs du cluster, voire créer une nouvelle instance si elle a besoin de la capacité.

Cette philosophie redondante s’applique à tous les niveaux de votre hiérarchie de composants. Si vous avez un microservice pour gérer le traitement d’image des médias téléchargés par l’utilisateur, par exemple, ce ne serait pas une bonne idée de l’exécuter simplement en arrière-plan sur l’une de vos machines. Si cette machine rencontre des problèmes, les utilisateurs peuvent ne pas être en mesure de télécharger, ce qui compte comme un temps d’arrêt partiel de votre service et peut être frustrant pour l’utilisateur final.

Parfois, vous devez garantie disponibilité pour les clients. Si vous garantissez une disponibilité de 99,999% dans un contrat de niveau de service (SLA), cela signifie que votre service ne peut pas être interrompu plus de cinq minutes par an. Cela rend la HA nécessaire dès le départ pour de nombreuses grandes entreprises.

Par exemple, des services comme AWS S3 sont livrés avec des SLA garantissant 99,9999999% (neuf 9) de la redondance des données. Cela signifie essentiellement que toutes vos données sont répliquées dans toutes les régions, ce qui les rend à l’abri de tout, sauf du scénario de météore géant impactant votre entrepôt de données. Même dans ce cas, avec une séparation physique, il pourrait être à l’abri des petits météores, ou à tout le moins, à l’abri d’un incendie d’entrepôt ou d’une panne de courant beaucoup plus réaliste.

Composants de bons systèmes HA

Qu’est-ce qui entraîne des temps d’arrêt? Sauf cas de force majeure, les temps d’arrêt sont généralement causés par une erreur humaine ou une défaillance aléatoire.

Les pannes aléatoires ne peuvent pas vraiment être planifiées, mais elles peuvent être planifiées avec des systèmes redondants. Ils peuvent également être détectés lorsqu’ils se produisent avec de bons systèmes de surveillance qui peuvent vous alerter des problèmes de votre réseau.

L’erreur humaine peut être planifiée. D’abord et avant tout, en minimisant le nombre d’erreurs avec des environnements de test soignés. Mais tout le monde fait des erreurs, même les grandes entreprises, vous devez donc avoir un plan en place lorsque des erreurs se produisent.

Mise à l’échelle automatique et redondance

La mise à l’échelle automatique est le processus de mise à l’échelle automatique du nombre de serveurs dont vous disposez, généralement pendant la journée, pour répondre aux pics de charge, mais également dans des situations de forte tension.

L’une des principales façons dont les services tombent en panne est le «câlin de la mort», lorsque des milliers d’utilisateurs affluent tous vers le site en masse, ou des pics de trafic d’une autre manière. Sans mise à l’échelle automatique, vous êtes foutu, car vous ne pouvez plus faire tourner les serveurs et devez attendre que la charge diminue ou faire démarrer manuellement une nouvelle instance pour répondre à la demande.

La mise à l’échelle automatique signifie que vous n’aurez jamais vraiment à gérer ce problème (même si vous devrez payer pour le temps serveur supplémentaire dont vous avez besoin). C’est en partie la raison pour laquelle des services tels que les bases de données sans serveur et les fonctions AWS Lambda sont si géniaux: ils évoluent extrêmement bien dès la sortie de la boîte.

Cependant, cela va au-delà de la simple mise à l’échelle automatique de vos serveurs principaux: si vous avez d’autres composants ou services dans votre réseau, ceux-ci doivent également pouvoir évoluer. Par exemple, vous devrez peut-être lancer des serveurs Web supplémentaires pour répondre aux besoins de trafic, mais si votre serveur de base de données est débordé, vous allez également avoir un problème.

Si vous souhaitez en savoir plus, vous pouvez lire notre article sur la mise en route de la mise à l’échelle automatique AWS.

Surveillance 24/7

La surveillance implique le suivi des journaux et des métriques de vos services en temps réel. Faire cela automatiquement avec des alarmes automatiques peut vous alerter sur les problèmes de votre réseau lorsqu’ils se produisent plutôt qu’après qu’ils affectent les utilisateurs.

Par exemple, vous pouvez définir une alarme pour qu’elle se déclenche lorsque votre serveur atteint 90% d’utilisation de la mémoire, ce qui peut indiquer une fuite de mémoire ou un problème avec une application surchargée.

Ensuite, vous pouvez configurer cette alarme pour indiquer à votre groupe de mise à l’échelle automatique d’ajouter une autre instance ou de remplacer l’instance actuelle par une nouvelle.

Mises à jour automatisées bleu / vert

Le scénario d’erreurs le plus courant est une mise à jour bâclée, lorsque votre code change et interrompt une partie imprévue de votre application. Cela peut être planifié avec des déploiements bleus / verts.

Un déploiement bleu / vert est un processus lent et progressif qui déploie vos modifications de code par étapes plutôt que toutes en même temps. Par exemple, imaginez que vous avez 10 serveurs exécutant le même bit de logiciel derrière un équilibreur de charge.

Un déploiement régulier peut simplement les mettre à jour tous immédiatement lorsque de nouvelles modifications sont appliquées, ou au moins les mettre à jour une par une pour éviter les temps d’arrêt.

Un déploiement bleu / vert déclencherait à la place un 11e serveur dans votre groupe de mise à l’échelle automatique et installerait les nouveaux changements de code. Ensuite, une fois qu’il était «vert» ou qu’il acceptait les demandes et qu’il était prêt à fonctionner, il remplacerait immédiatement l’un des serveurs «bleus» existants de votre groupe. Ensuite, vous rincez et répétez pour chaque serveur du cluster. Même si vous n’aviez qu’un seul serveur, cette méthode de mise à jour entraînerait pas de temps d’arrêt.

Mieux encore, vous pouvez immédiatement rétablir les modifications sur les serveurs bleus si des problèmes sont détectés avec vos systèmes de surveillance et vos alarmes. Cela signifie que même une mise à jour complètement bâclée ne supprimera pas votre service pendant plus de quelques minutes, idéalement pas du tout si vous avez plusieurs serveurs et que vous êtes capable de déployer la mise à jour lentement. Les déploiements bleu / vert peuvent être configurés pour ne mettre à jour que 10% de vos serveurs toutes les cinq minutes, par exemple, en déployant lentement la mise à jour sur une heure.