Chapitre 9 Utilisation de médiateurs dans une configuration à deux chaînes

Ce chapitre décrit la fonction de Solstice DiskSuitegrâce à laquelle Sun Cluster peut exploiter des services de données à haute disponibilité au moyen de deux chaînes de disques seulement. Les sujets abordés sont énumérés ci-dessous. Pour de plus amples informations sur les concepts et fonctions de Solstice DiskSuite, consultez la documentation de Solstice DiskSuite.

• "Aperçu des médiateurs"

• "Configuration des médiateurs"

• "Défaillances traitées à l'aide de médiateurs"

• "Administration des médiateurs"

Aperçu des médiateurs

Avec Sun Cluster, une chaîne double, c'est-à-dire une configuration à deux chaînes seulement, doit pouvoir rester fonctionnelle, sans intervention de l'utilisateur, lorsqu'un noeud ou une chaîne d'unités tombe en panne.

Dans une configuration à deux chaînes, les répliques de base de données d'état des métapériphériques sont toujours disposées de telle sorte que la moitié exactement des répliques se trouvent sur une chaîne, et l'autre moitié sur la seconde chaîne. Un quorum (la moitié + 1 ou plus) de répliques est nécessaire pour que les données les plus récentes soient présentées. Lorsque, dans une configuration à deux chaînes, l'une des chaînes est indisponible, un quorum de répliques ne sera pas disponible.

Un médiateur est un hôte (noeud) où sont stockées les données de médiateur. Les données de médiateur fournissent des informations sur l'emplacement des autres médiateurs et contiennent un compteur de validations identique à celui stocké dans les répliques de base de données. Ce compteur est utilisé pour confirmer la synchronisation des données de médiateur avec les données des répliques de base de données. Les données de médiateur sont vérifiées individuellement avant d'être utilisées.

Solstice DiskSuite nécessite un quorum de répliques (la moitié + 1) pour identifier les moments pendant lesquels les conditions d'exploitation sont "sûres". L'intégrité des données est ainsi assurée. Dans une configuration à deux chaînes, il arrive qu'une seule chaîne soit accessible. Dans un tel cas, il est impossible d'obtenir un quorum de répliques. Si des médiateurs sont utilisés et qu'un quorum de médiateurs est présent, les données de médiateur permettent parfois de déterminer si les données de la chaîne accessible sont à jour et qu'elles peuvent être utilisées sans aucun risque.

L'utilisation de médiateurs permet à Sun Clusterde veiller à ce que la plupart des données les plus récentes soient présentées en cas de défaillance d'une seule chaîne dans une configuration à deux chaînes.

Médiateurs or

Dans certains scénarios de défaillance de la configuration à deux chaînes, le concept d'un médiateur or a été mis en oeuvre afin d'éviter toute intervention inutile de la part de l'utilisateur. Si exactement la moitié des répliques de base de données sont accessibles et qu'un événement entraîne la mise à jour des hôtes médiateurs, deux tentatives de mise à jour des médiateurs sont effectuées. Lors de la première mise à jour, il y a tentative de modifier le nombre de validations et de définir un médiateur non or. La deuxième mise à jour n'a lieu que si, au cours de la première phase, tous les hôtes médiateurs ont été contactés avec succès et que le nombre de répliques accessibles (et dont le nombre de validations a été augmenté) correspond exactement à la moitié du nombre total de répliques. Si toutes les conditions sont satisfaites, la deuxième mise à jour attribue l'état or aux médiateurs. Cet état permet l'exécution de la relève de l'hôte or sans intervention de l'utilisateur. Si l'état or n'est pas attribué, les données passent en mode de lecture seule, et l'utilisateur doit intervenir pour assurer la relève ou la reprise. Pour que l'utilisateur puisse lancer une relève ou une reprise, il faut qu'exactement la moitié des répliques soient accessibles.

L'état or n'est stocké que dans la mémoire vive (RAM) non rémanente. Une fois la relève effectuée, les données de médiateur sont de nouveau mises à jour. Si l'un des hôtes médiateurs ne peut pas être mis à jour, l'état or est annulé. Comme l'état est en mémoire RAM seulement, la réinitialisation d'un hôte médiateur entraîne l'annulation de l'état or. L'état par défaut pour les médiateurs est non or.

Configuration des médiateurs

Figure 9-1 illustre un système Sun Clusterà configuration à deux chaînes et médiateurs sur deux noeuds Sun Cluster.

La grappe ne contient toujours que deux hôtes médiateurs, quel que soit le nombre de noeuds. Les hôtes médiateurs sont les mêmes pour tous les ensembles de disques utilisant des médiateurs dans une grappe donnée, même lorsqu'un hôte médiateur n'est pas membre de l'ensemble de serveurs pouvant maîtriser l'ensemble de disques.

Pour simplifier la présentation, les configurations illustrées ici n'utilisent qu'un seul ensemble de disques et une configuration symétrique. Dans ces scénarios, le nombre d'ensembles de disques n'a pas d'importance. Lorsque son état est stable, l'ensemble de disques est sous la maîtrise de phys-hahost1.

Figure 9-1 Sun Cluster Système en état stable avec médiateurs

En temps normal, les médiateurs ne sont pas utilisés lorsque la moitié + 1 des répliques de base de données sont accessibles. Lorsqu'exactement la moitié des répliques sont accessibles, le compteur de validations du médiateur peut être utilisé pour déterminer si la moitié accessible est la plus récente. Pour que le bon nombre de validations soit utilisé, il faut que les deux médiateurs soient accessibles ou encore que le médiateur soit de type or. La moitié + 1 des médiateurs constitue un quorum de médiateurs. Le quorum de médiateurs n'est pas tributaire du quorum de répliques.

Défaillances traitées à l'aide de médiateurs

Avec les médiateurs, il est possible d'effectuer une reprise lors de pannes simples et de certaines pannes doubles. Comme Sun Cluster n'assure la reprise automatique qu'en cas de défaillance simple, c'est ce type de panne qui sera traité en détails dans les paragraphes qui suivent. Des scénarios de pannes doubles sont également présentés, mais seuls les processus de reprise généraux sont décrits.

Figure 9-1 illustre une configuration à deux chaînes dont l'état est stable. Il faut noter que des médiateurs sont établis sur les deux noeuds Sun Cluster. Par conséquent, les deux noeuds doivent fonctionner pour qu'un quorum de médiateurs existe et que des médiateurs puissent être utilisés. Si l'un des noeuds Sun Cluster tombe en panne, il y a alors quorum de répliques. Lorsqu'une relève de l'ensemble de disques est nécessaire, celle-ci est effectuée sans l'aide des médiateurs.

Les sections qui suivent présentent divers scénarios de défaillance et décrivent le rôle des médiateurs dans la reprise.

Panne sur un serveur unique

Figure 9-2 illustre une situation de défaillance d'un noeud Sun Cluster. Dans ce cas, le logiciel médiateur n'est pas utilisé, car un quorum de répliques est disponible. Le noeud phys-hahost2 Sun Clusterdeviendra le maître de l'ensemble de disques auparavant sous la maîtrise de phys-hahost1.

Le processus de reprise dans ce scénario est identique à celui exécuté lors de la défaillance d'un noeud Sun Cluster dans une configuration à plus de deux chaînes de disques. L'administrateur ne doit intervenir que s'il faut commuter l'ensemble de disques après que phys-hahost1 eut réintégré la grappe. Pour de plus amples informations sur la procédure de commutation, consultez la page de manuel haswitch(1M).

Figure 9-2 Défaillance d'un serveur Sun Clusterunique avec médiateurs

Défaillance d'une seule chaîne

Figure 9-3 illustre la défaillance d'une seule chaîne dans une configuration auparavant stable (voir Figure 9-1). Lorsque la chaîne 1 tombe en panne, les hôtes médiateurs de phys-hahost1 et phys-hahost2 sont mis à jour de façon à refléter cet événement, et le système continue de fonctionner, comme suit :

• Aucune relève n'est effectuée.

• Le noeud phys-hahost1 Sun Cluster reste propriétaire de l'ensemble de disques.

• Comme la chaîne 1 a subi une défaillance, elle doit être resynchronisée par la chaîne 2. Pour de plus amples informations sur le processus de resynchronisation, consultez le Guide de l'utilisateur de Solstice DiskSuite et la page de manuel metareplace(1M).

Le compteur de validations est incrémenté, et les médiateurs or sont conservés tels quels.

Figure 9-3 Défaillance d'une chaîne unique avec médiateurs

Dans ce scénario, l'administration nécessaire est la même que dans le cas d'une défaillance de chaîne unique dans une configuration à trois chaînes ou plus. Pour plus de détails sur ces procédures, reportez-vous au chapitre pertinent sur l'administration des unités d'expansion de disque.

Défaillance d'un hôte et d'une chaîne

Figure 9-4 illustre un cas de défaillance double où les deux chaînes 1 et phys-hahost2 tombent en panne. Si la chaîne est tombée en panne en premier, suivie de l'hôte, le médiateur de phys-hahost1 peut être or. Dans un tel cas, les conditions sont les suivantes :

• L'hôte phys-hahost1 contient un médiateur or.

• La moitié des médiateurs sont disponibles.

• La moitié des répliques sont accessibles.

• Le compteur de validations affiché par le médiateur de phys-hahost1 est identique au compteur de validations dans les répliques de la chaîne 2.

Figure 9-4 Défaillance multiple - Un serveur et une chaîne

Ce type de panne entraîne une reprise automatique par Sun Cluster. Si phys-hahost2 était maître de l'ensemble de disques, c'est phys-hahost1 qui devient maître de cet ensemble. Dans le cas contraire, phys-hahost1 reste le maître de l'ensemble de disques. Après réparation de la chaîne 1, les données de cette chaîne doivent être resynchronisées avec celles de la chaîne 2. Pour de plus amples informations sur le processus de resynchronisation, consultez le Guide de l'utilisateur de Solstice DiskSuite et la page de manuel metareplace(1M).

Bien qu'il soit possible d'effectuer une reprise dans un tel scénario, vous devez alors veiller à restaurer les composants défectueux immédiatement, puisqu'une troisième défaillance rendra la grappe indisponible.

S'il n'y a pas de médiateur or sur phys-hahost1, il n'y a pas de reprise automatique par Sun Cluster, et une intervention de l'administrateur est alors nécessaire. Dans ce cas, Sun Cluster génère un message d'erreur et l'hôte logique passe en mode de maintenance (lecture seule). Si une telle situation ou une autre panne multiple survient, cherchez assistance auprès de votre fournisseur de services.

Administration des médiateurs

Les hôtes médiateurs sont administrés au moyen des commandes medstat(1M) et metaset(1M). Utilisez ces commandes pour ajouter ou supprimer des hôtes médiateurs, et pour vérifier et réparer les données de médiateur. Pour plus de détails, voir les pages de manuel medstat(1M), metaset(1M) et mediator(7).

Comment ajouter des hôtes médiateurs

Effectuez cette procédure après avoir installé et configuré Solstice DiskSuite.

1. Lancez le logiciel de grappe sur tous les noeuds.

   Sur le premier noeud :

   # scadmin startcluster

   Sur les autres noeuds :

   # scadmin startnode

2. Identifiez le nom du lien privé pour chaque noeud.

   Utilisez la commande grep(1) pour identifier le lien privé contenu dans le fichier nom_grappe.cdb.

   hahost1# grep "^cluster.node.0.hostname" \ /etc/opt/SUNWcluster/conf/nom_grappe.cdb cluster.node.0.hostname : hahost0 phys-hahost1# grep "cluster.node.0.hahost0" \ /etc/opt/SUNWcluster/conf/nom_grappe.cdb | grep 204 204.152.65.33 hahost1# grep "^cluster.node.1.hostname" \ /etc/opt/SUNWcluster/conf/nom_grappe.cdb cluster.node.1.hostname : hahost1 hahost1# grep "cluster.node.1.hahost1" \ /etc/opt/SUNWcluster/conf/nom_grappe.cdb | grep 204 204.152.65.34

   Dans cet exemple, 204.152.65.33 est le lien privé pour hahost0 et 204.152.65.34 le lien privé pour hahost1.

3. Configurez les médiateurs à l'aide de la commande metaset(1M).

   Ajoutez chaque hôte avec connectivité à l'ensemble de disques comme médiateur pour cet ensemble. Exécutez chaque commande sur l'hôte qui est actuellement maître de l'ensemble de disques. Vous pouvez utiliser la commande hastat(1M) pour déterminer le maître actuel de l'ensemble de disques. Les informations produites par hastat(1M) pour l'hôte logique identifient le maître de l'ensemble de disques.

   hahost1# metaset -s ensemble_disquesA -a -m hahost0,204.152.65.33 hahost1# metaset -s ensemble_disquesA -a -m hahost1,204.152.65.34 hahost1# metaset -s ensemble_disquesB -a -m hahost0,204.152.65.33 hahost1# metaset -s ensemble_disquesB -a -m hahost1,204.152.65.34 hahost1# metaset -s ensemble_disquesC -a -m hahost0,204.152.65.33 hahost1# metaset -s ensemble_disquesC -a -m hahost1,204.152.65.34

   La commande metaset(1M) traite le lien privé comme un alias.

Comment vérifier l'état des données de médiateur

1. Exécutez la commande medstat(1M).

   phys-hahost1# medstat -s ensemble_disques

   Consultez la page de manuel medstat(1M) pour savoir comment interpréter la sortie. Si la sortie indique que les données de médiateur pour l'un ou l'autre des hôtes médiateurs d'un ensemble de disques donné sont erronées, procédez comme expliqué maintenant pour remédier au problème.

Comment corriger des données de médiateur erronées

La commande medstat(1M) permet de vérifier l'état des médiateurs. Effectuez cette procédure si la commande medstat(1M) signale un hôte médiateur défectueux.

1. Supprimez les hôtes médiateurs défaillants de tous les ensembles de disques touchés.

   Connectez-vous au noeud Sun Clusterpropriétaire de l'ensemble de disques touché et tapez :

   phys-hahost1# metaset -s ensemble_disques -d -m hôte_mediateur_défectueux

2. Restaurez l'hôte médiateur et ses alias :

   phys-hahost1# metaset -s ensemble_disques -a -m hôte_mediateur_défectueux, alias_hôte_physique, ...

   ---

   Remarque :

   Les liens privés doivent être attribués comme alias d'hôte médiateur. Spécifiez d'abord l'adresse IP de l'hôte physique et ensuite le lien privé HA sur la ligne de commande metaset(1M). Consultez la page de manuel mediator(7) pour plus de détails sur l'utilisation de la commande metaset(1M).

   ---

Gestion des défaillances sans reprise automatique

Dans certains cas de défaillancedouble, il ne peut y avoir de reprise automatique par Sun Cluster. Ces scénarios sont les suivants :

• Panne d'un noeud et d'une chaîne dans une configuration à deux chaînes en l'absence de médiateur or sur le noeud fonctionnel. Ce scénario est décrit plus en détails dans la "Défaillance d'un hôte et d'une chaîne".

• Données de médiateur erronées, non valides ou inexistantes sur l'un des noeuds ou les deux et sur l'une des chaînes lors d'une défaillance d'une configuration à deux chaînes. La tentative suivante d'acquisition des hôtes logiques échouera.

• Panne d'une chaîne dans une configuration à deux chaînes alors que le nombre de répliques intactes sur la chaîne fonctionnelle ne représente pas au moins la moitié du total des répliques de l'ensemble de disques défaillant. Lorsque DiskSuite tente de nouveau de mettre à jour ces répliques, une erreur système grave se produit.

• Une défaillance sans reprise automatique s'est produite, et il y a eu tentative de désactiver l'état de maintenance du ou des hôtes logiques affectés avant la fin de l'exécution des procédures de reprise manuelle.

Il est très important de vérifier régulièrement l'état des ensembles de disques, des répliques et des médiateurs. La commande medstat(1M) est utile à cette fin. Les données de médiateur, les répliques et les disques erronés doivent toujours être réparés sur-le-champ pour éviter toute complication dans les cas de pannes multiples.

Quand une défaillance de ce type se produit, l'une des séries suivantes de messages d'erreur est consignée :

ERREUR : metaset -s sortie de <ensemble_disques> -f -t avec code 66 
ERREUR : base de données non valide pour ensemble <ensemble_disques> 
AVIS : ensemble <ensemble_disques> libéré 
ERREUR : metaset -s sortie de <ensemble_disques> -f -t avec code 2 
ERREUR : données étiquetées pour ensemble <ensemble_disques> 
AVIS : ensemble <ensemble_disques> libéré 
ERREUR : metaset -s sortie de <ensemble_disques> -f -t avec code 3 
ERREUR : seulement 50 % des répliques et 50 % des hôtes médiateurs 
  sont disponibles pour <ensemble_disques> 
AVIS : ensemble 
<ensemble_disques> libéré

Les messages suivants finissent également par être affichés :

ERREUR : impossible de devenir propriétaire des hôtes logiques <hôte>, passage 
    au mode de maintenance 
ERREUR : l'état d'un hôte logique en mode de maintenance ne peut être modifié 
    que par intervention manuelle de l'administrateur 
ERREUR : l'administrateur doit trouver l'origine du problème et le corriger et, 
    au besoin, utiliser la commande haswitch pour désactiver l'état de 
maintenance des hôtes logiques

Il faut noter que dans le cas d'une défaillance double de ce type, les objectifs de haute disponibilité sont sacrifiés au profit du maintien de l'intégrité des données. Il est possible que les données ne soient pas disponibles pendant un certain temps. En outre, il n'est pas possible de garantir complètement la récupération ou l'intégrité des données.

Dans un tel cas, vous devez communiquer sur-le-champ avec votre fournisseur de services. Toute tentative de reprise manuelle pour ce type de panne double ne doit être effectuée que par un représentant autorisé. Des efforts bien planifiés et concertés sont nécessaires pour assurer la récupération des données. Ne faites rien avant l'arrivée du représentant.

Votre fournisseur examinera les messages consignés, évaluera le problème et effectuera si possible la réparation des éléments matériels endommagés. Votre fournisseur pourra ensuite tenter d'accéder aux données à l'aide de certaines des options metaset(1M) spéciales décrites à la page de manuel mediator(7). Ces options doivent toujours être utilisées avec la plus grande prudence afin d'éviter la récupération des mauvaises données.

Ne tentez jamais d'alterner l'accès entre les deux chaînes. Cela ne ferait qu'aggraver la situation.

Avant de restaurer l'accès client aux données, exécutez toujours toutes les procédures de validation disponibles sur l'ensemble de données en entier ou sur les données touchées par les transactions effectuées récemment sur cet ensemble.

Avant d'exécuter la commande haswitch(1M) pour désactiver le mode de maintenance des hôtes logiques, veillez à libérer la propriété de l'ensemble de disques associé.

Messages d'erreur relatifs aux médiateurs

Les messages de consignation système ou de console signalent un problème de médiateurs ou de données de médiateur. Utilisez la procédure "Comment corriger des données de médiateur erronées" pour traiter les problèmes.

Attention : medstat indique des données de médiateur erronées sur l'hôte %s 
    pour les ensembles de disques %s
 
Attention : medstat a détecté une erreur fatale dans les données de médiateur 
    sur l'hôte %s de l'ensemble de disques %s ! 
Attention : échec de medstat pour l'ensemble de disques %s