[AIX Solaris HP-UX Linux Windows][z/OS]

Concept du gestionnaire des éditions d'application

L'identification des différences entre une version et une édition du gestionnaire d'édition d'application, la maîtrise des méthodes de déploiement et de mise à niveau de votre application, ainsi que de la validation et de la compatibilité des éditions vous permet de tirer pleinement profit du gestionnaire d'édition d'application pour gérer vos déploiements d'application.

Les applications Web non gérées peuvent être définies à l'aide d'une édition. Toutefois, elles ne peuvent pas être déployées ni passer en mode validation. Elles sont prises en charge mais n'ont pas accès à toutes les fonctions car il s'agit d'applications de gestion à cycle de vie assisté.
Fonction obsolète Fonction obsolète: Les serveurs Assisted and Complete Lifecycle sont obsolètes dans WebSphere Application Server version 9.0. Faites migrer les serveurs WebSphere Liberty vers la configuration de collectivité Liberty. Il n'existe pas d'action de migration recommandée pour les autres types de serveur.depfeat

Versions et éditions

Les termes version et édition permettent de différencier les opérations qui s'exécutent dans l'environnement de développement et de génération de celles qui s'exécutent dans l'environnement de déploiement et d'exploitation. Une version est une génération successive d'une interface, d'une fonction, d'une implémentation, d'une application toute entière, ou autre. Il s'agit d'un concept lié au développement et à la génération. Une édition est une génération de déploiements successifs, par exemple le déploiement d'un ensemble particulier d'artefacts versionnés. Il s'agit d'un concept lié au déploiement et à l'exploitation.

L'édition d'application désigne un déploiement unique d'une application particulière. Dans l'environnement d'administration de WebSphere Application Server, une édition d'application est une application qui n'est identifiée que par la combinaison d'un nom d'application et d'un nom d'édition. Plusieurs éditions de la même application ont le même nom d'application mais des noms d'édition différents. Le nom d'édition peut être numérique, comme 1.0 ou 2.0, ou il peut être descriptif, comme première édition ou édition bleue.
  • L'édition de base désigne une application déployée qui ne comporte aucune information d'édition associée.
  • L'Activation d'édition distingue deux états possibles pour une édition d'application. La première fois que vous installez une édition, elle est à l'état inactif. Vous ne pouvez démarrer l'édition que lorsqu'elle est à l'état actif. Le passage de l'état inactif à l'état actif est appelé activation.
  • On parle d'activation simultanée lorsque plusieurs éditions de la même application sont actives et démarrent simultanément. Des éditions actives simultanément peuvent permettre à certains utilisateurs d'accéder à une édition et à d'autres utilisateurs d'accéder à une autre édition. Par exemple, si vous lancez une nouvelle édition d'une application, vous voudrez peut être qu'un groupe d'utilisateurs restreint la teste, sans que tous les utilisateurs y aient accès. Avec une activation simultanée, vous devez établir une stratégie de routage pour distinguer les utilisateurs qui ont accès à une édition. Une stratégie de routage est stockée parmi les métadonnées de configuration d'une application. Elle permet en outre d'éviter les ambiguïtés et de déterminer l'édition qui doit recevoir le contrôle. L'exemple suivant est un diagramme qui illustre plusieurs éditions actives simultanément.
Figure 1. Editions actives simultanémentLa figure 1 présente l'activation simultanée de plusieurs éditions de la même application

Mise à niveau et déploiement de l'application

De nombreuses applications d'entreprise doivent être disponibles en permanence. Au sujet de la disponibilité de l'application, la norme recommande de déployer les applications sur des clusters de serveurs d'applications. Il est essentiel qu'un cluster soit redondant pour assurer une disponibilité permanente. On appelle Mise à niveau des applications sans interruption la capacité à mettre à niveau une application tout en conservant sa disponibilité permanente. En d'autres termes, les utilisateurs de l'application n'observent pas de perte de service lors de la mise à niveau de l'application.

Un déploiement sur une édition remplace une édition active par une nouvelle édition. Afin de permettre des mises à niveau d'application sans interruption, un déploiement sur une édition consiste à :
  • Bloquer la réception de nouvelles demandes sur ce serveur.
  • Mettre au repos les demandes de l'application sur un serveur donné.
  • Interrompre l'édition active en cours.
  • Démarrer la nouvelle édition.
  • Reprendre le flux des demandes vers cette édition.

Lorsque vous effectuez un déploiement vers une édition sur un cluster de serveurs d'applications, vous réalisez les activités suivantes sur l'ensemble des serveurs présents dans ce cluster :

Pour effectuer un déploiement sur un cluster cible, vous pouvez diviser le cluster en groupes et définir une taille de groupe, laquelle indique le nombre de noeuds à traiter à la fois. Le déploiement de groupe a pour résultat la mise à niveau des serveurs de chaque groupe sur la nouvelle édition au même moment. Chaque serveur du groupe est mis au repos, arrêté et réinitialisé. Un déploiement ne peut être effectué que sur un seul groupe à la fois dans la console d'administration. Lorsqu'un membre de la nouvelle édition devient disponible, toutes les demandes sont acheminées vers la nouvelle édition.

Lors du déploiement de l'édition, certains serveurs du cluster sont transférés de l'ancienne édition vers la nouvelle, certains serveurs sont en cours de transition et d'autres n'ont pas commencé la transition. Toutes les demandes d'application sont envoyées à un serveur ayant une instance active en cours d'exécution de la dernière édition de l'application demandée. Par exemple, lorsque vous réalisez un déploiement de l'édition 1.0 vers l'édition 2.0, toutes les demandes d'application sont desservies par l'édition 2.0 au moment où l'édition 2.0 devient disponible sur un serveur. Tout serveur exécutant encore l'édition 1.0 ne dessert pas les demandes jusqu'à ce qu'il soit mis à jour avec l'édition 2.0. L'exemple suivant est un diagramme qui illustre un déploiement de groupe.

Figure 2. Déploiement de groupe
La figure 2 présente un cluster cible divisé en groupes lors d'un déploiement de groupe

Le déploiement isolé sur une édition remplace une édition par moitié de cluster à la fois de sorte que toutes les demandes utilisateur soient desservies au moyen d'une édition cohérente de l'application. Toutes les demandes utilisateur sont desservies soit par l'ancienne, soit par la nouvelle édition, mais jamais par les deux éditions à la fois.

Un déploiement isolé garantit que toutes les demandes d'application sont desservies par une édition cohérente, par exemple, l'édition 1.0 ou 2.0, mais pas les deux éditions. L'édition actuellement disponible est mise hors ligne sur la moitié des serveurs que comprend le cluster. Sur ces serveurs, la nouvelle édition est activée et démarrée, mais les serveurs sont maintenus hors ligne jusqu'à l'achèvement de l'étape suivante, qui consiste à mettre l'édition actuellement active hors ligne sur le reste des serveurs. Dès lors, aucun serveur ne dispose plus d'une instance de l'une ou l'autre édition pour desservir les demandes d'application. Le routeur ODR met provisoirement en file d'attente toutes les demandes reçues pour cette application. Une fois l'application entièrement remise en ligne, la première moitié du cluster est remise en ligne. La seconde moitié du cluster passe de l'ancienne à la nouvelle édition et est remise en ligne. L'exemple suivant est un diagramme qui illustre un déploiement isolé :

Figure 3. Déploiement isolé
La figure 3 illustre comment la première moitié du cluster cible est remise en ligne après la mise hors ligne complète de l'application, et comment la seconde moitié du cluster passe de l'ancienne à la nouvelle édition avant d'être remise en ligne.

Validation et compatibilité des éditions

La validation d'édition désigne un cas spécial d'activation simultanée, au cours duquel la cible de déploiement attribuée d'une édition, par exemple, un cluster dynamique, est dupliquée et l'on prépare le démarrage de l'édition sur cette cible de déploiement dupliquée. La cible de déploiement dupliquée est appelée cible de validation. Des stratégies de routage doivent être utilisées pour désigner les demandes d'application qui doivent être envoyées à l'édition en cours de validation. Lorsqu'une édition est en cours de validation, elle est en mode validation.

Le mode validation vérifie que la nouvelle édition d'une application fonctionne dans son environnement de production sans mettre hors ligne l'édition actuellement disponible. Généralement, un test est envoyé à une édition en mode validation pour confirmer que les aspects d'environnement et de configuration de l'application, tels que la connectivité et l'accès à la base de données, fonctionnent comme prévu. Lors du déploiement du mode de validation d'une édition, l'opération a lieu sur la cible de déploiement où l'édition était installée à l'origine. Cela entraîne l'édition à quitter le mode validation. Lors de l'arrêt de la validation, la cible de validation est supprimée. L'exemple suivant est un diagramme qui illustre une validation d'édition.

Figure 4. Validation d'édition
La figure 4 montre comment un cluster dynamique est cloné et comment l'édition est préparée pour être démarrée sur la cible de déploiement clonée pendant la validation de l'édition

Certaines modifications d'application passent inaperçues, tandis que d'autres sont visibles par l'utilisateur final. Lorsqu'une mise à niveau d'application fournit les mêmes interfaces de programmation, au minimum, que la dernière modification et qu'aucune modification sémantique n'a été apportée au comportement essentiel, cette mise à jour est qualifiée de compatible avec les versions précédentes. En tant qu'utilisateur existant, vous pouvez utiliser l'application mise à niveau sans modifier les options d'utilisation ; vous ne verrez pas non plus de différence entre l'ancienne édition et l'édition actuelle.

Une mise à niveau d'application qui impose aux utilisateurs de modifier leur utilisation de l'application est une mise à niveau incompatible. Il peut s'avérer nécessaire de supprimer une fonction antérieure ou de modifier des interfaces pour améliorer la capacité de maintenance ou d'autres paramètres, ce qui peut apporter des modifications non compatibles avec votre environnement de déploiement. Les modifications non compatibles doivent être planifiées avec soin afin de gérer leur incidence sur les utilisateurs existants.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwve_xappedcon
Nom du fichier : cwve_xappedcon.html