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 i contenuti e le configurazioni esistenti da sotto /apps e /libs percorsi nell’archivio. Per le modifiche apportate al /etc , incluse le configurazioni di Context Hub, spesso è necessario riapplicare queste modifiche dopo l’aggiornamento. Durante l’aggiornamento viene creata una copia di backup di tutte le modifiche in cui non è possibile unire /var, Adobe consiglia di eseguire manualmente il backup di queste modifiche prima di iniziare l’aggiornamento.

Genera il file quickstart.properties generate-quickstart-properties

Quando si avvia AEM dal file jar, un quickstart.properties file generato 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

Il WorkflowPurgeTask e com.day.cq.audit.impl.AuditLogMaintenanceTask Le attività 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 dei flussi di lavoro e la configurazione dell’attività di manutenzione del registro di controllo sono disponibili all’indirizzo Manutenzione del registro di controllo dell’AEM 6.

Per la rimozione del flusso di lavoro e del registro di controllo in CQ 5.6 e la rimozione del registro di controllo in AEM 6.0, consulta Eliminare i nodi del flusso di lavoro e del controllo.

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 PreUpgradeTasksMBean Il componente OSGI viene fornito 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 PreUpgradeTasksMBeanImpl Il componente OSGI è preconfigurato con un elenco di tag di verifica dello stato pre-aggiornamento da eseguire quando runAllPreUpgradeHealthChecks viene chiamato il metodo:

L’elenco è modificabile. È possibile 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 bean gestiti utilizzando Console JMX.

Per accedere a MBean:

Di seguito sono elencati tutti i metodi disponibili che PreUpgradeTasksMBeanImpl espone:

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

Il modo personalizzato LoginModules sono configurati per l’autenticazione a livello di archivio, ma sono fondamentalmente cambiati in Apache Oak.

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

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

Per disattivare i moduli personalizzati definiti nella configurazione JAAS di repository.xml, è necessario modificare la configurazione per utilizzare il valore predefinito LoginModule, 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

Rimuovi i Service Pack, i Feature Pack o gli hotfix distribuiti tramite crx-quickstart/install sul 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 di Offline Revision Cleanup, vedere Esecuzione della pulizia delle revisioni offline.

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

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

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.