Show Menu
ARGOMENTI×

Procedura di aggiornamento

L’aggiornamento richiederà tempi di inattività per il livello Author, in quanto la maggior parte degli aggiornamenti AEM vengono eseguiti sul posto. Seguendo queste procedure ottimali, i tempi di inattività dei livelli di pubblicazione possono essere ridotti o eliminati.
Quando eseguite l’aggiornamento degli ambienti AEM, è necessario considerare le differenze di approccio tra l’aggiornamento degli ambienti di authoring e di pubblicazione al fine di 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 aggiornare una topologia di AEM attualmente in esecuzione su una versione di AEM 6.x. Poiché il processo varia a seconda dei livelli di creazione e pubblicazione, nonché delle distribuzioni basate su Mongo e TarMK, ciascun livello e ciascun microkernel è stato elencato in una sezione separata. Quando eseguite la distribuzione, è consigliabile aggiornare prima l’ambiente di authoring, determinare il successo e quindi procedere con gli ambienti di pubblicazione.

Livello autore TarMK

Avvio della topologia

La topologia presunta per questa sezione è costituita da un server Author in esecuzione su TarMK con un sistema Cold Standby. 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. Accertatevi di aggiornare o ricreare l'istanza di offload sulla nuova versione dopo aver disattivato gli agenti di replica nell'istanza Author e prima di riabilitarli.

Preparazione all'aggiornamento

  1. Interruzione dell'authoring dei contenuti
  2. Arrestare l'istanza standby
  3. Disattivazione degli agenti di replica sull'autore
  4. Eseguire le attività di manutenzione pre-aggiornamento .

Esecuzione aggiornamento

  1. Eseguire l'aggiornamento locale
  2. Aggiorna il modulo dispatcher se necessario
  3. QA convalida l'aggiornamento
  4. Arrestate l’istanza di creazione.

In caso di esito positivo

  1. Copiare l’istanza aggiornata per creare un nuovo Cold Standby
  2. Avviare l'istanza Author
  3. Avviate l’istanza Standby.

Se non riuscito (rollback)

  1. Avviare l'istanza Cold Standby come nuova istanza Primaria
  2. Ricostruite l'ambiente Authoring dal Cold Standby.

MongoMK Author Cluster

Avvio della topologia

La topologia presunta per questa sezione è costituita da un cluster MongoMK Author con almeno due istanze AEM Author, con il supporto di almeno due database MongoMK. Tutte le istanze Author condividono un archivio dati. Questi passaggi devono essere applicabili sia ai database S3 che ai file. La replica si verifica dai server Author alla farm TarMK Publish.

Preparazione all'aggiornamento

  1. Interruzione dell'authoring dei contenuti
  2. Duplicare l'archivio dati per il backup
  3. Interrompi tutte le istanze di AEM Author tranne una
  4. Rimuovere tutti i nodi MongoDB tranne uno dal set di repliche, l'istanza Mongo principale
  5. Aggiornare il DocumentNodeStoreService.cfg file sull'autore principale per riflettere il set di repliche per membro singolo
  6. Riavvia l'autore principale per assicurarne il corretto riavvio
  7. Disattivazione degli agenti di replica sull'autore principale
  8. Eseguire attività di manutenzione pre-aggiornamento sull'istanza Author principale
  9. Se necessario, aggiornare MongoDB sull'istanza Mongo principale alla versione 3.2 con WiredTiger

Esecuzione aggiornamento

  1. Eseguire un aggiornamento Esecuzione di un aggiornamento locale locale sull'autore principale
  2. Aggiornare il dispatcher o il modulo Web se necessario
  3. QA convalida l'aggiornamento

In caso di esito positivo

  1. Creare nuove istanze Author 6.3, collegate all'istanza Mongo aggiornata
  2. Rigenerare i nodi MongoDB rimossi dal cluster
  3. Aggiornare i DocumentNodeStoreService.cfg file per riflettere l'intero set di repliche
  4. Riavviate le istanze Author, una per volta
  5. Rimuovere l'archivio dati duplicato.

Se non riuscito (rollback)

  1. Riconfigurare le istanze Autore secondarie per collegarsi all'archivio dati duplicato
  2. Arrestare l'istanza principale Author aggiornata
  3. Chiudere l'istanza principale Mongo aggiornata.
  4. Avvia le istanze Mongo secondarie con una di esse come nuova istanza principale
  5. Configurare i DocumentNodeStoreService.cfg file sulle istanze Autore secondarie per puntare al set di repliche delle istanze Mongo non ancora aggiornate
  6. Avvio delle istanze Autore secondarie
  7. Pulizia delle istanze di creazione aggiornate, nodo Mongo e archivio dati.

TarMK Publish Farm

TarMK Publish Farm

La topologia presunta per questa sezione è costituita da due istanze di pubblicazione TarMK, precedute dai Dispatcher che sono a loro volta frontati da un sistema di bilanciamento del carico. La replica si verifica dal server Author alla farm TarMK Publish.

Esecuzione aggiornamento

  1. Arrestare il traffico all’istanza Pubblica 2 in corrispondenza del sistema di bilanciamento del carico
  2. Eseguire la manutenzione Attività di manutenzione pre-aggiornamento pre-aggiornamento su Publish 2
  3. Eseguire un aggiornamento locale su Pubblica 2
  4. Aggiornare il dispatcher o il modulo Web se necessario
  5. Svuotare la cache del dispatcher
  6. QA convalida Publish 2 tramite il dispatcher, dietro il firewall
  7. Arresta pubblicazione 2
  8. Copiare l’istanza Pubblica 2
  9. Avvia pubblicazione 2

In caso di esito positivo

  1. Abilita il traffico per Pubblica 2
  2. Arrestare il traffico su Pubblica 1
  3. Arrestare l’istanza Pubblica 1
  4. Sostituisce l’istanza Pubblica 1 con una copia di Pubblica 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. QA convalida Publish 1 tramite il dispatcher, dietro il firewall

Se non riuscito (rollback)

  1. Creare una copia di Publish 1
  2. Sostituisce l’istanza Pubblica 2 con una copia di Pubblica 1
  3. Svuotare la cache del dispatcher per Pubblica 2
  4. Avvia pubblicazione 2
  5. QA convalida Publish 2 tramite il dispatcher, dietro il firewall
  6. Abilita il traffico per Pubblica 2

Passaggi per l'aggiornamento finale

  1. Abilita il traffico per la pubblicazione 1
  2. Il QA esegue la convalida finale da un URL pubblico
  3. Abilitare gli agenti di replica dall'ambiente Authoring
  4. Riprendere l'authoring dei contenuti
  5. Eseguire controlli successivi all'aggiornamento .