Composants des zones

Cette section porte sur les composants de zones, requis et optionnels, susceptibles d'être configurés. Vous trouverez de plus amples informations dans la section Données de configuration de zones.

Nom de zone et chemin d'accès

Vous devez nommer la zone et choisir le chemin qui permettra d'y accéder.

Initialisation automatique (autoboot) d'une zone

Le paramètre de propriété autoboot détermine si la zone est automatiquement initialisée en cas d'initialisation de la zone globale. Le service des zones, svc:/system/zones:default doit également être activé.

Association de pools de ressources

Si vous avez configuré des pools de ressources sur votre système, comme décrit dans le Chapitre 13Création et administration des pools de ressources (tâches), vous pouvez utiliser la propriété pool pour associer la zone à l'un des pools de ressources lorsque vous la configurez.

À partir de la version Solaris 10 8/07, même si aucun pool de ressources n'est configuré, vous pouvez spécifier, à l'aide de la ressource dedicated-cpu, qu'un sous-ensemble des processeurs du système doit être dédié à une zone non globale tant que celle-ci est en cours d'exécution. Le système crée de manière dynamique un pool temporaire destiné à être utilisé lorsque la zone est en cours d'exécution. Vous pouvez propager les paramètres du pool pendant les migrations en les spécifiant dans la commande zonecfg.

Toute configuration de zone utilisant un pool permanent défini par le biais de la propriété pool est incompatible avec un pool temporaire configuré à l'aide de la ressource dedicated-cpu. Vous ne pouvez définir que l'une de ces deux propriétés.

Solaris 10 8/07 : ressource dedicated-cpu

La ressource dedicated-cpu spécifie qu'un sous-ensemble des processeurs du système doit être dédié à une zone non globale tant que celle-ci est en cours d'exécution. Dès que la zone est initialisée, le système crée de manière dynamique un pool temporaire destiné à être utilisé lorsque la zone est en cours d'exécution.

Vous pouvez propager les paramètres du pool pendant les migrations en les spécifiant dans la commande zonecfg.

La ressource dedicated-cpu définit les limites de ncpus et éventuellement d'importance.

ncpus

Spécifie le nombre de CPU ou une plage de CPU (par exemple 2–4). Si vous optez pour une plage de CPU parce que vous souhaitez que le pool de ressources se comporte de manière dynamique, vous devez également :

• définir la propriété importance ;

• activer le service poold. Pour plus d'informations, reportez-vous à la section Solaris 10 11/06 et ultérieur : activation du service de pools de ressources dynamiques à l'aide de svcadm.

importance

Si, pour un plus grand dynamisme du pool de ressources, vous avez choisi d'utiliser une plage de CPU, définissez également la propriété importance. La propriété importance détermine l'importance relative du pool mais est optionnelle. Elle n'est nécessaire que si vous spécifiez une plage pour ncpus et utilisez des pools de ressources dynamiques gérés par poold. Si poold n'est pas en cours d'exécution, la propriété importance est ignorée. Si poold est en cours d'exécution et si la propriété importance n'a pas été définie, importance adopte par défaut la valeur 1. Pour plus d'informations, reportez-vous à la section Contrainte de propriété pool.importance.

Les ressources capped-cpu et dedicated-cpu sont incompatibles. L'instance de contrôle de ressource cpu-shares et la ressource dedicated-cpu sont incompatibles.

Solaris 10 5/08 : ressource capped-cpu

La ressource capped-cpu définit une limite absolue très précise de la quantité de ressources CPU qu'un projet ou une zone peut consommer. Associée aux jeux de processeurs, la capacité de CPU limite l'utilisation de ressources CPU au sein d'un jeu. La ressource capped-cpu possède une seule propriété ncpus, dont la valeur est un nombre décimal positif avec deux chiffres après la virgule. Cette propriété correspond aux unités de CPU. Cette ressource n'accepte pas de plage, mais elle accepte les nombres décimaux. Lorsque vous spécifiez la propriété ncpus, notez que la valeur 1 correspond à 100 pourcent d'une CPU. Ainsi, la valeur 1,25 équivaut à 125 pourcent, car 100 pourcent correspond à une CPU complète sur le système.

Les ressources capped-cpu et dedicated-cpu sont incompatibles.

Classe de programmation dans une zone

Vous pouvez utiliser l'ordonnanceur équitable (FSS, Fair Share Scheduler) pour contrôler l'allocation des ressources CPU disponibles aux différentes zones en fonction de leur charge de travail. Celle-ci se reflète dans le nombre de parts de ressources CPU que vous assignez à chaque zone. Même si vous n'utilisez pas FSS pour gérer l'allocation de ressources CPU aux zones, vous pouvez définir la classe de programmation des zones pour utiliser FSS de manière à pouvoir assigner des parts aux projets au sein des zones.

Lorsque vous définissez explicitement la propriété cpu-shares, l'ordonnanceur équitable sert de classe de programmation pour la zone concernée. Dans ce cas, il est cependant préférable de définir FSS comme classe de programmation par défaut du système à l'aide de la commande dispadmin. Toutes les zones disposent ainsi d'une part équitable des ressources CPU du système. Toute zone pour laquelle la propriété cpu-shares n'est pas définie utilise la classe de programmation par défaut du système. Pour définir la classe de programmation d'une zone, vous pouvez procéder de différentes façons :

• Dans la version Solaris 10 8/07, vous pouvez utiliser la propriété scheduling-class de zonecfg.

• Vous pouvez avoir recours à l'utilitaire de pools de ressources. Si la zone est associée à un pool dont la propriété pool.scheduler est définie sur une classe de programmation valide, les processus exécutés dans cette zone le sont dans cette classe de programmation par défaut. Reportez-vous aux sections Introduction aux pools de ressources et Association d'un pool avec une classe de programmation.

• Si l'instance de contrôle de ressource cpu-shares est définie et si vous n'avez pas défini FSS comme la classe de programmation pour la zone, zoneadmd s'en charge lors de l'initialisation de celle-ci.

• Si la classe de programmation n'est pas définie par toute autre action, la zone hérite de la classe de programmation par défaut du système.

Notez que vous pouvez utiliser la commande priocntl décrite dans la page de manuel priocntl(1) pour placer les processus en cours d'exécution dans une autre classe de programmation sans modifier la classe de programmation par défaut et sans réinitialiser.

Solaris 10 8/07 : contrôle de la mémoire physique et ressource capped-memory

La ressource capped-memory définit les limites des propriétés physical, swap et locked de la mémoire. Chaque limite est optionnelle, mais vous devez en définir au moins une.

• Déterminez les valeurs pour cette ressource si vous prévoyez de limiter la mémoire de la zone à l'aide de rcapd dans la zone globale. La propriété physical de la ressource capped-memory est utilisée par rcapd comme valeur max-rss pour la zone.

• La propriété swap de la ressource capped-memory permet de définir le contrôle de ressource zone.max-swap.

• La propriété locked de la ressource capped-memory permet de définir le contrôle de ressource zone.max-locked-memory.

Généralement, les applications ne bloquent pas une quantité importante de mémoire, mais vous pouvez décider de définir un verrouillage de mémoire si les applications de la zone sont susceptibles de bloquer de la mémoire. Si la confiance de la zone est un problème, vous pouvez définir la limite de mémoire verrouillée à 10 % de la mémoire physique du système, ou 10 % de la limite de mémoire physique de la zone.

Pour plus d'informations, reportez-vous au Chapitre 10Contrôle de la mémoire physique à l'aide du démon d'allocation restrictive (présentation), au Chapitre 11Administration du démon d'allocation restrictive (tâches), ainsi qu'à la section Configuration d'une zone. Pour définir temporairement une limitation de ressources pour une zone, reportez-vous à la section Spécification d'une limitation temporaire de ressources pour une zone.

Interfaces réseau de zones

Les interfaces réseau configurées à l'aide de la commande zonecfg pour doter les zones d'une connectivité réseau sont automatiquement paramétrées et placées dans la zone concernée lors de son initialisation.

La couche IP accepte et livre les paquets pour le réseau. Cette couche inclut le routage IP, le protocole de résolution d'adresse (ARP, Address Resolution Protocol), l'architecture de sécurité IP (IPsec, IP security architecture) et le filtrage IP.

Deux modes IP sont disponibles pour les zones non globales : le mode IP partagé et le mode IP exclusif. Les zones en mode IP partagé partagent une interface réseau et les zones en mode IP exclusif doivent posséder une interface réseau dédiée.

Pour plus d'informations sur les fonctionnalités IP dans chacun de ces cas, reportez-vous aux sections Mise en réseau dans des zones non globales en mode IP partagé et Solaris 10 8/07 : mise en réseau dans des zones non globales en mode IP exclusif.

Zones non globales en mode IP partagé

Par défaut, les zones sont en mode IP partagé. Elles doivent avoir une ou plusieurs adresses IP dédiées et possèdent le même état et la même configuration de couche IP que la zone globale. Vous devez utiliser l'instance d'IP partagé si les deux conditions suivantes sont vérifiées :

• La zone sera connectée à la même liaison de données que la zone globale. En d'autres termes, elle se trouvera sur les mêmes sous-réseaux IP.

• Vous n'avez pas besoin des autres capacités fournies par les zones en mode IP exclusif.

La commande zonecfg permet d'assigner une ou plusieurs adresses IP aux zones en mode IP partagé. Il convient également de configurer les noms des liaisons de données dans la zone globale.

Ces adresses sont associées à des interfaces réseau logiques. La commande ifconfig peut être utilisée dans la zone globale pour ajouter ou supprimer des interfaces logiques dans une zone en cours d'exécution. Pour plus d'informations, reportez-vous à la section Interfaces réseau en mode IP partagé.

Solaris 10 8/07 : zones non globales en mode IP exclusif

Les zones en mode IP exclusif disposent de fonctionnalités IP complètes.

Elles possèdent leur propre état en termes d'IP.

Cela inclut les fonctionnalités suivantes :

• la configuration automatique d'adresse sans état via DHCPv4 et IPv6 ;

• le filtrage IP, fonctionnalité NAT comprise ;

• le multiacheminement sur réseau IP (IPMP, IP Network Multipathing) ;

• le routage IP ;

• la commande ndd permettant de définir les paramètres TCP/UDP/SCTP, ainsi que les boutons de niveau IP/ARP ;

• Les protocoles IPsec (IP security) et IKE (Internet Key Exchange), qui automatisent l'approvisionnement en matériel de chiffrement authentifié pour l'association de sécurité IPsec.

Toute zone en mode IP exclusif se voit assigner son propre jeu de liaisons de données à l'aide de la commande zonecfg. La propriété physical de la ressource net permet d'assigner un nom de liaison de données tel que xge0, e1000g1 ou bge32001 à la zone. La propriété address de la ressource net n'est pas définie.

Notez que la liaison de données assignée active la commande snoop.

La commande dladm peut être utilisée avec la sous-commande show-linkprop pour afficher l'assignation de liaisons de données aux zones en mode IP exclusif en cours d'exécution. La commande dladm peut également être utilisée avec la sous-commande set-linkprop pour assigner des liaisons de données supplémentaires aux zones en cours d'exécution. Vous trouverez des exemples d'utilisation à la section Solaris 10 8/07 : gestion des liaisons de données dans les zones non globales en mode IP exclusif.

Dans les zones en mode IP exclusif en cours d'exécution, la commande ifconfig peut être utilisée pour définir la configuration IP, ajout et suppression d'interfaces logiques compris. Vous pouvez procéder comme pour une zone globale, à l'aide de sysidtools, comme décrit dans la page de manuel sysidcfg(4).

La configuration IP d'une zone en mode IP exclusif ne peut être affichée que depuis la zone globale, à l'aide de la commande zlogin. Reportez-vous à l'exemple ci-dessous.

global# zlogin zone1 ifconfig -a

Différences entre les zones non globales en modes IP partagé et IP exclusif en matière de sécurité

Dans une zone en mode IP partagé, les applications de la zone (superutilisateur compris) ne peuvent pas envoyer de paquets avec des adresses IP source autres que celles assignées à la zone par le biais de l'utilitaire zonecfg. Dans ce type de zone, il est impossible d'envoyer ou de recevoir des paquets de liaisons de données arbitraires (couche 2).

Par contre, dans les zones en mode IP exclusif, zonecfg attribue la totalité de la liaison de données spécifiée à la zone. Son superutilisateur peut donc envoyer des paquets usurpés sur ces liaisons de données, comme dans une zone globale.

Utilisation simultanée de zones non globales en modes IP partagé et IP exclusif

Les zones en mode IP partagé partagent la couche IP avec la zone globale alors que les zones en mode IP exclusif possèdent leur propre instance de la couche IP. Ces deux types de zones peuvent être utilisées sur une même machine.

Systèmes de fichiers montés dans une zone

En règle générale, les systèmes de fichiers montés dans une zone comportent :

• le jeu de systèmes de fichiers montés lors de l'initialisation de la plate-forme virtuelle ;

• le jeu de systèmes de fichiers montés dans l'environnement applicatif lui-même.

Il s'agit par exemple de :

• systèmes de fichiers spécifiés dans le fichier /etc/vfstab d'une zone ;

• montages AutoFS et montages amorcés automatiquement par AutoFS ;

• montages explicitement exécutés par un administrateur de zone.

Les montages exécutés dans l'environnement applicatif font l'objet de certaines restrictions qui empêchent l'administrateur de zone de refuser de fournir des services au reste du système ou de réaliser des opérations affectant les autres zones.

Des restrictions de sécurité sont par ailleurs associées au montage de certains systèmes de fichiers à l'intérieur d'une zone et d'autres systèmes de fichiers ont un comportement particulier lorsqu'ils sont montés dans une zone. Pour plus d'informations, reportez-vous à la section Systèmes de fichiers et zones non globales.

Périphériques configurés dans des zones

La commande zonecfg utilise un système basé sur des règles pour spécifier les périphériques qui doivent figurer dans une zone donnée. Les périphériques répondant à l'une de ces règles sont inclus dans le système de fichiers /dev de la zone. Pour plus d'informations, reportez-vous à la section Configuration d'une zone.

ID hôte dans les zones

Vous pouvez définir une propriété hostid pour la zone non globale différente de la propriété hostid de la zone globale. Cette action est effectuée sur une machine physique consolidée dans une zone à l'aide de la capacité P2V. Les applications se trouvant actuellement dans la zone peuvent dépendre de la propriété hostid d'origine. Il se peut également que vous ne puissiez pas mettre à jour la configuration de l'application. Pour plus d'informations, reportez-vous à la section Types de ressources et de propriétés.

Paramétrage des contrôles de ressources à l'échelle d'une zone

L'administrateur global peut définir des contrôles de ressources privilégiés à l'échelle d'une zone. L'intérêt de ces contrôles est de limiter l'utilisation des ressources totales pour l'ensemble des entités processus à l'intérieur d'une zone.

La commande zonecfg permet de spécifier ces limites, pour les zones globales et non globales. Reportez-vous à la section Configuration d'une zone.

À partir de la version Solaris 10 8/07, le meilleur moyen de paramétrer un contrôle de ressource à l'échelle d'une zone consiste à utiliser le nom de propriété au lieu de la ressource rctl.

Solaris 10 5/08 : le contrôle de ressource zone.cpu-cap définit une limite absolue pour la quantité de ressources CPU correspondant à une zone. La valeur 100 représente 100 pourcent d'une CPU pour le paramètre project.cpu-cap. La valeur 1,25 équivaut à 125 pourcent, car 100 pourcent correspond à une capacité de CPU complète sur le système.

Lors de la définition de la ressource capped-cpu, il est possible de définir un nombre décimal pour l'unité. La valeur correspond au contrôle de ressource zone.capped-cpu mais est réduite par 100. La valeur 1 équivaut à la valeur 100 pour le contrôle de ressource.

Le contrôle de ressource zone.cpu-shares permet de limiter le nombre de parts de CPU FSS pour une zone. Les parts de CPU sont tout d'abord allouées à la zone, puis subdivisées entre les projets à l'intérieur de celle-ci comme spécifié dans les entrées project.cpu-shares. Pour plus d'informations, reportez-vous à la section Utilisation de l'ordonnanceur FSS sur un système Solaris doté de zones. Le nom de propriété globale de ce contrôle est cpu-shares.

Le contrôle de ressource zone.max-locked-memory permet de limiter le volume de mémoire physique verrouillée mis à disposition d'une zone et le contrôle de ressource project.max-locked-memory de contrôler l'allocation de ce type de mémoire aux différents projets à l'intérieur de la zone. Voir le Tableau 6–1 pour plus d'informations.

Le contrôle de ressource zone.max-lwps renforce l'isolement en empêchant que la présence de trop nombreux LWP dans une zone affecte d'autres zones. Le contrôle de ressource project.max-lwps permet de contrôler l'allocation de la ressource LWP aux différents projets à l'intérieur de la zone. Voir le Tableau 6–1 pour plus d'informations. Le nom de propriété globale de ce contrôle est max-lwps.

Les contrôles de ressources zone.max-msg-ids, zone.max-sem-ids, zone.max-shm-ids et zone.max-shm-memory permettent de limiter les ressources System V utilisées par tous les processus à l'intérieur d'une zone. Vous pouvez contrôler l'allocation des ressources System V aux différents projets à l'intérieur de la zone à l'aide des versions de projet de ces contrôles de ressources. Les noms de propriétés globales de ces contrôles sont max-msg-ids, max-sem-ids, max-shm-ids et max-shm-memory .

Le contrôle de ressource zone.max-swap permet de limiter le swap consommé par les mappages d'espace d'adresses des processus utilisateur et les montages tmpfs à l'intérieur d'une zone. La commande prstat -Z affiche une colonne SWAP indiquant le swap total consommé par les montages tmpfs et les processus de la zone. Cette valeur facilite le contrôle du swap réservé par chaque zone, qui peut être utilisé pour choisir un paramètre zone.max-swap adéquat.

Vous pouvez spécifier ces limites en exécutant les processus à l'aide de la commande prctl. Vous trouverez un exemple sous la section Définition de partages FSS dans la zone globale à l'aide de la commande prctl. Les limites spécifiées à l'aide de la commande prctl ne sont pas persistantes. Elles perdent leur effet dès que vous réinitialisez le système.

Solaris 10 11/06 et versions ultérieures : privilèges configurables

Lorsque vous initialisez une zone, un jeu par défaut de privilèges fiables est inclus dans la configuration. Ces privilèges sont jugés fiables, car ils évitent que tout processus privilégié d'une zone affecte les processus d'autres zones non globales du système ou de la zone globale. La commande zonecfg permet :

• d'ajouter des privilèges au jeu par défaut, étant entendu que ces modifications risquent de permettre aux processus d'une zone de contrôler une ressource globale et donc d'affecter les processus d'autres zones.

• de supprimer des privilèges du jeu par défaut, étant entendu que ces modifications risquent d'empêcher certains processus de fonctionner correctement si ces privilèges sont nécessaires à leur exécution.

Certains privilèges ne peuvent pas être supprimés du jeu de privilèges par défaut d'une zone et d'autres ne peuvent actuellement pas y être ajoutés.

Pour plus d'informations, reportez-vous aux sections Privilèges dans une zone non globale et Configuration d'une zone, ainsi qu'à la page de manuel privileges(5).

Ajout d'un commentaire à une zone

Le type de ressource attr permet d'ajouter un commentaire à une zone. Pour plus d'informations, reportez-vous à la section Configuration d'une zone.