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.

• Les deux premières rubriques, “Cluster à deux noeuds avec deux applications“ et “Cluster à deux noeuds avec trois applications“, présentent des scénarios de basculement de noeuds complets.

• La rubrique “Basculement de groupes de ressources uniquement“ illustre les opérations de basculement d'une application seulement.

Dans un environnement de cluster, une application est configurée dans la ressource et une ressource est configurée dans un groupe de ressources (GR). Lorsqu'un échec se produit, le groupe de ressources et ses applications associées basculent sur un autre noeud. Dans les exemples suivants les ressources n'apparaissent pas de manière explicite. Supposons que chaque ressource n'a qu'une seule application.

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

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

• Application 1 (App-1) est configurée dans le groupe de ressources GR-1.

• Application 2 (App-2) est configurée dans le groupe de ressources GR-2.

• Application 3 (App-3) est configurée dans le groupe de ressources GR-3.

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

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

• Toutes les applications sont configurées sous un même projet.

• Chaque ressource n'a qu'une seule application.

• Les applications ne sont pas les seuls processus actifs sur les noeuds.

• Les bases de données de projets sont configurées de la même manière sur tous les noeuds du cluster.

Cluster à deux noeuds avec deux applications

Vous pouvez configurer deux applications sur un cluster à deux noeuds pour assurer que chaque hôte physique (phys-schost-1, phys-schost-2) fonctionne comme maître par défaut d'une application. Chaque hôte physique sert de noeud 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 la base de données de projets des deux noeuds. 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 noeud, où les parts précisées dans le fichier de configuration leur sont attribuées. Par exemple, cette entrée dans le fichier /etc/project spécifie que 4 parts sont attribuées à l'application 1 et 1 part à 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. Toutefois, le pourcentage de temps UC disponible pour chaque application peut changer en fonction du nombre de parts attribuées à chaque processus demandant du temps UC.

Cluster à deux noeuds avec trois applications

Sur un cluster à deux noeuds avec trois applications, vous pouvez configurer un hôte physique (phys-schost-1) comme maître par défaut d'une application et le deuxième hôte (phys-schost-2 ) comme maître par défaut des deux autres applications. Dans l'exemple suivant, supposons que le fichier de base de données des projets se trouve sur chaque noeud. 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 noeud. Trois et deux parts sont respectivement allouées 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 UC et l'application 3 reçoit 40 pour cent du temps UC au cours du fonctionnement normal.

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

• L'application 1, avec 5 parts, reçoit 50 pour cent de l'UC.

• L'application 2, avec 3 parts, reçoit 30 pour cent de l'UC.

• L'application 3, avec 2 parts, reçoit 20 pour cent de l'UC.

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

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 noeud secondaire. Pendant ce temps, le maître par défaut continue de fonctionner dans le cluster.

durant un basculement, l'application basculant se voit attribuer des ressources tel que spécifié dans le fichier de configuration du noeud secondaire. Dans cet exemple, les fichiers de la base de données de projets des noeuds principaux et secondaires ont la même configuration.

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 schéma suivant illustre le fonctionnement de cette configuration en situation normale et en cas de basculement, où GR-2 contenant l'application 2 bascule sur phys-schost-2. Notez que le nombre de parts assignées ne change pas. Toutefois, le pourcentage de temps UC disponible pour chaque application peut varier en fonction du nombre de parts assignées à chaque application nécessitant du temps UC.