La haute disponibilité fait référence à une méthodologie de conception visant à assurer la disponibilité d'un système tant qu'il est praticable. L'objectif est de réduire au maximum les causes d'interruption de services tels que les échecs système et les besoins de maintenance, mais également de détecter le plus rapidement possible les événements susceptibles d'interrompre les services et de restaurer le plus vite possible le système à la suite d'une interruption. Dans la pratique, les méthodes automatisées de détection et de récupération en cas d'interruptions de services deviennent vite nécessaires puisqu'il convient d'atteindre des niveaux de disponibilité plus élevés.
Sentinel est une application complexe qui compte plusieurs niveaux interdépendants et fournit un large éventail de services. Elle intègre en outre plusieurs systèmes tiers externes pour la collecte et le partage de données ainsi que pour le traitement des incidents. La plupart des solutions haute disponibilité permettent à ceux qui les implémentent de déclarer des dépendances entre les services nécessitant une haute disponibilité et les services dépendants, mais cela ne s'applique qu'aux services s'exécutant sur le cluster proprement dit. Des systèmes externes à Sentinel, tels que les sources d'événements, doivent être configurés séparément pour assurer la disponibilité requise par l'organisation et doivent également être configurés pour gérer correctement les périodes d'indisponibilité de Sentinel, comme en cas de basculement. Si les droits d'accès sont très restreints, par exemple, en cas de recours à des sessions authentifiées pour l'envoi/la réception de données entre Sentinel et un système tiers, ce dernier doit être configuré pour accepter les sessions au départ et à destination de n'importe quel noeud de cluster (Sentinel doit être configuré avec une adresse IP virtuelle pour ce faire). NetIQ ne peut pas garantir un quelconque niveau de disponibilité entre son produit et des systèmes tiers échappant à son contrôle.
Tous les clusters haute disponibilité nécessitent une certaine forme de stockage partagé pour pouvoir déplacer rapidement les données d'application d'un noeud de cluster à l'autre, en cas de défaillance du noeud d'origine. La haute disponibilité exigée pour le système de stockage proprement dit est généralement obtenue à l'aide de la technologie SAN (Storage Area Network) connectée aux noeuds de cluster à l'aide d'un réseau Fibre Channel. Cela dit, d'autres systèmes utilisent NAS (Network Attached Storage), iSCSI ou d'autres technologies qui autorisent le montage distant d'un système de stockage partagé. Le stockage partagé est surtout nécessaire pour qu'en cas de défaillance d'un noeud de cluster, le cluster puisse déplacer sans problème le système de stockage vers un nouveau noeud.
REMARQUE :Pour iSCSI, vous devez utiliser la plus grande unité de transfert des messages (Message Transfer Unit - MTU) prise en charge par votre matériel. Les plus grandes MTU contribuent à un stockage performant. Sentinel risque de rencontrer des problèmes si la latence et/ou la bande passante vers le stockage est inférieure à celle recommandée.
Sentinel peut utiliser deux approches de base pour le stockage partagé. La première place l'ensemble des composants présents sur le système de stockage partagé : fichiers binaires de l'application, configuration et données d'événement. En cas de basculement, le système de stockage est démonté du noeud primaire et déplacé vers le noeud de sauvegarde qui charge l'ensemble de l'application et de la configuration à partir de l'emplacement de stockage partagé. Dans la seconde approche, les données d'événement sont enregistrées sur le système de stockage partagé, mais les fichiers binaires et la configuration de l'application sont stockées sur chaque noeud de cluster. En cas de basculement, seules les données d'événement sont déplacées vers le noeud de sauvegarde.
Chaque approche a son lot d'avantages et d'inconvénients, mais la seconde approche permet à l'installation Sentinel d'utiliser des chemins d'installation compatibles FHS standard, de vérifier la création des paquetages RPM ainsi que d'installer des correctifs et de modifier la configuration à chaud de manière à réduire les temps d'interruption de service.
À l'aide d'un exemple, cette solution vous guide dans la procédure d'installation d'un cluster qui utilise le système de stockage partagé iSCSI et place les fichiers binaires/la configuration de l'application sur chaque noeud de cluster.
L'un des composants clés de tout environnement à haute disponibilité est de pouvoir disposer d'une méthode fiable et cohérente pour surveiller les ressources à haute disponibilité, ainsi que les ressources dont elles dépendent. Pour mener à bien cette surveillance, l'environnement à haute disponibilité SLE utilise un composant appelé Agent de ressource ayant pour mission de signaler l'état de chaque ressource et de démarrer ou d'arrêter cette dernière (à chaque demande).
Pour éviter les interruptions de service inutiles, l'état indiqué par les agents de ressource pour les ressources surveillées doit être fiable. Les faux-positifs (une ressource est censée avoir échoué, mais s'est rétablie de façon autonome) peuvent entraîner la migration des services (et les interruptions qui en découlent) alors que ce n'est pas nécessaire, tandis que les faux-négatifs (l'agent de ressource signale qu'une ressource fonctionne correctement alors que ce n'est pas le cas) peuvent empêcher le bon fonctionnement du service. D'un autre côté, la surveillance externe d'un service peut être compliquée. Par exemple, il se peut que le port d'un service Web réponde à une simple commande ping, mais qu'il ne fournisse pas la réponse appropriée lorsqu'une véritable demande est envoyée. Dans de nombreux cas, pour obtenir une mesure réellement précise, la fonctionnalité de test automatique doit être intégrée au service proprement dit.
Cette solution fournit à Sentinel un agent de ressource OCF de base pour lui permettre d'effectuer une surveillance des principaux échecs au niveau du système Sentinel, du matériel et du système d'exploitation. Actuellement, les fonctionnalités de surveillance externes de Sentinel sont basées sur des sondes de port IP, mais il existe un risque de faux-positifs et de faux-négatifs. Nous avons l'intention d'améliorer Sentinel et l'agent de ressource au fil du temps afin d'améliorer la fiabilité de ce composant.
Au sein d'un cluster haute disponibilité, les services critiques sont surveillés en permanence et redémarrés automatiquement sur les autres noeuds en cas d'échec. Cette automatisation peut toutefois induire des erreurs en cas de problème de communication avec le noeud primaire : bien que le service exécuté sur ce noeud semble arrêté, il continue en réalité à s'exécuter et à inscrire des données dans l'espace de stockage partagé. Dans ce cas, le démarrage d'un nouvel ensemble de services sur un noeud de sauvegarde peut facilement entraîner l'altération des données.
Pour éviter cette situation, les clusters utilisent diverses techniques collectivement appelées Fencing (isolement), notamment SBD (Split Brain Detection) et STONITH (Shoot The Other Node In The Head). L'objectif premier est d'éviter l'altération des données sur le système de stockage partagé.