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 di AEM fully-back-up-aem

Prima di iniziare l’aggiornamento, è necessario eseguire il backup completo di 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 di 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, Adobe consiglia di eseguire manualmente il backup di tali modifiche prima di iniziare l'aggiornamento.

Genera il file quickstart.properties generate-quickstart-properties

All'avvio di 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, questo 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 del registro di controllo in AEM 6.

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

A causa del livello di personalizzazione consentito da AEM, in genere gli ambienti 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, inoltre, era difficile riprendere in modo sicuro gli aggiornamenti di AEM interrotti o non riusciti. 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 queste attività in modo unificato e di esaminarne i risultati su richiesta.

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

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 di AEM in cui è stata utilizzata la configurazione CRX2 è stato inserito nel file repository.xml, mentre da AEM 6 in poi 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 dei vecchi hotfix e service pack oltre alla nuova versione di 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 da 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. In questo caso, 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

In alcuni casi eccezionali, gli utenti del servizio potrebbero trovarsi in una versione precedente di AEM a cui viene erroneamente assegnato il tag di 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

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.