Utilizzo della reindicizzazione offline per ridurre i tempi di inattività durante un aggiornamento

Introduzione

Uno dei problemi principali nell'aggiornamento di Adobe Experience Manager è rappresentato dai tempi di inattività associati all'ambiente di authoring durante l'esecuzione di un aggiornamento locale. Gli autori dei contenuti non potranno accedere all'ambiente durante un aggiornamento. Pertanto, è consigliabile ridurre al minimo il tempo necessario per eseguire l'aggiornamento. Per i repository di grandi dimensioni, specialmente progetti AEM Assets, che in genere dispongono di grandi archivi dati e di un elevato livello di caricamenti di risorse all’ora, la reindicizzazione degli indici Oak richiede una percentuale significativa del tempo di aggiornamento.

Questa sezione descrive come utilizzare lo strumento di esecuzione Oak per reindicizzare il repository prima eseguendo l'aggiornamento, riducendo così la quantità di tempi di inattività durante l'aggiornamento effettivo. Le fasi presentate possono essere applicate agli indici Lucene delle versioni AEM 6.4 e successive.

Panoramica

Nuove versioni del AEM introducono modifiche alle definizioni dell'indice Oak mano a mano che il set di funzioni viene espanso. Le modifiche agli indici Oak forzano la reindicizzazione durante l'aggiornamento dell'istanza AEM. La reindicizzazione è costosa per le distribuzioni di risorse, in quanto il testo presente nelle risorse (ad esempio, testo contenuto in file pdf) viene estratto e indicizzato. Con i repository MongoMK, i dati sono persistenti sulla rete, aumentando ulteriormente la quantità di tempo di reindicizzazione richiede.

Il problema che la maggior parte dei clienti si trova ad affrontare durante un aggiornamento è la riduzione del tempo di inattività. La soluzione consiste nel saltare l'attività di reindicizzazione durante l'aggiornamento. Questo può essere ottenuto creando nuovi indici precedenti per eseguire l'aggiornamento, quindi semplicemente importandoli durante l'aggiornamento.

Approccio

offline-reindexing-upgrade-text-estrazione

L'idea è quella di creare l'indice prima dell'aggiornamento, rispetto alle definizioni di indice della versione AEM di destinazione utilizzando lo strumento Oak-run. Il diagramma precedente mostra l'approccio di reindicizzazione offline.

Inoltre, questo è l'ordine dei passaggi descritti nell'approccio:

  1. Testo dai binari viene estratto per primo
  2. Definizione dell'indice di destinazione
  3. Gli indici offline vengono creati
  4. Gli indici vengono quindi importati durante il processo di aggiornamento

Estrazione testo

Per abilitare l'indicizzazione completa in AEM, il testo dei file binari come il PDF viene estratto e aggiunto all'indice. In genere si tratta di un passo costoso nel processo di indicizzazione. L'estrazione del testo è una fase di ottimizzazione consigliata soprattutto per reindicizzare i repository di risorse in quanto contengono un gran numero di file binari.

offline-reindexing-upgrade-text-estrazione

Il testo dei file binari memorizzati nel sistema può essere estratto utilizzando lo strumento di esecuzione della quercia con la libreria tika. Un clone dei sistemi di produzione può essere fatto prima dell'aggiornamento e può essere utilizzato per questo processo di estrazione del testo. Questo processo crea quindi l'archivio di testo eseguendo i passaggi seguenti:

1. Naviga nella directory archivio e raccoglie i dettagli dei file binari

Questo passaggio genera un file CSV contenente un tuple di file binari, contenente un percorso e un ID BLOB.

Eseguire il comando seguente dalla directory da cui si desidera creare l'indice. L'esempio seguente presuppone la directory principale del repository.

java java -jar oak-run.jar tika <nodestore path> --fds-path <datastore path> --data-file text-extraction/oak-binary-stats.csv --generate

Dove nodestore path è il mongo_ur o crx-quickstart/repository/segmentstore/

Utilizzare il parametro --fake-ds-path=temp invece di –fds-path per accelerare il processo.

2. Riutilizzare l'archivio di testo binario disponibile nell'indice esistente

Eseguire il dump dei dati di indice dal sistema esistente ed estrarre l'archivio di testo.

È possibile scaricare i dati di indice esistenti utilizzando il seguente comando:

java -jar oak-run.jar index <nodestore path> --fds-path=<datastore path> --index-dump

Dove nodestore path è il mongo_ur o crx-quickstart/repository/segmentstore/

Quindi, utilizzate il dump dell'indice riportato sopra per compilare lo store:

java -jar oak-run.jar tika --data-file text-extraction/oak-binary-stats.csv --store-path text-extraction/store --index-dir ./indexing-result/index-dumps/<oak-index-name>/data populate

Dove oak-index-name è il nome dell'indice di testo completo, ad esempio "lucene".

3. Eseguire il processo di estrazione del testo utilizzando la libreria tika per i file binari mancanti nel passaggio precedente

java -cp oak-run.jar:tika-app-1.21.jar org.apache.jackrabbit.oak.run.Main tika --data-file text-extraction/oak-binary-stats.csv --store-path text-extraction/store --fds-path <datastore path> extract

Dove datastore path è il percorso dell'archivio dati binario.

L'archivio di testo creato può essere aggiornato e riutilizzato in futuro per gli scenari di reindicizzazione.

Per ulteriori dettagli sul processo di estrazione del testo, vedere la documentazione di esecuzione del Oak.

Riindicizzazione offline

offline-reindicxing-upgrade-offline-reindicizzazione

Creare l'indice Lucene offline prima dell'aggiornamento. Se si utilizza MongoMK, si consiglia di eseguirlo direttamente su uno dei nodi MongoMk, in quanto questo evita il sovraccarico di rete.

Per creare l'indice offline, attenetevi alla procedura seguente:

1. Genera definizioni dell'indice Oak Lucene per la AEM di destinazione

Eseguire il dump delle definizioni di indice esistenti. Le definizioni degli indici oggetto di modifiche sono state generate utilizzando il pacchetto dell'archivio Granite Adobe della versione AEM di destinazione e dell'esecuzione della quercia.

Per eliminare la definizione dell'indice dall'istanza di AEM source, eseguire questo comando:

NOTA

Per ulteriori dettagli sulle definizioni dell'indice di dumping, consultare la documentazione Oak.

java -jar oak-run.jar index --fds-path <datastore path> <nodestore path> --index-definitions

Dove si trovano datastore path e nodestore path dall'istanza AEM source.

Quindi, generate le definizioni dell'indice dalla versione target AEM utilizzando il pacchetto del repository Granite della versione di destinazione.

java -cp oak-run.jar:bundle-com.adobe.granite.repository.jar org.apache.jackrabbit.oak.index.IndexDefinitionUpdater --in indexing-definitions_source.json --out merge-index-definitions_target.json --initializer com.adobe.granite.repository.impl.GraniteContent
NOTA

Il processo di creazione della definizione dell'indice riportato sopra è supportato solo a partire dalla versione oak-run-1.12.0. Il targeting viene eseguito utilizzando il bundle del repository Granite com.adobe.granite.repository-x.x.xx.jar.

I passaggi precedenti creano un file JSON denominato merge-index-definitions_target.json che è la definizione di indice.

2. Creare un checkpoint nella directory archivio

Crea un checkpoint nell'istanza di produzione source AEM con una durata prolungata. Questa operazione deve essere eseguita prima della duplicazione del repository.

Tramite la console JMX situata in http://serveraddress:serverport/system/console/jmx, andate a CheckpointMBean e create un punto di controllo con una durata sufficiente (ad esempio, 200 giorni). Per questo, invocate CheckpointMBean#createCheckpoint con 17280000000 come argomento per la durata del ciclo di vita, in millisecondi.

Al termine, copiate l'ID del checkpoint appena creato e convalidate la durata utilizzando JMX CheckpointMBean#listCheckpoints.

NOTA

Questo punto di controllo verrà eliminato quando l'indice verrà importato in un secondo momento.

Per ulteriori dettagli, consultare creazione di punti di controllo nella documentazione Oak.

Eseguire l'indicizzazione offline per le definizioni di indice generate

La reindicizzazione Lucene può essere fatta offline utilizzando la rovere. Questo processo crea i dati di indice nel disco sotto indexing-result/indexes. non scrive nell'archivio e non richiede pertanto l'arresto dell'istanza AEM in esecuzione. L'archivio di testo creato viene incluso in questo processo:

java -Doak.indexer.memLimitInMB=500 -jar oak-run.jar index <nodestore path> --reindex --doc-traversal-mode --checkpoint <checkpoint> --fds-path <datastore path> --index-definitions-file merge-index-definitions_target.json --pre-extracted-text-dir text-extraction/store

Sample <checkpoint> looks like r16c85700008-0-8
—fds-path: path to data store.
--pre-extracted-text-dir: Directory of pre-extracted text.
merge-index-definitions_target: JSON file having merged definitions for the target AEM instance. indexes in this file will be re-indexed.

L'utilizzo del parametro --doc-traversal-mode è molto pratico con le installazioni MongoMK, in quanto migliora notevolmente il tempo di reindicizzazione, spooling del contenuto del repository in un file flat locale. Tuttavia, richiede uno spazio su disco aggiuntivo pari al doppio delle dimensioni del repository.

Nel caso di MongoMK, questo processo può essere accelerato se questo passaggio viene eseguito in un'istanza più vicina all'istanza MongoDB. Se eseguito sullo stesso computer, è possibile evitare il sovraccarico di rete.

Ulteriori dettagli tecnici sono disponibili nella documentazione di esecuzione della quercia per l'indicizzazione.

Importazione di indici

Con AEM 6.4 e versioni successive, AEM è in grado di importare indici da disco in sequenza di avvio. La cartella <repository>/indexing-result/indexes viene controllata per verificare la presenza di dati indice durante l'avvio. È possibile copiare l'indice pre-creato nella posizione sopra durante il processo di aggiornamento prima di iniziare con la nuova versione del target AEM jar. AEM lo importa nel repository e rimuove il checkpoint corrispondente dal sistema. Così un reindice è completamente evitato.

Suggerimenti aggiuntivi e risoluzione dei problemi

Di seguito sono riportati alcuni utili suggerimenti e istruzioni per la risoluzione di problemi.

Ridurre l'impatto sul sistema di produzione live

Si consiglia di duplicare il sistema di produzione e creare l'indice offline utilizzando il clone. Questo elimina ogni potenziale impatto sul sistema di produzione. Tuttavia, il checkpoint richiesto per l'importazione dell'indice deve essere presente nel sistema di produzione. Pertanto, è fondamentale creare un punto di controllo prima di eseguire il clone.

Preparare un Runbook e un'esecuzione di prova

Si consiglia di preparare un runbook ed eseguire alcune prove prima di eseguire l'aggiornamento in produzione.

Modalità Traversal Doc Con Indicizzazione Offline

L'indicizzazione offline richiede più passaggi dell'intero repository. Con le installazioni MongoMK, l'accesso al repository è effettuato attraverso la rete che influisce sulle prestazioni del processo di indicizzazione. Un'opzione consiste nell'eseguire il processo di indicizzazione offline sulla replica MongoDB stessa, che eliminerà il sovraccarico di rete. Un'altra opzione è l'utilizzo della modalità traversal del documento.

La modalità traversal Doc può essere applicata aggiungendo il parametro della riga di comando —doc-traversal al comando di esecuzione oak per l'indicizzazione offline. Questa modalità mette in comune una copia dell'intero repository nel disco locale come file semplice e la utilizza per eseguire l'indicizzazione.

In questa pagina