Cet article vous aidera à comprendre comment installer Sun Java System Application Server 9.1 dans les zones Solaris 10. Il explique l'installation possible et les scénarios de mise à niveau, leur limites et comment les surmonter.
Sun Java System Application Server 9.1 représente la distribution supportée par Sun du serveur d'application Open Source GlassFish version 2. Par conséquent, nous utiliserons le terme Application Server dans cet article pour englober les deux, sauf quand il importe de les distinguer.
Dans l'ensemble de cet article, les termes Solaris et SE Solaris font référence à l'environnement d'exploitation Solaris 10, sauf mention contraire.
Les zones Solaris sont utiles dans les déploiements où la gestion logicielle centralisée et une haute fiabilité sont importantes. Certaines considérations spéciales surviennent lorsque Application Server est installé dans les zones Solaris.
A propos des zones du SE Solaris
Une zone Solaris est un environnement de SE virtuel partitionné au sein du SE Solaris. Chaque zone se comporte comme un serveur virtuel entièrement isolé au sein d'une seule machine. Une zone est une primitive connue sous l'appellation conteneur Solaris lorsqu'elle est utilisée avec l'utilitaire de gestion de ressources du système.
Une application considère une zone comme un environnement de système d'exploitation isolé et sécurisé. Ainsi, vous pouvez isoler les applications les unes des autres en installant différentes zones, tout en conservant la gestion centralisée de certaines ressources du système d'exploitation.
Du point de vue d'un système d'exploitation supportant plusieurs zones, les ressources de système d'exploitation comprennent des ressources telles que gestion de processus, mémoire, configuration réseau, systèmes de fichiers, registres de packages, comptes utilisateur, bibliothèques partagées et, dans certains cas, des applications installées.
Une zone est toujours définie dans le SE Solaris: la zone globale. La zone globale correspond à l'environnement de SE où le SE Solaris est traditionnellement installé. La zone globale peut contenir d'autres zones. Les zones hébergées dans une zone globale sont appelées zones non-globales ou simplement zones.
Des zones peuvent être créées avec un minimum d'espace disque. Ces zones sont appelées zones sparse . Vous pouvez aussi créer une zone whole-root, qui duplique la totalité du système d'exploitation.
La figure suivante illustre la relation entre les zones, la zone globale, le noyau du système d'exploitation et les ressources matérielles qui en forment la base.
Figure 1.Applications isolées des zones Solaris
Cliquez ici pour agrandir l'image
Application Server (aussi bien Sun Java System Application Server 9.1 que GlassFish version 2) est disponible dans les téléchargements source et les binaires. Les binaires sont également distribués au format package natif (packages RPM sur le SE Linux et packages SVR
sur le SE Solaris). Cet article couvre uniquement l'installation des binaires du package natif Solaris, installés via le programme d'installation du package autonome téléchargeable. Vous pouvez installer les programmes d'installation à base de fichiers, généralement au format zip, partout et sans limitation de support de zone, dans la mesure où vous installez dans des répertoires inscriptibles.
Les options d'installation suivantes illustrent les sources possibles de confusion lors de l'installation d'Application Server ou de sa mise à niveau dans les zones Solaris.
Application Server intégré au SE Solaris 10 – La version 8.x de Sun Java System Application Server est intégrée au SE Solaris 10 et installée sous /usr/appserver.
Sun Java System Message Queue intégré au SE Solaris 10 – La version 3.7, mise à jour 1 de Sun Java System Message Queue (appelé Message Queue ci-après) est intégrée au SE Solaris 10 et installée sous /usr.
Version préinstallée de Java Enterprise System (Java ES) – Une version antérieure des packages Java ES peut être installée dans n'importe quelle zone. Dans de tels cas, le programme d'installation Java ES traite automatiquement la mise à niveau des versions d'Application Server et de Message Queue installées par le précédent Java ES. Notez toutefois que Message Queue peut être mis à niveau dans la zone globale et les zones whole-root, mais pas dans les zones sparse.
Niveaux de propagation du package SVR4 différents – La propagation dans les zones des packages Application Server et des composants associés peut varier en fonction de leur mode d'installation. Par exemple,
dans le cas d'Application Server intégré à Solaris, les packages sont définis pour se propager à toutes les zones. Par conséquent, la suppression d'un package de la zone globale supprime sa référence dans les zones sparse.
Quand les packages Application Server intégrés à Solaris sont mis à niveau par le programme d'installation Java ES, leurs niveaux de propagation sont redéfinis sur “zone globale” seulement.
Le programme d'installation Application Server comporte également un ensemble de composants partagés, dont Sun Java System Message Queue 4.1, High-Availability Database 4.4.3-6 (HADB), et JDK 5 mise à jour 12. Le programme d'installation Application Server met automatiquement à niveau ces composants lorsqu'il détecte une version antérieure dans les zones globales et whole-root. HADB peut être mis à niveau dans une zone sparse.
Les packages Application Server et HADB intégrés à Sun Java System Application Server 9.1, ne sont pas propagés aux autres zones lorsqu'ils sont installés dans la zone globale. Par conséquent, il est possible d'avoir plusieurs versions d'Application Server installées dans des zones non-globales sans conflit avec la version installée dans la zone globale.
En revanche, les composants partagés et les packages Message Queue sont toujours propagés à toutes les zones lors de l'installation d'Application Server dans la zone globale.
Les sections qui suivent étudient les types d'installations existantes d'Application Server dans les zones et leurs implications pour une nouvelle installation.
Avant d'installer Application Server dans la zone globale, une des conditions suivantes doit être vraie pour l'environnement d'installation :
Une version d'Application Server intégrée à Solaris a été installée dans la zone globale.
Une version du logiciel Java ES a été installée.
Aucune version intégrée d'Application Server n'a été installée, et aucune version antérieure de Java ES n'a été installée. L'environnement est "propre", sans installation d'Application Server.
Evidemment, si votre environnement est propre (cas 3 ci-dessus), vous pouvez installer Application Server directement sans conséquences négatives ou imprévues. Examinons maintenant les deux premiers cas et leurs implications.
Application Server est installé dans la zone globale depuis un logiciel Solaris standard
Pour déterminer s'il existe une version d'Application Server intégrée dans la zone globale, procédez comme suit.
Recherchez les packages Application Server SVR4 dans le système. La liste officielle des packages Application Server installés au sein de Solaris 10 se trouve dans la Liste des packages Sun SE en ligne.
Dans cette liste, recherchez les packages Application Server suivants : SUNWasac, SUNWascmn, SUNWasdb, SUNWasdem, SUNWasdemdb, SUNWasjdoc, SUNWasman, SUNWasr, SUNWasu et SUNWasut. Si vous disposez de la mise à jour 3 ou ultérieure de Solaris 10, vous avez également le package SUNWasjavadb (une version privée de Java DB utilisée uniquement pour Application Server).
Recherchez et validez le contenu du répertoire d'installation d'Application Server intégré. La version d'Application Server intégrée à Solaris 10 est toujours installée sous /usr/appserver. Pour déterminer la version d'Application Server, exécutez la commande /usr/appserver/bin/asadmin version -v. Ce chemin d'exécution de la commande garantit que vous ne considérez pas Java ES installé sous /usr/appserver. Notez le numéro de version. Il sera utile pour envisager l'exécution des installations ultérieures.
Vérifiez si un domaine par défaut créé depuis Application Server intégré à Solaris existe et est utilisé. Si le domaine est actif et utilisé mais que vous ne savez pas où il est situé, procédez comme suit pour le trouver en examinant le fichier de configuration général d'Application Serverasenv.conf. Localisez comme suit le chemin d’accès au fichier :
Affichez le contenu du fichier/usr/appserver//bin/asadmin dans un éditeur et recherchez la chaîne asenv.conf. La ligne contenant cette chaîne dans le fichier asadmin indique le chemin d'accès absolu au fichier asenv.conf.
Une fois le fichier asenv.conf localisé, ouvrez-le pour trouver l'emplacement des domaines par défaut pour l'installation. Le jeton AS_DEF_DOMAINS_PATH contient la valeur du répertoire root des domaines sous lequel le domaine par défaut et les domaines juste créés se trouvent. Notez que vous pouvez changer ce chemin d’accès avec l'option ignorer --domaindir.
Si vous découvrez qu'une version intégrée d'Application Server a été installée sur votre système, vous devez considérer les implications suivantes pour les installations et les mises à niveau ultérieures.
Si votre système comporte une version intégrée d'Application Server dans la zone globale, vous devez reconnaître que les packages Application Server et Message Queue installés dans la zone globale sont définis par défaut pour se propager aux autres zones. Si vous souhaitez utiliser des zones sparse, chacune éventuellement avec une version distincte d'Application Server, vous devez désinstaller l'installation d'Application Server de la zone globale. Pour désinstaller, supprimez tous les packages SVR4 indiqués ci-dessus de la Liste des packages Sun SE.
Si vous n'avez pas l'intention d'utiliser des zones sparse avec des installations séparées d'Application Server, il est inutile de supprimer les packages SVR4.
Une fois Application Server désinstallé de la zone globale, vous pouvez installer Application Server dans un nouveau répertoire ou par mise à niveau d'un répertoire d'installation existant, en écrasant les fichiers nécessaires. Si vous choisissez d'utiliser un répertoire existant et d'écraser la version précédente, sélectionnez /usr comme répertoire d'installation. appserver sera annexé automatiquement au chemin d’accès de l'installation.
Remarque : Si la version intégrée d' Application Server est activement utilisée et qu'elle comporte des domaines actifs, prenez soin de ne pas installer les binaires sous /usr, car l'installation écrasera aussi le répertoire de domaine par défaut. Dans ce cas, spécifiez un répertoire d'installation différent. Après l'installation, déplacez les applications de l'ancien domaine vers le nouveau domaine de l'installation avec Upgrade Tool (situé dans InstallDir/bin/asupgrade). Cet outil est installé avec Application Server. Consultez le Guide de mise à niveau et de migration Sun Java System Application Server 9.1 pour des informations plus détaillées.
L'un des avantages de l'installation d'Application Server dans la zone globale sous /usr réside dans le fait que, ce répertoire étant visible pour les autres zones sparse (monté en entrée lecture seule) les binaires Application Server peuvent être utilisés pour créer des domaines dans les zones sparse. Notez que lorsque Application Server tente d'écrire des fichiers (domaines, journal de base de données, fichiers de propriétés, etc.) il doit être dirigé vers un répertoire inscriptible. Vous pouvez spécifier les répertoires lorsque vous appelez la commande asadmin. Par exemple, la commande suivante crée un domaine administratif dans writable_dir/domains, un répertoire qu'Application Server peut écrire :
De même, la commande suivante démarre le serveur Java DB et spécifie writable_dircomme répertoire où le fichier derby.log et les autres fichiers de base de données sont stockés :
Les emplacements des répertoires de domaine par défaut créés lors des installations de Sun Java System Application Server 9.1 et de Java ES sont différents. Pour Java ES, l'emplacement par défaut est/var/opt/SUNWappserver/domains. Contrairement au programme d'installation Java ES, celui d'Application Server ne vous laisse pas le choix d'un répertoire root de domaine, et le domaine est toujours créé sous le répertoire d'installation choisi au moment de l'installation. Par conséquent, ne vous souciez pas d'écraser le répertoire des domaines, sauf si le root du domaine et de l'installation étaient explicitement définis sur le même répertoire lors de l'installation de Java ES.
Le programme d'installation de Sun Java System Application Server 9.1 ne prend en charge que les mises à niveau depuis Java ES 5 mise à jour 1. Si vous avez une version antérieure de Java ES, commencez par la mise à niveau vers Java ES 5 mise à jour 1, puis exécutez le programme d'installation de Sun Java System Application Server 9.1.
Java ES 5 mise à jour 1 intègre et installe Sun Java System Application Server 8.2 mise à jour 1 Enterprise Edition. Cette version et Sun Java System Application Server 9.1 portent les mêmes noms de package SVR4. Par conséquent, il est impossible d'installer deux versions différentes sur la même machine. Le répertoire de domaine par défaut étant différent dans chaque programme d'installation, effectuez votre mise à niveau dans l'ordre suivant :
Mettez les binaires à niveau par suppression des packages Application Server installés avec Java ES 5 mise à jour 1. Installez ensuite les packages Sun Java System Application Server 9.1 dans le répertoire de votre choix. Ce processus est automatisé par le programme d'installation de Sun Java System Application Server 9.1.
Après la mise à niveau binaire, exécutez l'assistant de mise à niveau de Sun Java System Application Server 9.1. Vous pouvez démarrer cet outil avec la commande bin/asupgrade depuis l'emplacement d'Application Server juste installé. Dans l'assistant de mise à niveau, spécifiez le répertoire de domaine Java ES 5 mise à jour 1 comme répertoire du domaine source et le répertoire de domaine Sun Java System Application Server 9.1 comme répertoire root de domaine cible.
Du point de vue des zones, il importe de noter que les niveaux de propagation des packages installés par Java ES 5 mise à jour 1 ne sont pas modifiés lors de la mise à niveau d'Application Server vers Sun Java System Application Server 9.1.
Les zones sparse servent dans les déploiements où une seule installation dans la zone globale doit être partagée par tous les utilisateurs d'une entreprise. La création des zones sparse est très économique. L'un des avantages de l'utilisation de zones sparse réside dans le fait que l'installation patchée depuis la zone globale est visible dans toutes les zones sparse.
L'installation dans une zone sparse est plus difficile que dans la zone globale, en raison des complications décrites ci-dessous.
Application Server est installé dans la zone globale d'un Solaris standard
Pour déterminer si une version intégrée d'Application Server se trouve dans la zone globale, procédez comme suit.
Recherchez les packages Application Server SVR4 dans le système. Vous trouverez la liste officielle des packages Application Server installés dans le cadre de Solaris 10 dans la Liste des packages Sun SE en ligne.
Dans cette liste, recherchez les packages Application Server suivants : SUNWasac, SUNWascmn, SUNWasdb, SUNWasdem, SUNWasdemdb, SUNWasjdoc, SUNWasman, SUNWasr, SUNWasu, et SUNWasut. Si vous disposez d'une mise à jour 3 ou ultérieure de Solaris 10, vous avez également le package SUNWasjavadb (une version privée de Java DB utilisée uniquement pour Application Server).
Recherchez et validez le contenu du répertoire d'installation d'Application Server intégré. La version d'Application Server intégrée à Solaris 10 est toujours installée sous/usr/appserver. Pour déterminer la version d'Application Server, exécutez la commande /usr/appserver/bin/asadmin version -v. Ce chemin d'exécution de la commande garantit que vous considérez une version d'Application Server intégrée à Solaris, et non une version intégrée à Java ES et installée sous/usr/appserver.
Vérifiez si un domaine par défaut créé depuis Application Server intégré à Solaris existe et est utilisé. Si le domaine est actif et utilisé mais que vous ne savez pas où il est situé, procédez comme suit pour le trouver :
Affichez le contenu du fichier/usr/appserver//bin/asadmin dans un éditeur.
Recherchez dans le fichier asadminla chaîne asenv.conf. La ligne contenant cette chaîne indique le chemin d’accès absolu au fichierasenv.conf.
Ouvrez le fichier asenv.conf pour trouver l'emplacement des domaines par défaut de l'installation. Le jeton AS_DEF_DOMAINS_PATH contient la valeur du répertoire root domaines sous lequel le domaine par défaut et les domaines juste créés se situent. Notez que vous pouvez changer ce chemin d’accès c avec l'option ignorer --domaindir.
Après avoir confirmé qu'une version intégrée d'Application Server existe toujours dans la zone globale, désinstallez-la en supprimant tous les packages indiqués à l'étape 1. Utilisez ensuite la commande pkgrm pour examiner et supprimer le contenu du répertoire /usr/appserver dans la zone globale.
Notez que la suppression d'Application Server de la zone globale est propagée aux zones sparse, car la version intégrée d'Application Server comprend des packages définis par défaut pour se propager à toutes les zones.
Message Queue est installé dans la zone globale à partir de Solaris standard
Tout comme Application Server intégré à Solaris, les packages Message Queue sont également installés sous le répertoire /usr de la zone globale et ne peuvent donc pas être écrasés depuis une zone sparse. Les packages Message Queue ne sont pas relocalisables et sont toujours installés sous/usr, qui est un point de montage en lecture seule dans une zone sparse.
Par conséquent, avant d'installer les binaires Application Server dans une zone sparse, utilisez le programme d'installation d'Application Server pour installer Message Queue dans la zone globale.
Vous pouvez installer ou mettre à niveau Message Queue dans la zone globale par l'une des méthodes suivantes. L'une ou l'autre assure que les packages sont mis à niveau si une version antérieure est détectée.
Vous ne pouvez pas sélectionner explicitement les composants de Message Queue dans une installation d'Application Server. Ils sont masqués et automatiquement sélectionnés ou désélectionnés pour installation lorsque vous installez d'autres composants. Les composants de Message Queue sont toujours sélectionnés lorsque vous sélectionnez un composant installable d'Application Server. Par exemple, exécutez le programme d'installation de Sun Java System Application Server 9.1 et sélectionnez Exemples d'applications pour installer Message Queue 4.1 dans le cadre d'une installation d'Application Server.
Vous pouvez aussi utiliser votre navigateur pour atteindre la page de téléchargement Open Message Queue, cliquer sur le lien Solaris approprié sous "Téléchargements d'installation d'IG Open MQ 4.1 les plus récents" et installer les packages Message Queue 4.1 SVR4.
Application Server est installé dans la zone globale par Java ES
Si Application Server a été installé dans la zone globale dans le cadre d'une installation de Java ES, les composants partagés et Message Queue installés dans la zone globale sont propagés dans les zones sparse, mais pas Application Server.
Pour installer Application Server dans une zone sparse :
Exécutez les étapes préliminaires suivantes avant d'installer dans une zone sparse :
Exécutez le programme d'installation de Sun Java System Application Server 9.1 dans la zone globale.
Dans le programme d'installation, sélectionnez HADB ou Exemples d'applications.
Choisissez d'installer JDK et de mettre tous les composants à niveau.
Installez Application Server dans la zone sparse.
Application Server est installé dans une zone sparse par Java ES
Pour mettre à niveau Application Server installé par Java ES dans une zone sparse :
Exécutez le programme d'installation de Sun Java System Application Server 9.1 dans la zone globale.
Dans le programme d'installation, sélectionnez HADB ou Exemples d'applications.
Choisissez d'installer JDK et de mettre tous les composants à niveau.
Exécutez le programme d'installation de Sun Java System Application Server 9.1 dans la zone sparse pour mettre à niveau l'installation de Java ES dans la zone sparse.
Après la mise à niveau binaire, exécutez l'assistant de mise à niveau de Sun Java System Application Server 9.1. Vous pouvez démarrer cet outil avec la commande bin/asupgrade depuis l'emplacement d'Application Server juste installé. Pour en savoir plus, consultez le Guide de mise à niveau et de migration Sun Java System Application Server 9.1.
Application Server installé dans la zone globale par le programme d'installation de Sun Java System Application Server 9.1
Si Application Server a été installé dans la zone globale par le programme d'installation Application Server, une version différente d'Application Server peut être installée dans une zone sparse, car les packages Application Server ne se propagent pas dans une zone sparse.
Les packages d'une zone whole-root sont copiés depuis la zone globale ; ils ne peuvent pas être propagés. Les zones whole-root augmentent la souplesse de configuration car leurs packages peuvent être corrigés localement, bien qu'il s'agisse de copies de la zone globale.
L'installation d'Application Server dans une zone whole-root est beaucoup plus simple que dans les autres zones. Tous les composants d'Application Server (y compris les composants partagés, Message Queue et HADB) peuvent être installés sans tenir compte des packages des autres zones, globale et sparse.
Les zones Solaris sont très efficaces et utiles à différents titres, mais elles introduisent des complications dans les installations d'Application Server. Vous devez considérer les nombreux facteurs qui affectent la propagation et la priorité entre les zones globale et non-globales lorsque vous installez Sun Java System Application Server 9.1 ou GlassFish version 2 dans une zone.
Support Développeur — conseils de programmation en ligne basés sur les incidents, assistance produit par téléphone, cours de formation développeur, programmes de service
Print-friendly Version
