Procedura di aggiornamento

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 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 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. Aggiornare il modulo del dispatcher se necessario

3. QA convalida l'aggiornamento

4. Arrestate l’istanza di creazione.

Se il risultato è

1. Copiare l’istanza aggiornata per creare un nuovo Cold Standby

2. Avviare l'istanza Author

3. Avviate l’istanza Standby.

In caso di esito negativo (rollback)

1. Avviare l'istanza Cold Standby come nuova istanza Primaria

2. Ricostruite l'ambiente Authoring dal Cold Standby.

Cluster di autore MongoMK

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 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, l’autore principale
4. Rimuovere tutti i nodi MongoDB tranne uno dal set di repliche, l'istanza Mongo principale
5. Aggiornare il file DocumentNodeStoreService.cfg sull'autore principale in modo che rifletta il set di repliche per membro singolo
6. Riavviate l'autore principale per assicurarvi che si riavvii correttamente
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 locale sull'autore principale
2. Aggiornare il dispatcher o il modulo Web se necessario
3. QA convalida l'aggiornamento

Se il risultato è

1. Creare nuove istanze Author 6.5, collegate all'istanza Mongo aggiornata

2. Rigenerare i nodi MongoDB rimossi dal cluster

3. Aggiornare i file DocumentNodeStoreService.cfg in modo che riflettano l'intero set di repliche

4. Riavviate le istanze Author, una per volta

5. Rimuovere l'archivio dati duplicato.

In caso di esito negativo (rollback)

1. Riconfigurare le istanze Autore secondarie per collegarsi all'archivio dati clonato

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 file DocumentNodeStoreService.cfg nelle 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, del nodo Mongo e dell'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 manutenzione 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

Se il risultato è

1. Abilita il traffico per Pubblica 2
2. Arrestare il traffico su Pubblica 1
3. Arrestate 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

In caso di esito negativo (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 finali di aggiornamento

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