Procedura di aggiornamento upgrade-procedure

NOTE
L’aggiornamento richiede tempi di inattività per il livello di authoring, in quanto la maggior parte degli aggiornamenti Adobe Experience Manager (AEM) viene eseguita sul posto. Seguendo queste best practice, è possibile ridurre o eliminare i tempi di inattività del livello di pubblicazione.

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 e le distribuzioni basate su Mongo e TarMK, ogni livello e microkernel è stato elencato in una sezione separata. Durante l’esecuzione della distribuzione, Adobe consiglia 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

Topologia iniziale starting-topology

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.

tarmk_Starting_topology

Preparazione all’aggiornamento upgrade-preparation

upgrade-preparation-author

  1. Interrompere l'authoring dei contenuti.

  2. Arresta l'istanza in standby.

  3. Disattiva gli agenti di replica sull’autore.

  4. Esegui il attività di manutenzione pre-aggiornamento.

Esecuzione dell’aggiornamento upgrade-execution

execute_upgrade

  1. Esegui il aggiornamento sul posto.

  2. Aggiornare il modulo Dispatcher se necessario.

  3. Il controllo qualità convalida l’aggiornamento.

  4. Arresta l'istanza di authoring.

In caso di esito positivo if-successful

if_success

  1. Copiare l'istanza aggiornata per creare un Cold Standby.

  2. Avvia l’istanza di authoring.

  3. Avvia l'istanza Standby.

In caso di esito negativo (rollback) if-unsuccessful-rollback

rollback

  1. Avviare l'istanza di standby a freddo come nuova istanza principale.

  2. Rigenerare l'ambiente di authoring dal Cold Standby.

Cluster di authoring MongoMK mongomk-author-cluster

Topologia iniziale starting-topology-1

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.

montopologia

Preparazione all’aggiornamento upgrade-preparation-1

mongo-upgrade_prep

  1. Interrompere l'authoring dei contenuti.
  2. Clonare l'archivio dati per il backup.
  3. Arresta tutte le istanze di AEM Author tranne una, ovvero l’istanza Autore principale.
  4. Rimuovi tutti i nodi MongoDB tranne uno dal set di repliche, l’istanza principale di Mongo.
  5. Aggiornare il DocumentNodeStoreService.cfg nell'istanza Autore principale per riflettere il set di repliche a membro singolo.
  6. Riavvia l’Autore primario per assicurarti che venga riavviato correttamente.
  7. Disabilita gli agenti di replica nell’istanza di authoring primaria.
  8. Esegui attività di manutenzione pre-aggiornamento sull’istanza Autore primaria.
  9. Se necessario, aggiorna MongoDB sull’istanza Mongo principale alla versione 3.2 con WiredTiger.

Esecuzione dell’aggiornamento Upgrade-execution-1

esecuzione mongola

  1. Esegui un aggiornamento sul posto sull’autore primario.
  2. Aggiornare il Dispatcher o il modulo web se necessario.
  3. Il controllo qualità convalida l’aggiornamento.

In caso di esito positivo if-successful-1

mongo-secondari

  1. Crea nuove istanze di authoring 6.5, connesse all’istanza di Mongo aggiornata.

  2. Rigenera i nodi MongoDB rimossi dal cluster.

  3. Aggiornare il DocumentNodeStoreService.cfg file per riflettere l'intero set di repliche.

  4. Riavvia le istanze di authoring, una alla volta.

  5. Rimuovi l’archivio dati clonato.

In caso di esito negativo (rollback) if-unsuccessful-rollback-2

mongo-rollback

  1. Riconfigura le istanze di authoring secondarie per la connessione all’archivio dati clonato.

  2. Arresta l'istanza principale di authoring aggiornata.

  3. Arresta l'istanza primaria Mongo aggiornata.

  4. Avvia le istanze Mongo secondarie con una di queste come nuova istanza primaria.

  5. Configurare DocumentNodeStoreService.cfg file nelle istanze di authoring secondarie per puntare al set di repliche delle istanze di Mongo non ancora aggiornate.

  6. Avvia le istanze di authoring secondarie.

  7. Rimuovi le istanze di authoring, il nodo Mongo e l’archivio dati aggiornati.

Farm di pubblicazione TarMK tarmk-publish-farm

Farm di pubblicazione TarMK tarmk-publish-farm-1

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.

tarmk-pub-farmv5

Esecuzione dell’aggiornamento upgrade-execution-2

upgrade-publish2

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

In caso di esito positivo if-successful-2

upgrade-publish1

  1. Attiva traffico per Pubblicazione 2.
  2. Arresta il traffico per la pubblicazione 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. Svuota la cache di Dispatcher per la pubblicazione 1.
  7. Avvia pubblicazione 1.
  8. Il controllo qualità convalida la pubblicazione 1 tramite Dispatcher, dietro il firewall.

In caso di esito negativo (rollback) if-unsuccessful-rollback-1

pub_rollback

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

Passaggi per l'aggiornamento finale final-upgrade-steps

  1. Attiva traffico per Pubblicazione 1.
  2. Il controllo qualità esegue la convalida finale da un URL pubblico.
  3. Abilita gli agenti di replica dall’ambiente di authoring.
  4. Riprendi l’authoring dei contenuti.
  5. Esegui controlli post-aggiornamento.

finale

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2