Vous consultez actuellement l'aide de la version:

Vérification de l’espace disque

Lors de l’exécution de la mise à niveau, en plus des activités de mise à niveau de contenu et du code, une migration du référentiel doit être effectuée. La migration crée une copie du référentiel dans le nouveau format tar de segment. Par conséquent, vous devez disposer de suffisamment d’espace disque pour conserver une seconde version du référentiel, potentiellement plus grande.

Sauvegarde complète d’AEM

AEM doit être entièrement sauvegardé avant de commencer la mise à niveau. Veillez à sauvegarder votre référentiel, l’installation de l’application, la banque de données et les instances Mongo, le cas échéant. Pour plus d’informations sur la sauvegarde et la restauration d’une instance AEM, voir Sauvegarde et restauration.

Sauvegarde des modifications sur /etc

Le processus de mise à niveau est utile dans le maintien et la fusion du contenu existant et des configurations à partir des chemins d’accès /apps et /libs dans le référentiel. Pour les modifications apportées au chemin d’accès /etc, y compris les configurations Context Hub, il est souvent nécessaire de réappliquer ces modifications après la mise à niveau. Alors que la mise à niveau crée une copie de sauvegarde de toutes les modifications qui ne peuvent pas fusionner sous /var, nous vous recommandons de sauvegarder ces modifications manuellement avant de commencer la mise à niveau.

Génération du fichier quickstart.properties

Lors du démarrage d’AEM depuis le fichier jar, un fichier quickstart.properties est généré sous crx-quickstart/conf. Si AEM a uniquement été lancé avec le script de démarrage dans le passé, ce fichier ne sera pas présent et la mise à niveau échouera. Veillez à vérifier l’existence de ce fichier et à redémarrer AEM depuis le fichier jar s’il n’existe pas.

Configuration de la purge du workflow et du journal d’audit

Les tâches WorkflowPurgeTask et com.day.cq.audit.impl.AuditLogMaintenanceTask nécessitent des configurations OSGi distinctes et ne fonctionneront pas sans celles-ci. Si elles échouent lors de l’exécution des tâches avant la mise à niveau, les configurations manquantes en sont la cause la plus probable. Par conséquent, veillez à ajouter des configurations OSGi pour ces tâches ou à les supprimer de la liste de tâches d’optimisation avant la mise à niveau si vous ne souhaitez pas les exécuter. La documentation pour la configuration des tâches de purge du workflow se trouve dans la section Administration des instances de workflow et la configuration des tâches de maintenance du journal d’audit se trouve dans la section Maintenance du journal d’audit dans AEM 6.

Pour la purge du workflow et du journal d’audit dans CQ 5.6 et la purge du journal d’audit dans AEM 6.0, voir Purge du workflow et des nœuds d’audit.

Installation, configuration et exécution des tâches précédant la mise à niveau

En raison du niveau de personnalisation accordé par AEM, il n’existe généralement pas de méthode uniforme pour effectuer les mises à niveau. Ceci complique la création d’une procédure standard de mise à niveau.

Dans les versions précédentes, il était aussi difficile pour les mises à niveau AEM qui ont été arrêtées ou ont échoué d’êtres enlevées sans risque. Cela a entrainé des situations dans lesquelles il était nécessaire d’effectuer un redémarrage complet d’une mise à niveau, ou des mises à niveau défectueuses ont été appliquées sans aucun avertissement.

Pour remédier à ces problemes, Adobe a ajouté plusieurs améliorations au processus de mise à niveau en vue de la rendre plus robuste et facile à utiliser. Les tâches de maintenance précédant la niveau, qui auparavant devaient être effectuées manuellement, sont en train d’être optimisées et automatisées. De même, des rapports d’après mise à niveau ont été ajoutés pour assurer un examen complet de la procédure en vue d’identifier plus facilement les problèmes.

Les tâches de maintenance postérieures à la mise à niveau sont actuellement réparties dans différentes interfaces, qui sont partiellement ou totalement exécutées manuellement. L’optimisation de la maintenance avant la mise à niveau apparue dans la version AEM 6.3 permet de déclencher ces tâches de façon unifiée et d’examiner leurs résultats sur demande.

Toutes les tâches comprises dans cette étape d’optimisation postérieure à la mise à niveau sont compatibles avec toutes les versions à partir d’AEM 6.0.

Configuration

Dans AEM 6.3 et versions ultérieures, les tâches d’optimisation de la maintenance précédant la mise à niveau sont incluses dans le fichier jar de démarrage rapide. Si vous effectuez une mise à niveau à partir d’une ancienne version d’AEM 6, elles sont disponibles via des packages distincts que vous pouvez télécharger à partir du gestionnaire de modules.

Vous pouvez trouver les modules à ces emplacements :

Utilisation

Le composant OSGi PreUpgradeTasksMBean est préconfiguré avec une liste de tâches de maintenance bénéficiant déjà de la mise à niveau, pouvant toutes être exécutées simultanément. Vous pouvez configurer les tâches en suivant la procédure ci-dessous :

  1. Accédez à la console web en vous rendans sur http://serveraddress:serverport/system/console/configMgr

  2. Recherchez « preupgradetasks », puis cliquez sur le premier composant correspondant. Le nom complet du composant est com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl

  3. Modifiez la liste des tâches de maintenance devant être exécutées comme illustré ci-dessous :

    1487758925984

La liste des tâches varie selon le mode d’exécution utilisé pour démarrer l’instance. Vous trouverez ci-dessous une description du mode d’exécution pour lequel chaque tâche de maintenance est conçue.

Tâche Mode d’exécution Notes
TarIndexMergeTask crx2  
DataStoreGarbageCollectionTask crx2 Exécute le marquage et le balayage. Pour les banques de données partagées, supprimez cette étape et procédez à l’exécution
manuellement ou préparez correctement les instances avant l’exécution.
ConsistencyCheckTask crx2  
WorkflowPurgeTask crx2/crx3 Doit configurer la configuration OSGi de purge du workflow Adobe Granite avant l’exécution.
GenerateBundlesListFileTask crx2/crx3  
RevisionCleanupTask crx3 Pour les instances TarMK sur AEM de 6.0 à 6.2, il faut plutôt exécuter manuellement le nettoyage des révisions hors ligne.
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 Doit configurer la configuration OSGi du planificateur de purge de journal d’audit avant l’exécution.

Attention :

DataStoreGarbageCollectionTask appelle l’opération de nettoyage de l’entrepôt de données avec la phase de marquage et de balayage le cas échéant. Pour les déploiements qui utilisent une banque de données partagée, veillez à la reconfigurer correctement ou à préparer l’instance pour éviter la suppression des éléments référencés par une autre instance. Cela peut nécessiter l’exécution manuelle de la phase de marquage sur toutes les instances avant de déclencher cette tâche postérieure à la mise à niveau.

Configuration par défaut pour les vérifications d’intégrité antérieures à la mise à niveau

Le composant OSGi PreUpgradeTasksMBeanImpl est préconfiguré avec une liste de balises de vérification de l’intégrité précédant la mise à niveau à exécuter lorsque la méthode runAllPreUpgradeHealthChecks est appelée :

  • system - balise utilisée par les vérifications d’intégrité de maintenance Granite
  • pre-upgrade - il s’agit d’une balise personnalisée pouvant être ajoutée à toutes les vérification d’intégrité que vous pouvez configurer pour une exécution avant une mise à niveau

La liste est modifiable. Vous pouvez utiliser les bouton Plus (+) et Moins (-) à côté des balises pour ajouter d’autres balises personnalisées ou pour supprimer les balises par défaut.

Méthodes MBean

La fonctionnalité bean gérée peut être accessible à l’aide de la console JMX.

Vous pouvez accéder aux MBeans en procédant comme suit :

  1. Accédez à la console JMX à l’adresse http://serveraddress:serverport/system/console/jmx

  2. Recherchez PreUpgradeTasks et cliquez sur le résultat

  3. Sélectionnez une méthode à partir de la section Opérations et sélectionnez Invoquer dans la fenêtre suivante.

Vous trouverez ci-dessous la liste de toutes les méthodes disponibles offertes par PreUpgradeTasksMBeanImpl :

Nom de méthode Type Description
getAvailablePreUpgradeTasksNames() INFO Affiche la liste de noms des tâches de maintenance avant la mise à niveau.
getAvailablePreUpgradeHealthChecksTagNames() INFO Affiche la liste des noms de balises des vérifications d’intégrité précédant la mise à niveau.
runAllPreUpgradeTasks() ACTION Exécute toutes les tâches de maintenance de la liste avant la mise à niveau.
runPreUpgradeTask(preUpgradeTaskName) ACTION Exécute la tâche de maintenance avant la mise à niveau avec le nom donné en tant que paramètre.
isRunAllPreUpgradeTaskRunning() ACTION_INFO Vérifie si la tâche runAllPreUpgradeTasksmaintenance est en cours d’exécution.
getAnyPreUpgradeTaskRunning() ACTION_INFO Vérifie si une tâche de maintenance avant la mise à niveau est en cours d’exécution et
renvoie un tableau contenant les noms des tâches en cours d’exécution.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) ACTION Affiche l’heure exacte d’exécution de la tâche de maintenance avant la mise à niveau avec le nom donné en tant que paramètre.
getPreUpgradeTaskLastRunState(preUpgradeTaskName) ACTION Affiche le dernier état d’exécution de la tâche de maintenance avant la mise à niveau, avec le nom donné en tant que paramètre.
runAllPreUpgradeHealthChecks(shutDownOnSuccess) ACTION

Exécute touttes les vérifications d’intégrité avant la mise à niveau et enregistre leur état dans un fichier nommé preUpgradeHCStatus.propertiessitué sur le chemin d’accès Sling de l’accueil. Si le paramètre shutDownOnSuccess est défini sur true, l’instance AEM est arrêtée, mais seulement si toutes les vérification d’intégrité avant la mise à niveau renvoient l’état « OK ».

Le fichier des propriétés est utilisé comme prérequis pour une future mise à niveau
et le processus de mise à niveau est interrompu si l’exécution de la vérification de l’intégrité avant la mise à niveau
échoue. Si vous souhaitez ignorer le résultat des vérifications d’intégrité
avant la mise à niveau et lancer la mise à niveau, vous pouvez supprimer le fichier.

detectUsageOfUnavailableAPI(aemVersion) ACTION Répertorie tous les modules importés qui ne fonctionneront plus
lors du passage à la version d’AEM spécifiée. La version cible d’AEM doit être
fournie en tant que paramètre.

Remarque :

Les méthodes MBean peuvent être invoquées via :

  • La console JMX
  • Toute application externe qui se connecte à JMX
  • cURL

Désactivation des modules de connexion personnalisés

Remarque :

Cette étape est nécessaire uniquement si vous effectuez une mise à niveau à partir d’une version d’AEM 5. Elle peut être entièrement ignorée pour les mises à niveau des versions ultérieures à AEM 6.

La manière dont les modules de connexion LoginModule sont configurés pour l’authentification au niveau du référentiel a complètement changé dans Apache Oak.

Dans les versions d’AEM qui utilisaient CRX2, la configuration était placée dans le fichier .xml du référentiel alors qu’à partir de la version 6 et suivantes, cette opération est effectuée dans le service Apache Felix JAAS Configuration Factory via la console web.

En conséquence, toute configuration existante doit être désactivée et recréée pour Apache Oak après la mise à niveau.

Pour désactiver les modules personnalisés définis dans la configuration JAAS de repository.xml, vous devez modifier la configuration afin d’utiliser le LoginModule par défaut, comme dans cet exemple :

<Security >
             ....
          <!--
                 Use LoginModule authenticating against repository itself
                 -->
                 <LoginModule class = "com.day.crx.core.CRXLoginModule" >
                     <param name = "anonymousId" value = "anonymous" />
                     <param name = "adminId" value ="admin" />
                     <param name = "disableNTLMAuth" value = "true" />
                     <param name = "tokenExpiration" value = "43200000" />
                     <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
                -->
                 </LoginModule >
         </ Security>

Remarque :

Pour plus d’informations, voir Authentification avec le module de connexion externe.

Pour un exemple de configuration LoginModule dans AEM 6, voir Configuration de LDAP avec AEM 6.

Supprimez les mises à jour du répertoire /install

Remarque :

Ne supprimez les modules du répertoire crx-quickstart/install qu’APRÈS avoir arrêté l’instance AEM. Il s’agit de l’une des dernières étapes avant le lancement de la procédure de mise à niveau statique.

Supprimez tous les Service Packs, les Feature Packs ou les correctifs logiciels qui ont été déployés via le répertoire crx-quickstart/install sur le système de fichiers local. Cela empêche l’installation accidentelle d’anciens correctifs et Service Packs sur la nouvelle version d’AEM après la mise à jour.

Arrêt de toutes les instances Cold Standby

Si vous utilisez TarMK Cold Standby, arrêtez toutes les instances Cold Standby. Cela vous offre une façon efficace de revenir en ligne en cas de problème avec la mise à niveau. Une fois que la mise à niveau a abouti, les instances Cold Standby devront être recréées à partir des instances principales mises à niveau.

Désactivation des tâches planifiées personnalisées

Désactivez toutes les tâches OSGi planifiées qui sont incluses dans le code de l’application.

Exécution d’un nettoyage des révisions hors ligne

Remarque :

Cette étape est nécessaire uniquement pour les installations TarMK

Si vous utilisez TarMK, vous devez effectuer le nettoyage des révisions hors ligne avant de procéder à la mise à niveau. Ainsi, l’étape de migration du référentiel et les tâches de mise à niveau associées sont nettement plus rapides et permettent de garantir que le nettoyage des révisions en ligne s’exécute correctement une fois la mise à niveau terminée. Pour plus d’informations sur l’exécution du nettoyage des révisions hors ligne, voir Exécution du nettoyage des révisions hors ligne.

Exécution du nettoyage de la mémoire de l’entrepôt de données

Remarque :

Cette étape est nécessaire uniquement pour les instances exécutant crx3

Après l’exécution du nettoyage des révisions sur les instances CRX3, vous devez procéder au nettoyage de la mémoire de l’entrepôt de données pour supprimer les tâches non référencées dans l’entrepôt de données. Pour obtenir des instructions, consultez la documentation sur le nettoyage de la mémoire de l’entrepôt de données.

Rotation des fichiers journaux

Il est conseillé d’archiver vos fichiers journal actuels avant de lancer la mise à niveau. Il sera alors plus facile de surveiller et d’analyser vos fichiers journaux pendant et après la mise à niveau pour identifier et résoudre les problèmes qui peuvent survenir.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne