Procedura di aggiornamento

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

Topologia iniziale

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.

Preparazione all'aggiornamento

1. Interrompere la creazione dei contenuti

2. Arresta l'istanza di standby

3. Disattiva gli agenti di replica sull'autore

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

Esecuzione aggiornamento

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

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)

1. Avvia l'istanza di standby a freddo come nuovo primario

2. Ricrea l’ambiente Authoring dallo standby a freddo.

Cluster di authoring MongoMK

Topologia iniziale

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.

Preparazione all'aggiornamento

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. Aggiornare il file DocumentNodeStoreService.cfg dell'autore principale in modo che rifletta il set di repliche per 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 di authoring principale
9. Se necessario, aggiorna MongoDB sull'istanza Mongo primaria alla versione 3.2 con WiredTiger

Esecuzione aggiornamento

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

In caso di esito positivo

1. Crea nuove istanze di authoring 6.5, connesse all'istanza 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 clonati.

In caso di esito negativo (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. Configurare i file DocumentNodeStoreService.cfg nelle istanze di authoring secondarie in modo che puntino 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.

Esecuzione aggiornamento

1. Arresta il traffico verso l’istanza Publish 2 al load balancer
2. Esegui manutenzione pre-aggiornamento su Publish 2
3. Esegui un aggiornamento in-place su Publish 2
4. Aggiorna 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

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. Aggiorna 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)

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 post-aggiornamento.