Temps de lecture: 8 minutes
La haute disponibilité est la description d’un système conçu pour être tolérant aux pannes, très fiable, fonctionne en continu sans intervention, ou ayant un seul point de défaillance. Ces systèmes sont très recherchés pour augmenter la disponibilité et le temps de disponibilité requis pour maintenir une infrastructure en fonctionnement sans problème. Les caractéristiques suivantes définissent un système à haute disponibilité.
Clustering haute disponibilité
Les clusters de serveurs haute disponibilité (ou clusters HA) sont définis comme un groupe de serveurs prenant en charge des applications ou des services pouvant être utilisés de manière fiable avec un minimum de temps d’arrêt. Ces clusters de serveurs fonctionnent à l’aide d’un type de logiciel spécialisé qui utilise la redondance pour atteindre les niveaux critiques de disponibilité de five9. À l’heure actuelle, environ 60 % des entreprises ont besoin de cinq à 9 ans ou plus pour fournir des services essentiels à leur entreprise.
Les logiciels haute disponibilité capitalisent sur les logiciels redondants installés sur plusieurs systèmes en regroupant ou en regroupant un groupe de serveurs se concentrant sur un objectif commun en cas de défaillance des composants. Sans cette forme de clustering, si l’application ou le site Web tombe en panne, le service ne sera pas disponible tant que les serveurs ne seront pas réparés. Le clustering HA résout ces situations en détectant les défauts et en redémarrant ou en remplaçant rapidement le serveur ou le service ou le serveur par un nouveau processus qui ne nécessite pas d’intervention humaine. Ceci est défini comme un modèle de « basculement ».
L’illustration ci-dessous montre un cluster simple à haute disponibilité à deux nœuds.
Les clusters haute disponibilité sont souvent utilisés pour les bases de données critiques, le partage de données, les applications et les sites Web de commerce électronique répartis sur un réseau. Les implémentations à haute disponibilité créent une redondance au sein d’un cluster pour supprimer un point de défaillance unique, y compris sur plusieurs connexions réseau et le stockage de données, qui peuvent être connectés de manière redondante via des réseaux de stockage géographiquement divers.
Les serveurs en cluster haute disponibilité utilisent généralement une méthodologie de réplication appelée Rythme cardiaque qui est utilisée pour surveiller l’état et la santé de chaque nœud au sein du cluster via une connexion réseau privée. Une circonstance critique que tous les logiciels de clustering doivent pouvoir traiter est appelée cerveau partagé, ce qui se produit lorsque toutes les liaisons internes privées tombent simultanément en panne, mais que les nœuds du cluster continuent de s’exécuter. Si cela se produit, chaque nœud du cluster peut déterminer de manière incorrecte que tous les autres nœuds sont en panne et tenter de démarrer des services que d’autres nœuds peuvent encore exécuter. Cette condition d’instances en double exécutant des services similaires, ce qui pourrait entraîner une corruption des données sur le système.
Une version typique d’un logiciel haute disponibilité fournit des attributs qui incluent à la fois la redondance matérielle et logicielle. Ces fonctionnalités incluent:
- La détection et la découverte automatiques des composants matériels et logiciels.
- Attribution autonome de rôles actifs et contingents à de nouveaux éléments.
- Détection des services logiciels défaillants, des composants matériels et d’autres constructions système.
- Surveillance et notification des composants redondants et du moment où ils doivent être activés.
- Possibilité d’adapter le cluster aux changements requis sans intervention externe.
Tolérance aux pannes
La tolérance aux pannes est définie comme la capacité de l’infrastructure d’un système à prévoir et à résister aux erreurs et à fournir une réponse automatique à ces problèmes s’ils sont rencontrés. La qualité principale de ces systèmes est des facteurs de conception avancés, qui peuvent être invoqués en cas de problème. Être capable de configurer une infrastructure qui envisage toutes les solutions possibles est une tâche considérable qui implique les connaissances et l’expérience nécessaires pour contrer les multiples préoccupations avant qu’elles ne surviennent. Les architectes de systèmes qui conçoivent de tels cadres disposeront à l’avance des méthodologies qui prévoient les moyens d’atténuer ces problèmes et de la capacité de mettre en œuvre ces cadres.
Les méthodes de redondance suivantes sont disponibles et devraient être revues au cours des premières étapes de conception et de mise en œuvre.
- Modèle N + 1 – Ce concept déduit la somme des équipements nécessaires (que nous appellerons ‘N’) pour maintenir l’ensemble du framework opérationnel, avec une sauvegarde de composant indépendante supplémentaire pour chacun des ‘N’ composants en cas de panne.
- Modèle N+2 – Similaire au modèle N+1 mais avec une couche de protection supplémentaire en cas de défaillance de deux composants.
- Modèle 2N – Cette modalité dispose d’une double sauvegarde redondante pour chaque élément afin de garantir que le framework du système est entièrement fonctionnel.
- Modèle 2N + 1 – Encore une fois, ce modèle est similaire au modèle 2N mais avec un composant supplémentaire pour ajouter une couche de protection tertiaire au framework du système.
Au fur et à mesure que les modèles passent de Nx à 2Nx, le facteur de coût augmente également de manière exponentielle, comme pour les systèmes vraiment redondants qui nécessitent une disponibilité. Ces modalités sont essentielles pour la stabilité et la disponibilité.
Fiabilité et fiabilité
L’un des locataires centraux d’un système à haute disponibilité est la disponibilité. La disponibilité est d’une importance primordiale, surtout si le but d’un système est de fournir un service essentiel comme les systèmes 911 qui répondent à des situations émergentes. En entreprise, un système de haute disponibilité est nécessaire pour garantir qu’un service vital reste en ligne. Un exemple serait un FAI ou un autre service qui ne peut tolérer une perte de fonction. Ces systèmes doivent être conçus avec une haute disponibilité et une tolérance aux pannes pour assurer la fiabilité et la disponibilité tout en minimisant les temps d’arrêt.
Gestion orchestrée des erreurs
En cas d’erreur, le système s’adaptera et compensera le problème tout en restant en ligne. La construction de ce type de système nécessite de la prévoyance et de la planification pour les imprévus. Être capable de prévoir les problèmes à l’avance et de planifier leur résolution est l’une des principales qualités d’un système à haute disponibilité.
Évolutivité
Si le système rencontre un problème comme un pic de trafic ou une augmentation de l’utilisation des ressources, la capacité du système à évoluer pour répondre à ces besoins doit être automatique et immédiate. L’intégration de fonctionnalités comme celles-ci dans le système permettra au système de réagir rapidement à tout changement dans la fonctionnalité systémique des processus d’architectures.
Disponibilité &Disponibilité de cinq 9
Cinq 9 est la norme de l’industrie pour mesurer le temps de disponibilité. Cette mesure peut être liée au système lui-même, aux processus du système dans un cadre ou au programme fonctionnant à l’intérieur d’une infrastructure. Cette estimation est souvent liée au programme fourni aux clients sous forme de formulaire ou de site Web ou d’application Web. La disponibilité des systèmes peut être mesurée comme le pourcentage de temps pendant lequel les systèmes sont disponibles en utilisant cette équation : x = (n-y) * 100 / n. Cette formule indique que « n” est le nombre total de minutes au cours d’un mois civil et « y” le nombre de minutes pendant lesquelles le service est inaccessible au cours d’un mois civil. Le tableau ci-dessous décrit les temps d’arrêt liés au pourcentage de « 9” représentés.
Comme nous pouvons le voir, plus le nombre de « 9” est élevé, plus le temps de disponibilité est fourni. L’objectif d’un système à haute disponibilité est d’atteindre un minimum de temps d’arrêt potentiel pour s’assurer que le système est toujours disponible pour fournir les services désignés.
Heartbeat
L’un des principaux composants de haute disponibilité s’appelle Heartbeat. Heartbeat est un démon qui fonctionne avec un logiciel de gestion de cluster tel que Pacemaker conçu spécifiquement pour la gestion des ressources de clustering à haute disponibilité. Ses caractéristiques les plus importantes sont:
- Aucun nombre maximum de nœuds spécifique ou fixe – Le rythme cardiaque peut être utilisé pour construire de grands clusters ainsi que des clusters élémentaires.
- Surveillance des ressources : les ressources peuvent être automatiquement redémarrées ou déplacées vers un autre nœud en cas d’échec.
- Un mécanisme de clôture nécessaire pour supprimer les nœuds défaillants du cluster.
- Une gestion des ressources affinée basée sur des politiques, les interdépendances des ressources et les contraintes.
- Un ensemble de règles basées sur le temps pour permettre différentes stratégies en fonction d’une période définie.
- Un groupe de scripts de ressources (pour des logiciels comme Apache, DB2, Oracle, PostgreSQL, etc.) inclus une gestion plus granulaire.
- Une interface graphique pour configurer, contrôler et surveiller les ressources et les nœuds.
Architecture de cluster
Disponibilité technique
Le premier segment d’un système hautement disponible est l’utilisation clairement conçue de serveurs d’applications en cluster conçus à l’avance pour répartir la charge entre l’ensemble du cluster, ce qui inclut la possibilité de basculer vers un système secondaire et éventuellement tertiaire.
La deuxième division comprend le besoin d’évolutivité de la base de données. Cela nécessite une mise à l’échelle, horizontale ou verticale, à l’aide de réplication maître multiple et d’un équilibreur de charge pour améliorer la stabilité et la disponibilité de la base de données.
La troisième caractéristique est la diversité géographique. Cela garantit que si une catastrophe naturelle frappe un lieu unique, cette défaillance n’entravera pas la capacité de fournir le service.
Le quatrième et peut-être le plus important composant est de fournir une méthodologie de réplication de sauvegarde et de reprise après sinistre. La possibilité d’assurer une sauvegarde fonctionnelle garantit la sécurité de nos données. L’utilisation de la dernière stratégie de sauvegarde (3-2-3) stipule que vous devez disposer de trois copies de vos données, sur deux types de supports différents, dans trois emplacements hors site géographiquement divers pour la reprise après sinistre.
Déploiement simple
Lorsque vous discutez du thème des déploiements simples, ils doivent être spécifiquement mappés à vos besoins métier spécifiques. Les caractéristiques suivantes bénéficieront à notre cadre opérationnel quelle que soit la verticale de l’industrie:
- Exigences de formation modestes
- Productivité accrue
- Cycle de vie prolongé
- Rentabilité
- Efficacité opérationnelle
- Mise en œuvre rapide
- Réduction des risques de sécurité
- Intégration simple
- Gestion simplifiée
Ces fonctionnalités définissent bon nombre des principaux aspects nécessaires pour garantir une solution de clustering hautement fiable et tolérante aux pannes. La haute disponibilité, à la base, doit être conçue avec ces caractéristiques à l’esprit. De telles fonctionnalités sont des éléments clés qui sont des actifs requis lors de l’adoption d’options de déploiement.
Objectifs des meilleures pratiques
Conception
L’objectif principal de tout l’objectif des meilleures pratiques de haute disponibilité est la conception, l’installation, le déploiement, l’intégration et le respect optimaux d’une convention standard au coût raisonnable le plus bas et à la complexité minimale tout en atteignant les objectifs benchmarked énoncés d’éliminer chaque point de défaillance du système.
Disponibilité
Tout d’abord, un objectif déterminé doit être défini avant la conception du système. Cela comprend l’établissement de l’Objectif du Point de récupération (RPO). Le RPO est la plus grande quantité de temps d’arrêt que votre entreprise est prête à perdre lors d’une panne majeure. Le matériel, les logiciels et les services auxiliaires de l’HA doivent tous avoir un RPO défini et testé.
Déploiement
Ensuite, le système doit être construit avec le matériel le plus robuste et le plus rentable disponible. Cela inclut les systèmes résilients aux pannes de courant et aux pannes matérielles, couvrant tout, des disques durs aux composants réseau, en passant par le système d’exploitation et l’application elle-même, englobant l’ensemble de la pile logicielle.
Evaluation&Testing
Une fois le système construit, une cheville ouvrière intégrale teste notre système cible pour s’assurer que le système de basculement est prêt à basculer en cas de défaillance de la source. Cela nécessite de préparer nos configurations réseau, nos serveurs, notre logiciel de réplication synchrone en temps réel et nos commutateurs pour passer du traitement de production source au système cible qui traite le changement à tout moment. Cette méthode utilisée dans ce scénario est connue sous le nom de système de « veille à chaud”. De plus, cela inclut la mise en place d’un calendrier de tests régimenté à mesure que le système est testé à nouveau régulièrement.
Réplication
Assurer une itération reproductible et reproductible de l’ensemble de la pile logicielle sur plusieurs régions est la clé de la durabilité, de la délivrabilité et de la solidité constantes du framework d’application. L’autre domaine de service important est le segment matériel reproductible, qui complète les cadres logiciels et de surveillance. Pouvoir s’appuyer sur une méthodologie de duplication dédiée est fondamental pour garantir un système entièrement tolérant aux pannes et fiable.
Surveillance &Suivi
Enfin, le suivi, l’évaluation et l’observation continus doivent être étroitement réglementés pour s’assurer que les objectifs de performance sont atteints. Tout écart par rapport à la norme doit être étudié et évalué afin de déterminer l’impact de la variance sur le système. Une fois cette disposition établie, une analyse de suivi devrait être effectuée pour déterminer si des modifications devraient être apportées pour inclure l’ajustement ou les modifications nécessaires pour ramener le système dans un nouvel état stable.
Conclusion
L’objectif principal d’un système à haute disponibilité est de prévenir et d’éliminer tous les points de défaillance uniques. Cela devrait inclure plusieurs plans d’action qui ont été testés et mis en place, prêts à réagir de manière indépendante et immédiate à toutes les perturbations, perturbations et pannes de service. Cela inclut les irrégularités matérielles, logicielles et applicatives. L’éradication des temps d’arrêt peut être accomplie avec la planification et la mise en œuvre composées et qualifiées d’un système. Un œil critique est nécessaire pour envisager et se préparer à tout événement ou catastrophe, qui pourrait entraver l’objectif principal de l’objectif de disponibilité déclaré et attendu. Un système de haute disponibilité bien mis en place peut atteindre cet objectif avec une planification et une conception appropriées, réduisant ou éliminant les perturbations et maximisant la disponibilité.
Une Planification minutieuse + Des Méthodologies de mise en œuvre Fiables + Des Plates-Formes Logicielles Stables + Une Infrastructure Matérielle Solide + Des Opérations Techniques Fluides + Des Objectifs de Gestion Prudents + Une Sécurité des Données cohérente + Des Systèmes de Redondance Prévisibles + Des Solutions de sauvegarde robustes + Plusieurs Options de récupération = 100% de Disponibilité
Nos équipes de support talentueuses sont composées de techniciens Linux et d’administrateurs Système expérimentés qui ont une connaissance approfondie de plusieurs technologies d’hébergement Web, en particulier celles discutées dans cet article.
Si vous êtes un serveur VPS entièrement géré, un Cloud Dédié, un Cloud Privé VMware, un Serveur Parent privé ou un propriétaire de serveur dédié et que vous n’êtes pas à l’aise avec l’exécution de l’une des étapes décrites, nous pouvons être joints par téléphone au @ 800.580.4985, un chat ou un ticket d’assistance pour vous aider dans ce processus.