Attività di manutenzione pre-aggiornamento pre-upgrade-maintenance-tasks

Prima di iniziare l’aggiornamento, è importante seguire queste operazioni di manutenzione per garantire che il sistema sia pronto e possa essere rimandato in caso di problemi:

Garantire spazio su disco sufficiente ensure-sufficient-disk-space

Durante l’esecuzione dell’aggiornamento, oltre alle attività di aggiornamento del contenuto e del codice, sarà necessario eseguire una migrazione dell’archivio. La migrazione creerà una copia dell’archivio nel nuovo formato Segment Tar. Di conseguenza, sarà necessario spazio su disco sufficiente per mantenere una seconda versione dell’archivio, potenzialmente più grande.

Backup completo AEM fully-back-up-aem

È necessario eseguire il backup completo di AEM prima di avviare l'aggiornamento. Se applicabile, assicurati di eseguire il backup dell’archivio, dell’installazione dell’applicazione, del datastore e delle istanze Mongo. Per ulteriori informazioni sul backup e il ripristino di un'istanza AEM, vedi Backup e ripristino.

Backup delle modifiche a /etc backup-changes-etc

Il processo di aggiornamento consente di mantenere e unire i contenuti e le configurazioni esistenti da in /apps e /libs nel repository. Per le modifiche apportate al /etc percorso, incluse le configurazioni di Context Hub, spesso è necessario riapplicare queste modifiche dopo l'aggiornamento. Mentre l'aggiornamento effettuerà una copia di backup di tutte le modifiche che non può unire in /var, è consigliabile eseguire manualmente il backup di queste modifiche prima di avviare l’aggiornamento.

Genera il file quickstart.properties generate-quickstart-properties

Quando si avvia AEM dal file jar, un quickstart.properties il file verrà generato in crx-quickstart/conf. Se AEM è stato avviato solo con lo script di avvio in passato, questo file non sarà presente e l'aggiornamento non riuscirà. Assicurati di verificare l'esistenza di questo file e riavvia AEM dal file jar se non è presente.

Configurare l’eliminazione del flusso di lavoro e del registro di controllo configure-wf-audit-purging

La WorkflowPurgeTask e com.day.cq.audit.impl.AuditLogMaintenanceTask le attività richiedono configurazioni OSGi separate e non funzioneranno senza di esse. Se non riescono durante l’esecuzione di un’attività di pre-aggiornamento, la ragione più probabile è la mancanza di configurazioni. Assicurati quindi di aggiungere le configurazioni OSGi per queste attività o rimuoverle completamente dall'elenco delle attività di ottimizzazione pre-aggiornamento se non desideri eseguirle. La documentazione per la configurazione delle attività di eliminazione del flusso di lavoro si trova in Amministrazione delle istanze dei flussi di lavoro e la configurazione dell'attività di manutenzione del registro di controllo si trova in Manutenzione del registro di controllo in AEM 6.

Per l'eliminazione del flusso di lavoro e del registro di controllo su CQ 5.6 e per l'eliminazione del registro di controllo su AEM 6.0, vedi Elimina il flusso di lavoro e i nodi di controllo.

Installare, configurare ed eseguire le attività di pre-aggiornamento install-configure-run-pre-upgrade-tasks

A causa del livello di personalizzazione AEM consente, gli ambienti di solito non aderiscono a un modo uniforme di eseguire gli aggiornamenti. Questo rende difficile la creazione di una procedura standardizzata per gli aggiornamenti.

Nelle versioni precedenti, era anche difficile per AEM aggiornamenti interrotti o che non sono stati ripresi in modo sicuro. Ciò portava a situazioni in cui era necessario riavviare la procedura di aggiornamento completo o in cui venivano eseguiti aggiornamenti difettosi senza attivare alcun avviso.

Per risolvere questi problemi, Adobe ha aggiunto diversi miglioramenti al processo di aggiornamento, rendendolo più flessibile e facile da usare. Le attività di manutenzione pre-aggiornamento che prima dovevano essere eseguite manualmente vengono ottimizzate e automatizzate. Inoltre, sono stati aggiunti rapporti post-aggiornamento in modo che il processo possa essere esaminato completamente nella speranza che tutti i problemi vengano trovati più facilmente.

Le attività di manutenzione pre-aggiornamento sono attualmente distribuite su varie interfacce che vengono eseguite manualmente o parzialmente. L'ottimizzazione della manutenzione pre-aggiornamento introdotta in AEM 6.3 consente un modo unificato per attivare queste attività e poterne controllare i risultati su richiesta.

Tutte le attività incluse nel passaggio di ottimizzazione pre-aggiornamento sono compatibili con tutte le versioni a partire da AEM 6.0.

Come configurarlo how-to-set-it-up

In AEM 6.3 e versioni successive, le attività di ottimizzazione della manutenzione pre-aggiornamento sono incluse nel jar quickstart. Se esegui l’aggiornamento da una versione precedente di AEM 6, questi vengono resi disponibili tramite pacchetti separati che puoi scaricare da Gestione pacchetti.

Puoi trovare i pacchetti nelle seguenti posizioni:

Come usarlo how-to-use-it

La PreUpgradeTasksMBean Il componente OSGI è preconfigurato con un elenco di attività di manutenzione pre-aggiornamento che possono essere eseguite tutte insieme. Puoi configurare le attività seguendo la procedura seguente:

L'elenco delle attività varia a seconda della modalità di esecuzione utilizzata per avviare l'istanza. Di seguito è riportata una descrizione della modalità di esecuzione per cui ogni attività di manutenzione è progettata.

Configurazione predefinita dei controlli di stato pre-aggiornamento default-configuration-of-the-pre-upgrade-health-checks

La PreUpgradeTasksMBeanImpl Il componente OSGI è preconfigurato con un elenco di tag di controllo dello stato di pre-aggiornamento da eseguire quando runAllPreUpgradeHealthChecks viene chiamato il metodo :

L’elenco è modificabile. Puoi utilizzare il segno più (+) e meno (-) oltre ai tag per aggiungere altri tag personalizzati o rimuovere quelli predefiniti.

Metodi MBean

È possibile accedere alla funzionalità dei fagioli gestiti utilizzando Console JMX.

Per accedere ai MBeans:

Di seguito è riportato un elenco di tutti i metodi disponibili che PreUpgradeTasksMBeanImpl espone:

Disattiva moduli di accesso personalizzati disable-custom-login-modules

Modalità personalizzata LoginModules sono configurati per l’autenticazione a livello di archivio è stato modificato radicalmente in Apache Oak.

Nelle versioni AEM che utilizzavano la configurazione CRX2 era stato inserito nel repository.xml file, mentre a partire dal AEM 6 viene fatto nel servizio Apache Felix JAAS Configuration Factory tramite la Web Console.

Pertanto, tutte le configurazioni esistenti dovranno essere disabilitate e ricreate per Apache Oak dopo l'aggiornamento.

Per disabilitare i moduli personalizzati definiti nella configurazione JAAS di repository.xml, è necessario modificare la configurazione per utilizzare il valore predefinito LoginModule, come in questo esempio:

<Security >
             ....
          <!--
                 Use LoginModule authenticating against repository itself
                 -->
                 <LoginModule class = "com.day.crx.core.CRXLoginModule" >
                     <param name = "anonymousId" value = "anonymous" />
                     <param name = "adminId" value ="admin" />
                     <param name = "disableNTLMAuth" value = "true" />
                     <param name = "tokenExpiration" value = "43200000" />
                     <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
                -->
                 </LoginModule >
         </ Security>

Rimuovere Gli Aggiornamenti Dalla Directory /install remove-updates-install-directory

Rimuovi i service pack, i feature pack o gli hotfix distribuiti tramite crx-quickstart/install nel file system locale. Questo impedirà l'installazione involontaria di vecchi hotfix e service pack sulla nuova versione AEM al termine dell'aggiornamento.

Interrompi istanze di standby a freddo stop-tarmk-coldstandby-instance

Se si utilizza lo standby a freddo di TarMK, arrestare le istanze di standby a freddo. Questo garantirà un modo efficiente di tornare online in caso di problemi nell'aggiornamento. Una volta completato correttamente l’aggiornamento, le istanze di standby a freddo dovranno essere ricreate dalle istanze primarie aggiornate.

Disattiva processi pianificati personalizzati disable-custom-scheduled-jobs

Disattiva tutti i processi pianificati OSGi inclusi nel codice dell'applicazione.

Esegui pulizia revisioni offline execute-offline-revision-cleanup

Se utilizzi TarMK, devi eseguire il cleanup delle revisioni offline prima di eseguire l'aggiornamento. In questo modo la fase di migrazione dell'archivio e le successive attività di aggiornamento verranno eseguite molto più velocemente e sarà utile per garantire che il cleanup delle revisioni online possa essere eseguito correttamente al termine dell'aggiornamento. Per informazioni sull'esecuzione del cleanup delle revisioni offline, vedi Esecuzione del cleanup delle revisioni offline.

Esegui raccolta oggetti inattivi del datastore execute-datastore-garbage-collection

Dopo aver eseguito la pulizia revisioni sulle istanze CRX3, esegui la raccolta oggetti inattivi Datastore per rimuovere eventuali BLOB non referenziati nell'archivio dati. Per istruzioni, consulta la documentazione su Raccolta rifiuti dell'archivio dati.

Eliminare gli utenti che potrebbero ostacolare l’aggiornamento delete-users-that-might-hinder-the-upgrade

Ci sono casi eccezionali in cui gli utenti del servizio possono finire in una versione precedente AEM con tag non corretti come utenti normali.

Se questo accade, l'aggiornamento avrà esito negativo con un messaggio come questo:

ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.

Per risolvere questo problema, assicurati di effettuare le seguenti operazioni:

Per risolvere questo problema, assicurati di effettuare le seguenti operazioni:

Se necessario, aggiornare lo schema del database upgrade-the-database-schema-if-needed

Di solito, lo stack Apache Oak sottostante utilizzato AEM per la persistenza si occuperà di aggiornare lo schema del database, se necessario.

Tuttavia, potrebbero verificarsi casi in cui lo schema non può essere aggiornato automaticamente. Si tratta per lo più di ambienti di sicurezza di elevata qualità in cui il database è in esecuzione sotto un utente con privilegi molto limitati. In questo caso, AEM continuerà a utilizzare il vecchio schema.

Per evitare che ciò si verifichi, devi aggiornare lo schema seguendo la procedura seguente:

Ruota file di registro rotate-log-files

È consigliabile archiviare i file di registro correnti prima di avviare l'aggiornamento. In questo modo sarà più facile monitorare e scansionare i file di registro durante e dopo l'aggiornamento per identificare e risolvere eventuali problemi.