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.

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.