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

Prima di iniziare l’aggiornamento, è importante seguire queste attività di manutenzione per garantire che il sistema sia pronto e possa essere ripristinato nel caso in cui si verifichino dei 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, è necessario eseguire una migrazione dell’archivio. La migrazione crea una copia dell’archivio nel nuovo formato Tar segmento. Di conseguenza, è necessario spazio su disco sufficiente per conservare una seconda versione, potenzialmente più grande, dell’archivio.

Backup completo dell'AEM fully-back-up-aem

Prima di iniziare l’aggiornamento è necessario eseguire il backup completo dell’AEM. Assicurati di eseguire il backup dell’archivio, dell’installazione dell’applicazione, dell’archivio dati e delle istanze Mongo, se applicabile. Per ulteriori informazioni sul backup e il ripristino di un'istanza AEM, vedere Backup e ripristino.

Backup delle modifiche in /etc backup-changes-etc

Il processo di aggiornamento consente di mantenere e unire il contenuto e le configurazioni esistenti dai percorsi /apps e /libs nell'archivio. Per le modifiche apportate al percorso /etc, incluse le configurazioni Context Hub, spesso è necessario riapplicare tali modifiche dopo l'aggiornamento. Anche se l'aggiornamento crea una copia di backup di tutte le modifiche che non è possibile unire in /var, l'Adobe consiglia di eseguire manualmente il backup di tali modifiche prima di iniziare l'aggiornamento.

Genera il file quickstart.properties generate-quickstart-properties

Quando si avvia AEM dal file jar, viene generato un file quickstart.properties in crx-quickstart/conf. Se AEM è stato avviato solo in passato con lo script di avvio, il file non è presente e l’aggiornamento non riesce. Verifica l’esistenza di questo file e, se non è presente, riavvia AEM dal file jar.

Configurare il flusso di lavoro e la rimozione del registro di controllo configure-wf-audit-purging

Le attività WorkflowPurgeTask e com.day.cq.audit.impl.AuditLogMaintenanceTask richiedono configurazioni OSGi separate e non possono funzionare senza di esse. In caso di errore durante l’esecuzione delle attività di pre-aggiornamento, la causa più probabile è la mancanza di configurazioni. Di conseguenza, se non desideri eseguirle, accertati di aggiungere configurazioni OSGi per queste attività o rimuoverle completamente dall’elenco delle attività di ottimizzazione pre-aggiornamento. La documentazione relativa alla configurazione delle attività di eliminazione del flusso di lavoro è disponibile all'indirizzo Amministrazione delle istanze del flusso di lavoro, mentre la configurazione delle attività di manutenzione del registro di controllo è disponibile all'indirizzo Gestione dei registri di controllo in AEM 6.

Per informazioni sull'eliminazione del flusso di lavoro e del registro di controllo in CQ 5.6 e sull'eliminazione del registro di controllo in AEM 6.0, vedere Eliminare i nodi di controllo e del flusso di lavoro.

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

A causa del livello di personalizzazione consentito da AEM, gli ambienti di solito non si attengono a un modo uniforme di eseguire gli aggiornamenti. In quanto tale, la creazione di una procedura standardizzata per gli aggiornamenti è un processo difficile.

Nelle versioni precedenti, era difficile anche per gli aggiornamenti AEM interrotti o che non erano riusciti a riprendere in modo sicuro. Questo problema causava situazioni in cui era necessario riavviare la procedura di aggiornamento completa 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ù resiliente e di facile utilizzo. Le attività di manutenzione pre-aggiornamento che prima dovevano essere eseguite manualmente vengono ottimizzate e automatizzate. Inoltre, sono stati aggiunti report di post-aggiornamento in modo da poter esaminare completamente il processo nella speranza che eventuali problemi vengano rilevati più facilmente.

Le attività di manutenzione pre-aggiornamento sono attualmente distribuite su varie interfacce che vengono parzialmente o completamente eseguite manualmente. L’ottimizzazione della manutenzione pre-aggiornamento introdotta in AEM 6.3 consente di attivare in modo unificato queste attività e di verificarne 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 impostarla how-to-set-it-up

In AEM 6.3 e versioni successive, le attività di ottimizzazione della manutenzione pre-aggiornamento sono incluse nel file jar quickstart.

Come usarlo how-to-use-it

Il componente OSGI PreUpgradeTasksMBean è preconfigurato con un elenco di attività di manutenzione pre-aggiornamento che possono essere eseguite tutte contemporaneamente. 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 integrità pre-aggiornamento default-configuration-of-the-pre-upgrade-health-checks

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

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

Metodi MBean

È possibile accedere alla funzionalità bean gestito utilizzando Console JMX.

Per accedere a MBean:

Di seguito è riportato un elenco di tutti i metodi disponibili esposti da PreUpgradeTasksMBeanImpl:

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

Il modo in cui LoginModules personalizzato è configurato per l'autenticazione a livello di archivio è cambiato radicalmente in Apache Oak.

Nelle versioni AEM che utilizzavano la configurazione di CRX2 veniva inserito nel file repository.xml, mentre a partire dall'AEM 6 viene eseguito nel servizio Apache Felix JAAS Configuration Factory tramite la console web.

Pertanto, dopo l’aggiornamento eventuali configurazioni esistenti dovranno essere disattivate e ricreate per Apache Oak.

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

<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>

Rimuovi aggiornamenti dalla directory /install remove-updates-install-directory

Rimuovere i Service Pack, i Feature Pack o gli hotfix distribuiti tramite la directory crx-quickstart/install nel file system locale. In questo modo si evita l’installazione involontaria di vecchi hotfix e service pack in aggiunta alla nuova versione dell’AEM al termine dell’aggiornamento.

Arresta tutte le istanze di standby a freddo stop-tarmk-coldstandby-instance

Se si utilizza lo standby a freddo TarMK, interrompere le istanze di standby a freddo. In questo modo è possibile tornare online in caso di problemi durante l'aggiornamento. Al termine dell’aggiornamento, è necessario ricompilare le istanze in standby a freddo dalle istanze primarie aggiornate.

Disabilita 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, esegui Offline Revision Cleanup prima dell’aggiornamento. In questo modo il passaggio di migrazione dell’archivio e le successive attività di aggiornamento vengono eseguiti molto più rapidamente e si garantisce che la pulizia delle revisioni online possa essere eseguita correttamente al termine dell’aggiornamento. Per informazioni sull'esecuzione della pulizia delle revisioni non in linea, vedere Esecuzione della pulizia delle revisioni non in linea.

Esegui raccolta oggetti inattivi archivio dati execute-datastore-garbage-collection

Dopo aver eseguito la pulizia delle revisioni sulle istanze di CRX3, è necessario eseguire la raccolta oggetti inattivi del datastore per rimuovere eventuali BLOB senza riferimenti nell’archivio dati. Per istruzioni, consulta la documentazione su Data Store Garbage Collection.

Aggiorna lo schema del database se necessario upgrade-the-database-schema-if-needed

Di solito, lo stack Apache Oak sottostante utilizzato dall’AEM per la persistenza si occupa dell’aggiornamento dello schema del database, se necessario.

Tuttavia, potrebbero verificarsi dei casi in cui non è possibile aggiornare automaticamente lo schema. Si tratta per lo più di ambienti ad alta sicurezza in cui il database viene eseguito da un utente con privilegi limitati. Se si verifica una situazione di questo tipo, l’AEM continua a utilizzare il vecchio schema.

Per evitare che si verifichi uno scenario di questo tipo, aggiorna lo schema effettuando le seguenti operazioni:

Elimina utenti che potrebbero impedire l'aggiornamento delete-users-that-might-hinder-the-upgrade

Ci sono casi eccezionali in cui gli utenti del servizio potrebbero finire con una versione precedente dell’AEM impropriamente taggata come utenti normali.

In questo caso, l’aggiornamento non riesce e viene visualizzato un messaggio simile al seguente:

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 il problema, eseguire le operazioni seguenti:

Ruota file di registro rotate-log-files

L'Adobe consiglia di archiviare i file di registro correnti prima di iniziare l'aggiornamento. In questo modo è più facile monitorare e analizzare i file di registro durante e dopo l’aggiornamento per identificare e risolvere eventuali problemi.