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.