Une zone représente une technologie de conteneur Solaris fournissant des environnements séparés sur une machine et isolant de manière logique les applications les unes des autres. Les zones vous permettent de créer des environnements du système d'exploitation virtuels au sein d'une instance sur le système d'exploitation Solaris. L'exécution de plusieurs applications dans différentes zones vous permet d'exécuter différentes instances ou différentes versions de la même application sur la même machine tout en conservant une administration centralisée et un partage efficace des ressources.
Cette section propose une brève description des zones et de leur utilisation avec Message Queue 3.7 UR1.
Une environnement de zones inclut une zone globale et une ou plusieurs zones non globales. Lors de la première installation de Solaris 10 sur un système, une seule zone globale est créée. Un administrateur peut créer d'autres zones non globales comme enfants de la zone globale. Chaque zone apparaît comme un système indépendant exécuté sous Solaris. Chaque zone possède sa propre adresse IP, sa propre configuration système, ses propres instances d'applications exécutées et son propre espace sur le système de fichiers.
La zone globale contient des ressources pouvant être partagées entre les zones non globales, ce qui permet une centralisation de certaines fonctions administratives. Par exemple, les packages installés dans la zone globale sont disponibles (propagés) sur toutes les zones non globales. Cela vous permet de centraliser la gestion du cycle de vie, comme l'installation, la mise à niveau et la désinstallation. De plus, l'isolation fournie par les zones non globales apporte une meilleure sécurité et vous permet d'avoir des instances configurées différemment ou différentes versions de la même application exécutées sur la même machine.
Les zones non globales sont soit des zones « whole root », soit des zones « sparse root » : votre choix de zones comme environnement pour une application dépend de la manière dont vous souhaitez équilibrer le contrôle administratif avec l'optimisation des ressources.
Les zones whole root contiennent une copie lecture/écriture du système de fichiers sur la zone globale. Les packages installés dans la zone globale sont automatiquement copiés (avec leurs informations de registre) vers les zones whole root. Cela permet de maximiser le contrôle administratif, aux dépens des ressources.
Les zones sparse root contiennent une copie lecture/écriture d'une partie du système de fichiers sur la zone globale ; les autres systèmes de fichiers sont installés comme systèmes de fichiers en lecture seule. Les packages installés dans la zone globale sont disponibles sur les zones sparse root par le biais des systèmes de fichiers en lecture seule et de la synchronisation automatique des informations de registre. Les zones sparse root optimisent le partage des ressources aux dépens de l'administration centralisée.
Les composants qui forment Java Enterprise System dépendent de certains composants partagés, ce qui entraîne certaines restrictions dans l'utilisation des zones. Dans un environnement de zones, les composants partagés dépendent des règles suivantes.
Tous les composants partagés dans une zone doivent être de la même version JES. Cette obligation entraîne trois conséquences.
Si vous souhaitez installer différentes versions de composants partagés, chaque version doit être installée dans une zone séparée.
Dans une zone, si un composant partagé est mis à niveau ou qu'une version ultérieure est installée, l'ensemble des composants partagés doit être mis à niveau.
Lorsque vous installez des composants partagés dans une zone globale, vous devez vérifier que les composants partagés dans les zones non globales sont mis à niveau au besoin.
Les composants partagés ne peuvent pas être installés dans des zones sparse root à cause du système de fichiers lecture/écriture de ces zones. Vous devez donc les installer dans une zone globale. Ces composants produit qui dépendent des composants partagés doivent d'abord être installés dans la zone globale puis propagés dans les zones non globales.
Ces conditions affectent l'installation de Message Queue car ce dernier est un produit composant de Java Enterprise System et, en tant que tel, est limité dans son utilisation de zones.
Le produit Message Queue est installé dans le répertoire /usr et doit d'abord être installé ou mis à niveau dans la zone globale.
Lorsque Message Queue est installé dans une zone globale, il est défini de manière à se propager dans toutes les zones non globales. Après avoir installé Message Queue dans la zone globale, la même version de Message Queue sera installée dans toutes les zones : si vous vous connectez à une zone et exécutez la commande pkginfo -l SUNWiqu, vous verrez le logiciel installé, de la même version que celle installée dans la zone globale. Vous pouvez ensuite exécuter les instances indépendantes du courtier Message Queue dans chaque zone puisque celles-ci ne partagent pas l'instance et les données de configuration stockées dans les répertoires /var et /etc. (La plupart des autres composants Java Enterprise System ne sont pas propagés s'ils sont installés dans la zone globale.)
Étant donné que Message Queue est propagé dans les zones non globales, l'instance globale est toujours liée aux installations dans les zones non globales. Ainsi, à chaque désinstallation ou mise à niveau de Message Queue dans la zone globale, les instances exécutées dans les zones non globales seront affectées. L'exemple suivant illustre les éventuels résultats inattendus découlant de cette opération.
Installez Message Queue 3.7 UR1 dans la zone globale. Les packages de Message Queue 3.7 UR1 sont également installés dans toutes les zones non globales.
Désinstallez Message Queue 3.7 UR1 dans une zone whole root. Ensuite, vous installez Message Queue 3.6 dans la zone whole root.
Vous possédez désormais différentes versions de Message Queue exécutées dans différentes zones - installation qui peut s'avérer fort utile.
Désinstallez Message Queue 3.7 UR1 dans la zone globale. Cela désinstallera Message Queue de toutes les autres zones - y compris l'instance Message Queue 3.6 dans la zone whole root.
Notez à chaque fois l'effet en cascade de l'installation et de la désinstallation de Message Queue dans la zone globale.
Les deux scénarios suivants vous expliquent comment installer différentes instances et versions de Message Queue dans différentes zones.
Si vous voulez installer Message Queue dans une zone whole root sur Solaris 10, Solaris 10U1, ou Solaris 10U2, vous devez d'abord mettre à niveau Lockhart dans la zone globale. Consultez la solution pour le bogue 645030 pour plus d'informations.
Installez la version souhaitée de Message Queue dans la zone globale.
Ces versions seront propagées dans toute zone non globale existante. Si vous créez des zones non globales supplémentaires, Message Queue sera également propagé dans ces zones. (Vous pouvez installer différentes instances dans les zones whole root ainsi que dans les zones sparse root, cependant, l'utilisation de zones sparse root permet une utilisation plus efficace de l'espace disque et des autres ressources).
Si vous voulez que Message Queue soit propagé dans toutes les autres zones non globales, créez ces zones maintenant.
Exécutez une instance de Message Queue dans chaque zone non globale.
Désinstallez Message Queue de la zone globale.
Créez des zones whole root et configurez chaque zone de manière à ne pas partager le répertoire /usr à l'aide de la directive suivante lors de la création de la zone.
remove inherit-pkg-dir dir=/usr
Installez différentes versions de Message Queue dans chaque zone whole root.
Notez que l'installation et la désinstallation de Message Queue dans la zone globale affectera toutes les instances (et versions) de Message Queue exécutées dans les zones whole root.