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.