test

Guide d'administration du système Solaris Resource Manager 1.3

Situations de basculement

Sur Sun Cluster, on peut configurer Solaris Resource Manager de sorte que la méthode heuristique pour l'attribution des ressources qui est décrite dans la base de données des limites (/var/srm/srmDB) demeure inchangée en cas de fonctionnement normal de la grappe ou dans des situations de commutation et de basculement. Pour de plus amples informations, reportez-vous à la rubrique Exemple d'attribution de parts.

Les rubriques qui suivent présentent des exemples de scénarios.

Dans un environnement de grappe, une application est configurée comme un élément d'un groupe de ressources (GR). Lorsqu'une panne se produit, le groupe de ressources ainsi que les applications qui lui sont associées basculent sur un autre noeud. Dans les exemples qui suivent, l'Application 1 (App-1) est configurée dans le groupe de ressources GR-1, l'Application 2 (App-2) dans le groupe de ressources GR-2 et l'Application 3 (App-3) dans le groupe de ressources GR-3.

Bien que les nombres de parts attribuées restent les mêmes, le pourcentage de ressources d'UC alloué à chaque application change après le basculement, en fonction du nombre d'applications tournant sur le noeud et du nombre de parts attribué à chaque application active.

Dans ces scénarios, prenons les configurations suivantes :

Grappe à deux noeuds avec deux applications

Vous pouvez configurer deux applications dans une grappe à deux noeuds, de sorte que chaque hôte physique (schôte_phys_1, schôte_phys_2) fasse office de maître par défaut pour une application. Chaque hôte physique agit en qualité de noeud de secours pour l'autre hôte physique. Toutes les applications doivent être représentées dans les fichiers de base de données des limites de Solaris Resource Manager des deux noeuds. Lorsque la grappe fonctionne normalement, chaque application tourne sur son maître par défaut, où toutes les ressources de l'UC lui sont attribuées par Solaris Resource Manager.

Lorsqu'un passage ou un basculement 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, le fichier de configuration suivant précise que 80 parts sont attribuées à l'application 1, contre 20 pour l'application 2. 

# limadm set cpu.shares=80 App-1 
# limadm set cpu.shares=20 App-2 
...

Le schéma ci-après présente le fonctionnement normal ainsi que le fonctionnement d'un basculement de cette configuration. Notez que, bien que le nombre de parts attribué ne change pas, le pourcentage de ressources d'UC disponibles pour chaque application peut changer, selon le nombre de parts attribué à chaque processus réclamant du temps d'UC.

Le contexte qui précède décrit le graphique.

Grappe à deux noeuds avec trois applications

Vous pouvez configurer une grappe à deux noeuds avec trois applications de sorte qu'un hôte physique (schôte_phys_1) soit le maître par défaut d'une application et le second hôte physique (schôte_phys_2) le maître par défaut des deux autres applications. Dans l'exemple suivant, supposons que le fichier de base de données des limites se trouve dans chaque noeud. Le fichier de base de données des limites ne change pas lorsqu'une commutation ou qu'un basculement a lieu : 

# limadm set cpu.shares=50	 App-1
# limadm set cpu.shares=30	 App-2
# limadm set cpu.shares=20	 App-3
...

Lorsque la grappe fonctionne normalement, l'application 1 se voit attribuer toutes les parts disponibles sur son maître par défaut, soit schôte_phys_1. Cela équivaut à 100 pour cent des ressources de l'UC, étant donné qu'il s'agit de la seule application à demander des ressources de l'UC sur ce noeud. Les applications 2 et 3 reçoivent respectivement 30 et 20 parts sur leur maître par défaut, schôte_phys_2. L'Application 2 recevrait donc 60 pour cent et l'Application 3, 40 pour cent des ressources de l'UC pendant un fonctionnement normal.

Si un basculement ou une commutation se produit et que l'Application 1 bascule vers schôte_phys_2, les parts des trois applications restent les mêmes, mais les pourcentages de ressources de l'UC sont réattribués en fonction du fichier de base de données des limites.

Le schéma ci-après présente le fonctionnement normal ainsi que le fonctionnement d'un basculement de cette configuration.

Le contexte qui précède décrit le graphique.

Basculement du groupe de ressources seulement

Dans une configuration où plusieurs groupes de ressources ont le même maître par défaut, il est possible pour un groupe de ressources (et ses applications associées) d'effectuer un basculement ou d'être commuté vers un noeud de secours, tandis que le maître par défaut continue à tourner dans la grappe.

Remarque :

en tel cas, l'application qui bascule se voit attribuer des ressources tel que précisé dans le fichier de configuration figurant sur le noeud de secours. Dans cet exemple, les fichiers de bases de données des limites ont la même configuration sur le noeud principal et sur le noeud secondaire.

Par exemple, ce fichier de configuration spécifie que l'Application 1 reçoit 30 parts, l'Application 2, 60 parts et l'Application 3, 60 parts. 

# limadm set cpu.shares=30 App-1
# limadm set cpu.shares=60 App-2
# limadm set cpu.shares=60 App-3
...

Le diagramme qui suit illustre les opérations normales et de basculement de cette configuration, où GR-2, qui contient l'Application 2, bascule vers schôte_phys_2. Notez que, bien que le nombre de parts attribué ne change pas, le pourcentage de ressources d'UC disponibles pour chaque application peut varier, selon le nombre de parts attribué à chaque application réclamant du temps d'UC.

Le contexte qui précède décrit le graphique.