L'aggiornamento richiederà tempi di inattività per il livello Author, in quanto la maggior parte degli aggiornamenti AEM vengono eseguiti sul posto. Seguendo queste procedure ottimali, i tempi di inattività dei livelli di pubblicazione possono essere ridotti o eliminati.
Quando eseguite l’aggiornamento degli ambienti AEM, è necessario considerare le differenze di approccio tra l’aggiornamento degli ambienti di authoring e di pubblicazione, al fine di 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 aggiornare una topologia AEM attualmente in esecuzione su una versione di AEM 6.x. Poiché il processo varia a seconda dei livelli di creazione e pubblicazione, nonché delle distribuzioni basate su Mongo e TarMK, ciascun livello e ciascun microkernel è stato elencato in una sezione separata. Quando eseguite la distribuzione, è consigliabile aggiornare prima l’ambiente di authoring, determinare il successo e quindi procedere con gli ambienti di pubblicazione.
La topologia presunta per questa sezione è costituita da un server Author in esecuzione su TarMK con un sistema Cold Standby. La replica si verifica dal server Author alla farm di pubblicazione TarMK. Anche se non illustrato qui, questo approccio può essere utilizzato anche per le distribuzioni che utilizzano lo scaricamento. Accertatevi di aggiornare o ricreare l'istanza di offload sulla nuova versione dopo aver disattivato gli agenti di replica nell'istanza Author e prima di riabilitarli.
Interruzione dell'authoring dei contenuti
Arrestare l'istanza standby
Disattivazione degli agenti di replica sull'autore
Eseguire le attività di manutenzione pre-aggiornamento.
Eseguire l'aggiornamento locale
Aggiornare il modulo del dispatcher se necessario
QA convalida l'aggiornamento
Arrestate l’istanza di creazione.
Copiare l’istanza aggiornata per creare un nuovo Cold Standby
Avviare l'istanza Author
Avviate l’istanza Standby.
Avviare l'istanza Cold Standby come nuova istanza Primaria
Ricostruite l'ambiente Authoring dal Cold Standby.
La topologia presunta per questa sezione è costituita da un cluster MongoMK Author con almeno due istanze AEM Author, con il supporto di almeno due database MongoMK. Tutte le istanze Author condividono un archivio dati. Questi passaggi devono essere applicabili sia ai database S3 che ai file. La replica si verifica dai server Author alla farm TarMK Publish.
DocumentNodeStoreService.cfg
sull'autore principale in modo che rifletta il set di repliche per membro singoloCreare nuove istanze Author 6.5, collegate all'istanza Mongo aggiornata
Rigenerare i nodi MongoDB rimossi dal cluster
Aggiornare i file DocumentNodeStoreService.cfg
in modo che riflettano l'intero set di repliche
Riavviate le istanze Author, una per volta
Rimuovere l'archivio dati duplicato.
Riconfigurare le istanze Autore secondarie per collegarsi all'archivio dati clonato
Arrestare l'istanza principale Author aggiornata
Chiudere l'istanza principale Mongo aggiornata.
Avvia le istanze Mongo secondarie con una di esse come nuova istanza principale
Configurare i file DocumentNodeStoreService.cfg
nelle istanze Autore secondarie per puntare al set di repliche delle istanze Mongo non ancora aggiornate
Avvio delle istanze Autore secondarie
Pulizia delle istanze di creazione aggiornate, del nodo Mongo e dell'archivio dati.
La topologia presunta per questa sezione è costituita da due istanze di pubblicazione TarMK, precedute dai Dispatcher che sono a loro volta frontati da un sistema di bilanciamento del carico. La replica si verifica dal server Author alla farm TarMK Publish.