Configuration d'un projet de services de données

Les services de données peuvent être configurés pour être lancés sous un nom de projet Solaris lorsqu'ils sont mis en ligne à 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 mise en correspondance de votre ressource ou groupe de ressources vers un ID projet vous permet d'utiliser des contrôles avancés, disponibles dans le système d'exploitation Solaris, pour gérer les charges de travail et la consommation du cluster.

Vous pouvez effectuer cette configuration uniquement si vous exécutez la version actuelle du logiciel Sun Cluster avec au minimum Solaris 9.

L'utilisation des fonctionnalités de gestion de Solaris dans un environnement Sun Cluster vous permet de vous assurer que vos applications les plus importantes sont prioritaires lors du partage d'un nœud avec d'autres applications. Il arrive que les applications partagent un nœud si vous avez des services consolidés ou si les applications ont basculé. L'utilisation des fonctionnalités de gestion décrites dans ce document peut améliorer la disponibilité d'une application stratégique en empêchant les applications à faible priorité de consommer des ressources système, par exemple le temps CPU.

La documentation Solaris relative à cette fonctionnalité décrit les « ressources » que sont le temps CPU, les processus, les tâches et composants semblables. La documentation Sun Cluster utilise le terme « ressources » pour décrire les entités qui sont sous le contrôle du RGM. La section suivante utilise le terme « ressource » pour désigner des entités Sun Cluster sous le contrôle du RGM. Elle utilise le terme « ressources » pour désigner le temps CPU, les processus et les tâches.

Cette section 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é. Elle décrit également plusieurs scénarios de basculement et donne des suggestions de planification pour l'utilisation des fonctionnalités de gestion du système d'exploitation Solaris.

Pour plus d'informations sur les notions fondamentales et les procédures relatives à la fonctionnalité de gestion, voir Chapitre 1, Network Service (Overview) du System Administration Guide: Network Services.

Lorsque vous configurez des ressources et des groupes de ressources pour qu'ils utilisent les fonctionnalités de gestion de Solaris dans un cluster, suivez le processus général suivant :

1. Configurez les applications comme partie intégrante de la ressource.

2. Configurez les ressources comme partie intégrante d'un groupe de ressources.

3. Activez les ressources du groupe de ressources.

4. Activez la gestion du groupe de ressources.

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

6. Configurez des 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 Resource_project_name ou RG_project_name afin d'associer l'ID 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, voir Annexe A, Standard Properties du Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Reportez-vous aux descriptions des propriétés r_properties(5) et rg_properties(5).

Le nom de projet spécifié doit figurer dans la base de données de projets (/etc/project) et le superutilisateur doit être configuré en tant que membre du projet nommé. Pour plus d'informations sur les notions fondamentales relatives à la base de données de projets, voir Chapitre 2, Projects and Tasks (Overview) du System Administration Guide: Solaris Containers-Resource Management and Solaris Zones. Pour consulter la description de la syntaxe d'un fichier projet, voir project(4).

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 du projet n'est pas effectif tant que la ressource ou le groupe de ressources n'ont pas été mis hors ligne, puis remis 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 CPU 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 CPU attribué à chaque charge. Pour plus d'informations, reportez-vous aux pages suivantes.

  • dispadmin(1M)

  • priocntl(1)

  • ps(1)

  • FSS(7).

• 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 des services de données pour l'utilisation des contrôles de Solaris dans un environnement Sun Cluster, vous devez choisir la méthode de contrôle et de suivi des ressources au travers des commutations et des basculements. Identifiez les dépendances dans le 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.

Utilisez les propriétés de groupe de ressources nodelist, failback, maximum_primaries et desired_primaries qui sont configurées avec scrgadm(1M) afin d'identifier les propriétés de la liste de nœuds de votre groupe de ressources.

• Pour consulter une brève présentation des dépendances de la liste de nœuds entre les groupes de ressources et les groupes de périphériques de disques, voir Relationship Between Resource Groups and Disk Device Groups du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

• Pour une description détaillée des propriétés, voir rg_properties(5).

Utilisez les propriétés preferenced et failback configurées avec scrgadm(1M) et scsetup(1M) pour identifier les priorités de la liste de nœuds du groupe de périphériques de disques.

• Pour plus d'informations sur les notions fondamentales relatives à la propriété preferenced, voir Groupes de périphériques de disques multiports .

• Pour plus d'informations sur les procédures, reportez-vous au paragraphe “Comment changer les propriétés des périphériques de disques” dans Administration des groupes de périphériques de disques du Guide d’administration système de Sun Cluster pour SE Solaris.

• Pour plus d'informations sur les notions fondamentales relatives à la configuration des nœuds et au comportement des services de données de basculement et évolutifs, voir Matériel système et composants logiciels Sun Cluster .

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

Les informations de la base de données de projets peuvent être contenues dans un fichier de base de données local /etc/project ou stockées dans la carte NIS ou dans le service d'annuaire LDAP.

Le système d'exploitation Solaris permet de configurer des paramètres d'utilisation de façon souple ; peu de limites 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. Pour plus d'informations sur la définition de la valeur process.max-address-space, voir rctladm(1M).

Si vous utilisez des contrôles de gestion avec le logiciel Sun Cluster, configurez des limites de mémoire de façon appropriée, pour empêcher tout basculement superflu et tout effet « ping-pong » des applications. En règle générale, respectez les consignes indiquées ci-dessous.

• 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 nœuds principaux et des nœuds 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 nœud secondaire ayant une limite de mémoire identique. Définissez une limite de mémoire légèrement supérieure sur le nœud 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 nœuds avec deux applications“ et “Cluster à deux nœuds avec trois applications“, présentent des scénarios de basculement de nœuds complets.

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

Dans un environnement Sun Cluster, vous configurez une application comme partie d'une ressource. Vous configurez ensuite une ressource comme partie d'un groupe de ressources. En cas de panne, le groupe de ressources ainsi que les applications qui lui sont associées basculent sur un autre nœud. 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 nœuds 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 CPU alloué à chaque application change après un basculement. Ce pourcentage dépend du nombre d'applications tournant sur le nœud 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 nœuds.

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

Cluster à deux nœuds avec deux applications

Vous pouvez configurer deux applications sur un cluster à deux nœuds pour vous assurer que chaque hôte physique (phys-schost-1, phys-schost-2) sert de maître par défaut pour une application. Chaque hôte physique sert de nœud 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 bases de données de projets sur les deux nœuds. 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 nœud, où les parts précisées dans le fichier de configuration leur sont attribuées. Par exemple, cette entrée du fichier /etc/project indique que 4 parts sont allouées à l'application 1 et qu'une part est allouée à 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. Cependant, le pourcentage de temps CPU disponible pour chaque application peut changer. Il dépend du nombre de parts assignées à chaque processus qui exige du temps CPU.

Cluster à deux nœuds avec trois applications

Sur un cluster à deux nœuds avec trois applications, vous pouvez configurer un hôte physique (phys-schost-1) comme maître par défaut d'une application. Vous pouvez configurer le second hôte physique (phys-schost-2) comme maître par défaut pour les deux applications restantes. Dans l'exemple suivant, supposons que le fichier de base de données des projets se trouve sur chaque nœud. 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 nœud. Trois parts et deux parts sont allouées respectivement 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 CPU et l'application 3 reçoit 40 pour cent du temps CPU au cours du fonctionnement normal.

Si un basculement ou une commutation se produisent et que l'application 1 est basculée sur phys-schost-2, les parts des trois applications restent les mêmes. Toutefois, les pourcentages de ressources CPU 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 CPU.

• 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 nœud 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 nœud secondaire. Dans cet exemple, les fichiers de base de données de projets sur les nœuds principal et secondaire ont les mêmes configurations.

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 diagramme suivant illustre les opérations normales et de basculement de cette configuration, où RG-2, qui contient l'application 2, bascule sur phys-schost-2. Notez que le nombre de parts assignées ne change pas. Toutefois, le pourcentage de temps CPU disponible pour chaque application peut changer, en fonction du nombre de parts assignées à chaque application qui exige du temps CPU.