Dans le monde réel, il peut y avoir des situations où une baisse de performance de vos serveurs peut se produire à partir d’événements allant d’un pic soudain de trafic peut conduire à une panne de courant soudaine. Cela peut être bien pire et vos serveurs peuvent être paralysés – indépendamment du fait que vos applications soient hébergées dans le cloud ou sur une machine physique. De telles situations sont inévitables. Cependant, plutôt que d’espérer qu’elles ne se produisent pas, ce que vous devriez réellement faire, c’est vous préparer pour que vos systèmes ne rencontrent pas de défaillance.
La réponse au problème est l’utilisation d’une configuration ou d’une architecture de haute disponibilité (HA). L’architecture de haute disponibilité est une approche de définition des composants, des modules ou de la mise en œuvre des services d’un système qui assure une performance opérationnelle optimale, même en cas de charges élevées. Bien qu’il n’y ait pas de règles fixes de mise en œuvre des systèmes HA, il y a généralement quelques bonnes pratiques à suivre afin de tirer le maximum des ressources les plus faibles.
Pourquoi en avez-vous besoin ?
Définissons le temps d’arrêt avant d’aller plus loin. Le temps d’arrêt est la période pendant laquelle votre système (ou réseau) n’est pas disponible pour être utilisé, ou ne répond pas. Les temps d’arrêt peuvent causer d’énormes pertes à une entreprise, car tous ses services sont mis en attente lorsque ses systèmes sont en panne. En août 2013, Amazon est tombé en panne pendant 15 minutes (services web et mobiles), et a fini par perdre plus de 66 000 dollars par minute. Ce sont des chiffres énormes, même pour une entreprise de la taille d’Amazon.
Il existe deux types de temps d’arrêt – programmé et non programmé. Un temps d’arrêt programmé est le résultat de la maintenance, qui est inévitable. Il s’agit notamment de l’application de correctifs, de la mise à jour de logiciels ou même de modifications du schéma de la base de données. Un temps d’arrêt non programmé est, quant à lui, causé par un événement imprévu, comme une panne matérielle ou logicielle. Cela peut être dû à une panne de courant ou à la défaillance d’un composant. Les temps d’arrêt programmés sont généralement exclus des calculs de performance.
L’objectif premier de la mise en œuvre d’une architecture de haute disponibilité est de s’assurer que votre système ou application est configuré pour gérer différentes charges et différentes pannes avec un temps d’arrêt minimal ou nul. Les sont de multiples composants qui vous aident à y parvenir, et nous allons les aborder brièvement.
Comment la disponibilité est-elle mesurée ?
Les organisations qui prévoient d’utiliser pleinement une infrastructure cloud doivent également être capables de répondre aux demandes de disponibilité 24/7. La disponibilité peut être mesurée comme le pourcentage de temps pendant lequel les systèmes sont disponibles.
x = (n – y) * 100/n
Où n est le nombre total de minutes dans un mois civil et y est le nombre total de minutes pendant lesquelles le service est indisponible dans le mois civil donné. La haute disponibilité désigne simplement un composant ou un système qui est opérationnel en permanence pendant une période de temps souhaitable. La norme de disponibilité d’un produit ou d’un système, largement répandue mais presque impossible à atteindre, est appelée disponibilité « cinq 9 » (99,999 %). La haute disponibilité est une exigence pour toute entreprise qui espère protéger ses activités contre les risques liés à une panne de système. Ces risques, peuvent conduire à des millions de dollars de perte de revenus.
Est-ce que le jeu en vaut vraiment la chandelle ?
Le fait d’opter pour une architecture de haute disponibilité vous donne de meilleures performances, c’est bien, mais cela a aussi un coût important. Vous devez vous demander si vous pensez que la décision est justifiée du point de vue financier.
Il faut décider si le temps de disponibilité supplémentaire vaut vraiment la somme d’argent qui doit y être consacrée. Vous devez vous demander à quel point les temps d’arrêt potentiels peuvent être dommageables pour votre entreprise et quelle est l’importance de vos services dans le fonctionnement de votre entreprise.
Comment y parvenir ?
Maintenant que vous avez décidé d’y aller, discutons des moyens de le mettre en œuvre. De manière non intuitive, ajouter plus de composants à un système n’aide pas à le rendre plus stable et à atteindre la haute disponibilité. Cela peut même conduire à l’inverse, car plus de composants augmente la probabilité de défaillances. Les conceptions modernes permettent de répartir les charges de travail sur plusieurs instances, comme un réseau ou un cluster, ce qui permet d’optimiser l’utilisation des ressources, de maximiser le rendement, de minimiser les temps de réponse et d’éviter la surcharge d’un système dans le processus connu sous le nom d’équilibrage des charges. Il s’agit également de passer à une ressource de secours comme un serveur, un composant ou un réseau en cas de défaillance d’un actif, connu sous le nom de systèmes de basculement.
Utilisation de serveurs d’applications multiples :
Imaginez que vous avez un seul serveur pour rendre vos services et qu’un pic soudain de trafic entraîne sa défaillance (ou le fait planter). Dans une telle situation, jusqu’à ce que votre serveur soit redémarré, aucune autre demande ne peut être servie, ce qui entraîne un temps d’arrêt.
La solution évidente ici est de déployer votre application sur plusieurs serveurs. Vous devez répartir la charge entre tous ceux-ci, de sorte qu’aucun d’entre eux ne soit surchargé et que le rendement soit optimal. Vous pouvez également déployer des parties de votre application sur différents serveurs. Par exemple, il pourrait y avoir un serveur distinct pour traiter les mails ou un autre pour traiter les fichiers statiques comme les images (comme un Content Delivery Network).
Scaling Databases:
Les bases de données sont les moyens les plus populaires et peut-être l’un des plus simples conceptuellement pour sauvegarder les données des utilisateurs. Il faut se rappeler que les bases de données sont aussi importantes pour vos services que vos serveurs d’applications. Les bases de données s’exécutent sur des serveurs distincts (comme l’Amazon RDS) et sont également sujettes aux crashs. Le pire, c’est que les crashs de bases de données peuvent conduire à une perte de données utilisateur, ce qui peut s’avérer coûteux.
La redondance est un processus qui crée des systèmes avec des niveaux élevés de disponibilité en réalisant la détectabilité des pannes et en évitant les pannes de cause commune. Ceci peut être réalisé en maintenant des esclaves, qui peuvent intervenir si le serveur principal tombe en panne. Un autre concept intéressant de mise à l’échelle des bases de données est le sharding. Un shard est une partition horizontale dans une base de données, où les rangées de la même table qui est ensuite exécutée sur un serveur séparé.
Lieux géographiques diversifiés:
Mettre à l’échelle vos applications puis vos bases de données est un très grand pas en avant, mais que se passe-t-il si tous les serveurs sont au même endroit physique et que quelque chose de terrible comme une catastrophe naturelle affecte le centre de données dans lequel vos serveurs sont situés ? Cela peut entraîner des temps d’arrêt potentiellement énormes.
Il est donc impératif que vous gardiez vos serveurs à différents endroits. La plupart des services web modernes vous permettent de sélectionner l’emplacement géographique de vos serveurs. Vous devriez choisir judicieusement pour vous assurer que vos serveurs sont répartis dans le monde entier et non localisés dans une zone.
Dans ce post, j’ai essayé d’aborder les idées de base qui forment l’idée d’une architecture de haute disponibilité. En dernière analyse, il est évident qu’aucun système unique ne peut résoudre tous les problèmes. Vous devez donc évaluer votre situation avec soin et décider des options qui vous conviennent le mieux. Nous espérons que cela vous a fait découvrir le monde de l’architecture de haute disponibilité et vous a aidé à décider comment vous y prendre pour y parvenir vous-même.
Quelles sont les meilleures pratiques ?
Afin d’endiguer les défaillances du système et de tenir à distance les temps d’arrêt prévus et imprévus, l’utilisation d’une architecture de haute disponibilité (HA) est fortement recommandée, en particulier pour les applications critiques. Les experts en disponibilité insistent sur le fait que pour qu’un système soit hautement disponible, ses composants doivent être bien conçus et rigoureusement testés. La conception et la mise en œuvre ultérieure d’une architecture de haute disponibilité peuvent s’avérer difficiles étant donné la vaste gamme d’options logicielles, matérielles et de déploiement. Cependant, un effort réussi commence généralement par une définition claire et une compréhension approfondie des besoins de l’entreprise. L’architecture choisie doit pouvoir répondre aux niveaux souhaités de sécurité, d’évolutivité, de performance et de disponibilité.
La seule façon de garantir que les environnements de calcul ont un niveau souhaitable de continuité opérationnelle pendant les heures de production est de les concevoir avec une haute disponibilité. En plus de concevoir correctement l’architecture, les entreprises peuvent maintenir les applications cruciales en ligne en observant les meilleures pratiques recommandées pour la haute disponibilité.
- Sauvegardes, récupération et réplication des données
La marque d’un bon plan de protection des données qui protège contre les défaillances du système est une stratégie de sauvegarde et de récupération solide. Les données précieuses ne devraient jamais être stockées sans sauvegardes appropriées, sans réplication ou sans la possibilité de recréer les données. Chaque centre de données doit prévoir à l’avance la perte ou la corruption de données. Les erreurs de données peuvent créer des problèmes d’authentification des clients, endommager les comptes financiers et, par la suite, la crédibilité de la communauté des affaires. La stratégie recommandée pour maintenir l’intégrité des données consiste à créer une sauvegarde complète de la base de données principale, puis à tester progressivement le serveur source pour détecter les corruptions de données. La création de sauvegardes complètes est au premier plan de la récupération d’une panne catastrophique du système.
- Clustering
Même avec la plus haute qualité d’ingénierie logicielle, tous les services d’application sont voués à échouer à un moment donné. La haute disponibilité consiste à fournir des services applicatifs indépendamment des défaillances. La mise en grappe peut fournir des services d’application à basculement instantané en cas de panne. Un service d’application qui est « conscient du cluster » est capable d’appeler des ressources à partir de plusieurs serveurs ; il se rabat sur un serveur secondaire si le serveur principal est hors ligne. Un cluster haute disponibilité comprend plusieurs nœuds qui partagent des informations via des grilles de mémoire de données partagées. Cela signifie que n’importe quel nœud peut être déconnecté ou arrêté du réseau et le reste du cluster continuera à fonctionner normalement, tant qu’au moins un seul nœud est pleinement fonctionnel. Chaque nœud peut être mis à niveau individuellement et réintégré pendant que le cluster fonctionne. Le coût élevé de l’achat de matériel supplémentaire pour mettre en œuvre un cluster peut être atténué par la mise en place d’un cluster virtualisé qui utilise les ressources matérielles disponibles.
- Équilibrage de la charge du réseau
L’équilibrage de la charge est un moyen efficace d’augmenter la disponibilité des applications web critiques. Lorsque des instances de défaillance de serveur sont détectées, elles sont remplacées de manière transparente lorsque le trafic est automatiquement redistribué vers les serveurs qui fonctionnent encore. L’équilibrage de la charge n’entraîne pas seulement une haute disponibilité, il facilite également l’évolutivité progressive. L’équilibrage de la charge du réseau peut être réalisé via un modèle « pull » ou « push ». Il facilite des niveaux plus élevés de tolérance aux pannes dans les applications de service.
- Solutions de basculement
L’architecture de haute disponibilité consiste traditionnellement en un ensemble de serveurs faiblement couplés qui ont des capacités de basculement. Le basculement est essentiellement un mode opérationnel de secours dans lequel les fonctions d’un composant du système sont assumées par un système secondaire dans le cas où le principal est hors ligne, soit en raison d’une panne, soit en raison d’un temps d’arrêt planifié. Un « basculement à froid » se produit lorsque le serveur secondaire n’est démarré qu’après l’arrêt complet du serveur primaire. Un « basculement à chaud » se produit lorsque tous les serveurs fonctionnent simultanément et que la charge est entièrement dirigée vers un seul serveur à un moment donné. Dans les deux scénarios, les tâches sont automatiquement transférées à un composant du système de secours, de sorte que le processus reste aussi transparent que possible pour l’utilisateur final. Le basculement peut être géré via le DNS, dans un environnement bien contrôlé.
- Dondance géographique
La géo-redondance est la seule ligne de défense lorsqu’il s’agit d’empêcher une défaillance du service face à des événements catastrophiques tels que des catastrophes naturelles qui provoquent des pannes de système. Comme dans le cas de la géo-réplication, plusieurs serveurs sont déployés sur des sites géographiques distincts. Ces sites doivent être répartis dans le monde entier et non localisés dans une zone spécifique. Il est essentiel d’exécuter des piles d’applications indépendantes dans chacun des sites, de sorte qu’en cas de panne dans un site, l’autre puisse continuer à fonctionner. Idéalement, ces emplacements devraient être complètement indépendants les uns des autres.
- Planifier pour l’échec
Malgré le fait que l’application des meilleures pratiques pour la haute disponibilité est essentiellement la planification pour l’échec ; il y a d’autres actions qu’une organisation peut prendre pour augmenter leur préparation en cas de défaillance du système conduisant à un temps d’arrêt. Les organisations devraient conserver les données relatives aux pannes ou à la consommation de ressources qui peuvent être utilisées pour isoler les problèmes et analyser les tendances. Ces données ne peuvent être recueillies que par une surveillance continue de la charge de travail opérationnelle. Un service d’assistance à la récupération peut être mis en place pour recueillir des informations sur les problèmes, établir l’historique des problèmes et commencer à résoudre immédiatement les problèmes. Un plan de reprise doit non seulement être bien documenté, mais aussi être testé régulièrement pour s’assurer de son caractère pratique en cas d’interruptions non planifiées. La formation du personnel à l’ingénierie de la disponibilité améliorera ses compétences en matière de conception, de déploiement et de maintenance des architectures de haute disponibilité. Des politiques de sécurité doivent également être mises en place pour limiter les incidences de pannes de système dues à des failles de sécurité.
Exemple : Architecture de haute disponibilité FileCloud
Le schéma suivant explique comment les serveurs FileCloud peuvent être configurés pour la haute disponibilité afin d’améliorer la fiabilité du service et de réduire les temps d’arrêt. Cliquez ici pour plus de détails.