La mise à niveau nécessite un temps d’interruption au niveau de l’auteur, car la plupart des mises à niveau d’AEM sont exécutées sur place. En suivant ces bonnes pratiques, vous pouvez réduire ou éliminer le temps d’interruption au niveau de la publication.
Lors de la mise à niveau de vos environnements AEM, vous devez tenir compte des différences d’approche entre les environnements de création et de publication afin de limiter le temps d’interruption pour vos auteurs et vos utilisateurs finaux. Cette page décrit une procédure de haut niveau pour améliorer une topologie AEM en cours d’exécution sur une version d’AEM 6.x. Étant donné que la procédure diffèrent entre les niveaux d’auteur et de publication, ainsi que les déploiements basés sur Mongo et TarMK, chaque niveau et micronoyau a été répertorié dans une section distincte. Lors du déploiement, nous vous conseillons d’abord de mettre à niveau votre environnement de création, de déterminer les critères de réussite, puis de passer aux environnments de publication.
La topologie utilisée pour cette section se compose d’un serveur s’exécutant sur TarMK avec Cold Standby. La réplication se produit du serveur de l’auteur à la ferme de publication TarMK. Bien que cela ne soit pas illustré ici, cette approche peut également être utilisée pour les déploiements qui utilisent le déchargement. Assurez-vous d’effectuer la mise à niveau ou de reconstituer une instance de chargement sur la nouvelle version après avoir désactivé les agents de réplication sur l’instance d’auteur et avant de les autoriser à nouveau.
Arrêtez la création de contenu
Arrêtez l’instance de secours
Désactivez les agents de réplication sur l’auteur
Exécutez les tâches de maintenance avant la mise à niveau.
Exécutez la mise à niveau sur place
Mettez à jour le module de dispatcher si nécessaire
Le contrôle qualité valide la mise à niveau
Fermez l’instance d’auteur.
Copiez l’instance mise à niveau pour créer une nouvelle instance Cold Standby
Lancez l’instance d’auteur
Démarrez l’instance Standby.
Démarrez l’instance Cold Standby en tant que nouvelle instance principale
Recréez l’environnement de création depuis l’instance Cold Standby.
La topologie utilisée pour cette section se compose d’un groupe d’auteurs MongoMK avec au moins deux instances d’auteur AEM, prises en charge par au moins deux bases de données MongoMK. Toutes les instances d’auteur partagent une banque de données. Ces étapes doivent s’appliquer aux entrepôts de données de fichier et S3. La réplication se produit des serveurs d’auteur à la ferme de publication TarMK.
DocumentNodeStoreService.cfg
sur l’auteur principal pour refléter votre ensemble de réplication à un seul membreCréez de nouvelles instances d’auteur 6.5, connectées à votre instance de mise à niveau Mongo
Recréez les nœuds MongoDB qui ont été supprimés du cluster
Mettez à jour les fichiers DocumentNodeStoreService.cfg
pour refléter l’ensemble de réplication complet
Redémarrez les instances d’auteur, une par une
Supprimez les entrepôt de données clonés.
Reconfigurez les instances d’auteur secondaires pour établir la connexion à l’entrepôt de données cloné
Désactivez l’instance d’auteur principale mise à niveau
Désactivez l’instance principale Mongo mise à niveau.
Démarrez les instances secondaires Mongo, l’une d’entre elles faisant office d’instance principale
Configurez les fichiers DocumentNodeStoreService.cfg
sur les instances d’auteur secondaires pour indiquer l’ensemble de réplication des instances Mongo qui ne sont pas encore mises à niveau
Démarrez les instances d’auteur secondaires
Nettoyez les instances d’auteur, le nœud Mongo et l’entrepôt de données mis à niveau.
La topologie utilisée pour cette section se compose de deux instances de publication TarMK, devancés par des dispatchers, eux-mêmes devancés par un équilibreur de charge. La réplication se produit du serveur de l’auteur à la ferme de publication TarMK.