|
| |
| Guide de mise à niveau de Sun Java Enterprise System 5 pour UNIX | |
Chapitre 1
Planification des mises à niveauCe chapitre fournit les informations nécessaires pour planifier la mise à niveau du logiciel Sun Java™ Enterprise System (Java ES) vers Java ES 5 dans un environnement de système d'exploitation Sun Solaris™ ou Red Hat Enterprise Linux (désigné Linux).
Il se compose des sections suivantes :
Composants de Java ES 5Pour présenter la planification de la mise à niveau du logiciel Java ES, cette section décrit les composants de Java ES 5 (version 5). Selon votre scénario de mise à niveau, vous devrez éventuellement actualiser un ou plusieurs composants vers leur version 5.
Les composants Java ES sont regroupés par types, comme cela est décrit dans Présentation technique de Java Enterprise System 5 (http://docs.sun.com/doc/819-3587).
- Composants partagés. Les composants partagés de Java ES correspondent à des bibliothèques partagées localement sur lesquelles s'appuient les composants du produit. Ces composants partagés sont installés automatiquement par le programme d'installation de Java ES. Les composants partagés installés dépendent des composants du produit installés.
Composants de la version 5
Le tableau suivant présente les composants de la version 5 par ordre alphabétique avec les abréviations utilisées dans les tableaux ultérieurs. Pour les composants de qualité de service mentionnés, le tableau précise le type d'amélioration de service offert.
Composants partagés de la version 5
Le tableau suivant présente les composants partagés de la version 5 par ordre alphabétique avec les abréviations utilisées dans les tableaux ultérieurs.
Java ESTechnologies de mise à niveauAucun utilitaire système ne met à niveau à lui seul tous les composants Java ES. En outre, les mises à niveau des composants du produit et des composants partagés comportent des caractéristiques différentes et n'utilisent pas les mêmes technologies, comme décrit ci-après.
Mise à niveau des composants du produit
La mise à niveau des composants du produit Java ES vers la version 5 est effectuée composant par composant, ordinateur par ordinateur. Elle met en uvre des processus spécifiques aux composants et documentées dans le présent Guide de mise à niveau.
La mise à niveau d'un composant peut aller d'une mise à niveau majeure, parfois incompatible avec la version précédente du composant, à une mise à niveau pleinement compatible ayant pour objet la correction de bogues. En raison des dépendances existant entre les composants de Java ES, la nature de la mise à niveau peut impliquer la mise à niveau éventuelle d'autres composants.
Les mises à niveau des composants de Java ES font intervenir deux opérations de base qui mettent en miroir l'installation et la configuration initiales des composants de Java ES :
- Installation des mises à niveau du logiciel. La mise à niveau du logiciel améliore ou corrige un logiciel existant ou remplace celui-ci. Il existe plusieurs procédures d'installation : application de patchs à des packages existants, remplacement sélectif de packages, installation de nouveaux packages ou réinstallation complète de composants.
- Reconfiguration. La reconfiguration prend en compte toutes les modifications des données de configuration, des données utilisateur ou des données d'application dynamiques requises pour la prise en charge du logiciel modifié. Une modification des données peut se traduire par des données supplémentaires, une modification du format des données (dans les fichiers de propriétés ou le schéma de la base de données) ou une modification de l'emplacement des données. Dans certains cas, la reconfiguration vous impose d'effectuer une procédure. Dans d'autres cas elle intervient automatiquement. Parfois, il est également nécessaire de déployer le logiciel du composant vers un conteneur Web.
En outre, les mises à niveau des composants du produit Java ES impliquent des tâches de préparation de la mise à niveau et, dans certains cas, des procédures de finalisation avant que la mise à niveau ne soit opérationnelle.
Approches de mise à niveau des composants du produit
Les procédures de mise à niveau spécifiques aux composants, qui servent à installer un logiciel actualisé et à reconfigurer les composants, couvrent les approches suivantes :
Utilisation de la fonctionnalité de mise à niveau du programme d'installation de Java ES
Le programme d'installation de la version 5 comporte une fonctionnalité permettant d'effectuer une mise à niveau de composant dans certains cas particuliers : Application Server, Message Queue, HADB et Base de données Java. Lorsque le programme d'installation de Java ES détecte une version préalablement installée de ces composants, il affecte à ceux-ci l'état “mise à niveau possible”.
Avant d'effectuer une mise à niveau, le programme d'installation recherche les versions actuelles et antérieures des composants partagés. S'il détermine qu'un composant partagé requis par le composant sélectionné est d'une version précédente ou n'est pas disponible, il met à niveau tous les composants partagés installés et installe tous les composants partagés manquants requis par le composant sélectionné. Dans certains cas (en particulier avec Application Server), le programme d'installation met également à niveau les composants dont dépend le composant en cours de mise à niveau.
Le programme d'installation supprime les packages de version antérieurs, installe les packages de composant de la version 5, puis reconfigure le composant mis à niveau selon les besoins. Dans le cas du Application Server fourni avec le système d'exploitation Solaris 9, le programme d'installation ne supprime pas les packages. Voir la section Mise à niveau d'Application Server pour la version 2).
Si vous utilisez la fonctionnalité de zones de Solaris 10, vous devez prendre en compte des considérations supplémentaires. Voir la section Prise en charge de zones dans le programme d'installation de Java ES.
Réinstallation complète d'un composant
La mise à niveau de certains composants passe par une réinstallation complète avec le programme d'installation de Java ES. Vous pouvez supprimer les packages de la version précédente et installer la version 5 au même emplacement ou installer celle-ci à un autre emplacement et laisser intacte la version précédente.
Dans les deux cas vous reconfigurez les composants du produit en effectuant une migration des données de configuration de la version précédente, en effectuant une nouvelle configuration ou en combinant les deux procédures. Pour certains composants, un utilitaire permet de reconfigurer l'installation ou de faire migrer les données de configuration correspondant au composant.
Utilitaire de mise à niveau spécifique au composant
Certains composants comportent un utilitaire ou un script pour automatiser la mise à niveau vers la version 5. En général, l'utilitaire effectue à la fois la mise à niveau des packages et toute reconfiguration requise dans le cadre de la mise à niveau. Dans le cas des composants déployés vers un conteneur Web, l'utilitaire effectue généralement un nouveau déploiement du composant mis à niveau vers le conteneur.
Application de patchs aux packages existants
Certains composants sont mis à niveau en appliquant manuellement des patchs aux packages existants. Les plates-formes Solaris et Linux emploient des technologies similaires pour gérer les packages installés et suivre les modifications apportées par l'intermédiaire d'un registre. Par contre, les technologies d'application de patchs diffèrent et influent sur les procédures de mise à niveau.
- Plate-forme Solaris. L'installation et la suppression des packages utilisent les commandes Solaris pkgadd et pkgrm. Une fois les packages installés, leur contenu peut être modifié à l'aide des patchs appliqués ou supprimés avec les commandes patchadd et patchrm. Les patchs des packages Solaris sont distribués par l'intermédiaire du site Web de SunSolve : http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
Les patchs Solaris peuvent concerner un ou plusieurs packages. La commande patchadd enregistre une sauvegarde du package auquel le patch est appliqué, afin de faciliter la suppression du patch par la commande patchrm. Les patchs sont identifiés par leur ID de patch, composé du numéro de patch suivi du numéro de révision incrémenté à mesure des modifications du patch dans le temps.
- Plate-forme Linux. L'installation et la mise à niveau des packages Red Hat Enterprise Linux (RPM) utilisent la commande rpm. Toutefois, une fois les packages installés, leur contenu ne peut plus être modifié à l'aide de patchs. Les patchs RPM sont mis à jour à l'aide de l'option de commande rpm -U, qui remplace le package en cours par un package plus récent.
Pour faciliter l'opération, de nombreuses mises à niveau de package RPM sont fournies non seulement avec la distribution du logiciel Java ES version 5, mais également par l'intermédiaire du site Web de SunSolve : http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
Pour une distribution via SunSolve, les packages RPM sont encapsulés sous la forme de patchs et se voient affecter un ID de patch et un numéro de révision comme les patchs Solaris. Ces patchs Linux peuvent inclure un ou plusieurs packages RPM, chaque package étant identifié par un nom RPM unique, un numéro RPM et un numéro de révision incrémenté à mesure des modifications du package RPM dans le temps.
Approche de mise à niveau pour chaque composant
Le tableau suivant illustre l'approche de mise à niveau vers la version 5 utilisée pour chaque composant :
Mises à niveau des composants partagés
Les mises à niveau des composants partagés de Java ES constituent une étape indispensable pour la mise à niveau des composants produit qui en dépendent.
La mise à niveau des composants partagés ne nécessite pas de reconfiguration des composants, ni l'exécution de procédures avant ou après la mise à niveau. En outre, les composants partagés mis à niveau peuvent être restaurés sur leur version antérieure.
Le grand nombre de composants partagés de Java ES (une trentaine) et les interactions complexes intervenant entre les composants partagés et les composants du produit imposent que tous les composants partagés d'une même instance du système d'exploitation soient synchronisés sur la même version de Java ES. Une instance du système d'exploitation correspond à un ordinateur unique exécutant le système d'exploitation Solaris 9, Solaris 10 ou or Red Hat Enterprise Linux, ou à l'un quelconque des environnements d'exploitation virtuels (zones) d'un ordinateur exécutant Solaris 10.
Du fait des impératifs de la synchronisation, il est déconseillé de mettre à niveau individuellement les composants partagés de Java ES. Effectuez simultanément la mise à niveau de tous les composants partagés vers la version 5.
La synchronisation des composants partagés sur la version 5 est effectuée par le programme d'installation de Java ES. Le programme d'installation synchronise les composants partagés lors de la mise à niveau des composants du produit (reportez-vous à la section Utilisation de la fonctionnalité de mise à niveau du programme d'installation de Java ES) ou lors d'une nouvelle installation de composants. Le programme d'installation contient également une fonction de synchronisation qui effectue la mise à niveau de tous les composants partagés existants et installe ceux qui manquent. Pour une description détaillée de cette fonction, reportez-vous à la section Synchronisation de tous les composants partagés.
Processus de mise à niveauLe processus de mise à niveau de Java ES se compose de plusieurs phases normalement effectuées dans un premier temps dans un environnement de séquencement avant d'être appliquées à un environnement de production. L'environnement de séquencement permet de tester chaque phase et de préparer des scripts qui seront utilisés par le personnel informatique pour mettre à niveau des déploiements Java ES complexes.
Lorsque vous avez testé le processus de mise à niveau et acquis la certitude que son fonctionnement est correct, vous pouvez l'appliquer à votre environnement de production.
Les différentes phases du processus sont énumérées dans le tableau suivant et décrites dans le présent Guide de mise à niveau. Ces phases s'appliquent aussi bien aux composants individuels qu'au déploiement de Java ES dans son ensemble.
Considérations relatives à la planification de la mise à niveauLa planification permet de spécifier les composants de Java ES qui doivent être mis à niveau et le séquencement de la mise à niveau sur les différents ordinateurs et systèmes d'exploitation qui composent votre déploiement Java ES.
Votre planification dépend de vos objectifs et de vos priorités, ainsi que de la portée et de la complexité de votre architecture de déploiement.
Par exemple, votre architecture de déploiement Java ES peut être constituée d'un composant Java ES unique exécuté sur un seul ordinateur, et votre objectif de mise à niveau peut être de corriger un bogue d'une version antérieure. D'autre part, votre architecture de déploiement peut aussi comporter un certain nombre de composants Java ES interdépendants déployés sur différents ordinateurs et votre objectif peut être d'obtenir de nouvelles fonctionnalités en procédant à la mise à niveau d'un nombre minimum de composants afin de réduire le temps d'indisponibilité du système.
En règle générale, plus le nombre de composants Java ES et le nombre d'ordinateurs composant l'architecture de déploiement sont élevés, plus la planification du déploiement sera complexe.
Toutefois, votre planification de mise à niveau dépend d'un certain nombre de facteurs autres que la portée et la complexité de votre architecture de déploiement. Ces facteurs incluent notamment les points suivants:
Dépendances pour la mise à niveau
L'un des principaux problèmes à prendre en compte lors de la planification de la mise à niveau d'un composant Java ES concerne les dépendances de ce composant par rapport à d'autres composants Java ES et les mises à niveau éventuelles requises pour ces composants afin de prendre en compte la mise à niveau du composant dépendant.
Il existe deux types de dépendances :
- Dépendance stricte. La mise à niveau d'un composant du produit vous impose de mettre à niveau un composant dont il dépend. Cette exigence peut être due à de nouvelles fonctionnalités, de nouvelles interfaces ou des corrections de bogue requises par le composant dépendant. Avec une dépendance stricte, il n'est pas possible de mettre à niveau et d'utiliser le composant dépendant sans mettre à niveau au préalable le composant dont il dépend.
- Dépendance souple. La mise à niveau d'un composant du produit ne vous impose pas de mettre à niveau un composant dont il dépend. Avec une dépendance souple, vous pouvez mettre à niveau et utiliser le composant dépendant sans mettre à niveau au préalable le composant dont il dépend.
La mise à niveau d'un composant Java ES exige la mise à niveau de tous les composants avec lesquels il présente une dépendance stricte, mais pas nécessairement celle des composants avec lesquelles la dépendance est souple, à part quelques exceptions relevées dans ce guide. Lorsqu'une mise à niveau implique des composants interdépendants multiples, vous n'êtes tenu de mettre à niveau un composant que si l'un des composants Java ES en cours de mise à niveau présente une dépendance stricte vis-à-vis de ce composant spécifique.
Dans certains cas particuliers dus à des incompatibilités, la mise à niveau d'un composant vous impose de mettre également à niveau un composant pris en charge. Ces cas particuliers sont mentionnés ici.
Chemins d'accès et stratégies pris en charge pour la mise à niveau
Votre planification dépend de la version de Java ES que vous souhaitez mettre à niveau vers la version 5.
Bien qu'il soit possible de mettre à niveau toutes les versions précédentes du logiciel vers Java ES 2005Q4 (version 4), les seules mises à niveau certifiées concernent Java ES 2005Q1 (version 3) et Java ES 2004Q2 (version 2). Le présent Guide de mise à niveau fournit des stratégies de mise à niveau à partir de Java ES. 2003Q4 (version 1) et des versions antérieures, mais ne fournit pas les procédures correspondantes.
Le tableau suivant décrit les différentes méthodes de mise à niveau vers la version 5, avec leurs caractéristiques et les stratégies utilisables pour effectuer la mise à niveau.
Les méthodes décrites dans le tableau présentent des différences et les processus de mise à niveau des composants dépendent souvent de la version modifiée. Les chapitres du présent Guide de mise à niveau qui décrivent la mise à niveau de chaque composant du produit sont donc subdivisés en sections, chacune correspondant à une méthode de mise à niveau différente.
Tableau 1-5 Méthodes de mise à niveau vers Java ES 5 (version 5)
Version du produit
Version de Java ES
Caractéristiques du système
Stratégies de mise à niveau
2005Q4
Version 4
Java ES 5 (version 5) accepte une combinaison de composants des versions 4 et 5 sur le même ordinateur, mais nécessite que les composants partagés soient synchronisés sur la même version. Les compatibilités entre les composants de la version 4 et de la version 5 ont été testées et les incompatibilités connues sont signalées dans les Notes de version de Java Enterprise System 5 pour UNIX, http://docs.sun.com/doc/820-0450.
La coexistence de composants de la version 4 et de la version 5 permet d'effectuer une mise à niveau sélective de certains composants de la version 4 vers la version 5 sur un ordinateur donné ou au sein d'une architecture de déploiement composée de plusieurs ordinateurs.
Si un composant de la version 5 nécessite un composant partagé de la version 5, tous les composants partagés présents sur l'ordinateur doivent être synchronisés sur la version 5.
2005Q1
Version 3
Similaire à la méthode de mise à niveau vers la version 4 ci-dessus. Java ES 5 (version 5) accepte une combinaison de composants des versions 3 ou 4 et 5 sur le même ordinateur, mais nécessite que les composants partagés soient synchronisés sur la même version. Les compatibilités entre les composants de la version 3 et de la version 5 ont été testées et les incompatibilités connues sont signalées dans les Notes de version de Java Enterprise System 5 pour UNIX, http://docs.sun.com/doc/820-0450.
Similaire à la méthode de mise à niveau vers la version 4 ci-dessus. La coexistence de composants de la version 3 et de la version 5 permet d'effectuer une mise à niveau sélective de certains composants de la version 3 vers la version 5 sur un ordinateur donné ou au sein d'une architecture de déploiement composée de plusieurs ordinateurs.
Si un composant de la version 5 nécessite un composant partagé de la version 5, tous les composants partagés présents sur l'ordinateur doivent être synchronisés sur la version 5.
2004Q2
Version 2
Se différencie des méthodes de mise à niveau des versions 4 et 3 ci-dessus. Java ES 5 (version 5) n'accepte pas une combinaison de composants des versions 2 et 5 sur le même ordinateur, qu'il s'agisse de composants du produit ou de composants partagés. Il existe des incompatibilités d'interface connues entre ces versions et l'interopérabilité entre les composants des versions 2 et 4 n'est pas garantie (elle n'a pas été testée).
Lors d'une mise à niveau de la version 2 à la version 5 sur un même ordinateur, tous les composants de la version 2 doivent être mise à niveau. Il est toutefois possible de mélanger des composants des versions 2 et 5 sur des ordinateurs différentsd'une architecture de déploiement.
2003Q4
et versions antérieuresVersions 1 et antérieures à Java ES
Similaire à la méthode de mise à niveau de la version 2 ci-dessus. Java ES 5 (version 5) n'accepte pas une combinaison de composants des versions 2 et 5 sur le même ordinateur, qu'il s'agisse de composants du produit ou de composants partagés. Il existe des incompatibilités d'interface connues entre ces versions et l'interopérabilité entre les composants des versions 1 ou antérieures et de la version 5 n'est pas garantie (elle n'a pas été testée).
Java ES ne garantit pas la mise à niveau directe à partir de la version 1 ou antérieure vers la version 5.
Dans d'autres cas, la mise à niveau de la version 1 peut être réalisée en passant d'abord par Java ES version 3, comme documenté dans le Guide de migration et de mise à niveau de Java Enterprise System version 3, http://docs.sun.com/doc/819-0062, puis en effectuant la mise à niveau de la version 3 à la version 5. Dans ce cas, le tableau de mise à niveau de ce composant dans le Guide de mise à niveau signale cette possibilité.
Dans d'autres cas, la mise à niveau de la version 1 vers la version 5 peut être réalisée de la même manière que pour passer de la version 2 ou 3 vers la version 5 et, dans ce cas, le tableau de mise à niveau de ce composant dans le Guide de mise à niveau signale cette possibilité.
Mise à niveau sélective ou globale
La différence entre les dépendances de mise à niveau strictes et souples offre la possibilité de planifier une mise à niveau sélective des composants de Java ES déployés dans un système. La mise à niveau sélective s'applique à la mise à niveau des versions 3 et 4 vers la version 5 sur un ordinateur unique. La mise à niveau sélective de la version 2 vers la version 5 sur un ordinateur unique n'est pas prise en charge.
En général, vous avez le choix entre une mise à niveau sélective et une mise à niveau globale des composants de Java ES sur un ordinateur.
- Mise à niveau sélective. Avec cette approche, vous commencez par le composant de Java ES que vous souhaitez mettre à niveau vers la version 5. Vous déterminez les dépendances strictes du composant. Les composants correspondants doivent également être mis à niveau. Répétez le processus pour chaque dépendance stricte détectée, jusqu'à ce qu'il n'y ait plus de composant à mettre à niveau. Cet exercice permet de définir tous les composants de Java ES qui doivent être mis à niveau.
- Mise à niveau globale. Dans cette approche vous mettez à niveau vers la version 5 tous les composants de Java ES déployés. Dans certains cas, la complexité d'un déploiement rend impraticable la mise à niveau simultanée d'un système tout entier.
Les deux approches sont comparées dans le tableau suivant.
Java ES version 4 acceptait également les mises à niveau sélectives. Il est donc possible de faire coexister sur le même ordinateur des composants des versions 3 et 4, chacun d'entre eux pouvant être mis à niveau sélectivement vers la version 5.
Mises à niveau portant sur plusieurs instances
L'ordre des procédures de mise à niveau défini dans une planification peut dépendre de la redondance mise en uvre dans l'architecture de déploiement. Plusieurs instances d'un composant Java ES peuvent être utilisées pour obtenir haute disponibilité, évolutivité, facilité de maintenance ou toute autre combinaison de ces qualités de service. Il existe trois technologies faisant usage de composants redondants dans l'architecture de déploiement Java ES : l'équilibrage de charge (Directory Proxy Server ;, Web Server, Web Proxy Server, Application Server, Access Manager et Portal Server), les techniques haute disponibilité (Sun Cluster et High Availability Session Store) et la réplication multimaître Directory Server.
Dans la plupart des cas impliquant la redondance, les mises à niveau doivent intervenir sans impliquer de perte de disponibilité importante. Ces mises à niveau progressives permettent de mettre à niveau successivement les instances redondantes d'un composant sans nuire au service qu'elles assurent.
Les instances redondantes sont généralement déployées sur des ordinateurs multiples. Dans la perspective de la planification d'une mise à niveau, cela peut impliquer d'isoler la mise à niveau de ces composants répliqués de celle des autres composants afin de réduire au maximum les indisponibilités du système. Vous effectuez toutes les tâches de préparation de la mise à niveau des composants répliqués sur chaque ordinateur avant de lancer la mise à niveau progressive.
Chaque technologie de réplication dispose de procédures de configuration ou de reconfiguration qui peuvent affecter l'ordre global des mises à niveau des composants de Java ES. Par exemple, les composants exécutés dans un environnement Sun Cluster peuvent exiger la mise à niveau de Sun Cluster avant leur propre mise à niveau.
Les chapitres du présent Guide de mise à niveau décrivant chaque composant du produit indiquent dans chaque cas les modalités de mise à niveau multiinstance.
Considérations portant sur le système d'exploitation
Un certain nombre de considérations relatives au système d'exploitation doivent être prises en compte dans la planification de la mise à niveau de Java EScomme indiqué ci-après.
Patchs du système d'exploitation nécessaires
La mise à niveau d'un composant Java ES peut nécessiter d'appliquer au préalable un patch au système d'exploitation ou de mettre celui-ci au niveau requis par le composant Java ES 5. Toutefois, au lieu d'appliquer les patchs ou les correctifs requis dans chaque cas, il est préférable d'amener le système d'exploitation au niveau requis par Java ES 5 dans son ensemble avant d'effectuer la mise à niveau de composants spécifiques du produit.
- Plate-forme Solaris. Les patchs du système d'exploitation sont accessibles sur le site SunSolve sous la forme d'un cluster de patchs, c'est-à-dire un ensemble de patchs du système d'exploitation pouvant être appliqués collectivement. Les clusters de patchs requis pour prendre en charge Java ES version 5 pour Solaris 9 et 10 sont disponibles à l'adresse http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Plate-forme Linux. Les versions de mise à niveau sont disponibles à l'adresse https://www.redhat.com/apps/download/. Il n'est toutefois pas nécessaire d'effectuer la mise à niveau du système d'exploitation Linux avant celle de Java ES.
Mises à niveau doubles : Java ES et système d'exploitation
Le système d'exploitation et Java ES ne seront plus synchrones si vous tentez de mettre à niveau soit Java ES ou le système d'exploitation vers une version non prise en charge. La matrice de support correspondante est indiquée dans le tableau suivant :
Si une mise à niveau de Java ES ou du système d'exploitation abouti à une configuration qui n'est pas prise en charge, vous devez alors effectuer une double mise à niveau : dans Java ES ainsi que dans le système d'exploitation. Les situations suivantes peuvent nécessiter une double mise à niveau :
Par exemple, Java ES 2004Q2 (version 2) est pris en charge sous Solaris 8 et 9 et sous Red Hat Enterprise Linux (RHEL) 2.1. Si vous souhaitez mettre votre plate-forme de système d'exploitation au niveau de Solaris 10 ou RHEL 3.0, qui ne sont pas pris en charge par Java ES version 2, vous devrez également mettre Java ES version 2 au niveau d'une version prenant en charge la plate-forme mise à niveau. Dans ce cas, il est préférable de passer à Java ES 5 (version 5).
Par exemple, Java ES 2005Q1 (version 3) et Java ES 2005Q4 (version 4) sont pris en charge sous Solaris 8 et RHEL 2.1. Si vous souhaitez mettre Java ES à niveau vers la version 5, qui n'est pas prise en charge par Solaris 8 et RHEL 2.1, vous devez mettre à niveau votre système d'exploitation vers une version prise en charge par Java ES 5 (version 5). Dans ce cas, il est préférable de passer à Solaris 10 ou RHEL 4.0.
En général, il y a deux solutions pour effectuer une double mise à niveau :
- Installation d'un nouveau système d'exploitation Installez le nouveau système d'exploitation suivi d'une nouvelle installation de Java ES version 5, comprenant une migration des données de composant de produit d'une version antérieure (notamment les données de configuration, les données en temps réel, les données personnalisées, etc.). Le système d'exploitation peut être installé sur un nouveau système (ou une zone Solaris 10) ou écraser un système de fichiers existant. Dans ce dernier cas, les données de composant doivent être sauvegardées en premier lieu et restaurées après l'installation du système d'exploitation.
- Mise à niveau d'un système d'exploitation existant Effectuez une mise à niveau du système d'exploitation en laissant le système de fichiers existant en place, suivi par une mise à niveau de composants de produits Java ES vers la version 5. Pour ce faire, la mise à niveau du système d'exploitation ne doit pas influencer la mise à niveau des composants de produits Java ES, de leur données et des composants partagés nécessaires.
Si la double mise à niveau n'est pas prise en charge par les composants de produits Java ES, c'est à dire si aucune de ces solutions ne fonctionne, vous pouvez installer à nouveau et reconfigurer le ou les composants après l'installation ou la mise à niveau du système d'exploitation.
Le tableau suivant affiche la solution de double mise à niveau prise en charge par les composants de produit Java ES.
Mises à niveau du système d'exploitation
Dans certains cas, la mise à niveau du système d'exploitation remplace des composants partagés de Java ES par une version plus ancienne. Il est alors possible de restaurer la version correcte de Java ES en mettant à niveau vers la version 5 le composant Message Queue, fourni avec le système d'exploitation Solaris. Cette mise à niveau provoque celle de tous les composants partagés résidents.
Environnements Solaris 10 multizone
Un certain nombre de considérations doivent être prises en compte lors de l'installation et de la mise à niveau de composants Java ES dans un environnement multizone. Pour une description des avantages et des limitations du déploiement de Java ES dans des zones Solaris 10 et les pratiques recommandées pour mettre à niveau les composants Java ES dans un environnement multizone, reportez-vous à la section Mise à niveau de Java ES 5 et zones Solaris 10.
Dépendances entre composants de Java ESL'un des points importants à prendre en compte dans la planification de la mise à niveau porte sur les dépendances entre les différents composants Java ES déployés dans le système. L'ordre de mise à niveau des composants dépend de la nature des dépendances existantes.
Cette section contient des informations sur les dépendances de composants Java ES qui ont des conséquences sur la planification des mises à niveau.
Dépendances par rapport à des composants partagés
Le Tableau 1-9 présente les dépendances des composants Java ES 5 (version 5) par rapport à des composants partagés. Les abréviations des composants du produit servant d'en-tête aux colonnes du Tableau 1-9 sont issues du Tableau 1-1. Les abréviations des composants partagés sont énumérées dans le Tableau 1-2.
Dans le Tableau 1-9, les dépendances strictes pour les mises à niveau de la version 3 et de la version 4 vers la version 5 sont marquées “H,” et les dépendances de mise à niveau souples sont marquées “S.” Pour les mises à niveau de la version 2 vers la version 5, toutes les dépendances de composants partagés sont, par définition, des dépendances de mise à niveau strictes ; tous les composants doivent être mis à niveau de la version 2 à la version 5.
Tableau 1-9 Dépendances des composants partagés pour les composants Java ES version 5
Composant partagé
AM
AS
DPS
DS
DS Console
HADB
JavaDB
MQ
MC
PS
PSRA
SC
SCG
SR
WPS
WS
ANT
S
S
H
H
H
ACL
S
H
BDB
S
CAC
H
S
H
H
H
S
S
S1
S1
FIS
ICU
S
H
H
S
S
S
IM-SDK
S
Java SE
S
S
H
H
H
S
H
S
S
S
S
S
S
H
S
S
JAF
S
S
S
S
H
JATO
S
S
S
S
S
S
JavaHelp™
S
S
S
S
S
JavaMail ™
S
S
S
S
H
S
JAXB
S
S
S
JAXP
S
S
S
S
H
S
JAXR
S
S
H
S
JAX-RPC
S
S
H
S
JAXWS
S
JCAPI
JDMK
H
S
H
H
H
S
S
S
S
JSS
S
S
S
S
S
JSTL
KTSE
S
S
S
LDAP C SDK
H
H
S
S
LDAP J SDK
S
MA Core
S
H
H
MFWK
H
H
H
NSPR
S
S
H
H
H
S
S
S
S
S
S
H
NSS
S
S
H
H
S
S
S
S
S
S
H
SAAJ
S
S
S
S
H
SASL
H
S
S
SEDC
S
S
SJWC
S
S
H
H
S
S
WSCL
S
S
H
S
XWSS
H
1Cette dépendance concerne spécifiquement Common Agent Container (CAC) version 1.1.
Les dépendances affichées dans le Tableau 1-9 pour tout composant de produit représentent les dépendances directes et indirectes de composants partagés : un composant du produit peut dépendre d'un composant partagé spécifique (dépendance directe) qui, lui-même, dépend d'un ou de plusieurs autres composants partagés (dépendance indirecte). La Figure 1-1 illustre les interdépendances entre les composants partagés.
Le Tableau 1-9 indique les composants partagés qui doivent être mis à niveau lors de la mise à niveau d'un ou plusieurs composants du produit sur un ordinateur déterminé.
Toutefois, les composants partagés de Java ES doivent être synchronisés (voir Mises à niveau des composants partagés) et vous ne pouvez donc pas les mettre à niveau un par un. Vous devez mettre à niveau simultanément tous les composants partagés présents sur un ordinateur ou dans une instance de système d'exploitation vers la version 5.
Si aucune dépendance stricte n'est impliquée, il n'est pas indispensable de procéder à la mise à niveau des composants partagés. Toutefois, en règle générale, il est conseillé de mettre à niveau les composants partagés sous-jacents de Java ES vers la version la plus récente. En pratique, lorsque des composants du produit sont installés ou mis à niveau par le programme d'installation de Java ES, tous les composants partagés présents sur l'ordinateur hôte sont automatiquement synchronisés sur la version 5.
Pour obtenir plus d'informations sur la mise à niveau manuelle de composants partagés, reportez-vous au Chapter 2, "Mise à niveau des composants partagés Java ES."
Figure 1-1 Interdépendances des composants partagés
Dépendances par rapport aux composants du produit
Les dépendances entre composants se répartissent en deux grandes catégories : les dépendances d'exécution et les dépendances de configuration.
- Dépendances d'exécution. Le fonctionnement d'un système logiciel est basé sur les interactions entre ses composants déployés. Les dépendances d'infrastructure entre les composants de Java ES sont étudiées dans le Présentation technique de Java Enterprise System 5. Si un composant de la version 5 comporte une dépendance stricte vis-à-vis d'un autre composant du produit, il n'est possible de mettre à niveau et d'utiliser le composant dépendant que si le composant dont il dépend est également mis à niveau.
- Dépendances de configuration. Dans certains cas, la configuration d'un composant Java ES requiert qu'un autre composant soit installé, configuré et en cours d'exécution. Par exemple, un annuaire d'utilisateurs/de groupesDirectory Server doit être actif pour qu'un service Access Manager puisse être enregistré. Les procédures de mise à niveau des composants exigent souvent la reconfiguration des composants mis à niveau ou la migration des données de configuration. Les dépendances de configuration peuvent influer sur l'ordre des procédures de mise à niveau.
Dans le cas des dépendances d'exécution, les relations existant entre les composants du produit peuvent appartenir à trois types :
- Obligatoire. Le composant ne peut pas fonctionner sans le composant dont il dépend.
- Facultatif. Le composant peut fonctionner sans le composant dont il dépend, mais un sous-ensemble de ses fonctionnalités dépend de l'autre composant.
- Co-dépendance. Les deux composants peuvent fonctionner l'un sans l'autre, mais leur utilisation conjointe peut fournir certaines fonctionnalités ou performances supplémentaires.
Le tableau suivant indique les dépendances et les relations existant entre les composants de Java ES énumérés dans le Tableau 1-1. Ces informations permettent de déterminer les dépendances strictes qui ont des conséquences sur la planification des mises à niveau.
La première colonne énumère les composants de la version 5 par ordre alphabétique. La seconde indique les autres composants de Java ES avec lesquels un composant de la version 5 a une relation de dépendance. La troisième colonne indique les versions de Java ES qui prennent en charge la dépendance de la version 5. La quatrième colonne décrit la relation de dépendance. La dernière colonne indique les caractéristiques spéciales de la dépendance, par exemple si le composant de support doit être local ou distant ou si des produits tiers peuvent supporter la dépendance.
Si un composant mis à niveau vers la version 5 comporte une dépendance vis-à-vis d'un autre composant de la version 5 (par opposition à un composant d'une version antérieure), il s'agit d'une dépendance stricte. Le composant de support doit également être mis à niveau vers la version 5.
Tableau 1-10 Dépendances entre les composants Java ES
Version 5
Composant du produitDépendance1
Version de Java ES
Nature de la dépendance
Caractéristiques
Access Manager
Directory Server
2-5
Obligatoire : stocke les données de configuration et permet la consultation des données utilisateur
Conteneur Web J2EE
- Application Server
- Web Server
4-5
4-5
Obligatoire : fournit les services d'exécution de conteneur Web
Local seulement
Access Manager SDK
Access Manager
3-5
Obligatoire : fournit les services Access Manager
Access Manager
Distr. AuthentificationAccess Manager
4-5
Obligatoire : fournit les services Access Manager
Conteneur Web J2EE
- Application Server
- Web Server
4-5
4-5
Obligatoire : fournit les services d'exécution de conteneur Web
Local seulement
Egalement pris en charge :;
- Weblogic2
- WebSphere3Access Manager
Reprise de sessionAccess Manager
5
Obligatoire : fournit les services Access Manager
Message Queue
4-5
Obligatoire : fournit une messagerie asynchrone fiable
Application Server
Message Queue
3-5
Obligatoire : fournit une messagerie asynchrone fiable
Local seulement
High Availability Session Store (HADB)
5
Obligatoire : enregistre l'état de la session requis pour la prise en charge du basculement entre instances
Local seulement
Base de données Java
5
Obligatoire : fournit la base de données par défaut du développeur et autre stockage permanent.
Local seulement
Web Server
3-5
Facultatif : fournit l'équilibrage de charge entre les instances
Local seulement
Directory Proxy Server ;
Directory Server
1-5
Co-dépendance : améliore la sécurité et les performances pour les requêtes d'annuaire. Fournit les données à Directory Proxy Server ;
Directory Server
Directory Proxy Server ;
1-5
Co-dépendance : améliore la sécurité et les performances pour les requêtes d'annuaire. Distribue la charge et les données de cache à partir de Directory Server
High Availability Session Store (HADB)
Aucune
Base de données Java
Aucune
Message Queue
Directory Server
2-5
Facultatif : stocke les objets gérés et les données utilisateur
Conteneur Web J2EE
- Application Server
- Web Server
2-5
2-5
Facultatif : prend en charge le transport HTTP entre le client et le courtier Message Queue
Base de données Java
5
Facultatif : stocke les messages persistants.
Local seulement
Sun Cluster
2-5
Facultatif : prend en charge la haute disponibilité
Monitoring Console
Aucune
Portal Server
Directory Server
4-5
Obligatoire : stocke les profils utilisateur et permet leur consultation
Conteneur Web J2EE
- Application Server
- Web Server
4-5
4-5
Obligatoire : fournit les services d'exécution de conteneur Web
Local seulement
Access Manager ouSDK
Access Manager4-5
Obligatoire : fournit les services d'authentification et d'autorisation, la connexion unique
Local seulement
(Si Access Manager est distant, Access Manager SDK doit être utilisé localement)Portal Server Secure Remote Access
5
Facultatif : fournit un accès distant sécurisé au travers des composants Gateway, Netlet Proxy et Rewriter Proxy
Service Registry Client
5
Obligatoire : fournit les bibliothèques requises pour la compilation
Base de données Java
5
Obligatoire : fournit la prise en charge de plusieurs applications portlet
Portal Server Secure Remote Access
PasserellePortal Server
5
Obligatoire : prend en charge la fonctionnalité de passerelle
Access Manager ouSDK
Access Manager4-5
Obligatoire : fournit les services d'authentification et d'autorisation, la connexion unique
Local seulement
(Si Access Manager est distant, Access Manager SDK doit être utilisé localement)Directory Server
4-5
Obligatoire : stocke les données utilisateur et permet leur consultation
Rewriter Proxy
Portal Server
5
Obligatoire : prend en charge la fonctionnalité Rewriter Proxy
Netlet Proxy
Portal Server
5
Obligatoire : prend en charge la fonctionnalité Netlet Proxy
Service Registry
Déploiement
Application Server
5
Obligatoire : fournit les services d'exécution de conteneur
Local seulement
Base de données Java
5
Obligatoire : fournit la base de données par défaut pour le stockage des services et des métadonnées apparentées
Local seulement
Service Registry Client
5
Obligatoire : fournit les bibliothèques client requises
Local seulement
Client
Aucune
Sun Cluster
Aucune
Agents Sun Cluster
Sun Cluster
4-5
Obligatoire : fournit l'accès aux services Sun Cluster
Local seulement
Sun Cluster Geographic Edition
Sun Cluster
4-5
Obligatoire : prend en charge la fonctionnalité Sun Cluster Geographic Edition
Local seulement
Web Proxy Server
Directory Server
2-5
Facultatif : fournit l'authentification LDAP
Web Server
2-5
Co-dépendance : améliore la sécurité et les performances pour les requêtes HTTP. Fournit les données à Web Proxy Server
Egalement pris en charge ;
- Weblogic2
- WebSphere3Web Server
Directory Server
1-5
Facultatif : fournit l'authentification LDAP
Web Proxy Server
1-5
Co-dépendance : améliore la sécurité et les performances pour les requêtes HTTP. Distribue la charge et les données de cache à partir de Web Server
1Pour chaque composant du produit, les dépendances sont présentées dans l'ordre normal de mise à niveau.
2BEA WebLogic Server
3IBM WebSphere Application Server
Consignes générales pour l'ordre des mises à niveauLe choix d'une mise à niveau sélective ou globale, l'impact des dépendances strictes et d'autres facteurs étudiés dans les sections précédentes influent sur les composants de Java ES que vous prévoyez de mettre à niveau et sur l'ordre des procédures. Néanmoins, quelques consignes générales sont valables dans la majorité des situations.
La liste suivante indique l'ordre dans lequel les composants de Java ES peuvent être correctement mis à niveau sur un ordinateur unique ou au sein d'un système déployé. Lorsque vous planifiez la mise à niveau, vous pouvez omettre les composants qui ne font pas partie de votre architecture de déploiement ou, pour une mise à niveau sélective, vous pouvez omettre les composants correspondant à des dépendances souples.
Les chapitres du présent Guide de mise à niveau sont organisés en fonction de l'ordre dans lequel les composants apparaissent dans la liste suivante.
RemarqueS
Avant d'effectuer la mise à niveau des composants de Java ES, veillez à appliquer toutes les mises à jour requises du système d'exploitation (voir Patchs du système d'exploitation nécessaires).
Consultez également la section Cas particuliers pour vérifier si des mises à jour concernent votre scénario de mise à niveau.
- Composants partagés (reportez-vous au Chapter 2, "Mise à niveau des composants partagés Java ES")
Les composants partagés doivent être mis à niveau avant les composants qui en dépendent. Dans la plupart des cas, la mise à niveau des composants partagés est assurée par le programme d'installation de Java ES. Toutefois, dans le cas de Web Proxy Server et Portal Server vous devez mettre explicitement à niveau les composants partagés.
- logiciel Sun Cluster (voir Chapter 3, "Logiciel Sun Cluster")
Si certains composants sont exécutés dans un environnement Sun Cluster et que le logiciel Sun Cluster doit faire l'objet d'une mise à niveau, il doit être mis à niveau avant les composants qui utilisent les services Sun Cluster. Le cas échéant, les agents Sun Cluster doivent être mis à niveau dans le cadre de la mise à niveau de Sun Cluster.
- logiciel Sun Cluster Geographic Edition (voir Chapter 4, "Sun Cluster Geographic Edition")
Sun Cluster Geographic Edition doit être mis à niveau après Sun Cluster, dont il dépend. Ce dernier doit être mis à niveau avant tout composant qui utilise les services Sun Cluster.
- Directory Server (reportez-vous au Chapter 5, "Directory Server")
De nombreux composants stockent les données utilisateur ou les données de configuration dans Directory Server, et la mise à niveau de Directory Server doit donc intervenir avant celle des composants présentant des dépendances de configuration ou d'exécution par rapport à Directory Server.
- Directory Proxy Server ; (reportez-vous au Chapter 6, "Directory Proxy Server ;")
Directory Proxy Server ; comporte une dépendance souple vis-à-vis de Directory Server et peut être mis à niveau à tout moment. Toutefois, certains composants peuvent accéder à Directory Server par l'intermédiaire de Directory Proxy Server ;. En conséquence, si Directory Proxy Server ; est mis à niveau, il doit l'être immédiatement après Directory Server.
- Web Server (reportez-vous au Chapter 7, "Web Server")
Un certain nombre de composants Java ES requièrent la prise en charge d'un conteneur Web, dont la mise à niveau éventuelle doit précéder celle des composants utilisant les services de conteneur Web. En principe, les services de conteneur Web doivent être fournis par Web Server ou Application Server, mais si votre architecture contient les deux composants, Web Server doit être mis à niveau en premier.
- Base de données Java (reportez-vous au Chapter 8, "Base de données Java")
Base de données Java doit être mis à niveau avant Application Server, ce qui nécessite d'utiliser Base de données Java comme base de données par défaut. Toutefois, Base de données Java est automatiquement mis à niveau par le programme d'installation de Java ES lors de la mise à niveau de Application Server.
- High Availability Session Store (reportez-vous au Chapter 9, "High Availability Session Store")
High Availability Session Store (HADB) doit être mis à niveau avant Application Server, qui nécessite la présence de High Availability Session Store pour la haute disponibilité. Toutefois, HADB est automatiquement mis à niveau par le programme d'installation de Java ES lors de la mise à niveau de Application Server.
- Message Queue (reportez-vous au Chapter 10, "Message Queue")
Message Queue doit être mis à niveau avant Application Server, qui nécessite Message Queue pour être compatible avec Java Enterprise Edition (Java EE). Toutefois, Message Queue est automatiquement mis à niveau par le programme d'installation de Java ES lors de la mise à niveau de Application Server.
- Application Server (reportez-vous au Chapter 11, "Application Server")
Application Server dépend de Message Queue et de High Availability Session Store. Il doit donc être mis à niveau après ces composants. Application Server peut également dépendre de Web Server pour son plug-in d'équilibrage de charge. Si vous utilisez cette fonctionnalité, Application Server doit donc être mis à niveau après Web Server.
- Service Registry (reportez-vous au Chapter 12, "Service Registry")
Service Registry doit être mis à niveau après Application Server, dont il dépend pour les services de conteneur.
- Web Proxy Server (reportez-vous au Chapter 13, "Web Proxy Server")
Web Proxy Server peut être mis à niveau à tout moment, mais cette opération est généralement effectuée après la mise à niveau du composant Web Server ou Application Server auquel il fournit un service de proxy. Web Proxy Server est un nouveau composant de Java ES version 5 qui peut être mis à niveau à partir de sa version précédente non incluse dans Java ES.
- Access Manager (reportez-vous au Chapter 14, "Access Manager"
Access Manager joue un rôle central pour l'authentification et l'autorisation, notamment la connexion unique, et sa mise à niveau éventuelle doit intervenir avant celle des composants qui dépendent de lui pour ces services.
- Portal Server (reportez-vous au Chapter 15, "Portal Server")
Portal Server dépend de nombreux composants parmi les précédents (Directory Server, un conteneur Web et Access Manager). Sa mise à niveau éventuelle doit suivre celle de ces composants.
- Portal Server Secure Remote Access (reportez-vous au Chapter 16, "Portal Server Secure Remote Access")
Portal Server Secure Remote Access doit être mis à niveau si Portal Server l'est.
Cas particuliersIl faut prendre un compte un petit nombre de cas particuliers en planifiant la mise à niveau de composants de Java ES vers la version 5. Ils sont décrits ci-après.
Mise à niveau sélective : Application Server non mis à niveau
Si vous effectuez une mise à niveau sélective d'un composant Java ES vers Java ES 5 sur un ordinateur exécutant la version 3 ou 4 d'Application Server (8.1) et que vous ne mettez pas à niveau Application Server vers la version 5, certaines situations doivent être prises en compte pour que Application Server continue à fonctionner correctement.
- Erreurs de compilation JSP. Avant d'effectuer la mise à niveau sélective, vous devez appliquer le patch Application Server indiqué dans le tableau suivant.
Tableau 1-11 Patchs1 requis lorsque Application Server n'est pas mis à niveau vers la version 5
Description
ID du patch : Solaris 9 et 10
ID du patch : Linux
Correctif pour les versions 3 et 4
Application Server119166-17 (SPARC)
119166-17 (x86)
119168-17
1Les numéros de version de patch sont les versions minimales requises. S'il existe des versions plus récentes, utilisez-les à la place de celles indiquées dans ce tableau.
Si vous n'appliquez pas le patch, Application Server rencontrera des erreurs de compilation JSP. (Les patchs indiqués dans le Tableau 1-11 peuvent également être appliqués rétroactivement pour résoudre le problème.)
- Déplacement des binaires de composant partagé ANT sous Linux. ANT version 5 est situé sur un chemin d'accès différent de celui des versions précédentes. La variable d'environnement d'Application Server spécifiée dans le fichier AppServer8-base/config/asenv.conf et qui pointe sur ANT doit être modifiée de :
Mise à niveau de Portal Server Interim Feature Release (IFR) 7.0 vers Java ES 5
Si vous effectuez la mise à niveau de Portal Server dans un environnement Web Server de la version Interim Feature Release (IFR) 7.0 2005Q4 vers la version 5, consultez la section Mise à niveau de Portal Server à partir de la version intermédiaire du logiciel (Interim Feature Release 7.0) qui indique les exceptions aux directives de la section Consignes générales pour l'ordre des mises à niveau.
Mise à niveau de Java ES 5 et zones Solaris 10Cette section traite des problèmes de mise à niveau de Java ES dans les zones Solaris 10 et fournit des recommandations pour cet environnement. Elle complète les informations portant sur Java ES 5 et les zones Solaris 10 dans le Guide de planification pour l'installation de Java Enterprise System 5, http://docs.sun.com/doc/820-0882.
Elle se compose des rubriques suivantes :
Prise en charge de zones dans le programme d'installation de Java ES
Le programme d'installation fournit une prise en charge de zones lors de la mise à niveau (et de l'installation) des composants produit de Java ES et pour la synchronisation des composants partagés. Des stratégies ont été mises en uvre dans le programme d'installation pour éviter les scénarios à problème.
Mise à niveau des composants du produit
Comme décrit dans la section Utilisation de la fonctionnalité de mise à niveau du programme d'installation de Java ES, le programme d'installation de Java ES permet de mettre à niveau un certain nombre de composants du produit et les composants partagés correspondants. Cette fonctionnalité de mise à niveau s'applique aux zones globales et à toutes les zones non globales.
Il existe toutefois trois exceptions à ce comportement en relation avec les zones :
- Dans les zones « sparse root », certains composants partagés ne peuvent pas être installés ou mis à niveau parce qu'ils résident dans des répertoires en lecture seule. Dans de tels cas, la mise à niveau des composants du produit est suspendue jusqu'à ce que ces composants partagés aient été installés ou mis à niveau dans la zone globale. Le programme d'installation fournit 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 réinstallez ces composants partagés dans la zone globale avant de continuer. Utilisez l'option Tous les composants partagés.”
- Application Server et Message Queue sont fournis avec le système d'exploitation Solaris. Aucun des deux ne peut être directement mis à niveau dans une zone « sparse root ». Pour plus de détails sur ces composants, reportez-vous à la section Cas particuliers pour les composants du produit.
- Si des zones non globales sont présentes dans une zone globale, le programme d'installation ne met pas à niveau les composants partagés installés et n'installe pas les composants manquants requis par un composant sélectionné. À la place, il synchronise tous Java ES les composants partagés sur la version 5, qu'ils soient ou non requis pour un composant spécifique. Cela permet la propagation de tous les composants partagés de la version 5 aux zones non globales, en évitant tout mélange de versions dans ces zones.
Remarque
Il existe un petit nombre de cas particuliers ou d'exceptions susceptibles d'interférer avec l'installation ou la mise à niveau de composants dans les zones non globales. Ils sont décrits dans la section Cas particuliers ou exceptions.
Synchronisation de tous les composants partagés
La version 5 fournit une option de synchronisation des composants partagés pour le cas où tous ces composants devraient être synchronisés sur leur version 5. Lorsque l'option Tous les composants partagés est sélectionnée, le programme d'installation met à niveau tous les composants partagés installés et installe tous les composants partagés manquants, qu'ils soient ou non requis pour un composant spécifique. Cette option s'applique aux zones globales et aux zones racine entières (mais pas aux zones « sparse root »).
L'option Tous les composants partagés est décrite plus en détail dans la section Synchronisation de tous les composants partagés. Elle est requise dans les deux scénarios suivants de mise à niveau par zone :
- Mise à niveau manuelle des composants du produit. L'option Tous les composants partagés est requise pour effectuer l'installation et la mise à niveau des composants partagés lorsque la mise à niveau de composants du produit ne peut pas utiliser le programme d'installation de Java ES.
- Mises à niveau dans une zone « Sparse Root ». Certains composants partagés ne peuvent pas être installés ou mis à niveau dans les zones « sparse root » par défaut. En conséquence, si vous utilisez le programme d'installation de Java ES pour mettre à niveau des composants du produit dans les zones « sparse root », vous devrez peut-être commencer par synchroniser les composants partagés dans la zone globale, selon les composants partagés concernés. Dans ce cas, vous utiliserez l'option Tous les composants partagés dans la zone globale pour effectuer l'installation et la mise à jour requises.
Vous trouverez un récapitulatif du comportement du programme d'installation de Java ES vis-à-vis des zones et des composants partagés dans la section traitant des zones Java ES 5 et Solaris 10 du Guide de planification pour l'installation de Java Enterprise System 5, http://docs.sun.com/doc/819-5079.
Pratiques de mise à niveau recommandées
Lorsque vous définissez une planification de mise à niveau, examinez tous les déploiements multizone éventuels de Java ES. Gardez à l'esprit les stratégies d'installation et d'administration de zones présentées dans le Guide de planification pour l'installation de Java Enterprise System 5, http://docs.sun.com/doc/819-5079. Dans certains cas, vous devrez peut-être désinstaller des composants dans une ou plusieurs zones et les réinstaller ailleurs pour mettre en uvre les pratiques recommandées suivantes :
- Evitez de mélanger les stratégies. En particulier :
- Veillez à ce que votre stratégie de déploiement et d'administration de zones Java ES soit aussi simple que possible. Ne mélangez pas des déploiements de racine complète et « sparse root » de composants Java ES sur le même ordinateur. (Les procédures et les pratiques requises pour prendre en charge les déploiements de zone « sparse root » peuvent interférer avec les déploiements de zone racine globale.)
- N'installez pas le même composant Java ES à la fois dans la zone globale et dans des zones non globales, même s'il s'agit de versions différentes. (Les procédures requises pour mettre à niveau une installation de zone globale peuvent détruire les installations de zones non globales.)
- Si des composants Java ES de la version 4 ou d'une version antérieure ont été installés dans une zone racine globale, ne mettez pas à niveau de composants Java ES vers la version 5 dans la zone globale. Cela pourrait aboutir à un mélange de fichiers des versions 4 et 5 dans la zone racine globale.
- Pratiques de mise à niveau :
- Si vous souhaitez mettre à niveau tous les composants installés de la version 4 vers la version 5, synchronisez tous les composants Java ES partagés dans la zone globale, puis effectuez la mise à niveau des composants du produit requis dans les zones où ils ont été installés. (Les composants partagés de la version 5 assurent une compatibilité ascendante.)
- Si des composants du produit de la version 4 ou 5 sont installés dans un environnement sans zones et que vous souhaitez ajouter des zones non globales à l'environnement puis installer les composants du produit dans ces zones, vous devrez peut-être désinstaller les composants de la zone globale et les réinstaller dans les zones non globales.
Cas particuliers ou exceptions
Il existe un certain nombre de cas particuliers. La cause en est parfois que certains composants partagés et certains composants du produit Java ES sont fournis avec Solaris 10. De ce fait, ces composants existent automatiquement dans la zone globale et, en conséquence, dans toute zone non globale créée à partir de la zone globale.
Cas particuliers pour les composants du produit
- Message Queue. Message Queue est fourni avec Solaris 10. Il est donc automatiquement propagé lors de la création de zones non globales (sauf si vous l'avez préalablement retiré de la zone globale). Message Queue ne peut pas être installé ou mis à niveau 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 propagé par défaut vers les zones non globales, contrairement aux autres composants du produit.
- Application Server. Application Server est fourni avec Solaris 10. Il est donc automatiquement propagé lors de la création de zones non globales (sauf si vous l'avez préalablement retiré de la zone globale). Lorsqu'il est propagé de cette manière, Application Server est installé dans /usr et ne peut pas être mis à niveau par le programme d'installation de Java ES dans une zone « sparse root » (par défaut, le répertoire /usr est en lecture seule). Pour résoudre ce problème, les packages Application Server fournis doivent être supprimés manuellement de la zone globale avant d'installer Application Server version 5 dans une zone « sparse root ». Voir la section SE Solaris uniquement : supprimez manuellement les packages d' Application Server fournis avec le système d'exploitation..
- Sun Cluster.Le logiciel Sun Cluster n'est pas pris en charge dans les zones non globales.
Cas particuliers pour les composants partagés
- Sun Java Web Console (SJWC). Les packages SJWC fournis avec Solaris 10 (Mise à jour 1 et 2) ne peuvent pas être supprimés par le programme d'installation de Java ES. Dans ces anciens packages SJWC, l'attribut SUNW_PKG_ALLZONES était défini sur True, ce qui signifie que le package devait être identique dans toutes les zones et ne pouvait être géré que par l'administrateur global. En conséquence, ces packages doivent être supprimés manuellement de la zone globale et remplacés par les packages corrects.
Si le programme d'installation de Java ES tente d'installer un composant du produit sélectionné dans une zone non globale et détecte que SJWC doit être mis à niveau, il se bloquera. Cela se produira dans le cas d'une installation sous Solaris 10, Mise à jour 1 et 2.
Pour éviter le problème, un script spécial a été développé pour supprimer de la zone globale les anciens packages SJWC et les remplacer par SJWC version 5, dans lequel l'attribut de propagation de zone est correctement défini. Reportez-vous au Guide d'installation de Java Enterprise System 5 pour UNIX pour de plus amples détails.
