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:
-
Passa alla console Web navigando in https://serveraddress:serverport/system/console/configMgr
-
Cerca "pre-aggiornamento attività", quindi fai clic sul primo componente corrispondente. Il nome completo del componente è
com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
-
Modificare l'elenco delle attività di manutenzione che devono essere eseguite come illustrato di seguito:
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.
DataStoreGarbageCollectionTask
chiama un’operazione di raccolta oggetti inattivi del datastore con la fase di contrassegno e sweep, se utilizzate. Per le distribuzioni che utilizzano un archivio dati condiviso, assicurati di riconfigurarlo correttamente o di preparare l’istanza per evitare l’eliminazione degli elementi a cui fa riferimento un’altra istanza. Questo processo potrebbe richiedere l’esecuzione manuale della fase di contrassegno su tutte le istanze prima di attivare questa attività di pre-aggiornamento.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:
-
sistema - il tag utilizzato dai controlli di integrità della manutenzione granite
-
pre-aggiornamento - un tag personalizzato che può essere aggiunto a tutti i controlli di integrità che puoi impostare per l’esecuzione prima di un aggiornamento
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:
-
Andare alla console JMX all’indirizzo https://serveraddress:serverport/system/console/jmx
-
Cerca PreUpgradeTasks e fai clic sul risultato
-
Seleziona un metodo dalla Operazioni sezione e seleziona Richiama nella finestra seguente.
Di seguito sono elencati tutti i metodi disponibili che PreUpgradeTasksMBeanImpl
espone:
- Console JMX
- Qualsiasi applicazione esterna che si connette a JMX
- cURL
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>
LoginModule
configurazione in AEM 6, vedi Configurazione di LDAP con AEM 6.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:
-
Arrestare l'istanza AEM che deve essere aggiornata.
-
Aggiornare lo schema del database. Consultare la documentazione relativa al tipo di database in uso per verificare gli strumenti necessari per ottenere il risultato.
Per ulteriori informazioni su come Oak gestisce gli aggiornamenti dello schema, consulta questa pagina del sito web Apache.
-
Procedere con l'aggiornamento dell'AEM.
Elimina utenti che potrebbero impedire l'aggiornamento delete-users-that-might-hinder-the-upgrade
- Stai effettuando l’aggiornamento da versioni AEM precedenti alla 6.3 di AEM
- Durante l’aggiornamento si verifica uno degli errori indicati di seguito.
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:
-
Scollega l’istanza dal traffico di produzione
-
Crea un backup di uno o più utenti che causano il problema. Puoi eseguire questa operazione tramite Gestione pacchetti. Per ulteriori informazioni, consulta Come utilizzare i pacchetti.
-
Eliminare uno o più utenti che causano il problema. Di seguito è riportato un elenco di utenti che potrebbero rientrare in questa categoria:
dynamic-media-replication
communities-ugc-writer
communities-utility-reader
communities-user-admin
oauthservice
sling-scripting
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.