L’aggiornamento richiederà tempi di inattività per il livello di authoring, in quanto la maggior parte degli aggiornamenti AEM viene eseguita sul posto. Seguendo queste best practice, i tempi di inattività del livello di pubblicazione possono essere ridotti al minimo o eliminati.
Durante l’aggiornamento degli ambienti AEM, è necessario tenere conto delle differenze di approccio tra l’aggiornamento degli ambienti di authoring e di pubblicazione per ridurre al minimo i tempi di inattività sia per gli autori che per gli utenti finali. Questa pagina illustra la procedura di alto livello per l’aggiornamento di una topologia AEM attualmente in esecuzione su una versione di AEM 6.x. Poiché il processo varia tra i livelli di authoring e pubblicazione, nonché tra le distribuzioni basate su Mongo e TarMK, ogni livello e microkernel è stato elencato in una sezione separata. Durante l’esecuzione della distribuzione, consigliamo innanzitutto di aggiornare l’ambiente di authoring, determinare il successo e quindi procedere agli ambienti di pubblicazione.
La topologia ipotizzata per questa sezione è costituita da un server di authoring in esecuzione su TarMK con uno standby a freddo. La replica viene eseguita dal server di authoring alla farm di pubblicazione TarMK. Anche se non illustrato qui, questo approccio può essere utilizzato per le distribuzioni che utilizzano lo scaricamento. Assicurati di aggiornare o ricreare l’istanza di offload nella nuova versione dopo aver disabilitato gli agenti di replica nell’istanza di authoring e prima di riabilitarli.
Interrompere l’authoring dei contenuti
Arresta l'istanza in standby
Disattiva agenti di replica sull’autore
Esegui il attività di manutenzione pre-aggiornamento.
Esegui il aggiornamento sul posto
Aggiornare il modulo dispatcher se necessario
Controllo qualità convalida l’aggiornamento
Arresta l'istanza di authoring.
Copiare l'istanza aggiornata per creare una nuova modalità di standby a freddo
Avvia l’istanza di authoring
Avvia l'istanza Standby.
Avvia l'istanza di standby a freddo come nuova istanza principale
Rigenerare l'ambiente di authoring dal Cold Standby.
La topologia ipotizzata per questa sezione è costituita da un cluster di authoring MongoMK con almeno due istanze di authoring AEM, supportate da almeno due database MongoMK. Tutte le istanze dell’Autore condividono un archivio dati. Questi passaggi devono essere applicati sia agli archivi dati S3 che a quelli di file. La replica viene eseguita dai server di authoring alla farm di pubblicazione TarMK.
DocumentNodeStoreService.cfg
file nell'istanza Autore principale per riflettere il set di repliche a membro singoloCrea nuove istanze di authoring 6.5, connesse all’istanza di Mongo aggiornata
Rigenera i nodi MongoDB rimossi dal cluster
Aggiornare il DocumentNodeStoreService.cfg
file per riflettere l'intero set di repliche
Riavvia le istanze di authoring, una alla volta
Rimuovi l’archivio dati clonato.
Riconfigura le istanze di authoring secondarie per la connessione all’archivio dati clonato
Arresta l'istanza principale di authoring aggiornata
Arresta l'istanza primaria Mongo aggiornata.
Avvia le istanze Mongo secondarie con una di queste come nuova istanza primaria
Configurare DocumentNodeStoreService.cfg
file nelle istanze di authoring secondarie per puntare al set di repliche delle istanze di Mongo non ancora aggiornate
Avvia le istanze di authoring secondarie
Rimuovi le istanze di authoring, il nodo Mongo e l’archivio dati aggiornati.
La topologia ipotizzata per questa sezione è costituita da due istanze di pubblicazione TarMK, precedute da Dispatcher che sono a loro volta precedute da un load balancer. La replica viene eseguita dal server di authoring alla farm di pubblicazione TarMK.