test

Guide des notions fondamentales de Sun Cluster pour SE Solaris

Scénarios de basculement

Vous pouvez configurer les paramètres de gestion de sorte que l'allocation de la configuration de projet (/etc/project) soit opérationnelle durant le fonctionnement normal du cluster et dans les situations de commutation et de basculement.

Les rubriques suivantes présentent des exemples de scénarios.

Dans un environnement Sun Cluster, vous configurez une application comme partie d'une ressource. Vous configurez ensuite une ressource comme partie d'un groupe de ressources. En cas de panne, le groupe de ressources ainsi que les applications qui lui sont associées basculent sur un autre nœud. Dans les exemples suivants les ressources n'apparaissent pas de manière explicite. Supposons que chaque ressource n'a qu'une seule application.

Remarque –

un basculement intervient en fonction de l'ordre de préférence de la liste de nœuds définie par le RGM.

Les exemples présentés ci-après comportent les contraintes suivantes :

Bien que le nombre de parts attribuées reste le même, le pourcentage de temps CPU alloué à chaque application change après un basculement. Ce pourcentage dépend du nombre d'applications tournant sur le nœud et du nombre de parts attribuées à chaque application active.

Pour ces scénarios, supposons que nous avons les configurations suivantes :

Cluster à deux nœuds avec deux applications

Vous pouvez configurer deux applications sur un cluster à deux nœuds pour vous assurer que chaque hôte physique (phys-schost-1, phys-schost-2) sert de maître par défaut pour une application. Chaque hôte physique sert de nœud secondaire à l'autre hôte physique. Tous les projets associés à l'application 1 et à l'application 2 doivent être représentés dans les fichiers de bases de données de projets sur les deux nœuds. Lorsque le cluster fonctionne normalement, chaque application tourne sur son maître par défaut, où le temps UC lui est attribué par la fonction de gestion.

Lorsqu'un basculement ou une commutation a lieu, les deux applications tournent sur un seul nœud, où les parts précisées dans le fichier de configuration leur sont attribuées. Par exemple, cette entrée du fichier /etc/project indique que 4 parts sont allouées à l'application 1 et qu'une part est allouée à l'application 2. 

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

Le schéma indiqué ci-après présente le fonctionnement de cette configuration en situation normale et en cas de basculement. Le nombre de parts assignées ne change pas. Cependant, le pourcentage de temps CPU disponible pour chaque application peut changer. Il dépend du nombre de parts assignées à chaque processus qui exige du temps CPU.

Illustration : le contexte précédent décrit le graphique.

Cluster à deux nœuds avec trois applications

Sur un cluster à deux nœuds avec trois applications, vous pouvez configurer un hôte physique (phys-schost-1) comme maître par défaut d'une application. Vous pouvez configurer le second hôte physique (phys-schost-2) comme maître par défaut pour les deux applications restantes. Dans l'exemple suivant, supposons que le fichier de base de données des projets se trouve sur chaque nœud. Le fichier de base de données des projets ne change pas lorsqu'un basculement ou une commutation a lieu. 

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

Lorsque le cluster fonctionne normalement, 5 parts sont allouées à l'application 1 sur son maître par défaut, phys-schost-1. Ce nombre équivaut à 100 pour cent du temps UC parce que c'est la seule application qui demande du temps UC sur ce nœud. Trois parts et deux parts sont allouées respectivement aux applications 2 et 3 sur leur maître par défaut, phys-schost-2. L'application 2 reçoit 60 pour cent du temps CPU et l'application 3 reçoit 40 pour cent du temps CPU au cours du fonctionnement normal.

Si un basculement ou une commutation se produisent et que l'application 1 est basculée sur phys-schost-2, les parts des trois applications restent les mêmes. Toutefois, les pourcentages de ressources CPU sont allouées en fonction du fichier de la base de données des projets.

Le schéma indiqué ci-après présente le fonctionnement de cette configuration en situation normale et en cas de basculement.

Illustration : le contexte précédent décrit le graphique.

Basculement du groupe de ressources uniquement

Dans une configuration où plusieurs groupes de ressources ont le même maître par défaut, un groupe de ressources (et ses applications associées) peuvent basculer ou commuter sur un nœud secondaire. Pendant ce temps, le maître par défaut continue de fonctionner dans le cluster.

Remarque –

durant un basculement, l'application basculant se voit attribuer des ressources tel que spécifié dans le fichier de configuration du nœud secondaire. Dans cet exemple, les fichiers de base de données de projets sur les nœuds principal et secondaire ont les mêmes configurations.

Par exemple, cet échantillon de fichier de configuration spécifie que 1 part est allouée à l'application, 2 parts sont allouées à l'application 2 et 2 parts à l'application 3. 

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)

Le diagramme suivant illustre les opérations normales et de basculement de cette configuration, où RG-2, qui contient l'application 2, bascule sur phys-schost-2. Notez que le nombre de parts assignées ne change pas. Toutefois, le pourcentage de temps CPU disponible pour chaque application peut changer, en fonction du nombre de parts assignées à chaque application qui exige du temps CPU.

Illustration : le contexte précédent décrit le graphique.