Chapitre 2. Avant de configurer le module complémentaire Red Hat High Availability (Haute Disponibilité)

Ce chapitre décrit les tâches à effectuer et les considérations à prendre en compte avant de procéder à l'installation et à la configuration du module complémentaire Red Hat High Availability. Ce chapitre est composé des sections suivantes.

Important

Assurez-vous que le déploiement du module complémentaire Red Hat High Availability correspond bien à vos besoins et peut être pris en charge. Consultez un représentant autorisé de Red Hat pour vérifier votre configuration avant de la déployer. En outre, prévoyez suffisamment de temps pour une période de rodage de la configuration afin de tester les différents modes d'échec.

2.1. Considérations pour une configuration générale

Vous pouvez configurer le module complémentaire Red Hat High Availability de différentes manières afin de mieux correspondre à vos besoins. Prenez en compte les considérations générales suivantes lorsque vous planifiez, configurez et implémentez votre déploiement.
Le nombre de nœuds de cluster pris en charge
Le nombre maximum de nœuds de cluster pris en charge par le module complémentaire High Availability (Haute Disponibilité) est 16.
Clusters de site unique
Seuls les clusters pour site unique sont entièrement pris en charge à l'heure actuelle. Les clusters s'étalant sur de multiples emplacements physiques ne sont pas officiellement pris en charge. Pour obtenir plus de détails et discuter des clusters sur de multiples sites, veuillez consulter votre représentant du support ou des ventes Red Hat.
GFS2
Même si un système de fichiers GFS2 peut être implémenté sur un système autonome ou en tant que partie d'une configuration de cluster, Red Hat ne prend pas en charge GFS2 en tant que système de fichiers à nœud unique. Red Hat prend en charge un certain nombre de systèmes de fichiers à nœud unique de haute performance qui sont optimisés pour un nœud unique et possèdent ainsi un plafond plus bas qu'un système de fichiers de cluster. Red Hat recommande l'utilisation de ces systèmes de fichiers plutôt que GFS2 dans le cas où un nœud unique doit monter le système de fichiers. Red Hat continuera à prendre en charge les systèmes de fichiers GFS2 à nœud unique pour ses clients existants.
Lorsque vous configurer un système de fichiers GFS2 en tant que système de fichiers de cluster, vous devez vous assurer que tous les nœuds du cluster ont accès au système de fichiers partagé. Les configurations de clusters asymétriques dans lesquelles certains nœuds ont accès au système de fichiers et pas d'autres ne sont pas prises en charge. Ceci ne requiert pas que tous les nœuds montent le système de fichiers GFS2.
Configuration du matériel sans point de défaillance unique (No-single-point-of-failure hardware configuration)
Les clusters peuvent inclure une matrice RAID à double contrôleur, de multiples canaux réseau liés, de multiples chemins d'accès entre les membres du cluster et le stockage, et des systèmes onduleurs (UPS, de l'anglais « un-interruptible power supply ») afin de s'assurer qu'aucune défaillance unique ne résulte en temps d'inactivité ou en perte de données.
Alternativement, un cluster de bas coût peut être installé pour offrir moins de disponibilité qu'un cluster sans point de défaillance unique. Par exemple, vous pouvez paramétrer un cluster avec une matrice RAID à contrôleur unique et un seul canal Ethernet.
Certaines alternatives à bas coût, comme les contrôleurs RAID hôtes, les RAID logiciels sans prise en charge de clusters, et les configurations parallèles SCSI avec multi-initiateur ne sont pas compatibles, ou ne sont pas appropriées pour une utilisation en tant que stockage partagé de cluster.
Assurance d'intégrité des données
Pour s'assurer de l'intégrité des données, seul un nœud peut exécuter un service de cluster et accéder aux données du cluster-service à la fois. L'utilisation d'interrupteurs d'alimentation dans la configuration du matériel du cluster active un nœud pour alimenter le cycle d'alimentation d'un autre nœud avant de redémarrer les services HA de ce nœud pendant le processus de basculement. Ceci empêche les deux nœuds d'accéder simultanément aux données et de les corrompres. Des périphériques fence (des solutions matérielles ou logicielles pouvant allumer, éteindre et redémarrer des nœuds de clusters à distance) sont utilisés pour garantir l'intégrité des données sous toutes conditions d'échec.
Liaison de canal Ethernet
Le quorum du cluster et la santé du nœud sont déterminés par la communication de messages parmi les nœuds du cluster via Ethernet. En outre, les nœuds de clusters utilisent Ethernet pour tout un éventail d'autres fonctions critiques de clusters (pour le fencing par exemple). Avec la liaison de canaux Ethernet, de multiples interfaces Ethernet sont configurées de manière à se comporter comme une seule interface, réduisant ainsi le risque de défaillance d'un point unique dans la connexion Ethernet commutée habituelle parmi les nœuds de clusters et le reste du matériel du cluster.
À partir de Red Hat Enterprise Linux 6.4, les modes de liaisons 0, 1 et 2 sont pris en charge.
IPv4 et IPv6
Le module complémentaire High Availability prend en charge les protocoles Internet IPv4 et IPv6. La prise en charge de IPv6 par le module complémentaire High Availability est une nouveauté de Red Hat Enterprise Linux 6.