Procedura di aggiornamento

ATTENZIONE

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.

tarmk_start_topology

Preparazione all'aggiornamento

upgrade-preparation-author

  1. Interrompere la creazione dei contenuti
  2. Arresta l'istanza di standby
  3. Disattiva gli agenti di replica sull'autore
  4. Esegui il attività di manutenzione pre-aggiornamento.

Esecuzione aggiornamento

execute_upgrade

  1. Esegui il aggiornamento sul posto
  2. Aggiorna il modulo dispatcher se necessario
  3. Controllo qualità convalida l'aggiornamento
  4. Arresta l'istanza dell'autore.

In caso di esito positivo

if_success

  1. Copia l'istanza aggiornata per creare un nuovo standby a freddo
  2. Avvia l'istanza Author
  3. Avvia l'istanza Standby.

In caso di esito negativo (rollback)

rollback

  1. Avvia l'istanza di standby a freddo come nuovo primario
  2. 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.

mongo-topologia

Preparazione all'aggiornamento

mongo-upgrade_prep

  1. Interrompere la creazione dei contenuti
  2. Clonare l'archivio dati per il backup
  3. Interrompi tutte le istanze AEM Author tranne una, il tuo autore principale
  4. Rimuovi tutti i nodi MongoDB tranne uno dal set di repliche, l'istanza Mongo primaria
  5. Aggiorna DocumentNodeStoreService.cfg file sull'autore principale per riflettere il set di repliche membro singolo
  6. Riavvia l'autore principale per assicurarne il corretto riavvio
  7. Disattiva gli agenti di replica sull'autore principale
  8. Esegui attività di manutenzione pre-aggiornamento sull’istanza Author principale
  9. Se necessario, aggiorna MongoDB sull'istanza Mongo primaria alla versione 3.2 con WiredTiger

Esecuzione aggiornamento

esecuzione di un mongo

  1. Eseguire un aggiornamento sul posto sull'autore principale
  2. Aggiornare il Dispatcher o il modulo Web se necessario
  3. Controllo qualità convalida l'aggiornamento

In caso di esito positivo

mongo-secondari

  1. Crea nuove istanze di authoring 6.3, connesse all'istanza Mongo aggiornata
  2. Rigenera i nodi MongoDB rimossi dal cluster
  3. Aggiorna DocumentNodeStoreService.cfg file per riflettere l'intero set di repliche
  4. Riavvia le istanze di authoring, una alla volta
  5. Rimuovi l'archivio dati clonati.

In caso di esito negativo (rollback)

mongo-rollback

  1. Riconfigura le istanze di authoring secondarie per connettersi all’archivio dati clonati
  2. Arrestare l'istanza primaria Author aggiornata
  3. Spegni l'istanza primaria Mongo aggiornata.
  4. Avvia le istanze Mongo secondarie con una di esse come nuova istanza primaria
  5. Configura le DocumentNodeStoreService.cfg file nelle istanze di authoring secondarie per puntare al set di repliche delle istanze Mongo non ancora aggiornate
  6. Avvia le istanze di authoring secondarie
  7. 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.

tarmk-pub-farmv5

Esecuzione aggiornamento

upgrade-publish2

  1. Arresta il traffico verso l’istanza Publish 2 al load balancer
  2. Esegui manutenzione pre-aggiornamento su Publish 2
  3. Eseguire un aggiornamento sul posto su Publish 2
  4. Aggiornare il Dispatcher o il modulo Web se necessario
  5. Svuotare la cache del Dispatcher
  6. Il controllo qualità convalida la pubblicazione 2 tramite Dispatcher, dietro il firewall
  7. Arresta pubblicazione 2
  8. Copia l'istanza Publish 2
  9. Avvia pubblicazione 2

In caso di esito positivo

upgrade-publish1

  1. Abilita il traffico a Pubblica 2
  2. Arresta il traffico per pubblicare 1
  3. Arresta l’istanza Publish 1
  4. Sostituisci l’istanza Publish 1 con una copia di Publish 2
  5. Aggiornare il Dispatcher o il modulo Web se necessario
  6. Svuotare la cache del Dispatcher per Pubblica 1
  7. Avvia pubblicazione 1
  8. Il controllo qualità convalida la pubblicazione 1 tramite Dispatcher, dietro il firewall

In caso di esito negativo (rollback)

pub_rollback

  1. Crea una copia di Publish 1
  2. Sostituisci l’istanza Publish 2 con una copia di Publish 1
  3. Svuotare la cache del Dispatcher per Pubblica 2
  4. Avvia pubblicazione 2
  5. Il controllo qualità convalida la pubblicazione 2 tramite Dispatcher, dietro il firewall
  6. Abilita il traffico a Pubblica 2

Passaggi per l'aggiornamento finale

  1. Abilita il traffico alla pubblicazione 1
  2. Il controllo qualità esegue la convalida finale da un URL pubblico
  3. Abilitare gli agenti di replica dall’ambiente Author
  4. Riprendere l’authoring dei contenuti
  5. Esegui controlli successivi all’aggiornamento.

finale

In questa pagina