Configuration de Solaris Resource Manager dans un environnement Sun Cluster 2.2

Topologies valides

Vous pouvez installer Solaris Resource Manager sur n'importe quelle topologie Sun Cluster valide, dans des grappes comportant deux noeuds ou plus. Les topologies valides comprennent notamment :

• Symétrique -- deux noeuds configurés de façon identique. Ces deux noeuds offrent des services de données dans des conditions normales.

• Asymétrique -- Configuration à deux noeuds où un noeud agit en qualité de mécanisme de relève pour l'autre noeud.

• N+1 (étoile) -- Deux noeuds ou plus. Un noeud fait office de mécanisme de relève pour les autres noeuds.

• N à N (évolutive) -- Tous les serveurs sont directement connectés à un groupe de disques partagés. Ainsi, n'importe quel serveur peut prendre la relève en ce qui concerne les services de données.

Ces topologies sont décrites en détail au chapitre 1 du Guide d'installation du logiciel Sun Cluster 2.2, qui est accessible à l'adresse docs.sun.com.

Définition des besoins

Avant de configurer 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 passages et les reprises en cas de panne. Si vous configurez tous les noeuds de grappe de la même façon, les limites quant à l'usage 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 équation. Par exemple, si l'application 1 a pour maître phys-host1 mais si elle peut, suite à un passage ou une reprise en cas de panne, passer à phys-host2 ou à phys-host3, cette application doit figurer dans les fichiers de configuration de ces trois noeuds ( phys-host1, phys-host2 et phys-host3).

Solaris Resource Manager est très souple en ce qui concerne la configuration des paramètres d'usage et 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 aux sections suivantes pour la configuration de vos systèmes.

Configuration des paramètres de limites de mémoire

Lorsque vous utilisez Solaris Resource Manager avec Sun Cluster, vous devez configurer adéquatement les limites de mémoire, afin de prévenir une reprise en cas de panne, 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 fait 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 au site). Vous prévenez ainsi le va-et-vient et l'administrateur du 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'usage cumulatif

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 passage ou de reprise après une panne, les données cumulatives sur l'usage (usage 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'usage de Solaris Resource Manager, vous pouvez créer des scripts qui recueillent l'information cumulative des noeuds de la grappe. Étant 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. Pour de plus amples informations, voir Chapitre 8.

Situations de reprise en cas de panne

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 ainsi que dans les cas de commutation et de reprise.

Passez en revue les exemples suivants.

Grappe à deux noeuds avec deux applications

Vous pouvez configurer deux applications dans une grappe à deux noeuds, de sorte que chaque hôte matériel fasse office de maître par défaut pour une application. Chaque hôte matériel agit en qualité de noeud de secours pour l'autre hôte matériel. 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 parts lui sont attribuées (car Solaris Resource Manager attribue toutes les ressources disponibles). Lorsqu'un passage ou une reprise 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, l'exemple de fichier de configuration suivant précise que lorsque les deux applications tournent sur le même noeud, 80 parts sont attribuées à l'application 1, tandis que l'application 2 reçoit 20 parts :

#limadm set cpu.shares=80 app1
#limadm set cpu.shares=20 app2
...

Le schéma ci-après présente le fonctionnement normal et en cas de reprise de cette configuration.

Grappe à deux noeuds avec trois applications

Vous pouvez configurer une grappe à deux noeuds avec trois applications de sorte qu'un hôte physique ( phys-host1) soit le maître par défaut d'une application et le second hôte physique ( phys-host2) 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'un passage ou une reprise a lieu :

#limadm set cpu.shares=50	 app1
#limadm set cpu.shares=30	 app2
#limadm set cpu.shares=20	 app3
...

Lorsque la grappe fonctionne normalement, l'application 1 se voit attribuer toutes les parts disponibles sur son maître par défaut, soit phys-host1. Les applications 2 et 3 reçoivent 60 et 40 parts, respectivement, sur leur maître par défaut, soit phys-host2, car une partie proportionnelle de toutes les ressources disponibles est attribuée à chaque application. Si une reprise ou un passage a lieu et si l'application 1 passe à phys-host2, les parts des trois applications sont réattribuées conformément au fichier de base de données des limites. Ainsi, l'application 1 reçoit 50 parts, l'application 2 en obtient 30 et l'application 3 recueille 20 parts.

Le schéma ci-après présente le fonctionnement normal et en cas de reprise de cette configuration.

Reprise de l'hôte logique seulement

Dans une configuration pour laquelle plusieurs hôtes logiques ont le même maître par défaut, il est possible pour un hôte logique (et ses applications associées) d'effectuer une reprise ou de passer à un noeud de secours, tandis que le maître par défaut continue à tourner dans la grappe. En tel cas, l'application qui est transférée se voit attribuer les ressources disponibles qui sont précisées dans le fichier de configuration figurant dans le noeud de secours. Le comportement est identique à celui décrit pour les grappes à deux noeuds.

Le schéma ci-après présente le fonctionnement normal et en cas de reprise de cette configuration.