Configuration de Solaris Resource Manager dans un environnement Sun Cluster 3.0 mis à jour

Topologies valides

Vous pouvez installer Solaris Resource Manager sur n'importe quelle topologie Sun Cluster 3.0 mis à jour valide. Pour une description détaillée des topologies valides, reportez-vous à la rubrique Sun Cluster 3.0 12/01 Concepts.

Définition des besoins

Avant de configurer le produit Solaris Resource Manager dans un environnement Sun Cluster, vous devez décider du type de contrôle et de suivi des ressources à préconiser pour les commutations et les basculements. Si vous configurez tous les noeuds de grappe de la même façon, les limites quant à l'utilisation seront appliquées de manière identique pour les noeuds principaux et les noeuds de secours.

Certes, les paramètres de configuration ne doivent pas être identiques pour toutes les applications, dans les fichiers de configuration de tous les noeuds, mais toutes les applications doivent au moins être représentées dans les fichiers de configuration de tous les maîtres éventuels de cette application. Par exemple, si l'application 1 a pour maître schôte_phys_1 mais si elle peut, suite à un passage ou une reprise en cas de panne, passer à schôte_phys_2 ou à schôte_phys_3, cette application doit figurer dans les fichiers de configuration de ces trois noeuds ( schôte_phys_1, schôte_phys_2 et schôte_phys_3).

Solaris Resource Manager est très souple en ce qui concerne la configuration des paramètres d'utilisation et paramètres cumulatifs : très peu de restrictions sont imposées par Sun Cluster. Les choix de configuration sont tributaires des besoins du site. Tenez compte des indications précisées dans les rubriques suivantes pour la configuration de vos systèmes.

Configuration des paramètres de limites de mémoire

Lorsque vous utilisez le produit Solaris Resource Manager avec Sun Cluster, vous devez configurer adéquatement les limites de mémoire, afin de prévenir un basculement, et donc un va-et-vient, inutiles des applications. En général :

• Ne définissez pas de limites de mémoire trop basses.

  Lorsqu'une application atteint sa limite de mémoire, elle peut faire l'objet d'une reprise. Cet aspect est particulièrement important pour les applications de base de données, pour lesquelles l'atteinte de la limite de mémoire virtuelle risque d'avoir des conséquences imprévues.

• Ne définissez pas des limites de mémoire identiques pour les noeuds principaux et les noeuds de secours.

  En effet, un va-et-vient risque de se produire si une application atteint sa limite de mémoire et fait l'objet d'une reprise dans un noeud de secours présentant une limite de mémoire identique. Définissez une limite de mémoire légèrement plus élevée pour le noeud de secours (cette différence dépend des applications, des ressources et des préférences qui prévalent sur le site). Vous prévenez ainsi le va-et-vient et l'administrateur système dispose d'un délai pour modifier les paramètres selon les besoins.

• Définissez des limites de mémoire Solaris Resource Manager en vue de l'équilibrage approximatif de la charge des situations à problèmes.

  Par exemple, pour éviter qu'une application qui s'emballe ne consomme une quantité excessive de ressources.

Utilisation des paramètres d'utilisation cumulative

Plusieurs paramètres de Solaris Resource Manager servent à assurer le suivi de la consommation cumulative des ressources système :parts d'UC, nombre de connexions et temps de connexion. Toutefois, en cas de commutation ou de basculement, les données cumulatives sur l'utilisation (utilisation de l'UC, nombre de connexions et temps de connexion) sont remises à zéro par défaut sur le nouveau maître, pour toutes les applications qui ont fait l'objet d'un passage ou d'une reprise. Les données cumulatives ne sont pas transférées dynamiquement d'un noeud à un autre.

Pour éviter de nuire à l'exactitude de la fonction de cumul de l'utilisation de Solaris Resource Manager, vous pouvez créer des scripts qui recueillent l'information cumulative des noeuds de la grappe. Etant donné qu'une application peut tourner sur n'importe lequel de ses maîtres éventuels durant une période de cumul, les scripts doivent recueillir l'information cumulative de tous les maîtres possibles d'une application donnée. Pour de plus amples informations, reportez-vous au Chapitre 9.

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.

• Les deux premières rubriques, Grappe à deux noeuds avec deux applications et Grappe à deux noeuds avec trois applications, présentent des scénarios de basculement pour des noeuds entiers.

• La rubrique Basculement du groupe de ressources seulement illustre le basculement d'une application seule.

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 :

• Toutes les applications sont configurées sous un noeud limite père commun.

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

• Les bases de données de limites sont configurées de la même manière sur chaque noeud de la grappe.

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.

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.

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

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

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

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

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.

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.