DocumentazioneAEM 6.4Guida alla distribuzione

Procedura di aggiornamento upgrade-procedure

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

Creato per:

  • Developer
CAUTION
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.
NOTE
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 tarmk-author-tier

Avvio topologia starting-topology

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

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 upgrade-execution-1

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-successful

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) if-unsuccessful-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 mongomk-author-cluster

Avvio topologia starting

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 preparation

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 execution

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 successful-1

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) if-unsuccessful

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

TarMK Publish Farm 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 execution-upgrade

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 successful-2

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) 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 final-upgrade-steps

  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

recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56