AEM 6.4 ha raggiunto la fine del supporto esteso e questa documentazione non viene più aggiornata. Per maggiori dettagli, consulta la nostra periodi di assistenza tecnica. Trova le versioni supportate qui.
NOTA
L’aggiornamento richiederà tempi di inattività per il livello di authoring, in quanto la maggior parte degli aggiornamenti AEM vengono eseguiti sul posto. Seguendo queste best practice, è possibile ridurre o eliminare i tempi di inattività del livello di pubblicazione.
Quando aggiorni gli ambienti di AEM, è necessario considerare le differenze di approccio tra l’aggiornamento degli ambienti di authoring o 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 è diverso tra i livelli di authoring e pubblicazione e le implementazioni 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 con gli ambienti di pubblicazione.
Livello di authoring TarMK
Avvio topologia
La topologia presunta per questa sezione è costituita da un server Author in esecuzione su TarMK con uno standby a freddo. 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. Assicurati di aggiornare o ricreare l'istanza di offload sulla nuova versione dopo aver disabilitato gli agenti di replica sull'istanza Author e prima di riabilitarli.
Copia l'istanza aggiornata per creare un nuovo standby a freddo
Avvia l'istanza Author
Avvia l'istanza Standby.
In caso di esito negativo (rollback)
Avvia l'istanza di standby a freddo come nuovo primario
Ricrea l’ambiente Authoring dallo standby a freddo.
Cluster di authoring MongoMK
Avvio topologia
La topologia presunta per questa sezione è costituita da un cluster Autore MongoMK con almeno due istanze Autore AEM, supportate da almeno due database MongoMK. Tutte le istanze Autore condividono un datastore. Questi passaggi devono essere applicati sia ai datastore S3 che ai file . La replica si verifica dai server Author alla farm TarMK Publish.
Preparazione all'aggiornamento
Interrompere la creazione dei contenuti
Clonare l'archivio dati per il backup
Interrompi tutte le istanze AEM Author tranne una, il tuo autore principale
Rimuovi tutti i nodi MongoDB tranne uno dal set di repliche, l'istanza Mongo primaria
Aggiorna DocumentNodeStoreService.cfg file sull'autore principale per riflettere il set di repliche membro singolo
Riavvia l'autore principale per assicurarne il corretto riavvio
Disattiva gli agenti di replica sull'autore principale
Aggiornare il Dispatcher o il modulo Web se necessario
Controllo qualità convalida l'aggiornamento
In caso di esito positivo
Crea nuove istanze di authoring 6.3, connesse all'istanza Mongo aggiornata
Rigenera i nodi MongoDB rimossi dal cluster
Aggiorna DocumentNodeStoreService.cfg file per riflettere l'intero set di repliche
Riavvia le istanze di authoring, una alla volta
Rimuovi l'archivio dati clonati.
In caso di esito negativo (rollback)
Riconfigura le istanze di authoring secondarie per connettersi all’archivio dati clonati
Arrestare l'istanza primaria Author aggiornata
Spegni l'istanza primaria Mongo aggiornata.
Avvia le istanze Mongo secondarie con una di esse come nuova istanza primaria
Configura le DocumentNodeStoreService.cfg file nelle istanze di authoring secondarie per puntare al set di repliche delle istanze Mongo non ancora aggiornate
Avvia le istanze di authoring secondarie
Pulisci le istanze dell’autore aggiornate, il nodo Mongo e l’archivio dati.
TarMK Publish Farm
TarMK Publish Farm
La topologia presunta per questa sezione è costituita da due istanze di pubblicazione TarMK, precedute da Dispatcher che a loro volta sono precedute da un load balancer. La replica si verifica dal server Author alla farm di pubblicazione TarMK.
Esecuzione aggiornamento
Arresta il traffico verso l’istanza Publish 2 al load balancer