Installation et configuration de Solaris Container Manager 3.6

Présentation du processus de création de conteneur

La définition de chaque projet commence par la création d'un conteneur. Un projet peut être de trois types différents, suivant la sélection effectuée lors de sa création. Le type du projet détermine la façon dont les processus associés sont contrôlés.

Types de projet

Lorsque vous créez un nouveau conteneur, vous devez sélectionner le type de projet. Un projet fournit un identificateur administratif réseau pour tous les travaux associés. Tous les processus exécutés dans un conteneur ont le même ID de projet et un conteneur contrôle l'utilisation des ressources en fonction de cet ID de projet. Le type du conteneur est fonction du type de projet sélectionné lors de la création du conteneur.

À chaque conteneur correspond un nom de projet conservé de façon permanente dans les informations qui s'y rapportent. Lorsqu'un conteneur est activé sur un hôte, le nom de projet associé est ajouté dans le fichier /etc/project de cet hôte. Cette entrée est conservée tant que le conteneur reste actif sur l'hôte.

Deux projets différents ne peuvent pas avoir le même nom de projet actif simultanément sur un hôte. En effet, le contrôle des processus exécutés dans un conteneur s'effectuant en fonction de l'ID de projet, chaque nom de projet doit être unique sur un hôte.

Lorsque vous créez des projets de type Utilisateur et Groupe, le nom de l'utilisateur ou du groupe est intégré au nom du projet. Pour les conteneurs de type Utilisateur, le nom du projet correspond au nom de l'utilisateur.nomutilisateur. Pour les conteneurs de type Groupe, le nom du projet correspond au nom du groupe.nomgroupe. Pour cette raison, lorsque vous créez des projets de type Utilisateur ou Groupe, vous ne pouvez pas utiliser un nom d'utilisateur ou de groupe correspondant à une entrée du fichier /etc/project pour les conteneurs par défaut. Pour plus d'informations à ce sujet, reportez-vous à la section Conteneurs par défaut.

Dans le cadre de la création de conteneurs de type Application, vous pouvez utiliser un nom de projet de votre choix. L'assistant de création de projet autorise l'utilisation de noms de projets dupliqués pour différents projets de type Application. En revanche, deux projets de type Application qui utilisent le même nom de projet ne peuvent pas être actifs simultanément sur le même hôte. Ne réutilisez les noms de projets lors de la création de projets de type Application que si vous envisagez d'activer ces conteneurs sur des hôtes différents. Si vous tentez d'activer un deuxième projet sur un hôte associé à un projet doté du même nom de projet, l'activation n'aboutira pas.

Le tableau ci-dessous fournit des informations détaillées sur les trois types de projet disponibles et sur les différences observées en fonction de la sélection.

Tableau 3–2 Détails des types de projet


Type de projet	Version de système d'exploitation	Détails
Utilisateur	Solaris 8	Seul type de projet pris en charge par Solaris 8. Le nom du projet dans le fichier `/etc/project` correspond au nom de l'utilisateur.`nomutilisateur`. Le projet devient le projet par défaut principal de l'utilisateur.
	Solaris 9 et Solaris 10	Le nom du projet dans le fichier `/etc/project` correspond au nom de l'utilisateur.`nomutilisateur`, avec la liste des utilisateurs UNIX autorisés à participer au projet. Le format valide est `nomutilisateur`.
Groupe	Solaris 9 et Solaris 10	Le nom du projet dans le fichier `/etc/project` correspond au nom du groupe.`nomgroupe`. Le format valide est `nomgroupe`.
Application	Solaris 9 et Solaris 10	Le nom du projet peut être le nom de l'application ou tout autre nom. Le nom spécifié est ajouté au fichier `/etc/project`. Une expression à rechercher peut être spécifiée afin de transférer automatiquement les processus correspondants sous le nom du projet. Cette expression est sensible à la casse. Le `nomutilisateur` ou `nomgroupe` correspondant sous lequel les processus sont exécutés doit être indiqué.

À propos de la création de réservations de ressources (parts de CPU)

Avant de commencer à utiliser les projets pour gérer les ressources d'une application, vous devez d'abord connaître les tendances d'utilisation de ressources pour cette application. Les performances de certaines applications, comme ORACLE®, risquent d'être considérablement affectées si la valeur de capital de mémoire utilisée est inappropriée. Pour chaque projet, un ensemble de réservations de ressources doit être configuré : une part de CPU minimale et, facultativement, une réservation maximum de mémoire (capital de mémoire). Il est recommandé de ne commencer à utiliser les projets pour gérer ces réservations qu'une fois les besoins en ressources définis pour les applications.

Attention –

Ne définissez pas pour un projet un capital de mémoire physique inférieur aux ressources habituellement utilisées par l'application. Cela risque de nuire aux performances de l'application et peut se traduire par des délais importants en raison du niveau de pagination et d'échange plus élevé dans la mesure où l'application doit utiliser davantage de mémoire virtuelle.

Votre plan de consolidation des serveurs doit être finalisé avant de commencer à utiliser les projets pour gérer les ressources système. Une autre tâche importante consiste à identifier les tendances d'utilisation des ressources par les applications intégrées à votre plan de consolidation. Le scénario idéal est celui où vous pouvez identifier les tendances d'utilisation des ressources par l'application pendant une période minimale d'un mois dans votre environnement de test avant de procéder à la mise en oeuvre de votre plan dans votre environnement de production. Après avoir identifié les tendances d'utilisation des CPU et de la mémoire, vous pouvez spécifier un pourcentage légèrement supérieur aux besoins typiques de mémoire.

Lorsque vous réservez les parts de CPU requises par un projet, vous assignez un nombre de CPU sous la forme d'un entier. Par exemple, 25, 1 et 37 sont des valeurs possibles. Le terme part est utilisé pour définir une partie des ressources de CPU du système allouée à un projet. Si vous assignez un nombre de parts de CPU élevé à un projet, par rapport aux autres projets, l'ordonnanceur équitable (FSS) alloue plus de ressources de CPU à ce projet.

Les parts de CPU ne doivent pas être considérées comme un pourcentage des ressources de CPU. Elles servent à définir l'importance relative d'une charge par rapport à une autre charge. Par exemple, si le projet Ventes est deux fois plus important que le projet Marketing, il doit se voir allouer deux fois plus de parts que ce dernier. Le nombre de parts assignées ne convient pas : 2 parts pour le projet Ventes et 1 part pour le projet Marketing est équivalent à 18 parts pour le projet Ventes et 9 parts pour le projet Marketing. Dans les deux cas, le projet Ventes bénéficie de deux fois plus de CPU que le projet Marketing.

Les parts de CPU peuvent être divisées en deux catégories :

Parts d'UC
(Solaris 10 uniquement) Parts de CPU de projet (dans une zone spécifique)

Assignation de parts de CPU à la création d'un pool ou d'un projet

Sur les hôtes Solaris 8, un seul pool de ressources, pool_default, est disponible. Le pool pool_default est associé à une valeur de 100 parts de CPU.

Sur les hôtes Solaris 9 et 10, lorsque vous créez un pool de ressources, c'est vous qui définissez la valeur des parts de CPU pour le pool. Solaris Container Manager fournit une valeur par défaut que vous pouvez remplacez par l'entier de votre choix. Certains administrateurs système utilisent une formule de 100 parts de 100 CPU par CPU disponible pour le pool de ressources. Par exemple, vous pouvez assigner 100 parts de CPU à un pool associé à 1 CPU.

Si ce pool est rattaché à trois projets (Project X, Project Y et Project Z), vous pouvez assigner au projet le plus important, le Project X, 50 parts de CPU, 10 parts au Project Y et 40 parts au Project Z.

Figure 3–8 Parts de CPU de projet

Les parts de CPU sont allouées au projet lors de la création de celui-ci via l'assistant Nouveau projet. Cet assistant indique les parts de CPU non réservées pour le pool ce qui vous permet de déterminer les parts de CPU disponibles et d'allouer la valeur appropriée au projet.

Figure 3–9 Parts de CPU

Assignation des parts de CPU à un projet

(Solaris 10 uniquement) Assignation des parts de CPU lors de la création d'une zone

Si l'hôte utilise le système d'exploitation Solaris 10, vous pouvez créer des zones et assigner des parts de CPU à la zone globale et des parts de CPU de projet pour les projets de la zone. Il s'agit d'entités associées.

L'assignation des parts de CPU et des parts de CPU de projet s'effectue lors de la création de la zone via l'assistant Nouvelle zone. À l'étape 4 de l'assistant Nouvelle zone, vous devez sélectionner un pool de ressources. L'assistant indique le nombre total de parts de CPU du pool, ainsi que les parts de CPU disponibles pour celui-ci.

Vous devez spécifier une valeur correspondant aux parts de CPU à allouer à cette zone à partir du pool de ressources. Cette valeur (un entier) doit être inférieure ou égale au nombre total de parts de CPU disponibles pour le pool.

Figure 3–10 Parts de CPU assignées à la zone

Si le nombre total de parts de CPU disponibles du pool est de 100, vous pouvez allouer la totalité ou une partie de ces 100 parts à la zone. Dans cet exemple, 20 parts de CPU du pool sont assignées à la zone.

Assignation des parts de CPU de projet lors de la création d'une zone

À l'étape 4 de l'assistant Nouvelle zone, vous avez également la possibilité de spécifier le nombre de parts de CPU de projet. Le champ correspondant définit le nombre de parts de CPU allouées aux projets de la zone. Lorsque vous définissez cette valeur, vous paramétrez la valeur des parts de CPU de projet pour la zone. Vous pouvez spécifier l'entier de votre choix. Cet entier détermine la granularité ciblée.

Par exemple, si vous définissez une valeur de 1000 parts de CPU de projet pour une Zone A, sur le plan physique, 1000 parts de CPU de projet correspondent à 20 parts de CPU, héritées du pool de ressources, divisées en 1000 parts. La formule ci-dessous explique le rapport entre 1 part de CPU de projet et les parts de CPU de cet exemple :

1 part de CPU de projet = 20 (nombre de parts de CPU allouées à la zone)/1000 (nombre de parts de CPU de projet) = 0,02 parts de CPU

Lorsque vous créez un projet, Project 1, dans la Zone A, celui-ci se voit allouer des parts par la zone et non directement par le pool de ressources. Si 300 parts sont allouées au Projet 1 dans la Zone A, 300 parts de CPU de projet ou 300/1000 x 20/100 = 0,06 parts de CPU lui sont ensuite encore assignées.

Figure 3–11 Parts de CPU assignées à une zone

L'assignation des parts de CPU de projet à un projet s'effectue à partir de l'assistant Nouveau projet. À l'étape 7 de cet assistant où vous spécifiez les réservations de ressources pour le projet, vous devez spécifier les parts de CPU de projet dans le champ Réservations de CPU (Parts de CPU). Cela ne s'applique que lors de la création d'un projet dans une zone sur un hôte Solaris 10 uniquement.

Figure 3–12 Parts de CPU de projet

Remarque –

Lorsque vous créez un projet sur un hôte Solaris 8 ou 9, le champ Parts de CPU non réservées est destiné à la saisie des parts de CPU (non des parts de CPU de projet).

Attention –

N'utilisez pas la ligne de commande (commande zonecfg) pour modifier manuellement les parts de CPU. Cela risque de gêner les calculs du logiciel Solaris Container Manager.

Zone globale et projets associés

La zone globale est la seule zone qui ne soit pas rattachée à un seul pool de ressources. Elle peut donc utiliser les ressources de CPU de n'importe quel pool. Les projets de la zone globale peuvent utiliser les ressources de CPU de tout pool de ressources situé sur l'hôte car une zone globale masquée existe dans chaque pool de ressources de l'hôte.

Par exemple, le pool de ressources Pool_default est associé à 4 CPU et aux zones zone_1 et zone_2. Il dispose de 10 parts de 10 CPU. Zone_1 a 5 parts de CPU, zone_2 en a 4 et la zone globale en a 1.

Un autre pool de ressources, Pool_1, est associé à 2 CPU et a 10 parts de CPU. Une seule zone, zone_3, est déployée pour Pool_1. Zone_3 a 9 parts de CPU. La zone globale a 1 part de CPU.

Les projets de la zone globale bénéficient des ressources de CPU issues de la part de CPU du pool sur lesquels ils sont déployés.

Dans Solaris Container Manager, les projets de la zone globale doivent être déployés dans le pool pool_default.

Ordonnanceur équitable (FSS -Fair Share Scheduler)

Container Manager utilise l'ordonnanceur équitable pour garantir les parts minimums de CPU que vous définissez. L'ordonnanceur équitable est l'ordonnanceur par défaut. Il calcule la proportion de CPU allouée à un projet en divisant les parts du projet par le nombre total des parts des projets actifs. Un projet actif est un projet dont au moins l'un des processus utilise la CPU. Les parts des projets inactifs, à savoir les projets sans processus actif, ne sont pas prises en compte dans les calculs.

Par exemple, trois projets sont créés : ventes, marketing et base de données. Deux, une et quatre parts leur sont allouées respectivement. Ces trois projets sont actifs. Les ressources de CPU pour le pool de ressources se répartissent comme suit : le projet ventes reçoit 2/7 des ressources de CPU, le projet marketing 1/7 et le projet base de données 4/7. Lorsque le projet ventes est inactif, le projet marketing reçoit 1/5 des ressources de CPU et le projet base de données 4/5.

Notez que l'ordonnanceur équitable ne limite l'utilisation des CPU qu'en cas de conflit. Un projet qui est le seul à être actif sur le système peut utiliser 100 % de la CPU, indépendamment du nombre de parts qui lui est alloué. Ainsi, aucun cycle de CPU n'est perdu. Si un projet n'utilise pas toutes les parts de CPU qui lui sont allouées car aucune tâche ne lui est associée, les ressources de CPU restantes sont réparties entre les autres processus actifs. Si aucune part de CPU n'est spécifiée pour un projet, le système lui en alloue une. Les processus associés à des projets disposant de zéro (0) parts sont exécutés suivant la priorité la plus basse du système. Ces processus sont uniquement exécutés lorsque les projets dotés de parts supérieures à zéro n'utilisent pas les ressources de CPU.

Ordonnanceur temporel (TS - Timesharing Scheduler)

L'ordonnanceur temporel tente de fournir à chaque processus un accès relativement équitable aux CPU disponibles, en allouant de CPU en fonction de la priorité. Cet ordonnanceur ne nécessitant aucune gestion, il est particulièrement simple à utiliser. Toutefois, il ne permet de garantir les performances d'une application donnée. Son utilisation convient lorsque l'allocation des CPU n'est pas nécessaire.

Par exemple, si un pool de ressources FSS est assigné à deux projets, chacun doté de deux parts, le nombre de processus exécutés dans ces projets n'est pas important. Un projet peut uniquement utiliser 50 % de la CPU disponible. Par conséquent, si un processus est exécuté dans le projet Ventes et 99 dans le projet Marketing, celui du projet Ventes peut utiliser 50 % de la CPU disponible. Les 99 processus du projet Marketing doivent se partager 50 % des ressources de CPU disponibles.

Dans un pool de ressources TS, les parts de CPU sont allouées par processus. Le processus du projet Ventes n'a accès qu'à 1 % de la CPU, alors que les 99 processus du projet Marketing peuvent utiliser 99 % des ressources de CPU disponibles.

Pour plus d'informations sur l'ordonnanceur équitable ou l'ordonnanceur temporel, reportez-vous au System Administration Guide: Network Services.

Utilisation de Container Manager pour connaître les tendances d'utilisation des ressources d'une application

Vous pouvez utiliser Container Manager dans votre environnement de test comme outil d'identification des tendances d'utilisation des ressources d'une application en procédant comme suit :

Installez et configurez Container Manager, ainsi que tout autre logiciel requis.

Pour plus d'informations à ce sujet, reportez-vous au Chapitre 2, Installation et configuration du gestionnaire de conteneurs.
Installez le logiciel Performance Reporting Manager ; sur toutes les machines agent à contrôler.

Pour plus d'informations à ce sujet, reportez-vous au Chapitre 2, Installation et configuration du gestionnaire de conteneurs et au Sun Management Center 3.6 Performance Reporting Manager User’s Guide.
Créez un conteneur de type Application pour l'application dont vous souhaitez connaître les tendances d'utilisation des ressources. Dans l'assistant Nouveau projet, spécifiez uniquement une réservation minimum de CPU. N'indiquez pas de capital de mémoire.

Pour plus d'informations à ce sujet, reportez-vous aux sections Création d'un projet de type Application et Pour créer un projet de type Application.
Contrôlez l'utilisation des ressources pendant quelques semaines en vous servant des graphes quotidien, hebdomadaire ou en temps réel. Vous disposez de deux graphes, un pour les ressources de CPU et un pour la mémoire utilisée, sont disponibles pour le conteneur exécuté sur un hôte individuel. Vous pouvez également afficher la table Processus pour surveiller les processus exécutés dans l'application.

Pour plus d'informations à ce sujet, reportez-vous aux sections Pour demander un rapport d'utilisation des ressources pour un projet actif et Visualisation des processus d'un projet.
Après avoir spécifié les besoins maximums de mémoire physique pour l'application, modifiez les propriétés du conteneur de façon à ajouter un capital de mémoire. Ne configurez pas un capital de mémoire inférieur à la quantité de mémoire maximum utilisée par l'application.

Pour plus d'informations à ce sujet, reportez-vous à la section Pour modifier un projet via une page de propriétés.
Définissez une alarme de façon à être informé dès que la mémoire utilisée dépasse le capital de mémoire spécifié. Ajustez le capital de mémoire via la page de propriétés.

Pour plus d'informations à ce sujet, reportez-vous aux sections Pour définir un seuil d'alarme et Pour modifier un projet via une page de propriétés.

Après avoir identifié les tendances d'utilisation des ressources via Container Manager, vous pouvez utiliser les cconteneurs pour procéder au regroupement des serveurs dans votre environnement de production.

Pour plus d'informations sur la planification et la mise en oeuvre de la consolidation de serveurs, reportez-vous au manule Blueprints Sun, Consolidation in the Data Center de David Hornby et Ken Pepple. Pour plus d'informations sur la consolidation des serveurs sur des systèmes utilisant une base de données ORACLE, reportez-vous au livre blanc Sun intitulé Consolidating Oracle RDBMS Instances Using Solaris Resource Manager Software.