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.