DocumentazioneAEM 6.5Guida utente

Procedura di aggiornamento upgrade-procedure

Last update: Sun Jul 14 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
  • Argomenti:

Creato per:

  • Amministratore
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 al minimo o eliminare i tempi di inattività a livello di Publish.

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.

topologia_iniziale_tarmk

Preparazione all’aggiornamento upgrade-preparation

aggiornamento-preparazione-autore

  1. Interrompere l'authoring dei contenuti.

  2. Arresta l'istanza in standby.

  3. Disattiva gli agenti di replica sull’autore.

  4. Esegui le attività di manutenzione precedenti all'aggiornamento.

Esecuzione dell’aggiornamento upgrade-execution

esegui_aggiornamento

  1. Esegui l'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

se_riuscito

  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 Publish TarMK.

topologia mongo

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 file DocumentNodeStoreService.cfg nell'istanza di authoring primaria in modo che rifletta 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 mongo

  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 i file DocumentNodeStoreService.cfg 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 i file DocumentNodeStoreService.cfg nelle istanze di authoring secondarie in modo che puntino 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 Publish TarMK tarmk-publish-farm

Farm Publish 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 Author alla farm di Publish TarMK.

tarmk-pub-farmv5

Esecuzione dell’aggiornamento upgrade-execution-2

aggiornamento-pubblicazione2

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

In caso di esito positivo if-successful-2

aggiornamento-pubblicazione1

  1. Abilita il traffico verso Publish 2.
  2. Arrestare il traffico verso Publish 1.
  3. Arresta l'istanza di Publish 1.
  4. Sostituisci l’istanza di 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 Publish 1.
  7. Avviare Publish 1.
  8. Il controllo qualità convalida Publish 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 di Publish 2 con una copia di Publish 1.
  3. Svuota la cache di Dispatcher per Publish 2.
  4. Avviare Publish 2.
  5. Il controllo qualità convalida Publish 2 tramite Dispatcher, dietro il firewall.
  6. Abilita il traffico verso Publish 2.

Passaggi per l'aggiornamento finale final-upgrade-steps

  1. Abilita il traffico verso Publish 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. Eseguire controlli post-aggiornamento.

finale

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