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.