Attività di manutenzione pre-aggiornamento

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

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

È 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, vedere Backup e ripristino.

Backup delle modifiche a /etc

Il processo di aggiornamento consente di mantenere e unire i contenuti e le configurazioni esistenti dai percorsi /apps e /libs nell’archivio. Per le modifiche apportate al percorso /etc, incluse le configurazioni di Context Hub, spesso è necessario riapplicare queste modifiche dopo l’aggiornamento. Anche se l'aggiornamento effettuerà una copia di backup delle modifiche che non possono essere unite in /var, è consigliabile eseguire manualmente il backup di queste modifiche prima di avviare l'aggiornamento.

Genera il file quickstart.properties

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

Le attività WorkflowPurgeTask e com.day.cq.audit.impl.AuditLogMaintenanceTask 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 del flusso di lavoro e la configurazione delle attività di manutenzione del registro di controllo si trova in Gestione 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, consulta Eliminare il flusso di lavoro e i nodi di controllo.

Installare, configurare ed eseguire le attività di pre-aggiornamento

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

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

Il componente PreUpgradeTasksMBean 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:

  1. Vai alla Console web navigando su https://serveraddress:serverport/system/console/configMgr

  2. Cerca "preupgradeTasks", quindi fai clic sul primo componente corrispondente. Il nome completo del componente è com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl

  3. Modificare l'elenco delle attività di manutenzione da eseguire come illustrato di seguito:

    1487758925984

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.

Attività Modalità esecuzione Note
TarIndexMergeTask crx2
DataStoreGarbageCollectionTask crx2 Correrà mark e sweep. Per i datastore condivisi, rimuovi questo passaggio ed esegui
manualmente o in modo appropriato le istanze prima dell'esecuzione.
ConsistencyCheckTask crx2
WorkflowPurgeTask crx2/crx3 È necessario configurare OSGi Adobe Granite Workflow Purge Configuration prima dell'esecuzione.
GenerateBundlesListFileTask crx2/crx3
RevisionCleanupTask crx3 Per le istanze TarMK su AEM 6.0 a 6.2, esegui manualmente il cleanup delle revisioni offline.
com.day.cq.audit.impl.AuditLogMaintenanceTask crx3 È necessario configurare la configurazione OSGi dell’utilità di pianificazione della rimozione del registro di controllo prima dell’esecuzione.
ATTENZIONE

DataStoreGarbageCollectionTask sta chiamando un'operazione di raccolta oggetti inattivi Datastore con la fase di marcatura e sweep, se utilizzata. Per le distribuzioni che utilizzano un datastore condiviso, assicurati di riconfigurarlo o di prepararlo correttamente oppure di evitare l’eliminazione degli elementi a cui fa riferimento un’altra istanza. Questa operazione 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 stato pre-aggiornamento

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

  • sistema : il tag utilizzato dai controlli di integrità della manutenzione granitica

  • pre-aggiornamento : si tratta di un tag personalizzato che può essere aggiunto a tutti i controlli di integrità che è possibile impostare per l'esecuzione prima di un aggiornamento

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

Metodi MBean

È possibile accedere alla funzionalità dei fagioli gestiti tramite la console JMX.

Per accedere ai MBeans:

  1. Andando alla console JMX all'indirizzo https://serveraddress:serverport/system/console/jmx

  2. Cerca PreUpgradeTasks e fai clic sul risultato

  3. Seleziona un metodo dalla sezione Operazioni e seleziona Richiama nella finestra seguente.

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

Nome metodo Tipo Descrizione
getAvailablePreUpgradeTasksNames() INFO Visualizza l'elenco dei nomi delle attività di manutenzione pre-aggiornamento disponibili.
getAvailablePreUpgradeHealthChecksTagNames() INFORMAZIONI Visualizza l'elenco dei nomi dei tag dei controlli di integrità pre-aggiornamento.
runAllPreUpgradeTasks() AZIONE Esegue tutte le attività di manutenzione pre-aggiornamento nell’elenco.
runPreUpgradeTask(preUpgradeTaskName) AZIONE Esegue l'attività di manutenzione pre-aggiornamento con il nome specificato come parametro.
isRunAllPreUpgradeTaskRunning() ACTION_INFO Controlla se l'attività runAllPreUpgradeTasksmaintenance è attualmente in esecuzione.
getAnyPreUpgradeTaskRunning() ACTION_INFO Controlla se un'attività di manutenzione pre-aggiornamento è attualmente in esecuzione e
restituisce una matrice contenente i nomi delle attività in esecuzione.
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) AZIONE Visualizza il tempo di esecuzione esatto dell'attività di manutenzione pre-aggiornamento con il nome specificato come parametro.
getPreUpgradeTaskLastRunState(preUpgradeTaskName) AZIONE Visualizza l'ultimo stato di esecuzione dell'attività di manutenzione pre-aggiornamento con il nome specificato come parametro.
runAllPreUpgradeHealthChecks(shutDownOnSuccess) AZIONE

Esegue tutti i controlli di integrità pre-aggiornamento e ne salva lo stato in un file denominato preUpgradeHCStatus.properties che si trova nel percorso principale sling. Se il parametro shutDownOnSuccess è impostato su true, l'istanza AEM verrà chiusa, ma solo se tutti i controlli di integrità precedenti all'aggiornamento hanno uno stato OK.

Il file delle proprietà verrà utilizzato come condizione preliminare per qualsiasi aggiornamento futuro
e il processo di aggiornamento verrà interrotto se l'esecuzione del controllo dello stato di pre-aggiornamento
non è riuscita. Se desideri ignorare il risultato dei controlli di integrità pre-aggiornamento
e avviare comunque l'aggiornamento, puoi eliminare il file.

detectUsageOfUnavailableAPI(aemVersion) AZIONE Elenca tutti i pacchetti importati che non saranno più soddisfatti quando
viene eseguito l'aggiornamento alla versione AEM specificata. La versione di destinazione AEM deve essere
specificata come parametro.
NOTA

I metodi MBean possono essere richiamati tramite:

  • Console JMX
  • Qualsiasi applicazione esterna che si connette a JMX
  • cURL

Disattiva moduli di accesso personalizzati

NOTA

Questo passaggio è necessario solo se si esegue l’aggiornamento da una versione AEM 5. Può essere ignorato completamente per gli aggiornamenti dalle versioni precedenti di AEM 6.

Il modo in cui le LoginModules personalizzate sono configurate per l'autenticazione a livello di archivio è cambiato radicalmente in Apache Oak.

Nelle versioni AEM che utilizzavano la configurazione CRX2 venivano inseriti nel file repository.xml, mentre a partire da AEM 6 viene eseguito nel servizio Apache Felix JAAS Configuration Factory tramite la console Web.

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 i moduli predefiniti 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>
NOTA

Per ulteriori informazioni, consulta Autenticazione con il modulo di accesso esterno.

Per un esempio di configurazione LoginModule nel AEM 6, consulta Configurazione di LDAP con AEM 6.

Rimuovi aggiornamenti dalla directory /install

NOTA

Rimuovi i pacchetti solo dalla directory crx-quickstart/install DOPO aver chiuso l'istanza AEM. Questo sarà uno degli ultimi passaggi prima di avviare la procedura di aggiornamento in-place.

Rimuovi tutti i service pack, i feature pack o gli hotfix distribuiti tramite la directory 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

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

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

Esegui pulizia revisioni offline

NOTA

Questo passaggio è necessario solo per le installazioni TarMK

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, vedere Esecuzione del cleanup delle revisioni offline.

Esegui raccolta oggetti inattivi del datastore

NOTA

Questo passaggio è necessario solo per le istanze che eseguono crx3

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 del Data Store.

Aggiornare lo schema di database se necessario

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:

  1. Arresta l'istanza AEM che deve essere aggiornata.

  2. Aggiornare lo schema del database. Consulta la documentazione relativa al tipo di database in uso per vedere quali strumenti devi utilizzare per ottenere questo risultato.

    Per ulteriori informazioni su come Oak gestisce gli aggiornamenti dello schema, consulta questa pagina sul sito web Apache.

  3. Procedi con l'aggiornamento AEM.

Eliminare gli utenti che potrebbero ostacolare l'aggiornamento

NOTA

Questa attività di manutenzione pre-aggiornamento è necessaria solo se:

  • È in corso l'aggiornamento da AEM versioni precedenti a AEM 6.3
  • Durante l'aggiornamento si verifica uno degli errori indicati di seguito.

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:

  1. Stacca l’istanza dal traffico di produzione

  2. Crea un backup degli utenti che causano il problema. Puoi eseguire questa operazione tramite Gestione pacchetti. Per ulteriori informazioni, vedere Come lavorare con i pacchetti.

  3. Elimina gli utenti che causano il problema. Di seguito è riportato un elenco di utenti che potrebbero rientrare in questa categoria:

    1. dynamic-media-replication
    2. communities-ugc-writer
    3. communities-utility-reader
    4. communities-user-admin
    5. oauthservice
    6. sling-scripting

Ruota file di registro

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

In questa pagina