Vous consultez actuellement l'aide de la version:

Oak-run prend en charge tous les scénarios d’indexation sur la ligne de commande, sans qu’il faille orchestrer l’exécution de ces scénarios par le biais de la console JMX d’AEM.

Les principaux avantages liés à l’utilisation de la commande d’index oak-run.jar pour la gestion des index Oak sont les suivants :

  1. La commande d’index oak-runfournitun nouvel ensemble d’indexation pour AEM 6.4.
  2. Oak-run réduit la durée de réindexation, ce qui a un effet bénéfique sur les délais de réindexation des référentiels de grande taille.
  3. Oak-run réduit la consommation des ressources au cours de la réindexation dans AEM, ce qui se traduit par de meilleures performances globales du système.
  4. Oak-run fournit une réindexation hors-bande. Cette méthode prend en charge les situations dans lesquelles un environnement de production doit être disponible. Aucune maintenance ou période d’indisponibilité normalement requise pour la réindexation n’est tolérée.

Les sections suivantes fournissent des échantillons de commande. La commande d’index oak-run prend en charge toutes les configurations NodeStore et BlobStore. Les exemples fournis ci-dessous concernent les configurations avec FileDataStore et SegmentNodeStore.

Cas d’utilisation 1 – Contrôle de cohérence de l’index

Il s’agit d’un cas d’utilisation lié à l’altération d’index. Dans certains cas, il s’avérait impossible de déterminer les index qui étaient altérés. C’est pourquoi Adobe a développé des outils qui :

  1. effectuent des contrôles de cohérence sur tous les index, et génèrent un rapport sur les index valides et non valides ;
  2. peuvent être utilisés même si AEM n’est pas accessible ;
  3. sont faciles à utiliser.

La recherche d’index altérés peut être effectuée au moyen de l’opération --index-consistency-check :

java -jar oak-run*.jar index --fds-path=/path/to/datastore  /path/to/segmentstore/ --index-consistency-check

Cette opération génère un rapport dans le fichier indexing-result/index-consistency-check-report.txt. Vous trouverez, ci-dessous, un exemple de rapport :

Valid indexes :
        - /content/oak:index/enablementResourceName
        - /oak:index/cqProjectLucene
        - /oak:index/cqTagLucene
        - /oak:index/lucene
        - /oak:index/ntBaseLucene
        - /oak:index/socialLucene
    Invalid indexes :
        - /oak:index/atDamIndex
        - /oak:index/atIndex
        - /oak:index/cqPageLucene
        - /oak:index/damAssetLucene
        - /oak:index/groups
        - /oak:index/slingeventJob
        - /oak:index/users
        - /oak:index/workflowDataLucene
    Ignored indexes as these are not of type lucene:
        - /oak:index/acPrincipalName
        - /oak:index/active

Avantages

Cet outil peut à présent être utilisé par le service d’assistance et l’administrateur système pour déterminer rapidement les index qui sont altérés, puis les réindexer.

Cas d’utilisation 2 – Statistiques sur les index

Pour diagnostiquer certains des cas relatifs aux performances des requêtes, Adobe nécessitait généralement une définition d’index existante ; des statistiques sur les requêtes provenant de la configuration du client. Jusqu’à présent, ces informations étaient disséminées sur plusieurs ressources. Pour faciliter le dépannage, Adobe a créé des outils qui :

  1. vident toute la définition d’index présente sur le système dans un seul fichier JSON ;

  2. vident les statistiques importantes des index existants ;

  3. vident le contenu de l’index en vue d’une analyse hors ligne ;

  4. peuvent être utilisés même si AEM n’est pas accessible.

Les opérations ci-dessus peuvent désormais être effectuées par le biais des commandes d’index d’opération suivantes :

  • --index-info : collecte et vide diverses statistiques liées aux index.


  • --index-definitions : collecte et vide des définitions d’index.


  • --index-dump : vide le contenu de l’index.

Vous trouverez, ci-dessous, un exemple d’utilisation pratique des commandes :

java -jar oak-run*.jar index --fds-path=/path/to/datastore  /path/to/segmentstore/ --index-info --index-definitions --index-dump

Les rapports sont générés dans indexing-result/index-info.txt et dans indexing-result/index-definitions.json

Les mêmes informations sont, en outre, disponibles via la console web et font partie du fichier zip de vidage de la configuration. Elles sont accessibles à l’emplacement suivant :

http://serverhost:serverport/system/console/status-oak-index-defn

Avantages

Cet outil permet de collecter rapidement toutes les informations requises concernant les problèmes d’indexation ou de requête, et de réduire le temps consacré à l’extraction de ces informations.

Cas d’utilisation 3 – Réindexation

En fonction des scénarios, une réindexation doit être effectuée dans certains cas. Actuellement, la réindexation s’effectue en définissant l’indicateur reindex sur true dans le nœud de définition d’index via CRXDE ou via l’interface utilisateur du Gestionnaire d’index. Une fois cet indicateur défini, la réindexation s’opère de façon asynchrone.

Quelques observations concernant la réindexation :

  • La réindexation s’avère beaucoup plus lente sur les configurations DocumentNodeStore que sur les configurations SegmentNodeStore dans lesquelles tout le contenu est local.
  • Avec la conception actuelle, la situation est la suivante : pendant la réindexation, le moteur d’indexation asynchrone est bloqué, et tous les autres index deviennent obsolètes et ne sont plus mis à jour pendant la durée de l’indexation. Par conséquent, si le système est en cours d’utilisation, il se peut que les utilisateurs n’aient pas accès à des résultats actualisés.
  • La réindexation implique la traversée de l’ensemble du référentiel, ce qui peut faire peser une charge importante sur la configuration AEM et, partant, avoir une incidence sur l’expérience utilisateur.
  • Dans le cas d’une installation DocumentNodeStore dans laquelle la réindexation peut prendre un temps considérable, si la connexion à la base de données Mongo échoue en plein milieu de l’opération, l’indexation doit être relancée depuis le début.
  • Dans certains cas, la réindexation peut prendre un certain temps en raison de l’extraction de texte. Cela concerne tout particulièrement les configurations comprenant un grand nombre de fichiers PDF, où le temps consacré à l’extraction de texte peut avoir une incidence sur la durée d’indexation.

Pour répondre à ces objectifs, les outils d’index oak-run prennent en charge différents modes de réindexation qui peuvent être utilisés suivant les besoins. La commande d’index oak-run offre les avantages suivants :

  • Réindexation hors-bande : la réindexation oak-run peut être effectuée séparément d’une configuration AEM en cours d’exécution, ce qui réduit l’impact sur l’instance AEM en cours d’utilisation.
  • Réindexation hors-piste : la réindexation s’effectue sans que cela n’ait d’incidence sur les opérations d’indexation. Cela signifie que le moteur d’indexation asynchrone peut continuer à indexer d’autres index.
  • Réindexation simplifiée pour les installations DocumentNodeStore  : pour les installations DocumentNodeStore, la réindexation peut être réalisée avec une seule commande, ce qui garantit une exécution optimale.
  • Prise en charge de la mise à jour des définitions d’index et de l’ajout de nouvelles définitions d’index.

 

Réindexation – DocumentNodeStore

Pour les installations DocumentNodeStore, la réindexation peut être effectuée au moyen d’une seule commande oak-run :

java -jar oak-run*.jar index --reindex --index-paths=/oak:index/lucene --read-write --fds-path=/path/to/datastore mongodb://server:port/aem

Cela présente les avantages suivants :

  • Incidence minimale sur les instances AEM en cours d’exécution. La plupart des lectures peuvent être effectuées à partir de serveurs secondaires et les activités de traversée requises pour la réindexation n’ont pas de répercussions négatives sur les caches AEM en cours d’exécution.
  • Les utilisateurs peuvent également fournir un fichier JSON d’un nouvel index ou d’un index mis à jour par le biais de l’option --index-definitions-file.

Réindexation – SegmentNodeStore

Pour les installations SegmentNodeStore, la réindexation peut être effectuée de l’une des façons suivantes :

Réindexation en ligne – SegmentNodeStore

Suivez la méthode habituelle où la réindexation est effectuée en définissant l’indicateur reindex

Réindexation en ligne – SegmentNodeStore – L’instance AEM est en cours d’exécution

Dans le cas des installations SegmentNodeStore, un seul processus peut accéder à des fichiers de segment en mode lecture/écriture. C’est la raison pour laquelle d’autres tâches manuelles doivent être effectuées avec certaines opérations de l’indexation oak-run.

Ces tâches sont notamment les suivantes :

  1. Texte de l’étape
  2. Connectez oak-run au même référentiel que celui utilisé par AEM en mode lecture seule et procédez à l’indexation. Voici un exemple de commande à exécuter pour réaliser cette opération :

    java -jar oak-run-1.7.6.jar index --fds-path=/Users/dhasler/dev/cq/quickstart/target/crx-quickstart/repository/datastore/ --checkpoint 26b7da38-a699-45b2-82fb-73aa2f9af0e2 --reindex --index-paths=/oak:index/lucene /Users/dhasler/dev/cq/quickstart/target/crx-quickstart/repository/segmentstore/
  3. Pour terminer, importez les fichiers d’index créés au moyen de l’opération IndexerMBean#importIndex à partir de l’emplacement où oak-run a enregistré les fichiers d’indexation après avoir exécuté la commande ci-dessus.

Dans ce cas, il n’est pas nécessaire d’arrêter le serveur AEM, ni de provisionner une nouvelle instance. Cependant, comme l’indexation implique la traversée de l’ensemble du référentiel, cela augmentera la charge d’E/S sur l’installation, ce qui aura des répercussions négatives sur les performances d’exécution.

Réindexation en ligne – SegmentNodeStore – L’instance AEM est arrêtée

Pour les installations SegmentNodeStore, la réindexation peut être effectuée au moyen d’une seule commande oak-run. Cependant, l’instance AEM doit être arrêtée.

Vous pouvez déclencher la réindexation à l’aide de la commande suivante :

java -jar oak-run*.jar index --reindex --index-paths=/oak:index/lucene --read-write --fds-path=/path/to/datastore  /path/to/segmentstore/ 

À la différence de la méthode décrite ci-dessus, la création du point de contrôle et l’importation de l’index sont, dans ce cas, effectuées automatiquement. L’inconvénient est qu’AEM doit être arrêté pendant le processus.

Réindexation hors-bande – SegmentNodeStore

Dans ce scénario, vous pouvez effectuer la réindexation sur une configuration clonée afin de réduire l’impact sur l’instance AEM en cours d’exécution :

  1. Créez le point de contrôle au moyen d’une opération JMX. Pour ce faire, vous pouvez accéder à la Console JMX et rechercher CheckpointManager. Cliquez ensuite sur l’opération createCheckpoint(long p1) à l’aide d’une valeur d’expiration élevée, en secondes (par exemple, 2592000).

  2. Copiez le dossier crx-quickstart sur un nouvel ordinateur.

  3. Effectuez la réindexation via la commande d’index oak-run.

  4. Copiez les fichiers d’index générés sur le serveur AEM.

  5. Importez les fichiers d’index via JMX.

Dans ce scénario d’utilisation, on part du principe que l’entrepôt de données est accessible sur une autre instance, ce qui peut s’avérer impossible si FileDataStore est placé sur une solution de stockage cloud telle qu’EBS.Cela exclut le scénario dans lequel FileDataStore est également cloné. Si la définition d’index n’effectue pas d’indexation du texte intégral, il n’est pas nécessaire d’accéder à DataStore.

Cas d’utilisation 4 – Mise à jour des définitions d’index

Actuellement, vous pouvez envoyer des modifications de définition d’index via le module ACS Ensure Index. Cela permet d’envoyer les définitions d’index via le module de contenu, ce qui exigera, par la suite, que la réindexation soit effectuée en définissant l’indicateur reindex sur true.

Cela donne de bons résultats avec les plus petites installations pour lesquelles la réindexation est de courte durée. Cependant, pour les référentiels très volumineux, la réindexation prendra beaucoup plus de temps. Dans ce cas, il est désormais possible d’utiliser l’outil d’indexation oak-run.

Oak-run permet à présent de fournir des définitions d’index au format JSON et de créer l’index en mode hors-bande dans lequel aucune modification n’est effectuée sur une instance dynamique.

Le processus dont vous devez tenir compte pour ce scénario d’utilisation est le suivant :

  1. Un développeur met à jour les définitions d’index sur une instance locale, puis génère un fichier JSON de définition d’index au moyen de l’option --index-definitions.
  2. Le fichier JSON mis à jour est ensuite donné à l’administrateur système.
  3. L’administrateur système suit la méthode hors-bande et prépare l’index sur une autre installation.
  4. Une fois cette opération terminée, les fichiers d’index générés seront importés sur une installation AEM active.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne