Configuration de projets de services de données

Les services de données peuvent être configurés pour démarrer sous un nom de projet Solaris lorsqu'ils sont connectés à l'aide du RGM. La configuration associe une ressource ou un groupe de ressources géré par le RGM à une ID de projet Solaris. La correspondance entre votre ressource ou groupe de ressources et une ID de projet vous permet d'utiliser les outils de contrôle sophistiqués de l'environnement Solaris pour gérer les charges de travail et la consommation au sein du cluster.

cette configuration n'est possible que si la version actuelle du logiciel Sun Cluster fonctionne sous Solaris 9.

L'utilisation des fonctions de gestion de Solaris dans un environnement de cluster vous permet d'assurer que les applications les plus importantes gardent la priorité lorsqu'un noeud est partagé avec d'autres applications. Il arrive que les applications partagent un noeud si vous avez des services consolidés ou si les applications ont basculé. L'utilisation des fonctions de gestion décrites ci-dessus permettent d'améliorer la disponibilité d'une application critique en empêchant d'autres applications non prioritaires de consommer trop de ressources du système tel que le temps UC.

la documentation Solaris se rapportant à cette fonction désigne le temps UC, les processus, les tâches et les composants similaires sous le terme de « ressources ». La documentation Sun Cluster utilise quant à elle le terme de « ressources » pour désigner les entités sous le contrôle du RGM. Dans la rubrique suivante, on utilisera le terme de« ressource » en référence aux entités de Sun Cluster qui sont sous le contrôle du RGM et le terme de « ressources système » en référence au temps UC, aux processus et aux tâches.

Cette rubrique décrit la procédure de configuration des services de données pour le lancement de processus dans un project(4) Solaris 9 spécifié. Cette rubrique présente également plusieurs scénarios de basculement et des suggestions pour l'utilisation des fonctions de gestion de l'environnement Solaris. Pour consulter la documentation complète de la fonction de gestion, reportez-vous à la rubrique System Administration Guide: Resource Management and Network Services de la Solaris 9 System Administrator Collection.

Pour configurer des ressources ou groupes de ressources en vue de l'utilisation des fonctions de gestion Solaris dans un cluster, procédez de la manière suivante :

1. Configurez les applications dans la ressource.

2. Configurez les ressources dans le groupe de ressources.

3. Activez les ressources du groupe de ressources.

4. Mettez le groupe de ressource à l'état géré.

5. Créez un projet Solaris pour votre groupe de ressources.

6. Configurez les propriétés standard pour associer le nom du groupe de ressources au projet que vous avez créé à l'étape 5.

7. Mettez le groupe de ressources en ligne.

Pour configurer les propriétés standard Nom_projet_ressource ou Nom_projet_GR afin d'associer l'ID de projet Solaris à la ressource ou au groupe de ressources, utilisez l'option -y avec la commande scrgadm(1M). Définissez les valeurs des propriétés de la ressource ou du groupe de ressources. Pour consulter les définitions des propriétés, reportez-vous à la rubrique “Standard Properties” dans le document Sun Cluster 3.1 Data Services Installation and Configuration Guide. Reportez-vous aux documents r_properties(5) et rg_properties(5) pour de plus amples informations sur les propriétés.

Le nom de projet spécifié doit figuré dans la base de données des projets ( /etc/project) et le superutilisateur doit être configuré comme membre du projet nommé. Reportez-vous à la rubrique “Projects and Tasks” du document System Administration Guide: Resource Management and Network Services de la collection Solaris 9 System Administratorpour de plus amples informations concernant la conception de la base données de noms de projets. Reportez-vous à la rubrique project( 4) pour consulter la description de la syntaxe des fichiers de projets.

Lorsque le RGM met les ressources ou les groupes de ressources en ligne, il lance les processus connexes sous le nom du projet.

les utilisateurs peuvent à tout moment associer la ressource ou le groupe de ressources à un projet. Toutefois, le nom de projet ne sera effectif qu'au moment où la ressource ou le groupe de ressources aura été mis hors ligne puis de nouveau en ligne à l'aide du RGM.

Le lancement des ressources ou des groupes de ressources sous le nom de projet vous permet de configurer les fonctions indiquées ci-après pour gérer les ressources système au sein du cluster.

• Comptabilité étendue : elle constitue un moyen souple d'enregistrer la consommation d'une tâche ou d'un procédé. La comptabilité étendue vous permet d'examiner l'historique de l'utilisation et d'évaluer les besoins en capacité des charges de travail futures.

• Contrôles : ce mécanisme permet d'appliquer des contraintes aux ressources système. On peut empêcher les processus, tâches et projets de surconsommer certaines ressources système.

• Fair Share Scheduling (FSS) : cette fonction offre la possibilité de contrôler l'allocation de temps UC aux charges de travail, en fonction de leur importance. L'importance des charges de travail est définie par le nombre de parts de temps UC attribué à chaque charge. Reportez-vous à la rubrique dispadmin (1M) pour consulter la procédure de définition de FSS comme programmateur par défaut. Consultez également les documents priocntl(1), ps(1) et FSS(7) pour de plus amples informations.

• Pools : cette fonction offre la possibilité d'utiliser des partitions pour les applications interactives en fonction des besoins de l'application. Les pools permettent de segmenter un serveur qui prend en charge un certain nombre d'applications différentes. Grâce à l'utilisation de pools les réponses des applications deviennent plus prévisibles.

Détermination des besoins pour la configuration de projets

Avant de configurer les services de données pour l'utilisation des fonctions de contrôle de Solaris dans un environnement Sun Cluster, vous devez décider de la manière dont vous souhaitez contrôler et suivre les ressources au cours des commutations et des basculements. Veillez à identifier les dépendances au sein du cluster avant de configurer un nouveau projet. Par exemple, les ressources et groupes de ressources dépendent des groupes de périphériques de disques. Pour identifier les priorités de la liste de noeuds de votre groupe de ressources, utilisez les propriétés de groupes de ressources liste_noeuds, rétablissement, éléments_principaux_max et éléments_principaux_souhaités configurées avec scrgadm (1M). Reportez-vous à la rubrique “Relationship Between Resource Groups and Disk Device Groups” dans le document Sun Cluster 3.1 Data Services Installation and Configuration Guide pour obtenir une brève description des dépendances entre les groupes de ressources et les groupes de périphériques de disques dans la liste de noeuds. Pour obtenir une description détaillée des propriétés, reportez-vous à la rubrique rg_properties (5).

Pour déterminer les priorités des groupes de périphériques de disques dans la liste de noeuds, utilisez les propriétés prédilection et rétablissement configurées avec scrgadm( 1M) et scsetup( 1M). Pour des informations relatives à la procédure, reportez-vous à la rubrique “How To Change Disk Device Properties” de “ Administering Disk Device Groups” dans le document Sun Cluster 3.1 System Administration Guide. Reportez-vous à la rubrique Les composants matériels du système SunPlex pour obtenir des informations théoriques concernant la configuration des noeuds et le comportement des services de données évolutifs ou de basculement.

Si vous configurez tous les noeuds du cluster de la même façon, les limites d'utilisation sont appliquées de manière identique aux noeuds principaux et aux noeuds secondaires. Les paramètres de configuration des projets doivent être identiques pour toutes les applications dans les fichiers de configuration de tous les noeuds. Tous les projets associés à l'application doivent au moins être accessibles par la base de données du projet sur tous les maîtres potentiels de cette application. Supposons que l'application 1 est contrôlée par phys-schost-1 mais qu'elle peut être potentiellement commutée ou basculée sur phys-schost-2 ou phys-schost-3. Le projet associé à l'application 1 doit être accessible sur les trois noeuds (phys-schost-1 , phys-schost-2 et phys-schost-3).

les informations de la base de données de projet peuvent être placées dans un fichier de base de données /etc/project ou stockées dans la mappe NIS ou le service de répertoire LDAP.

L'environnement Solaris permet une configuration souple des paramètres d'utilisation et 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 rubriques suivantes pour la configuration de vos systèmes.

Définition des limites de mémoire virtuelle par processus

Pour limiter la mémoire virtuelle par processus, définissez le paramètre process.max-address-space. Reportez-vous à la rubrique rctladm( 1M) pour de plus amples informations sur la définition de la valeur de process.max-address-space.

Lorsque vous utilisez les fonctions de contrôle de gestion avec Sun Cluster, veillez à configurer les limites de la mémoire de manière à éviter les basculements intempestifs des applications et un effet « ping-pong » sur celles-ci. 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 basculer. Cet aspect est particulièrement important pour les applications de base de données, où les conséquences liées à l'atteinte de la limite de mémoire virtuelle sont imprévisibles.

• Les limites de mémoire des noeuds principaux et des noeuds secondaires ne doivent pas être identiques.

  Si elles l'étaient, un effet ping-pong pourrait se produire au moment où l'application atteint sa limite de mémoire et bascule sur un noeud secondaire ayant une limite de mémoire identique. Définissez une limite de mémoire légèrement supérieure sur le noeud secondaire. Vous préviendrez ainsi des effets ping-pong et l'administrateur système aura un laps de temps lui permettant de régler les paramètres si nécessaire.

• Utilisez les limites de la mémoire de gestion de ressources pour l'équilibrage de la charge.

  Vous pouvez par exemple utiliser les limites de la mémoire pour empêcher une application errante de consommer trop d'espace de swap.

Scénarios de basculement

Vous pouvez configurer les paramètres de gestion de sorte que l'allocation de la configuration de projet (/etc/project) soit opérationnelle durant le fonctionnement normal du cluster et dans les situations de commutation et de basculement.

Les rubriques suivantes présentent des exemples de scénarios.

• Les deux premières rubriques, “Cluster à deux noeuds avec deux applications“ et “Cluster à deux noeuds avec trois applications“, présentent des scénarios de basculement de noeuds complets.

• La rubrique “Basculement de groupes de ressources uniquement“ illustre les opérations de basculement d'une application seulement.

Dans un environnement de cluster, une application est configurée dans la ressource et une ressource est configurée dans un groupe de ressources (GR). Lorsqu'un échec se produit, le groupe de ressources et ses applications associées basculent sur un autre noeud. Dans les exemples suivants les ressources n'apparaissent pas de manière explicite. Supposons que chaque ressource n'a qu'une seule application.

un basculement intervient en fonction de l'ordre de préférence de la liste de noeuds définie par le RGM.

Les exemples présentés ci-après comportent les contraintes suivantes :

• Application 1 (App-1) est configurée dans le groupe de ressources GR-1.

• Application 2 (App-2) est configurée dans le groupe de ressources GR-2.

• Application 3 (App-3) est configurée dans le groupe de ressources GR-3.

Bien que le nombre de parts attribuées reste le même, le pourcentage de temps UC alloué à chaque application change après un basculement. Ce pourcentage dépend du nombre d'applications tournant sur le noeud et du nombre de parts attribuées à chaque application active.

Pour ces scénarios, supposons que nous avons les configurations suivantes :

• Toutes les applications sont configurées sous un même projet.

• Chaque ressource n'a qu'une seule application.

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

• Les bases de données de projets sont configurées de la même manière sur tous les noeuds du cluster.

Cluster à deux noeuds avec deux applications

Vous pouvez configurer deux applications sur un cluster à deux noeuds pour assurer que chaque hôte physique (phys-schost-1, phys-schost-2) fonctionne comme maître par défaut d'une application. Chaque hôte physique sert de noeud secondaire à l'autre hôte physique. Tous les projets associés à l'application 1 et l'application 2 doivent être représentés dans les fichiers de la base de données de projets des deux noeuds. Lorsque le cluster fonctionne normalement, chaque application tourne sur son maître par défaut, où le temps UC lui est attribué par la fonction de gestion.

Lorsqu'un basculement ou une commutation 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, cette entrée dans le fichier /etc/project spécifie que 4 parts sont attribuées à l'application 1 et 1 part à l'application 2.

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

Le schéma indiqué ci-après présente le fonctionnement de cette configuration en situation normale et en cas de basculement. Le nombre de parts assignées ne change pas. Toutefois, le pourcentage de temps UC disponible pour chaque application peut changer en fonction du nombre de parts attribuées à chaque processus demandant du temps UC.

Cluster à deux noeuds avec trois applications

Sur un cluster à deux noeuds avec trois applications, vous pouvez configurer un hôte physique (phys-schost-1) comme maître par défaut d'une application et le deuxième hôte (phys-schost-2 ) comme maître par défaut des deux autres applications. Dans l'exemple suivant, supposons que le fichier de base de données des projets se trouve sur chaque noeud. Le fichier de base de données des projets ne change pas lorsqu'un basculement ou une commutation a lieu.

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none)
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

Lorsque le cluster fonctionne normalement, 5 parts sont allouées à l'application 1 sur son maître par défaut, phys-schost-1. Ce nombre équivaut à 100 pour cent du temps UC parce que c'est la seule application qui demande du temps UC sur ce noeud. Trois et deux parts sont respectivement allouées aux applications 2 et 3 sur leur maître par défaut, phys-schost-2 . L'application 2 reçoit 60 pour cent du temps UC et l'application 3 reçoit 40 pour cent du temps UC au cours du fonctionnement normal.

Si un basculement ou une commutation se produit et que l'application 1 bascule sur phys-schost-2, les parts des trois applications restent les mêmes. Toutefois, les pourcentages de ressources UC sont allouées en fonction du fichier de la base de données des projets.

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

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

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

Le schéma indiqué ci-après présente le fonctionnement de cette configuration en situation normale et en cas de basculement.

Basculement du groupe de ressources uniquement

Dans une configuration où plusieurs groupes de ressources ont le même maître par défaut, un groupe de ressources (et ses applications associées) peuvent basculer ou commuter sur un noeud secondaire. Pendant ce temps, le maître par défaut continue de fonctionner dans le cluster.

durant un basculement, l'application basculant se voit attribuer des ressources tel que spécifié dans le fichier de configuration du noeud secondaire. Dans cet exemple, les fichiers de la base de données de projets des noeuds principaux et secondaires ont la même configuration.

Par exemple, cet échantillon de fichier de configuration spécifie que 1 part est allouée à l'application, 2 parts sont allouées à l'application 2 et 2 parts à l'application 3.

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

Le schéma suivant illustre le fonctionnement de cette configuration en situation normale et en cas de basculement, où GR-2 contenant l'application 2 bascule sur phys-schost-2. Notez que le nombre de parts assignées ne change pas. Toutefois, le pourcentage de temps UC disponible pour chaque application peut varier en fonction du nombre de parts assignées à chaque application nécessitant du temps UC.