Show Menu
ARGOMENTI×

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 di eseguire l'aggiornamento, riducendo così la quantità di tempi di inattività durante l'aggiornamento effettivo. Le fasi presentate possono essere applicate agli indici Lucene per le 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 prima di eseguire l'aggiornamento, quindi semplicemente importandoli durante l'aggiornamento.

Approccio

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.
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 si trova il mongo_ur o crx-quickstart/repository/segmentstore/
Utilizzate il --fake-ds-path=temp parametro invece di –fds-path velocizzare 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 si trova 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, consulta la documentazione di esecuzione Oak.

Riindicizzazione offline

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 versione 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 di origine , eseguire il comando seguente:
Per maggiori dettagli sulle definizioni dell'indice di dumping, consulta la documentazione oak-run-indexing.html#async-index-data Oak.
java -jar oak-run.jar index --fds-path <datastore path> <nodestore path> --index-definitions

Posizione datastore path e nodestore path dell'istanza di AEM origine .
Quindi, generate le definizioni di indice dalla versione di destinazione AEM utilizzando il bundle 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

Il processo di creazione della definizione di indice riportato sopra è supportato solo a partire dalla oak-run-1.12.0 versione. 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 nell'archivio
Crea un punto di controllo nell’istanza di AEM origine di produzione con una durata prolungata. Questa operazione deve essere eseguita prima della duplicazione del repository.
Tramite console JMX ubicata in http://serveraddress:serverport/system/console/jmx , andate a CheckpointMBean creare un checkpoint con una durata sufficiente (ad esempio, 200 giorni). Per questo, invocate CheckpointMBean#createCheckpoint con 17280000000 come argomento 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 .
Questo punto di controllo verrà eliminato quando l'indice verrà importato in un secondo momento.
Per ulteriori informazioni, consulta la sezione dedicata alla creazione dei 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 nella directory 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 --doc-traversal-mode parametro è 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 si trovano 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 dei dati di indice durante l'avvio. Potete copiare l'indice pre-creato nella posizione sopra durante il processo di aggiornamento prima di iniziare con la nuova versione del AEM di destinazione . 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 della quercia 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.