Annexe A Java ES et zones Solaris 10

Cette annexe décrit les difficultés que vous pouvez rencontrer en installant et configurant les composants Java ES dans les zones Solaris 10 et vous présente certains conseils pour y faire face. Elle se compose des sections suivantes:

• Que sont les zones ?

• Pourquoi utiliser des zones pour Java ES ?

• Restrictions des zones de composants Java ES

• Prise en charge des zones dans le programme d'installation de Java ES

• Conseils d'utilisation des zones avec Java ES

• Cas spéciaux ou exceptions

• Cas concret : installation d'Application Server dans une zone sparse root

Que sont les zones ?

Les zones représentent une fonction de gestion des ressources et des applications du système d'exploitation Solaris 10. Cette fonction permet au système d'exploitation d'être représenté pour les applications sous forme d'environnements virtuels (zones), isolés et sécurisés. Ces zones offrent les avantages de l'indépendance d'un système d'exploitation avec un certain niveau de gestion centralisée des ressources. Ainsi, les applications peuvent être isolées les unes des autres en étant installées et exécutées sur différentes zones, alors que dans le même temps, certaines ressources du système d'exploitation peuvent être réparties et gérées de manière centralisée.

Pour un système d'exploitation prenant en charge plusieurs zones, les ressources de ce système peuvent contenir les éléments suivants : gestion de processus, mémoire, configuration réseau, systèmes de fichiers, registres de package, comptes utilisateur, bibliothèques partagées et, dans certains cas, applications installées.

Structure d'un environnement multizone

Un environnement multizone consiste en une zone globale (système d'exploitation par défaut) et une ou plusieurs zones non globales. La zone globale contient les ressources pouvant être réparties dans les zones non globales par un administrateur (de zone) global. Les zones non globales offrent les fonctions suivantes :

• Sécurité. En exécutant les services distribués dans des zones non globales, vous limitez les éventuels dommages découlant d'une violation de sécurité. Un intrus qui exploite avec succès un défaut de sécurité dans un logiciel sur une zone est confiné dans cette zone. Les privilèges disponibles dans une zone non globale représentent un sous-ensemble de ceux disponibles dans une zone globale.

• Isolation de l'exécution. Les zones non globales permettent de déployer plusieurs applications sur le même ordinateur même si ces applications requièrent différents niveaux de sécurité, un accès exclusif aux ressources globales ou une configuration individualisée. Par exemple, plusieurs applications exécutées dans différentes zones peuvent être liées sur le même port réseau en utilisant les adresses IP distinctes associées à chaque zone non globale. Les applications ne peuvent pas surveiller ou intercepter entre elles le trafic réseau, les données du système de fichiers ou l'activité des processus.

• Isolation administrative. L'environnement du système d'exploitation virtuel permet une administration séparée de chaque zone non globale. Les actions effectuées par un administrateur de zone (en opposition à l'administrateur global) dans une zone non globale, telles que la création de comptes utilisateur, l'installation et la configuration de logiciels ou la gestion de processus, n'affectent pas les autres zones.

Il existe deux types de zones non globales : les zones whole root et les zones sparse root :

• Zones whole root. Elles contiennent une copie lecture/écriture du système de fichiers existant sur la zone globale. Lorsqu'une zone whole root est créée, tous les packages installés sur la zone globale deviennent disponibles pour cette zone : une base de données de packages est créée et tous les fichiers sont copiés sur la zone whole root pour l'utilisation spéciale et indépendante de la zone.

• Zones sparse root. Elles contiennent une copie lecture/écriture d'une partie seulement du système de fichiers existant sur la zone globale (d'où le nom « sparse root », racine fragmentée), alors que d'autres systèmes de fichiers sont installés en lecture seule à partir de la zone globale sous forme de systèmes de fichiers virtuels loopback. Lorsqu'une zone sparse root est créée, l'administrateur global sélectionne les systèmes de fichiers à partager avec la zone sparse root (par défaut, les répertoires /usr, /lib, /sbin et /platform sont partagés sous forme de systèmes de fichiers en lecture seule). Tous les packages installés sur la zone globale sont accessibles à la zone sparse root : une base de données de packages est créée et tous les fichiers dans le système de fichiers installé sont partagés avec la zone.

Zones whole root vs. Zones sparse root

Le choix entre les zones non globales whole root ou sparse root repose sur un compromis entre l'efficacité des ressources et le contrôle administratif. Les zones whole root permettent de maximiser le contrôle administratif (indépendance et isolation) aux dépens de la mémoire et d'autres ressources, alors que les zones sparse root permettent d'optimiser le partage efficace des exécutables et des bibliothèques partagées (tout en utilisant une empreinte disque beaucoup plus petite) aux dépens de l'indépendance administrative. Il n'existe actuellement aucun moyen de départager les zones sparse root et whole root en termes de performances, il s'agit essentiellement de spécificités logicielles.

Propagation des packages

Lorsque les packages installés sur une zone globale (par défaut) sont disponibles pour toutes les zones non globales, on parle de propagation des packages. (Pour que la propagation puisse se réaliser, les zones non globales nouvellement créées doivent être entièrement initialisées, c'est-à-dire en état d'exécution.) La propagation fournit une visibilité locale (non globale) et un accès aux packages installés dans la zone globale. La propagation permet d'effectuer une gestion du cycle de vie des packages d'applications (installation, mise à niveau, désinstallation) de manière centralisée par un administrateur global, alors que la configuration des applications et la gestion de l'exécution sont réalisées par les administrateurs de zones (non globales).

Pour les zones whole root, la propagation a lieu via la copie automatique des fichiers installés de la zone globale vers les zones whole root et via la synchronisation automatique des informations de registre. Pour les zones sparse root, la propagation s'effectue à l'aide des systèmes de fichiers en lecture seule partagés entre les zones globales et sparse root et via la synchronisation automatique des informations de registre.

La propagation des packages dans les zones non globales est contrôlée au niveau des packages à l'aide des attributs de packages internes. Pour certaines valeurs de ces attributs (les valeurs par défaut, du moins), la propagation peut être désactivée au moment de l'installation à l'aide de l'option pkgadd —G, qui ignore les valeurs d'attribut. Une fois installé, le comportement de propagation d'un package ne peut pas être modifié, sauf en le désinstallant et réinstallant. Les patchs, par exemple, ne peuvent pas modifier le comportement de propagation d'un package. En effet, les patchs doivent être installés selon le comportement de propagation du package qu'ils mettent à niveau.

Pourquoi utiliser des zones pour Java ES ?

L'isolation qui s'applique aux applications exécutées dans différentes zones est similaire à l'isolation fournie par l'exécution d'applications sur le système d'exploitation de différents ordinateurs. Ainsi, au lieu d'installer, de configurer et d'exécuter les composants Java ES sur différents ordinateurs afin de les isoler et de les sécuriser, ces composants peuvent être installés, configurés ou exécutés dans différentes zones du même ordinateur.

Ce renforcement des composants Java ES peut également entraîner une meilleure utilisation des ressources. Les composants Java ES exécutés sur des ordinateurs dédiés, sous-utilisés, peuvent être désormais exécutés dans différentes zones non globales d'un seul ordinateur. Les administateurs globaux peuvent répartir les ressources de manière dynamique parmi les différentes zones selon les exigences en ressources des composants exécutés dans ces zones. (Notez que cette possibilité requiert plus de connaissances et de compréhension des exigences en ressources des différents composants que les informations actuellement disponibles.)

Un environnement multizone offre d'autres avantages :

• Séparation des versions. Des ensembles parallèles de composants Java ES de différentes versions peuvent être exécutés dans différentes zones. Cela permet la migration d'une version Java ES à une autre sur une certaine période. Par exemple, les composants de Java ES Version 4 dans une zone non globale peuvent être exécutés en parallèle aux composants de Java ES Version 5 dans une autre zone non globale. Pour pouvoir réaliser ce type de séparation de version, la gestion du cycle de vie (ainsi que la gestion de la configuration et de l'exécution) doit être déléguée aux administrateurs de zone.

• Gestion du cycle de vie centralisée. Même si elles ne sont pas prises en charge totalement en raison des restrictions de Java ES, les zones permettent de centraliser la gestion du cycle de vie des composants Java ES : ces composants peuvent être installés, mis à niveau et désinstallés dans la zone globale mais configurés et exécutés dans un certain nombre de zones non globales afin de fournir l'isolation de l'exécution, la sécurité, l'évolutivité et d'autres besoins. La centralisation de la gestion du cycle de vie s'avère pratique lorsque plusieurs instances d'un composant sont exécutées dans différentes zones ou lorsque vous souhaitez vous assurer que de telles instances sont synchronisées sur la même version.

  Par exemple, vous pouvez installer une seule fois Application Server dans la zone globale et exécuter plusieurs instances dans différentes zones non globales. Les diverses instances d'Application Server peuvent prendre en charge Access Manager, Portal Server, ou d'autres composants Java ES (il peut s'agir des mêmes composants ou de différents composants dans les zones non globales). Sinon, les instances d'Application Server peuvent être utilisées par différentes équipes de développement dans différentes zones.

  Pour réaliser cet objectif, la gestion du cycle de vie est effectuée par un administrateur global, alors que la gestion de la configuration et de l'exécution est déléguée aux administrateurs de zone correspondants. Cette approche nécessite une importante coordination lors de l'exécution des tâches de gestion du cycle de vie (telles que la mise à niveau).

• Indépendance organisationnelle. Différentes organisations peuvent maintenir des déploiements de composants Java ES séparés ou des instances d'exécution de composants Java ES séparées, le tout coexistant et exécuté sur le même ordinateur. Par exemple, différents groupes de développeurs peuvent utiliser leurs propres instances distinctes de composants Java ES ou des organisations peuvent utiliser divers déploiements de composants pour les phases de test, de mise en œuvre de la pré-production ou de production. L'indépendance organisationnelle peut être réalisée de différentes manières, selon des objectifs spécifiques : soit en centralisant la gestion du cycle de vie Java ES tout en déléguant la gestion de la configuration et de l'exécution aux administrateurs de zone, soit en déléguant l'ensemble des fonctions de gestion (cycle de vie, configuration et exécution) aux administrateurs de zone.

Les différents objectifs que vous pouvez réaliser en utilisant Java ES dans un environnement multizone et les scénarios d'usage correspondants requièrent différentes stratégies pour le déploiement et l'administration des composants Java ES dans ce type d'environnement. Certains objectifs se réalisent à l'aide de l'isolation de différentes zones pour gérer indépendamment les composants Java ES et leurs instances d'exécution, alors que d'autres objectifs font appel aux capacités de propagation de la zone globale pour simplifier la gestion du cycle de vie des composants Java ES.

Les stratégies d'installation et d'administration pour utiliser Java ES dans un environnement multizone seront revues après avoir abordé les restrictions de ce type d'environnement imposées par la nature du logiciel Java ES.

Restrictions des zones de composants Java ES

Les composants Java ES sont regroupés en différents types, comme décrit dans Présentation technique de Sun Java Enterprise System 5. Par conséquent, les composants de service système fournissent les principaux services d'infrastructure Java ES, tandis que les composants de qualité de service tendent à améliorer ces services système. Ces deux types de composants Java ES sont référés ici comme composants produit, composants sélectionnables dans le programme d'installation de Java ES.

Chaque composant produit dépend d'une ou plusieurs bibliothèques partagées localement, connues sous le nom de composants partagés Java ES. Les composants partagés sont automatiquement installés par le programme d'installation de Java ES lors de l'installation d'un composant produit et dépendent du type de composants produit en cours d'installation. Ils ne sont pas individuellement sélectionnés, installés ou configurés lors du déploiement des composants produit Java ES.

Zones et composants partagés Java ES

La discussion dans Pourquoi utiliser des zones pour Java ES ? portait sur l'utilisation des zones par les composants produit Java ES : ces composants pouvant être explicitement sélectionnés dans le programme d'installation de Java ES et installés et configurés dans diverses zones de manière à obtenir l'architecture de déploiement et les capacités fonctionnelles souhaitées. Cependant, les composants partagés, dont dépendent les composants produit, entraînent certaines restrictions pour le déploiement de Java ES dans un environnement multizone. Voici les deux principales difficultés concernant l'utilisation des composants partagés Java ES et des zones :

Synchronisation des composants partagés

Les difficultés de contrôle et de prise en charge du grand nombre (environ 30) d'interactions complexes entre les composants partagés Java ES et les composants produit Java ES nécessitent que tous les composants partagés d'une instance de système d'exploitation unique soient synchronisés sur la même version Java ES. En d'autres termes, tous les composants partagés Java ES installés dans un environnement sans zone, ou dans n'importe quelle zone d'un environnement Solaris 10, doivent être de la même version. Cette exigence entraîne certaines restrictions concernant l'utilisation de Java ES dans un environnement multizone.

Voici les conséquences de ce besoin de synchronisation :

• Les différentes versions des composants partagés Java ES ne peuvent résider que dans des zones différentes. Par exemple, vous pouvez installer les composants partagés de Java ES Version 4 dans une zone et les composants partagés de Java ES Version 5 dans une autre zone mais vous ne pouvez pas les combiner dans une seule et même zone.

• Si un composant partagé dans une zone est mis à niveau ou que tout nouveau composant partagé d'une version supérieure est installé, alors tous les composants partagés de cette zone doivent être mis à niveau dans le même temps. (Les composants partagés doivent être rétrocompatibles afin que les composants produit de la Version 4 puissent fonctionner avec les composants partagés de la Version 5.) Supposons, par exemple, qu'un composant produit de la Version 5 soit installé dans une zone dans laquelle un ou plusieurs composants produit de la Version 4 résident. Étant donné que le composant produit Version 5 requiert un certain nombre de composants partagés Version 5, de par le besoin de synchronisation, il est nécessaire que tous les composants partagés Version 4 résidant dans cette zone soient mis à niveau en Version 5 au moment de l'installation du composant produit Version 5. Il en va ainsi même si le composant produit Version 5 installé requiert des composants partagés différents de ceux déjà installés dans la zone.

• Lorsque des composants partagés sont installés et qu'ils se propagent à partir de la zone globale (voir la section Stratégies de propagation Java ES), il est important de maintenir une synchronisation des composants partagés dans toutes les zones. Sinon, les composants partagés d'une version précédente dans une zone non globale pourraient se mélanger avec les composants partagés Version 5 propagés à partir de la zone globale. (Nous soulignons l'importance de cette action car habituellement la gestion du cycle de vie des composants partagés s'effectue uniquement dans la zone globale : Pour plus d'informations, reportez-vous au Tableau A–2 et à la section Cas spéciaux relatifs aux composants partagés.).

Le besoin de synchronisation des composants partagés impose des restrictions sur l'utilisation du programme d'installation de Java ES dans un environnement multizone (pour plus d'informations, voir Prise en charge des zones dans le programme d'installation de Java ES) et modifie les procédures d'installation et de mise à niveau des composants produit Java ES dans ce type d'environnement.

Composants partagés et Zones sparse root

L'utilisation de Java ES dans un environnement multizone peut également être modifiée du fait qu'un grand nombre de composants partagés ne peut être installé dans les zones sparse root à cause des systèmes de fichiers en lecture seule présents dans ces zones. Par conséquent, ces composants partagés, dont le répertoire de base est /usr (répertoire qui par défaut est partagé par la zone globale), doivent être installés dans la zone globale afin d'être accessibles dans une zone sparse root.

L'incapacité à installer certains composants partagés Java ES dans des zones sparse root signifie que pour correctement installer des composants produit ayant des dépendances sur de tels composants partagés dans des zones sparse root, ces derniers doivent d'abord être installés dans la zone globale et propagés dans les zones non globales.

Composants produit Java ES et Zones

Certains des objectifs présentés dans la section Pourquoi utiliser des zones pour Java ES ? pour l'utilisation de Java ES dans un environnement multizone, et les scénarios d'usage correspondants, font appel aux capacités de propagation de la zone globale afin de simplifier la gestion du cycle de vie des composants produit Java ES. De tels scénarios d'usage, par exemple, proposent la gestion du cycle de vie des composants produit Java ES dans la zone globale par l'administrateur global, tandis que la gestion de la configuration et de l'exécution de ces composants est effectuée dans des zones non globales par des administrateurs de zone.

En d'autres termes, les composants produit sont installés et mis à niveau dans une zone globale alors que les instances sont configurées et exécutées dans des zones non globales. Ce scénario d'usage combine les avantages de la gestion centralisée du cycle de vie avec l'isolation et la sécurité apportées par les zones non globales.

Cependant, ce scénario dépend de la capacité de chaque composant produit à être installé dans la zone globale mais configuré et exécuté dans une zone non globale. Cette séparation dépend du mode de configuration de chaque composant produit, du lieu de stockage des données de configuration et des applications dynamiques, du mode de repérage des données de configuration via l'exécution des binaires et du mode d'exécution des mises à niveau. La séparation peut également dépendre des fonctions de scripts de pré ou post installation/mise à niveau : ils démarrent ou stoppent les instances de composants, créent des liens vers les données de configuration ou effectuent d'autres tâches qui atténuent la distinction entre la gestion de la configuration et du cycle de vie.

Cette séparation peut également dépendre de la réalisation de la configuration dans une zone whole root ou sparse root. Par exemple, si le script de configuration des composants produit écrit sur un système de fichiers en lecture seule dans une zone sparse root (par exemple /usr) ou si des systèmes de fichiers rajoutés (tels que /opt) sont partagés dans une zone sparse root, il est possible que la configuration du composant échoue.

---

Remarque –

Presque tous les composants produit Java ES sont installés sous /opt , qui, par défaut, peut être écrit dans les zones sparse root. Pour plus d'informations, reportez-vous à Référence de l’installation de Sun Java Enterprise System 5 pour UNIX

---

Au jour d'aujourd'hui, la capacité de chacun des 20 composants produit Java ES de prendre en charge la séparation de la gestion du cycle de vie et de la gestion de la configuration/exécution entre les zones globales et non globales n'a pas encore été établie. Les divers composants produit ont adopté différentes approches concernant les opérations de configuration et de mise à niveau. Vu la situation, la propagation des composants produit Java ES (sauf pour Message Queue) n'est actuellement pas prise en charge. Pour plus d'informations, reportez-vous à la section Stratégies de propagation Java ES.

Prise en charge des zones dans le programme d'installation de Java ES

En s'appuyant sur les scénarios d'usage abordés dans la section Pourquoi utiliser des zones pour Java ES ? et sur les exigences et restrictions applicables aux composants de Java ES, abordées dans la section Restrictions des zones de composants Java ES , le programme d'installation de Java ES fournit une prise en charge des zones pour l'installation (et la mise à niveau) des composants produit Java ES et pour la synchronisation des composants partagés. Des stratégies ont été implémentées dans le programme d'installation pour ne plus rencontrer de scénarios problématiques lors de l'installation ou de la mise à niveau.

Stratégies de propagation Java ES

En s'appuyant sur les limitations présentées à la section 3, le programme d'installation de Java ES ajoute deux stratégies de propagation Java ES :

• Lorsque des composants produit sont installés dans la zone globale, ils sont définis par défaut pour ne pas se propager dans les zones non globales (à l'exception de Message Queue). Ainsi, les zones non globales ne les voient pas dans leur registre et n'ont pas accès aux composants installés.

• Lorsque des composants partagés sont installés dans la zone globale (par exemple comme partie de l'installation des composants produit), ils sont définis de manière à se propager dans les zones non globales. Ainsi, les zones non globales les voient dans leur registre et ont accès aux composants partagés installés. Cette stratégie aide à appliquer l'exigence selon laquelle les versions de composants partagés doivent être synchronisées dans les zones, comme décrit dans la section Zones et composants partagés Java ES.

Installation des composants produit

Le programme d'installation de Java ES peut installer les composants produit ainsi que les composants partagés nécessaires pour prendre en charge chaque composant produit. Avant d'installer un composant produit sélectionné, le programme d'installation vérifie l'existence des versions actuelles et précédentes des composants partagés. Si le programme d'installation détecte qu'un composant partagé requis par le composant sélectionné appartient à une ancienne version ou n'est pas installé, celui-ci mettra à niveau tous les composants partagés actuellement installés et installera tout composant partagé manquant requis par le composant sélectionné. Ce comportement, qui répond aux exigences de la section Synchronisation des composants partagés, est valable pour les systèmes d'exploitation sans zone, pour les zones globales et pour toutes les zones non globales.

Voici cependant deux exceptions à cette règle :

• Dans les zones sparse root, certains composants partagés ne peuvent pas être installés ou mis à niveau (voir section Composants partagés et Zones sparse root), l'installation est alors bloquée jusqu'à ce que ces composants soient installés ou mis à niveau dans la zone globale. Le programme d'installation affiche le message suivant : Les composants partagés suivants, requis par les composants sélectionnés, ne peuvent pas être installés ou mis à niveau dans une zone sparse root. Installez ou procédez à la mise à niveau de ces composants partagés dans la zone globale avant de poursuivre. Utilisez l'option Synchroniser tous les composants partagésPour plus d'informations, reportez-vous à la section Synchroniser tous les composants partagés.

• Dans une zone globale, en présence de zones non globales, au lieu de mettre à niveau tous les composants partagés actuellement installés et installer chaque composant partagé manquant requis par un composant sélectionné, le programme d'installation synchronise tous les composants partagés Java ES, qu'ils soient requis ou non par un composant produit spécifique. Cela permet de propager tous les composants partagés dans les zones non globales, en supposant qu'il n'y ait pas de mélange de différentes versions de composants partagés dans les zones non globales.

Mise à niveau des composants produit

Une nouvelle fonctionnalité a été implémentée dans Java ES Version 5 pour pouvoir mettre à niveau des composants produit dans certaines situations : Application Server, Message Queue, HADB et Java DB. Lorsque le programme d'installation de Java ES détecte les versions précédemment installées de ces composants produit, celui-ci les marque comme pouvant être mises à niveau dans la page de sélection des composants. Si certains de ces composants sont sélectionnés, le programme d'installation les mettra à niveau en utilisant la même procédure que pour une installation normale.

Par exemple, avant de mettre à niveau un composant produit sélectionné, le programme d'installation vérifie l'existence des versions actuelles et précédentes des composants partagés. Si le programme d'installation détecte qu'un composant partagé requis par le composant sélectionné appartient à une ancienne version ou n'est pas installé, celui-ci mettra à niveau tous les composants partagés actuellement installés et installera tout composant partagé manquant requis par le composant sélectionné. Ce comportement, qui répond aux exigences de la section Synchronisation des composants partagés, est valable pour les systèmes d'exploitation sans zone, pour les zones globales et pour toutes les zones non globales.

Voici cependant trois exceptions à cette règle :

• Dans les zones sparse root, certains composants partagés ne peuvent pas être installés ou mis à niveau, l'opération de mise à niveau est alors bloquée jusqu'à ce que ces composants soient installés ou mis à niveau dans la zone globale. (Pour plus d'informations, reportez-vous à la section Composants partagés et Zones sparse root) Le programme d'installation affiche le message suivant : Les composants partagés suivants, requis par les composants sélectionnés, ne peuvent pas être installés ou mis à niveau dans une zone sparse root. Installez ou procédez à la mise à niveau de ces composants partagés dans la zone globale avant de poursuivre. Utilisez l'option Synchroniser tous les composants partagés(Pour plus d'informations, reportez-vous à la section Synchroniser tous les composants partagés.)

• Application Server et Message Queue sont tous les deux intégrés dans le système d'exploitation Solaris. Mais aucune de ces versions ne peut être directement mise à niveau dans une zone sparse root. Pour plus de détails concernant ces composants intégrés, reportez-vous à la section Cas spéciaux relatifs aux composants produit.

• Dans une zone globale, en présence de zones non globales, au lieu de mettre à niveau tous les composants partagés actuellement installés et installer chaque composant partagé manquant requis par un composant sélectionné pour l'installation, le programme d'installation synchronise tous les composants partagés Java ES, qu'ils soient requis ou non à ce moment là par un des composants sélectionnés pour l'installation. Cela permet de propager tous les composants partagés dans les zones non globales, en supposant qu'il n'y ait pas de mélange de différentes versions de composants partagés dans les zones non globales.

---

Remarque –

Il existe un certain nombre de cas spéciaux ou d'exceptions pouvant interférer avec l'installation ou la mise à niveau des composants produit dans les zones non globales. Ces cas sont décrits dans la section Cas spéciaux ou exceptions.

---

Synchroniser tous les composants partagés

L'option de synchronisation des composants partagés permet de répondre aux situations dans lesquelles tous les composants partagés doivent être synchronisés. Lorsque l'option Synchroniser tous les composants partagés est sélectionnée, le programme d'installation mettra à niveau tous les composants partagés actuellement installés et installera tout composant partagé manquant, qu'il soit requis ou non par un composant produit spécifique. Cette option est valable pour les zones globales et les zones whole root, mais pas pour les zones sparse root.

Elle est nécessaire dans les deux scénarios suivants basés sur les zones :

• Mise à niveau manuelle des composants produit L'option Synchroniser tous les composants partagés est requise pour effectuer l'installation et la mise à niveau des composants partagés, qui sont nécessaires lors de la mise à niveau des composants produit qui ne peuvent pas être mis à niveau à l'aide du programme d'installation Java ES.

• Installations et mises à niveau dans une zone sparse root Certains composants partagés ne peuvent pas être installés dans les zones sparse root par défaut. (Pour plus de détails, reportez-vous aux sections Installation des composants produit et Mise à niveau des composants produit.) Par conséquent, lors de l'exécution du programme d'installation dans les zones sparse root, vous devrez peut-être d'abord synchroniser les composants partagés dans la zone globale, en fonction des composants partagés impliqués. Utilisez l'option Synchroniser tous les composants partagés dans la zone globale pour effectuer l'installation et la mise à niveau des composants partagés, qui sont requises dans ce cas.

Résumé des comportements du programme d'installation Java ES pour les composants partagés

Les comportements décrits dans les sections précédentes sont rassemblés dans le tableau suivant. Ce dernier montre de quelle manière le traitement des composants partagés par le programme d'installation Java ES dépend du contexte de zone ainsi que des éléments sélectionnés dans la page de sélection des composants.

Tableau A–1 Comportement du programme d'installation pour les composants partagés

Contexte de zone	Composant produit sélectionné	Tous les composants partagés sélectionnés
Système d'exploitation sans zone	Mettre à niveau tous les composants partagés actuellement installés  Installer chaque composant partagé manquant requis par le composant produit sélectionné	Mettre à niveau tous les composants partagés actuellement installés  Installer chaque composant partagé manquant, qu'il soit requis ou non par un composant produit spécifique
Zone globale : sans zones non globales	Mettre à niveau tous les composants partagés actuellement installés  Installer chaque composant partagé manquant requis par le composant produit sélectionné	Mettre à niveau tous les composants partagés actuellement installés   Installer chaque composant partagé manquant, qu'il soit requis ou non par un composant produit spécifique
Zone globale : avec des zones non globales	Mettre à niveau tous les composants partagés actuellement installés   Installer chaque composant partagé manquant, qu'il soit requis ou non par un composant produit spécifique	Mettre à niveau tous les composants partagés actuellement installés, installer chaque composant partagé manquant, qu'il soit requis ou non par un composant produit spécifique
Zone whole root	Mettre à niveau tous les composants partagés actuellement installés  Installer chaque composant partagé manquant requis par le composant produit sélectionné	Mettre à niveau tous les composants partagés actuellement installés  Installer chaque composant partagé manquant, qu'il soit requis ou non par un composant produit spécifique
Zone sparse root	Impossible de mettre à niveau ou d'installer certains composants partagés dans des répertoires en lecture seule. Si le programme d'installation rencontre de tels composants partagés, il bloque le processus et envoie un message d'instruction à l'utilisateur pour gérer les composants partagés dans la zone globale.	Impossible de mettre à niveau ou d'installer certains composants partagés dans des répertoires en lecture seule. Le programme d'installation bloque alors le processus et envoie un message d'instruction à l'utilisateur pour gérer les composants partagés dans la zone globale.

Conseils d'utilisation des zones avec Java ES

Alors que le déploiement de Java ES dans un environnement multizone a pour objectif général de fournir une isolation de l'exécution et une utilisation efficace des ressources pour les composants produit, l'utilisation d'un environnement multizone suit un certain nombre d'objectifs plus spécifiques. Ils sont traités comme indiqué dans la section Pourquoi utiliser des zones pour Java ES ?. Les stratégies d'installation et d'administration de Java ES dans un environnement multizone dépendent largement des objectifs que vous souhaitez atteindre.

LeTableau A–2 compare cinq scénarios, les stratégies d'installation et d'administration correspondantes et les objectifs sensés être atteints. Bien que la combinaison de ces scénarios soit possible dans certaines situations, les résultats peuvent s'avérer problématiques et entraîner des dysfonctionnements administratifs. Par conséquent, Java ES Version 5 ne prend généralement pas en charge les déploiements combinant ces scénarios.

De plus, les scénarios 1 et 5 sont problématiques, donc Java ES Version 5 ne les prend actuellement pas en charge (il est tout de même possible qu'une adaptation soit mise en œuvre pour des composants produit spécifiques pour le scénario 5).

Tableau A–2 Stratégies d'installation et d'administration des zones pour Java ES

Scénario (stratégie d'installation)	Stratégie d'administration	Objectif (voir la section Pourquoi utiliser des zones pour Java ES ?)	Commentaires
1 : Installer les composants produit et composants partagés dans la zone globale avec la propagation activée. Aucun composant installé dans les zones non globales.*	Gestion du cycle de vie des composants : administrateur global   Gestion de la configuration et de l'exécution : administrateurs de zone	Gestion centralisée du cycle de vie des composants produit   Indépendance organisationnelle de la gestion de la configuration et de l'exécution des composants produit	Problématique : Option non encore prise en charge pour les composants produit Java ES, sauf pour Message Queue. Nécessite la prise en charge par les composants produit de l'installation dans la zone globale et la gestion de la configuration et de l'exécution dans les zones non globales.
2 : Installer les composants partagés dans la zone globale et les composants produit dans les zones whole root	Gestion du cycle de vie des composants partagés : administrateur global   Gestion du cycle de vie des composants produit : administrateurs de zone   Gestion de la configuration et de l'exécution : administrateurs de zone	Gestion centralisée du cycle de vie des composants partagés   Indépendance organisationnelle de la gestion du cycle de vie, de la configuration et de l'exécution des composants produit	Est généralement valable lorsque tous les composants sont de la même version de Java ES ou lors de la mise à niveau de tous les composants produit dans toutes les zones whole root.
3 : Installer les composants partagés dans la zone globale et les composants produit dans les zones sparse root**	Cf. scénario n° 2	Gestion centralisée du cycle de vie des composants produit.   Indépendance organisationnelle de la gestion du cycle de vie, de la configuration et de l'exécution des composants produit   Efficacité des ressources accrue par rapport au scénario #2 (voir section Zones whole root vs. Zones sparse root)	Ce scénario est recommandé lors de l'installation de composants produit dans les zones sparse root. (Certains composants partagés peuvent être installés dans les zones sparse root et doivent donc être installés dans la zone globale.)
4 : Installer les composants produit et composants partagés dans les zones whole root	Gestion du cycle de vie des composants : administrateurs de zone, gestion de la configuration et de l'exécution : administrateurs de zone	Séparation de version	Aucun composant partagé ou composant produit ne doit être installé dans la zone globale. Scénario recommandé pour les zones whole root.
5 : Installer les composants produit et composants partagés dans les zones sparse root	Cf. scénario n° 4	Indépendance organisationnelle de la gestion du cycle de vie, de la configuration et de l'exécution des composants produit  Efficacité des ressources accrue par rapport au scénario #4 (voir section Zones whole root vs. Zones sparse root)	Problématique : Option non disponible car un certain nombre de composants partagés ne peut pas être installé dans les zones sparse root.

* Le scénario 1 ne fait pas la distinction entre les environnements de zones whole root et sparse root ; il suppose qu'aucun composant produit n'est installé dans les zones non globales. L'installation des composants de produit dans les zones non globales est présentée dans les scénarios 2-5.

** Le scénario 3 suppose que /opt n'est pas un répertoire en lecture seule dans la zone sparse root. Si le répertoire /opt était en lecture seule, la plupart des composants produit Java ES ne pourraient pas être installés dans les zones sparse root et devraient donc être installés dans la zone globale comme décrit dans le scénario 1 (appproche alternative).

Pratiques recommandées

Avec le Tableau A–2 comme référence, voici quelques recommandations :

• Planifiez votre stratégie de déploiement des zones Java ES à l'avance selon les objectifs visés (section Pourquoi utiliser des zones pour Java ES ?). Des objectifs différents nécessitent des stratégies d'installation et d'administration différentes, comme le montrent les scénarios du Tableau A–2.

• Évitez de combiner les scénarios. Notamment\~:

  • Assurez-vous que votre stratégie de déploiement et d'administration des zones Java ES reste la plus simple possible. Ne combinez pas les déploiements whole root et sparse root des composants Java ES sur le même ordinateur. (Les procédures et pratiques nécessaires à la prise en charge des déploiements en zone sparse root du scénario 3 peuvent interférer avec les déploiements en zone whole root du scénario 4.)

  • N'installez pas le même composant produit Java ES dans la zone globale et dans les zones non globales, même si la version est différente. (Les procédures nécessaires à la mise à niveau de l'installation en zone globale du scénario 1 peuvent corrompre les installations en zone non globale du scénario 4.)

  • Lorsque des composants Java ES Version 4 (ou version précédente) ont été installés dans une zone whole root, n'installez pas de composants Java ES Version 5 (ni de composants produit, ni de composants partagés) dans la zone globale et ne procédez pas à la mise à niveau des composants Java ES en Version 5 dans la zone globale. En d'autres termes, le scénario 2 n'est pas pris en charge lorsqu'il y a des installations pré-existantes dans une zone whole root. (Une installation ou une mise à niveau dans la zone globale pourrait résulter en un mélange des fichiers Version 4 et Version 5 dans la zone whole root.)

• Pratiques d'installation recommandées :

  • Si vous souhaitez exécuter différents composants produit Java ES dans différentes zones, installez-les dans des zones non globales (scénarios 2, 3, 4, 5).

  • Si vous souhaitez exécuter différents composants produit Java ES dans différentes zones mais gérer de manière centralisée les cycles de vie des composants partagés, synchronisez ces derniers dans la zone globale, puis installez les composants produit dans des zones non globales (scénarios 2, 3). (Cette pratique est également valable pour les zones sparse root.)

  • Si vous souhaitez effectuer une séparation des versions des composants produit Java ES ou pour d'autres raisons isoler les déploiements des composants produit Java ES (scénario 4), installez et configurez l'ensemble des composants Java ES dans des zones whole root. N'installez pas de composant Java ES dans la zone globale.

• Pratiques de mise à niveau recommandées :

  • Si vous souhaitez mettre à niveau tous les composants produit Version 4 installés en Version 5, synchronisez l'ensemble des composants partagés Java ES dans la zone globale, puis procédez à la mise à niveau des composants produit choisis dans les zones où ils ont été installés. (Les composants partagés Version 5 sont rétrocompatibles.)

  • Si les composants produit Version 4 ou 5 sont installés dans un environnement sans zone et que vous souhaitez ajouter des zones non globales à cet environnement et installer des composants produit dans ces zones nouvellement créées, assurez-vous de suivre les recommandations ci-dessus. Il vous sera peut-être nécessaire de désinstaller des composants de la zone globale et de les réinstaller dans des zones non globales.

Architectures de déploiement

Les descriptions de scénario contenues dans le Tableau A–2 et les pratiques recommandées ci-dessus n'incluent pas les architectures de déploiement Java ES pour un environnement multizone. De telles architectures représenteraient une adaptation des architectures de déploiement créées pour les environnements réseau à plusieurs ordinateurs. En d'autres termes, la présence d'environnements multizones ne modifie pas les approches de conception du déploiement de base pour obtenir de meilleures performances, une haute disponibilité, l'évolutivité, la sécurité et l'entretien pour les systèmes de déploiement Java ES. Ce qu'un environnement multizone vous permet de faire est de consolider ces architectures de déploiement sur un nombre restreint d'ordinateurs.

Cependant, les détails relatifs à l'adaptation de l'architecture de déploiement Java ES à un environnement multizone dépendent largement des stratégies administratives choisies, comme mentionné dans les sections précédentes. Les architectures de déploiement dépendent également de la stratégie choisie pour obtenir une haute disponibilité.

Notez que le Tableau A–2 et les pratiques recommandées ci-dessus n'incluent pas les procédures recommandées d'implémentation des scénarios présentés. Dans certains cas, l'ordre dans lequel les composants Java ES sont installés et l'ordre dans lequel les zones non locales sont créées peuvent s'avérer importants.

Cas spéciaux ou exceptions

Un certain nombre de cas spéciaux résulte du fait que certains composants partagés Java ES et certains composants produit Java ES sont intégrés à Solaris 10. Par conséquent, ces composants Java ES existent dans la zone globale, ainsi que dans chaque zone non globale créée à partir cette zone.

Cas spéciaux relatifs aux composants produit

• Message Queue est intégré à Solaris 10. Par conséquent, il est automatiquement propagé lors de la création de zones non globales (à moins que vous n'ayez au préalable supprimé Message Queue de la zone globale). Il est impossible d'installer Message Queue dans une zone sparse root. Lorsqu'il est installé ou mis à niveau dans une zone globale par le programme d'installation de Java ES, Message Queue est, par défaut, propagé dans les zones non globales, à la différence des autres composants produit.

• Application Server est intégré à Solaris 10. Par conséquent, il est automatiquement propagé lors de la création de zones non globales (à moins que vous n'ayez au préalable supprimé Application Server de la zone globale). Avec une propagation de ce type, Application Server intégré, installé dans /usr , ne peut pas être mis à niveau par le programme d'installation de Java ES dans une zone sparse root (par défaut, /usr est en lecture seule). Pour contourner ce problème, Application Server intégré doit être supprimé manuellement de la zone globale avant d'installer Application Server (Version 5) dans une zone sparse root.

• Sun Cluster peut uniquement être installé dans une zone globale. Sun Cluster n'est pas pris en charge dans les zones non globales.

Cas spéciaux relatifs aux composants partagés

• Les packages SJWC, intégrés à Solaris 10 (Mise à jour 1 et Mise à jour 2), ne peuvent pas être supprimés par le programme d'installation de Java ES. Le paramètre SUNW_PKG_ALLZONES de ces anciens packages a été défini sur True (Vrai), ce qui signifie que le package doit être identique dans toutes les zones et ne peut être géré que par l'administrateur global. Par conséquent, ces packages doivent être supprimés manuellement dans la zone globale en vue d'être remplacés par les packages corrects.

  Si le programme d'installation de Java ES tente d'installer un composant sélectionné dans une zone non globale et qu'il détecte un besoin de mise à niveau pour SJWC, celui-ci s'arrêtera. Cela se produit lors de l'installation sous Solaris 10, mise à jour 1 et 2.

  La solution développée est un script spécial visant à supprimer les anciens packages de SJWC de la zone globale et les remplacer par SJWC 2.2.6, comportant les paramètres corrects pour les attributs de propagation des zones. Par conséquent, SJWC 2 2.6 est propagé vers tous les zones non globales.

• Common Agent Container. La version 1.1 est uniquement installée lorsque Sun Cluster, Sun Cluster GE, ou les Agents Sun Cluster sont installés. Elle n'est pas installée lorsque l'option Synchroniser tous les composants partagés est sélectionnée. Dans ce cas, seule la version 2.0 est installée.

• Sun Explorer Data Collector. Ce composant partagé est uniquement installé lorsque Sun Cluster, Sun Cluster GE ou les Agents Sun Cluster sont installés. Il n'est pas installé lorsque l'option Synchroniser tous les composants partagés est sélectionnée.

Cas concret : installation d'Application Server dans une zone sparse root

L'exemple suivant vise à illustrer certaines des complexités relatives à la prise en charge des zones de Java ES. Dans cet exemple, l'objectif est d'installer Application Server dans une zone sparse root de Solaris 10. Cette installation est compliquée du fait que Application Server (ainsi que Message Queue, dont dépend Application Server), est intégré avec Solaris 10, et que, par conséquent, la version intégrée est installée dans toutes les zones non globales. Pour plus d'informations, reportez-vous à la section Cas spéciaux relatifs aux composants produit.

Pour installer Application Server dans une zone sparse root, vous devez d'abord supprimer la version intégrée. (Il ne suffit pas de simplement mettre à jour la version intégrée dans la zone sparse root car celle-ci est installée dans un répertoire en lecture seule.) Pour supprimer la version intégrée de la zone sparse root, vous devez d'abord la supprimer de la zone globale.

En outre, Message Queue est installé dans la zone globale - situation de départ du scénario 3 du Tableau A–2, dans lequel seuls les composants partagés (aucun composant produit) sont installés dans la zone globale. Néanmoins, Message Queue ne peut pas être installé dans une zone sparse root, car il est installé dans un répertoire en lecture seule, il doit ainsi être installé et mis à niveau dans la zone globale.

Vous devez alors procéder comme suit :

1. Vérifiez que Solaris 10 est exécuté sur votre système.

   Cet exemple suppose qu'une version normale de Solaris 10 sans aucun composant Java ES a été installée dans la zone globale.

2. Créez une zone sparse root (configurez, installez et initialisez-la).

   Cette zone incluera tous les composants Java ES déjà installés dans la zone globale, à savoir les versions de Message Queue et Application Server intégrés à Solaris 10.

3. Supprimez la version intégrée d'Application Server de la zone globale.

   Pour ce faire, supprimez manuellement les packages d'Application Server :

   pkgrm SUNWascmnse SUNWaslb SUNWasut ...

   via la commande suivante (pour l'ensemble complet des packages) :

   pkginfo -I|grep -I application server

   Vous obtiendrez les packages suivants :

   SUNWascmnse, SUNWaslb, SUNWasut, SUNWasac, SUNWasdem, SUNWasman, SUNWaswbcr, SUNWasacee, SUNWashdm, SUNWasmanee, SUNWascml, SUNWasJdbcDrivers, SUNWasu, SUNWascmn, SUNWasjdoc, SUNWasuee

   ainsi que les packages de localisation suivants :

   SUNWLocaleasacee, SUNWLocaleascmnse, SUNWLocaleasu, SUNWLocaleasuee

   La suppression d'Application Server de la zone globale est propagée dans la zone sparse root créée à l'étape 2 (ces deux étapes peuvent être inversées).

4. Installez les composants partagés de Java ES 5 dans la zone globale.

   1. Exécutez le programme d'installation de Java ES dans la zone globale.

   2. Sélectionnez l'option Synchroniser tous les composants partagés à partir du panneau de sélection des composants. Ne sélectionnez pas d'autres composants.

   3. Procédez à la synchronisation des composants partagés. L'ensemble des composants partagés est désormais synchronisé dans la zone globale et propagé dans toutes les zones non globales.

5. Procédez à la mise à niveau de Message Queue dans la zone globale.

   La version de Message Queue intégrée à Solaris 10 est déjà installée dans la zone sparse root (étape 2). Pour mettre le programme à niveau dans cette zone, mettez-le simplement à niveau dans la zone globale ; la mise à niveau se propagera dans la zone sparse root. (Message Queue est le seul composant produit ne pouvant pas être installé dans une zone sparse root, mais lorsqu'il est installé dans la zone globale, il se propage dans les zones non globales.).

   1. Exécutez le programme d'installation de Java ES dans la zone globale.

   2. Sélectionnez Message Queue dans le panneau de sélection des composants. Ne sélectionnez pas d'autres composants.

   3. Procédez à la mise à niveau de Message Queue.

6. Installez Application Server dans la zone sparse root.

   1. Exécutez le programme d'installation de Java ES dans la zone sparse root.

   2. Sélectionnez Application Server dans le panneau de sélection des composants. Ne sélectionnez aucun autre composant pour la mise à niveau. Ne sélectionnez pas Message Queue si celui-ci est déjà sélectionné.

   3. Terminez l'installation d'Application Server.