Configuration des magasins de nœuds et des entrepôts de données dans AEM 6

Présentation

Dans Adobe Experience Manager (AEM), les données binaires peuvent être stockées indépendamment des nœuds de contenu. Les données binaires sont stockées dans un entrepôt de données alors que les nœuds de contenu sont stockés dans un magasin de nœuds.

Les entrepôts de données et les magasins de nœuds peuvent être configués en utilisant la configuration OSGi. Chaque configuration OSGi est référencé à l’aide d’un PID (identifiant de persistant).

Étapes de configuration

Pour configurer le magasin de nœuds et l’entrepôt de données, procédez comme suit :

  1. Copiez le fichier JAR quickstart AEM dans son répertoire d’installation.

  2. Créez un dossier crx-quickstart/install dans le répertoire d’installation.

  3. Configurez tout d’abord le magasin de nœuds en créant un fichier de configuration avec le nom de l’option de magasin de nœuds que vous voulez utiliser dans le répertoire crx-quickstart/install.

    Par exemple, le magasin de noeuds de document (qui est la base de l’implémentation d’AEM MongoMK) utilise le fichier org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config.

  4. Modifiez le fichier et définissez vos options de configuration.

  5. Créez un fichier de configuration avec le PID de l’entrepôt de données que vous souhaitez utiliser. Modifiez le fichier pour définir les options de configuration.

    REMARQUE
  6. Démarrez AEM.

Configurations des magasins de nœuds

ATTENTION

Les versions plus récentes d’Oak utilisent de nouveaux format et schéma d’affectation de noms pour les fichiers de configuration OSGi. Le nouveau schéma d’affectation de noms requiert que le fichier de configuration soit nommé .config. Le nouveau format exige que les valeurs soient saisies et est documenté ici.

Si vous effectuez une mise à niveau à partir d’une version plus ancienne d’Oak, veillez d’abord à sauvegarder le dossier crx-quickstart/install. Après la mise à niveau, restaurez les contenus du dossier à l’installation mise à niveau, puis modifiez l’extension des fichiers de configuration de .cfg en .config.

Si vous lisez cet article en vue de vous préparer pour effectuer une mise à niveau à partir d’une installation d’AEM 5.x, n’oubliez pas de consulter la documentation de mise à niveau en premier.

Magasins de nœuds de segment

Le magasin de nœuds de segment constitue la base de l’implémentation de TarMK d’Adobe dans AEM 6. Il utilise le PID org.apache.jackrabbit.oak.segment.SegmentNodeStoreService pour la configuration.

ATTENTION

Le PID de la banque de noeuds de segment est passé de org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in previous versions de l’AEM 6 à org.apache.jackrabbit.oak.segment.SegmentNodeStoreService dans AEM 6.3. Veillez à effectuer les ajustements de configuration nécessaires pour refléter cette modification.

Vous pouvez configurer les options suivantes :

  • repository.home : chemin vers le répertoire racine du référentiel dans lequel sont stockées les données associées au référentiel. Par défaut, les fichiers de segment sont stockés dans le répertoire crx-quickstart/segmentstore.

  • tarmk.size : taille maximale d’un segment en Mo. La valeur maximale par défaut étant de 256 Mo.

  • customBlobStore : valeur booléenne indiquant qu’un entrepôt de données personnalisé est utilisé. La valeur par défaut est true pour AEM 6.3 et les versions ultérieures. Pour les versions antérieures à AEM 6.3, la valeur par défaut était false.

Voici un exemple de fichier org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config :

#Path to repo
repository.home="crx-quickstart/repository"

#Max segment size
tarmk.size=I"256"

#Custom data store
customBlobStore=B"true"

Magasin de nœuds de document

Le magasin de noeuds de document est la base de l’implémentation d’AEM MongoMK. Le PID org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreServiceest utilisé. Les options de configuration suivantes sont disponibles :

  • mongouri : MongoURI requis pour se connecter à la base donnée Mongo. La valeur par défaut est de mongodb://localhost:27017

  • db : nom de la base de donnée Mongo. La valeur par défaut est Oak . Toutefois, les nouvelles installations AEM 6 utilisent aem-auteur comme nom de base de donnée par défaut.

  • cache : taille du cache en Mo. Elle est distribuée entre différents caches utilisés dans DocumentNodeStore. La valeur par défaut est de 256.

  • changesSize : taille en Mo de la collection limitée utilisée dans Mongo pour la mise en cache de la sortie diff. La valeur par défaut est de 256.

  • customBlobStore : valeur booléenne indiquant qu’un entrepôt de données personnalisé sera utilisé. La valeur par défaut est de false.

Voici un exemple de fichier org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config :

#Mongo server details
mongouri="mongodb://localhost:27017"

#Name of Mongo database to use
db="aem-author"

#Store binaries in custom BlobStore
customBlobStore=B"false"

Configurations des entrepôts de données

Lorsque vous traitez un grand nombre de fichiers binaires, il est recommandé d’utiliser un entrepôt de données externe au lieu de l’entrepôt de nœuds par défaut pour optimiser la performance.

Par exemple, si votre projet requiert un grand nombre de ressources multimédias, vous pouvez les stocker dans l’entrepôt de données de fichier ou S3 afin d’y accéder plus rapidement qu’en les stockant directement dans MongoDB.

L’entrepôt de données basé sur les fichiers offre de meilleures performances que MongoDB. De plus, les opérations de sauvegarde et de restauration Mongo sont plus lentes lorsque le nombre de ressources est élevé.

Reportez-vous aux sections ci-dessous pour plus d’informations sur les différents entrepôts de données et les différentes configurations.

REMARQUE

Pour activer les entrepôts de données personnalisés, vous devez vérifier que customBlobStore est défini sur true dans le fichier de configuration de magasin de nœuds respectif (magasin de nœuds de segment ou magasin de nœuds de document).

Entrepôt de données basé sur les fichiers

Il s’agit de l’implémentation de FileDataStore présent dans Jackrabbit 2, qui offre une méthode pour stocker les données binaires comme tout autre fichier sur le système de fichiers. Il utilise le PID org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.

Voici les options de configuration disponibles :

  • repository.home : chemin vers le répertoire racine du référentiel dans lequel sont stockées les différentes données associées au référentiel. Par défaut, les fichiers binaires sont stockés dans le répertoire crx-quickstart/repository/datastore.

  • path: Chemin d’accès au répertoire dans lequel les fichiers seront stockés. S’il est spécifié, il prévaut sur la valeur repository.home.

  • minRecordLength : taille minimale en octets d’un fichier stocké dans l’entrepôt de données. Un contenu binaire inférieur à cette valeur est intégré.

REMARQUE

Lorsque vous utilisez un NAS pour stocker les entrepôts de données basés sur les fichiers partagés, assurez-vous d’utiliser uniquement les appareils les plus performants afin d’éviter des problèmes de performances.

Entrepôt de données S3 Amazon

AEM peut être configuré pour stocker des données dans Amazon Simple Storage Service (S3). Il utilise le PID org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config pour la configuration.

Pour activer la fonctionnalité de l’entrepôt de données S3, un Feature Pack contenant le connecteur d’entrepôt de données S3 doit être téléchargé et installé. Accédez au référentiel Adobe, puis téléchargez la dernière version des versions 1.8.x du Feature Pack (par exemple, com.adobe.granite.oak.s3connector-1.8.0.zip). En outre, vous devez également télécharger et installer le dernier Service Pack d’AEM, comme indiqué sur la page AEM 6.4 Service Pack Notes .

REMARQUE

Lorsque vous utilisez AEM 6.4 avec TarMK, les fichiers binaires sont stockés par défaut dans FileDataStore. Pour utiliser TarMK avec l’entrepôt de données S3, vous devez commencer AEM en utilisant le mode d’exécution crx3tar-nofds , par exemple :

java -jar aem6.4.jar -r crx3tar-nofds

À la fin du téléchargement, vous pouvez installer et configurer le connecteur S3 comme suit :

  1. Extrayez le contenu du fichier zip du Feature Pack dans un dossier temporaire.

  2. Accédez au dossier temporaire et naviguez jusqu’à l’emplacement suivant :

    jcr_root/libs/system/install
    

    Copiez tout le contenu de l’emplacement ci-dessus vers <aem-install>/crx-quickstart/install.

  3. Si AEM est déjà configuré pour fonctionner avec le stockage Tar ou MongoDB, supprimez tous les fichiers de configuration existants du dossier aem-install/crx-quickstart/install avant de continuer. Les fichiers à supprimer sont les suivants :

    • For MongoMK: org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
    • For TarMK: org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
  4. Retournez à l’emplacement temporaire où le Feature Pack a été extrait, puis copiez le contenu du dossier suivant :

    • jcr_root/libs/system/config

    vers

    • <aem-install>/crx-quickstart/install

    Veillez à copier uniquement les fichiers de configuration nécessaires pour votre configuration actuelle. Pour une configuration d’entrepôts de données partagé et dédié, copiez le fichier org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config.

    REMARQUE

    Dans une configuration en cluster, effectuez les étapes ci-dessus sur tous les nœuds du cluster, l’un après l’autre. Veillez également à utiliser les mêmes configurations S3 pour tous les nœuds.

  5. Modifiez le fichier, puis ajoutez les options de configuration requises par votre configuration.

  6. Démarrez AEM.

Mise à nouveau vers une nouvelle version du connecteur 1.8.x S3

Si vous devez effectuer une mise à niveau vers une nouvelle version du connecteur 1.8.x S3 (par exemple, de la version 1.8.0 vers la version 1.8.1), procédez comme suit :

  1. Désactivez l’instance AEM.

  2. Accédez à <aem-install>/crx-quickstart/install/15 dans le dossier d’installation d’AEM et sauvegardez son contenu.

  3. Après la sauvegarde, supprimez l'ancienne version de S3 Connector et ses dépendances en supprimant tous les fichiers jar du dossier <aem-install>/crx-quickstart/install/15, par exemple :

    • oak-blob-cloud-1.6.1.jar
    • aws-java-sdk-osgi-1.10.76.jar
    REMARQUE

    Les noms de fichier présentés ci-dessus sont utilisés à titre d’exemple uniquement et ne sont pas définitifs.

  4. Téléchargez la dernière version du Feature Pack 1.8.x depuis le référentiel Adobe.

  5. Décompressez le contenu dans un dossier distinct, puis accédez à jcr_root/libs/system/install/15.

  6. Copiez les fichiers jar dans le dossier d’installation AEM <aem-install>/crx-quickstart/install/15.

  7. Démarrez AEM et vérifiez les fonctionnalités du connecteur.

Vous pouvez utiliser le fichier de configuration avec les options suivantes :

  • accessKey : Clé d’accès AWS.

  • secretKey : clé d’accès secrète AWS. Remarque : Vous pouvez également utiliser les rôles IAM pour l’authentification. Si vous utilisez des rôles IAM, vous n’avez plus besoin de spécifier les accessKey et secretKey.

  • s3Bucket: Nom du compartiment.

  • s3Region : La région du seau.

  • path: Chemin d’accès de l’entrepôt de données. La valeur par défaut est <AEM install folder>/repository/datastore

  • minRecordLength: Taille minimale d’un objet qui doit être stocké dans l’entrepôt de données. La valeur minimale/par défaut est 16 Ko.

  • maxCachedBinarySize : Les fichiers binaires dont la taille est inférieure ou égale à cette taille seront stockés dans le cache mémoire. La taille est en octets. La valeur par défaut est 17408(17 Ko).

  • cacheSize : Taille du cache. La valeur est spécifiée en octets. La valeur par défaut est 64 Go.

  • secret : À utiliser uniquement si vous utilisez la réplication sans fichier binaire pour la configuration de la banque de données partagée.

  • stagingSplitPercentage: Pourcentage de la taille du cache configuré pour être utilisé pour l’évaluation des téléchargements asynchrones. La valeur par défaut est 10.

  • uploadThreads : Nombre de threads de chargement utilisés pour les chargements asynchrones. La valeur par défaut est 10.

  • stagingPurgeInterval : Intervalle en secondes pour la purge des chargements terminés du cache intermédiaire. La valeur par défaut est 300 secondes (5 minutes).

  • stagingRetryInterval : Intervalle de reprise en secondes pour les chargements ayant échoué. La valeur par défaut est 600 secondes (10 minutes).

Options de régions de compartiment

US Standard us-standard
Ouest des États-Unis us-west-2
Ouest des États-Unis (Californie du Nord) us-west-1
UE (Irlande)
EU
Asie-Pacifique (Singapour)
ap-southeast-1
Asie-Pacifique (Sydney)
ap-southeast-2
Asie-Pacifique (Tokyo) ap-northeast-1
Amérique du Sud (Sao Paolo)
sa-east-1

Mise en cache de DataStore

REMARQUE

Les mises en oeuvre de DataStore de S3DataStore, CachingFileDataStore et AzureDataStore prennent en charge la mise en cache du système de fichiers local. L’implémentation de CachingFileDataStore est utile lorsque DataStore est sur NFS (système de fichiers réseau).

Lors de la mise à niveau à partir d’une ancienne implémentation de mise en cache (pré-oak 1.6), il existe une différence dans la structure du répertoire de cache du système de fichiers local. Dans l’ancienne structure de cache, les fichiers téléchargés et chargés étaient placés directement dans le chemin du cache. La nouvelle structure sépare les téléchargements et les téléchargements et les stocke dans deux répertoires nommés upload et download sous le chemin du cache. Le processus de mise à niveau doit être transparent et tout téléchargement en attente doit être planifié. De plus, les fichiers précédemment téléchargés dans le cache seront placés dans le cache lors de l’initialisation.

Vous pouvez également mettre à niveau le cache hors ligne à l’aide de la commande datastorecacheupgrade de oak-run. Pour plus d’informations sur l’exécution de la commande, consultez le fichier lisez-moi du module oak-run.

Le cache est limité en taille et il peut être configuré à l’aide du paramètre cacheSize .

Téléchargements

Le cache local sera vérifié pour l’enregistrement du fichier/blob demandé avant de pouvoir y accéder à partir du DataStore. Lorsque la taille du cache dépasse la limite configurée (voir le paramètre cacheSize) lors de l’ajout d’un fichier, certains des fichiers seront évincés pour récupérer de l’espace.

Téléchargement asynchrone

Le cache prend en charge les téléchargements asynchrones vers le DataStore. Les fichiers sont placés localement, dans le cache (sur le système de fichiers) et une tâche asynchrone commence à les télécharger. Le nombre de téléchargements asynchrones est limité par la taille du cache intermédiaire. La taille du cache intermédiaire est configurée à l’aide du paramètre stagingSplitPercentage. Ce paramètre définit le pourcentage de taille de cache à utiliser pour le cache intermédiaire. En outre, le pourcentage de cache disponible pour les téléchargements est calculé comme suit : (100 - stagingSplitPercentage) &ast;cacheSize.

Les téléchargements asynchrones sont multithreads et le nombre de threads est configuré à l’aide du paramètre uploadThreads .

Les fichiers sont déplacés vers le cache principal de téléchargement une fois les téléchargements effectués. Lorsque la taille du cache intermédiaire dépasse sa limite, les fichiers sont téléchargés de manière synchrone vers le DataStore jusqu’à ce que les téléchargements asynchrones précédents soient terminés et que de l’espace soit à nouveau disponible dans le cache intermédiaire. Les fichiers chargés sont supprimés de la zone d’évaluation par une tâche périodique dont l’intervalle est configuré par le paramètre stagingPurgeInterval .

Les téléchargements ayant échoué (en raison d’une interruption du réseau, par exemple) sont placés dans une file d’attente pour effectuer régulièrement de nouvelles tentatives. L’intervalle de reprise est configuré à l’aide de stagingRetryInterval parameter.

Configuration d’une réplication sans binaire avec Amazon S3

Pour configurer une réplication sans binaire avec S3, les étapes suivantes sont nécessaires :

  1. Installez les instances de création et de publication, puis vérifiez qu’elles démarrent correctement.

  2. Accédez aux paramètres de l’agent de réplication, en ouvrant une page sur http://localhost:4502/etc/replication/agents.author/publish.html.

  3. Appuyez sur le bouton Modifier dans la section Paramètres.

  4. Modifiez l’option Serialization type en Binary less.

  5. Ajoutez le paramètre " binaryless= true" dans l’URI de transport. Après la modification, l’URI doit ressembler à ce qui suit :

    http://localhost:4503/bin/receive?sling:authRequestLogin=1&binaryless=true

  6. Redémarrez toutes les instances de création et de publication pour que les modifications soient appliquées.

Création d’un cluster à l’aide de S3 et MongoDB

  1. Décompressez le quickstart CQ en utilisant la commande suivante :

    java -jar cq-quickstart.jar -unpack

  2. Après la décompression d’AEM, créez un dossier à l’intérieur du répertoire d’installation crx-quickstart/install.

  3. Créez ces deux fichiers à l’interieur du dossier crx-quickstart :

    • org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService. config
    • org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config

    Une fois que ces fichiers ont été créés, ajoutez les options de configuration selon vos besoins.

  4. Installez les deux lots requis pour l’entrepôt de données S3, comme expliqué plus haut.

  5. Vérifiez que MongoDB est installé et qu’une instance de mongod est en cours d’exécution.

  6. Démarrez AEM à l’aide de la commande suivante :

    java -Xmx1024m -XX:MaxPermSize=256M -jar cq-quickstart.jar -r crx3,crx3mongo

  7. Répétez les étapes 1 à 4 pour la seconde instance d’AEM.

  8. Démarrez la seconde instance d’AEM.

Configuration d’un entrepôt de données partagé

  1. Créez d’abord le fichier de configuration d’entrepôt de données sur chaque instance devant partager l’entrepôt de données :

    • Si vous utilisez une balise FileDataStore, créez un fichier nommé org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config et placez-le dans le dossier <aem-install>/crx-quickstart/install.
    • Si vous utilisez S3 comme entrepôt de données, créez un fichier nommé rg.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config dans le dossier <aem-install>/crx-quickstart/install comme indiqué ci-dessus.
  2. Modifiez les fichiers de donfiguration d’entrepôt de données sur chaque instance pour qu’ils pointent vers le même entrepôt de données. Pour en savoir plus, voir cet article.

  3. Si l’instance a été clonée à partir d’un serveur existant, vous devez supprimer le clusterId de la nouvelle instance à l’aide du dernier outil oak-run lorsque le référentiel est hors ligne. La commande que vous devez exécuter est la suivante :

    java -jar oak-run.jar resetclusterid < repository path | Mongo URI >
    
    REMARQUE

    Si un magasin de nœuds de segment est configuré, le chemin du référentiel doit être spécifié. Par défaut, le chemin d’accès est <aem-install-folder>/crx-quickstart/repository/segmentstore. Si un magasin de noeuds de document est configuré, vous pouvez utiliser un URI de chaîne de connexion Mongo.

    REMARQUE

    L’outil Oak-run peut être téléchargé à partir de cet emplacement :

    https://mvnrepository.com/artifact/org.apache.jackrabbit/oak-run/

    Différentes versions de l’outil doivent être utilisées selon la version d’Oak utilisée avec l’installation AEM. Vérifiez les exigences de version énumérés ci-dessous avant d’utiliser l’outil :

    • Pour les versions 1.2.x d’Oak, utilisez Oak-run 1.2.12 ou une version ultérieure.
    • Pour des versions d’Oak plus récentes que celle ci-dessus, utilisez la version d’Oak-run qui correspond au système Oak de votre installation AEM.
  4. Enfin, validez la configuration. Pour cela, vous devez rechercher un fichier unique ajouté à l’entrepôt de données par chaque référentiel le partageant. Le format des fichiers est repository-[UUID], où l’UUID est un identifiant unique de chaque référentiel individuel.

    Une configuration correcte devrait être donc dotée d’autant de fichiers uniques que de référentiels partageant l’entrepôt de données.

    Les fichiers sont stockés différemment, selon l’entrepôt de données :

    • Pour FileDataStore, les fichiers sont créés sous le chemin racine du dossier de l’entrepôt de données.
    • Pour la balise S3DataStore , les fichiers sont créés dans le compartiment S3 configuré sous le dossier META .

Entrepôt de données Azure

AEM peut être configuré pour stocker des donnés dans le service de stockage Azure de Microsoft. Il utilise le PID org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore.config pour la configuration.

Pour activer la fonctionnalité d’entrepôt de données Azure, un Feature Pack contenant le connecteur Azure doit être téléchargé et installé. Accédez au référentiel d’Adobe et téléchargez la dernière version des versions 1.6.x du Feature Pack (par exemple, com.adobe.granite.oak.azureblobconnector-1.6.3.zip).

REMARQUE

Lorsque vous utilisez AEM 6.4 avec TarMK, les fichiers binaires sont stockés par défaut dans FileDataStore. Pour utiliser TarMK avec Azure DataStore, vous devez commencer AEM en utilisant le mode d’exécution crx3tar-nofds, par exemple :

java -jar aem6.4.jar -r crx3tar-nofds

Une fois téléchargé, vous pouvez installer et configurer le connecteur Azure comme suit :

  1. Extrayez le contenu du fichier zip du Feature Pack dans un dossier temporaire.

  2. Accédez au dossier temporaire et copiez le contenu de jcr_root/libs/system/install dans le dossier <aem-install>crx-quickstart/install.

  3. Si AEM est déjà configuré pour fonctionner avec le stockage Tar ou MongoDB, supprimez tous les fichiers de configuration existants du dossier /crx-quickstart/install avant de continuer. Les fichiers à supprimer sont les suivants :

    Pour MongoMK :

    org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config

    Pour TarMK :

    org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

  4. Revenez à l’emplacement temporaire où le Feature Pack a été extrait et copiez le contenu de jcr_root/libs/system/config dans le dossier <aem-install>/crx-quickstart/install.

  5. Modifiez le fichier de configuration et ajoutez les options de configuration requises par votre configuration.

  6. Démarrez AEM.

Vous pouvez utiliser le fichier de configuration avec les options suivantes :

  • azureSas="": Dans la version 1.6.3 du connecteur, la prise en charge Azure Shared Access Signature (SAS) a été ajoutée. Si les informations d’identification SAS et de stockage figurent dans le fichier de configuration, SAS a la priorité. Pour plus d’informations sur SAS, consultez la documentation officielle. Assurez-vous que le caractère '=' est placé dans une séquence d’échappement telle que '='.

  • azureBlobEndpoint="" : point de terminaison Blob Azure. Par exemple, https://<compte-stockage>.blob.core.windows.net.

  • accessKey="" : nom du compte de stockage. Pour plus d’informations sur les informations d’identification de l’authentification Microsoft Azure, reportez-vous à la documentation officielle.

  • secretKey="" : clé d’accès au stockage. Assurez-vous que le caractère '=' est placé dans une séquence d’échappement telle que '='.

  • container="" : nom du conteneur de stockage blob Microsoft Azure. Le conteneur est le regroupement d’un ensemble de blobs. Pour plus de détails, consultez la documentation officielle.

  • maxConnections="" : nombre de demandes simultanées par opération. La valeur par défaut est 1.

  • maxErrorRetry="": Nombre de tentatives par requête. La valeur par défaut est 3.

  • socketTimeout="": Délai d’expiration, en millisecondes, utilisé pour la requête. la valeur par défaut est de 5 minutes.

En plus des paramètres ci-dessus, les paramètres suivants peuvent également être configurés :

  • path: Chemin d’accès de l’entrepôt de données. La valeur par défaut est <aem-install>/repository/datastore.
  • RecordLength: Taille minimale d’un objet qui doit être stocké dans l’entrepôt de données. La valeur par défaut est de 16 Ko.
  • maxCachedBinarySize : Les fichiers binaires dont la taille est inférieure ou égale à cette taille seront stockés dans le cache mémoire. La taille est en octets. La valeur par défaut est 1 7408 (17 Ko).
  • cacheSize : Taille du cache. La valeur est spécifiée en octets. La valeur par défaut est de 64 Go.
  • secret : À utiliser uniquement si vous utilisez la réplication sans fichier binaire pour la configuration de la banque de données partagée.
  • stagingSplitPercentage: Pourcentage de la taille du cache configuré pour être utilisé pour l’évaluation des téléchargements asynchrones. La valeur par défaut est 10.
  • uploadThreads : Nombre de threads de chargement utilisés pour les chargements asynchrones. La valeur par défaut est 10.
  • stagingPurgeInterval : Intervalle en secondes pour la purge des chargements terminés du cache intermédiaire. La valeur par défaut est de 300 secondes (5 minutes).
  • stagingRetryInterval : Intervalle de reprise en secondes pour les chargements ayant échoué. La valeur par défaut est de 600 secondes (10 minutes).
REMARQUE

Tous les paramètres doivent être placés entre guillemets, par exemple :

accessKey="ASDASDERFAERAER"
secretKey="28932hfjlkwdo8fufsdfas\=\="

Nettoyage de la mémoire d’entrepôt de données

Le processus de nettoyage de la mémoire d’entrepôt de données est utilisé pour supprimer tous les fichiers inutilisés dans l’entrepôt de données en vue de libérer de l’espace disque.

Vous pouvez exécuter le nettoyage de la mémoire d’entrepôt de données en procédant comme suit :

  1. Accédez à la console JMX située à l’adresse https://<serveraddress:port>/system/console/jmx

  2. Recherchant RepositoryManagement. Une fois que vous aurez trouvé le gestionnaire de référentiel MBean, cliquez dessus pour afficher les options disponibles.

  3. Accédez à la fin de la page, puis cliquez sur le lien startDataStoreGC(boolean markOnly).

  4. Dans la boîte de dialogue suivante, saisissez false pour le paramètre markOnly, puis cliquez sur Invoke :

    chlimage_1-122

    REMARQUE

    Le paramètre markOnly indique si la phase de balayage du nettoyage sera exécutée ou non.

Nettoyage de la mémoire d’entrepôt de données pour les entrepôts de données partagés

REMARQUE

Lorsque le nettoyage de la mémoire est effectué dans une configuration d’entrepôt de données partagé ou en cluster (avec Mongo ou Segment Tar), le journal peut contenir des avertissements sur l’impossibilité de supprimer certains ID de blob. Cela se produit car les ID d’objets blob supprimés dans un nettoyage précédent sont à nouveau référencés de manière incorrecte par d’autres noeuds de cluster ou partagés qui ne disposent pas d’informations sur les suppressions d’ID. Lorsque le nettoyage est effectué, un avertissement est donc enregistré dans le journal après une tentative de suppression d’un ID qui avait déjà été supprimé lors du précédent nettoyage. Ce comportement n’a toutefois aucune incidence sur les performances ou la fonctionnalité.

Avec des versions plus récentes d’AEM, le nettoyage de la mémoire d’entrepôt de données peut également être effectué sur des entrepôts de données partagés par plusieurs référentiels. Pour pouvoir exécuter le nettoyage de la mémoire d’entrepôt de données sur un entrepôt de données partagé, procédez comme suit :

  1. Vérifiez que les tâches de maintenance configurées pour le nettoyage de la mémoire d’entrepôt de données sont désactivées sur toutes les instances de référentiel partageant l’entrepôt de données.

  2. Exécutez les étapes mentionnées dans Nettoyage de la mémoire binaire individuellement sur toutes les instances de référentiel partageant l’entrepôt de données. Veillez toutefois à saisir true pour le paramètre markOnly avant de cliquer sur le bouton Appeler :

    chlimage_1-123

  3. Après avoir effectué la procédure ci-dessus sur toutes les instances, exécutez à nouveau le nettoyage de l’entrepôt de données à partir d’une des instances :

    1. Accédez à la console JMX, puis sélectionnez le gestionnaire de référentiel Mbean.
    2. Cliquez sur le lien Click startDataStoreGC(boolean markOnly).
    3. Dans la boîte de dialogue suivante, saisissez à nouveau false pour le paramètre markOnly .

    Cela permettra d’assembler tous les fichiers trouvés à l’aide de la phase de repérage utilisée précédemment et de supprimer ensuite le reste inutilisé de l’entrepôt de données.

Sur cette page