Tâches de maintenance avant la mise à niveau pre-upgrade-maintenance-tasks

CAUTION
AEM 6.4 a atteint la fin de la prise en charge étendue et cette documentation n’est plus mise à jour. Pour plus d’informations, voir notre période de support technique. Rechercher les versions prises en charge here.

Avant de commencer la mise à niveau, il est important de suivre ces tâches de maintenance pour vous assurer que le système est prêt et peut être restauré en cas de problème :

Vérification de la disponibilité de l’espace disque nécessaire ensure-sufficient-disk-space

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

Sauvegarde complète d’AEM fully-back-up-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 backup-changes-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 generate-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é démarré avec le script de démarrage dans le passé, ce fichier ne sera pas présent et la mise à niveau échouera. Assurez-vous de vérifier l’existence de ce fichier et redémarrez l’AEM à partir du fichier jar s’il n’est pas présent.

Configuration de la purge du workflow et du journal d’audit configure-wf-audit-purging

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

Pour la purge des workflows et des journaux d’audit sur CQ 5.6, ainsi que la purge des journaux d’audit sur AEM 6.0, voir Purge des noeuds de workflow et d’audit.

Installation, configuration et exécution des tâches précédant la mise à niveau install-configure-run-pre-upgrade-tasks

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. La création d’une procédure normalisée pour les mises à niveau est ainsi un processus difficile.

Dans les versions précédentes, il était également difficile d’AEM mises à niveau qui ont été arrêtées ou qui n’ont pas pu être reprise en toute sécurité. Cela a conduit à des situations où le redémarrage de la procédure de mise à niveau complète était nécessaire ou où des mises à niveau défectueuses ont été effectuées sans déclencher d’avertissement.

Pour résoudre ces problèmes, Adobe a ajouté plusieurs améliorations au processus de mise à niveau, le rendant plus résistant et plus convivial. Les tâches de maintenance préalables à la mise à niveau qui devaient auparavant être effectuées manuellement sont optimisées et automatisées. En outre, des rapports après la mise à niveau ont été ajoutés afin que le processus puisse être entièrement examiné dans l’espoir que les problèmes éventuels soient plus facilement détectés.

Les tâches de maintenance préalables à la mise à niveau sont actuellement réparties sur différentes interfaces, qui sont partiellement ou totalement exécutées manuellement. L’optimisation de la maintenance avant la mise à niveau introduite dans AEM 6.3 permet de déclencher ces tâches de manière unifiée et d’examiner leur résultat à la demande.

Toutes les tâches incluses dans l’étape d’optimisation avant la mise à niveau sont compatibles avec toutes les versions à partir d’AEM 6.0.

Comment le configurer how-to-set-it-up

Dans AEM version 6.3 et ultérieure, les tâches d’optimisation de la maintenance avant 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 modules distincts que vous pouvez télécharger à partir du gestionnaire de modules.

Vous trouverez les packages à ces emplacements :

Comment l’utiliser how-to-use-it

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 accédant à https://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 en fonction du 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
Remarques
TarIndexMergeTask
crx2
DataStoreGarbageCollectionTask
crx2
Exécute le marquage et le balayage. Pour les banques de données partagées, supprimez cette étape et exécutez
préparez manuellement ou correctement les instances avant l’exécution.
ConsistencyCheckTask
crx2
WorkflowPurgeTask
crx2/crx3
Doit configurer la configuration OSGi de purge de workflow Granite de l’Adobe avant l’exécution.
GenerateBundlesListFileTask
crx2/crx3
RevisionCleanupTask
crx3
Pour les instances TarMK sur AEM 6.0 à 6.2, exécutez manuellement le nettoyage des révisions hors ligne à la place.
com.day.cq.audit.impl.AuditLogMaintenanceTask
crx3
Doit configurer la configuration OSGi du planificateur de purge du journal d’audit avant l’exécution.
CAUTION
DataStoreGarbageCollectionTask appelle l’opération de récupération de l’espace mémoire du magasin 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, assurez-vous de la reconfigurer correctement ou de préparer l’instance afin d’é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 de pré-mise à niveau.

Configuration par défaut des contrôles de l’intégrité avant la mise à niveau default-configuration-of-the-pre-upgrade-health-checks

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 contrôles de l’intégrité de la maintenance Granite

  • pre-upgrade  : il s’agit d’une balise personnalisée qui peut être ajoutée à toutes les vérifications d’intégrité dont vous pouvez définir l’exécution avant une mise à niveau

La liste peut être modifiée. Vous pouvez utiliser le plus (+) et moins (-) en plus des balises pour ajouter d’autres balises personnalisées ou supprimer les balises par défaut.

Méthodes MBean

La fonctionnalité bean gérée est accessible à l’aide du Console JMX.

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

  1. Accédez à la console JMX à l’adresse https://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 des noms des tâches de maintenance disponibles avant la mise à niveau.
getAvailablePreUpgradeHealthChecksTagNames()
INFO
Affiche la liste des noms des balises des contrôles d’intégrité avant la mise à niveau.
runAllPreUpgradeTasks()
ACTION
Exécute toutes les tâches de maintenance avant la mise à niveau de la liste.
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 d’exécution exacte 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 toutes les vérifications d’intégrité avant la mise à niveau et enregistre leur statut dans un fichier nommé preUpgradeHCStatus.properties situé 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 le statut « OK ».

Le fichier de propriétés sera utilisé comme prérequis pour toute mise à niveau ultérieure.
et le processus de mise à niveau sera arrêté si le contrôle de l’intégrité précédant la mise à niveau est effectué.
l’exécution a échoué. Si vous souhaitez ignorer le résultat de la pré-mise à niveau
des contrôles d’intégrité et lancer la mise à niveau, vous pouvez tout de même supprimer le fichier.

detectUsageOfUnavailableAPI(aemVersion)
ACTION
Répertorie tous les packages importés qui ne fonctionneront plus
lors du passage à la version d’AEM spécifiée. La version AEM cible doit être
donné en tant que paramètre.
NOTE
Les méthodes MBean peuvent être invoquées via :
  • Console JMX
  • Toute application externe qui se connecte à JMX
  • cURL

Désactivation des modules de connexion personnalisés disable-custom-login-modules

NOTE
Cette étape est nécessaire uniquement si vous effectuez une mise à niveau à partir d’une version d’AEM 5. Il peut être entièrement ignoré pour les mises à niveau à partir d’AEM 6 versions plus anciennes.

La manière dont les modules de connexion LoginModules 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 repository.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>
NOTE
Pour plus d’informations, consultez la section Authentification avec le module de connexion externe.
Pour un exemple de configuration de LoginModule dans AEM 6, consultez la section Configuration de LDAP avec AEM 6.

Suppression des mises à jour du répertoire /install remove-updates-install-directory

NOTE
Supprimez uniquement les packages du répertoire crx-quickstart/install APRÈS avoir arrêté l’instance AEM. Il s’agit de l’une des dernières étapes avant de commencer la procédure de mise à niveau statique.

Supprimez tous les packs de services, les packs de fonctionnalités 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êchera l’installation accidentelle d’anciens correctifs et Service Packs en plus de la nouvelle version d’AEM une fois la mise à jour terminée.

Arrêt de toutes les instances Cold Standby stop-tarmk-coldstandby-instance

Si vous utilisez TarMK cold Secondaire, arrêtez toutes les instances Secondaires froides. Cela garantit un moyen efficace de revenir en ligne en cas de problèmes lors de la mise à niveau. Une fois la mise à niveau terminée, les instances Secondaires en froid devront être reconstruites à partir des instances Principales mises à niveau.

Désactivation des tâches planifiées personnalisées disable-custom-scheduled-jobs

Désactivez toutes les tâches OSGi planifiées incluses dans le code de votre application.

Exécution d’un nettoyage des révisions hors ligne execute-offline-revision-cleanup

NOTE
Cette étape n’est nécessaire que pour les installations TarMK

Si vous utilisez TarMK, vous devez exécuter le nettoyage des révisions hors ligne avant la mise à niveau. L’étape de migration du référentiel et les tâches de mise à niveau qui s’ensuivent s’exécuteront ainsi beaucoup plus rapidement et le nettoyage des révisions en ligne pourra s’exécuter 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 de la récupération de l’espace mémoire du magasin de données execute-datastore-garbage-collection

NOTE
Cette étape n'est nécessaire que pour les instances exécutant crx3

Après avoir exécuté le nettoyage des révisions sur les instances CRX3, vous devez exécuter le nettoyage de la mémoire d’entrepôt de données pour supprimer tous les objets blob non référencés dans l’entrepôt de données. Pour obtenir des instructions, consultez la documentation sur Nettoyage de la mémoire d’entrepôt de données.

Suppression des utilisateurs susceptibles d’entraver la mise à niveau delete-users-that-might-hinder-the-upgrade

NOTE
Cette tâche de maintenance avant la mise à niveau n’est nécessaire que si :
  • vous effectuez une mise à niveau à partir des versions d’AEM antérieures à AEM 6.3 ;
  • vous rencontrez les erreurs mentionnées ci-dessous lors de la mise à niveau.

Il existe des cas exceptionnels où les utilisateurs du service peuvent se retrouver dans des versions AEM plus anciennes mal balisées en tant qu’utilisateurs standard.

Si cela se produit, la mise à niveau échoue avec un message comme celui-ci :

ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.

Pour contourner ce problème, procédez comme suit :

Pour contourner ce problème, procédez comme suit :

  • Désolidarisez l’instance du trafic d’exploitation.

  • Créez une sauvegarde du ou des utilisateurs à l’origine du problème. Vous pouvez le faire via le gestionnaire de packages. Pour plus d’informations sur les packages, consultez la rubrique Utilisation des packages.

  • Supprimez le ou les utilisateurs à l’origine du problème. Vous trouverez ci-dessous une liste d’utilisateurs qui peuvent appartenir à cette catégorie :

    • dynamic-media-replication
    • communities-ugc-writer
    • communities-utility-reader
    • communities-user-admin
    • oauthservice
    • sling-scripting

Mise à niveau du schéma de base de données si nécessaire upgrade-the-database-schema-if-needed

En règle générale, la pile Apache Oak sous-jacente utilisée par AEM pour la persistance s’occupe de la mise à niveau du schéma de base de données si nécessaire.

Cependant, il peut arriver que le schéma ne puisse pas être mis à niveau automatiquement. Il s’agit principalement d’environnements de sécurité élevée dans lesquels la base de données s’exécute sous un utilisateur avec des privilèges très limités. Si cela se produit, AEM continuera à utiliser l’ancien schéma.

Pour éviter cela, vous devez mettre à niveau le schéma en suivant la procédure ci-dessous :

  1. Arrêtez l’instance AEM qui doit être mise à niveau.

  2. Mettez à niveau le schéma de la base de données. Consultez la documentation relative à votre type de base de données afin de connaître les outils à utiliser pour y parvenir.

    Pour plus d’informations sur la façon dont Oak gère les mises à niveau des schémas, consultez cette page sur le site web d’Apache.

  3. Continuez la mise à niveau d’AEM.

Rotation des fichiers journaux rotate-log-files

Nous vous recommandons d’archiver vos fichiers journaux actuels avant de commencer votre mise à niveau. Cela facilite la surveillance et l’analyse de vos fichiers journaux pendant et après la mise à niveau pour identifier et résoudre les problèmes qui peuvent se produire.

recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56