Le format de persistance de TarMK change avec AEM 6.5. Ces modifications ne nécessitent pas d’étape de migration proactive. Les référentiels existants font l’objet d’une migration progressive, qui est transparente pour l’utilisateur. Le processus de migration est lancé la première fois qu’AEM 6.5 (ou les outils associés) accède(nt) au référentiel.

Une fois la migration vers le format de persistance AEM 6.5 lancée, le référentiel ne peut plus être rétabli vers le format de persistance AEM 6.3 précédent.

Dans AEM 6.3, des modifications au niveau du format de stockage étaient nécessaires, notamment pour améliorer les performances et l’efficacité du nettoyage des révisions en ligne. Ces modifications ne sont pas rétrocompatibles et les référentiels créés avec l’ancien segment Oak (AEM 6.2 et versions antérieures) doivent être migrés.

Autres avantages liés à la modification du format de stockage :

• Amélioration de l’évolutivité (taille du segment optimisée).
• Récupération de l’espace mémoire du magasin de données plus rapide.
  
• Travail de base pour les améliorations futures.

Le nettoyage des révisions hors ligne récupère tout sauf la dernière génération par rapport aux deux dernières générations de nettoyage des révisions en ligne. S’il existe un nouveau référentiel, le nettoyage des révisions en ligne ne récupère aucun espace lorsqu’il est exécuté pour la première fois après le nettoyage des révisions hors ligne, car il n’existe aucune génération suffisamment ancienne pour être récupérée.

Lisez également la section "Exécution du nettoyage des révisions en ligne après le nettoyage des révisions hors ligne" de la section ce chapitre.

Le nettoyage des révisions en ligne est disponible uniquement avec AEM 6.3 et les versions ultérieures. En outre, si vous utilisez une ancienne version d’AEM, vous devez migrer vers la nouvelle Oak Segment Tar.

• Taille du référentiel
• Chargement sur le système (requêtes par minute, en particulier opérations d’écriture)
• Modèle d’activité (lectures et écritures)
• Spécifications matérielles (performances du processeur, mémoire, IOPS)

L’espace disque est surveillé en permanence lors du nettoyage des révisions en ligne. Si l’espace disque disponible tombe en dessous d’une valeur critique, le processus est annulé. La valeur critique est de 25 % de l’empreinte disque actuelle du référentiel et elle n’est pas configurable.

Adobe vous recommande de dimensionner le disque au moins deux ou trois fois plus grand que la taille initialement estimée du référentiel.

L’espace libre du tas est surveillé en permanence pendant le processus de nettoyage. Si l’espace de tas libre tombe sous une valeur critique, le processus est annulé. La valeur critique est configurée via org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. La valeur par défaut est 15%.

Les recommandations pour le dimensionnement minimal du tas de compression ne sont pas séparées des recommandations de dimensionnement de la mémoire d’AEM. En général : Si une instance d’AEM est suffisamment dimensionnée pour gérer les cas d’utilisation et la charge utile attendue, le processus de nettoyage obtient suffisamment de mémoire.

• Assurez-vous qu’il est exécuté tous les jours.
  
• Assurez-vous qu’il est exécuté lorsque les activités du référentiel sont minimales en configurant les fenêtres de maintenance dans le tableau de bord des opérations de manière adéquate.
• Faites évoluer les ressources du système (processeur, mémoire, E/S).

Le nettoyage des révisions repose sur une phase d’estimation pour décider s’il y a suffisamment d’espace mémoire à libérer. L’estimateur compare la taille actuelle à la taille du référentiel après sa dernière compression. Si la taille dépasse le delta configuré, le nettoyage s’exécute. La taille du delta est définie sur 1 Go. Cela signifie que si la taille du référentiel n’a pas augmenté de 1 Go depuis la dernière exécution de nettoyage, la nouvelle itération de nettoyage des révisions est ignorée.

Vous trouverez, ci-dessous, des entrées de journaux pertinentes pour la phase d’estimation :

• Le GC de révision s’exécute : Size delta is N% or N/N (N/N bytes), so running compaction
• Révision du contenu not run : Le delta de taille est N% ou N/N (octets N/N), donc ignorer la compression pour l’instant

S’il y a des écritures simultanées sur le système, le nettoyage des révisions en ligne peut nécessiter un accès exclusif à l’écriture pour pouvoir effectuer les changements à la fin d’un cycle de compression. Le système entre dans mode forceCompact, comme expliqué plus en détail dans la section Documentation Oak. Lors de la compression forcée, un verrou d’écriture exclusif est acquis afin de valider les modifications sans qu’aucune écriture simultanée n’interfère. Pour limiter l’impact sur les temps de réponse, une valeur de délai d’expiration peut être définie. Cette valeur est définie sur une minute par défaut, ce qui signifie que si la compression forcée ne se termine pas en une minute, le processus de compression est abandonné au profit de validations simultanées.

a durée de la compression forcée dépend des facteurs suivants :

• matériel : spécifiquement IOPS. La durée diminue avec davantage d’IOPS.
• taille de la banque de segments : la durée augmente avec la taille du magasin de segments.

Comment le nettoyage des révisions en ligne est-il exécuté sur une instance de secours ?

Dans une configuration Cold Standby, seule l’instance principale doit être configurée pour exécuter le nettoyage des révisions en ligne. Sur l’instance de secours, le nettoyage des révisions en ligne n’a pas besoin d’être programmé de manière spécifique.

L’opération correspondante sur une instance de secours est le nettoyage automatique. Cela correspond à la phase de nettoyage du nettoyage des révisions en ligne. Le nettoyage automatique est exécuté sur l’instance secondaire après l’exécution du nettoyage des révisions en ligne sur l’instance principale.

Les phases d’estimation et de compression ne seront pas exécutées sur une instance secondaire.

Le nettoyage des révisions hors ligne peut supprimer immédiatement les anciennes révisions, tandis que le nettoyage des révisions en ligne doit tenir compte des anciennes révisions toujours référencées par la pile d’applications. Le premier peut ainsi enlever les ordures de manière plus agressive que le second où l'effet est amorti au cours de quelques cycles de nettoyage de la mémoire.

Lisez également la section "Exécution du nettoyage des révisions en ligne après le nettoyage des révisions hors ligne" de la section ce chapitre.

• Dans les environnements Windows, ’accès standard aux fichiers est toujours appliqué ; l’accès mappé par la mémoire n’est donc pas utilisé. n règle générale, il est conseillé d’allouer toute la mémoire vive (RAM) disponible au tas et d’augmenter la taille de segmentCache. Pour augmenter la taille de segmentCache, ajoutez l’option segmentCache.size à org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (par exemple : segmentCache.size=20480). N’oubliez pas de laisser de la mémoire vive pour le système d’exploitation et d’autres processus.
• Dans les environnements autres que Windows, augmentez la taille de la mémoire physique pour améliorer le mappage de la mémoire du référentiel.

• L’espace disque doit être surveillé lorsque le nettoyage des révisions en ligne est activé. Le nettoyage ne s’exécute pas ou s’arrête de manière préventive lorsque l’espace disque est insuffisant.
• Vérifiez les journaux pendant la durée d’exécution du nettoyage des révisions en ligne. Cela ne devrait pas durer plus de 2 heures.
• Nombre de points de contrôle. S’il existe plus de 3 points de contrôle durant l’exécution de la compression, il est recommandé de nettoyer les points de contrôle.

Vous pouvez vérifier si le nettoyage des révisions en ligne s’est terminé correctement en vérifiant les journaux.

Par exemple, « TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles » signifie que l’étape de compression a été effectuée avec succès, sauf si elle a été précédée du message « TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles », ce qui signifie qu’il y avait trop de charge simultanée.

En conséquence, un message « TarMK GC #{}: cleanup completed in {} ({} ms » s’affiche lorsque l’étape de nettoyage est terminée.

L’état, la progression et les statistiques sont présentés via JMX (SegmentRevisionGarbageCollection MBean). Pour plus d’informations sur le MBean SegmentRevisionGarbageCollection, lisez le paragraphe suivant.

Les progrès peuvent être suivis à partir de l’attribut EstimatedRevisionGCCompletion de SegmentRevisionGarbageCollection MBean.

Vous pouvez obtenir une référence du MBean à l’aide de la variable ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

Les statistiques ne sont disponibles que depuis le dernier démarrage du système. Des outils de surveillance externes peuvent être utilisés pour conserver les données au-delà du temps de disponibilité AEM. Consultez la documentation AEM pour joindre les vérifications d’intégrité à Nagios en tant qu’exemple d’outil de surveillance externe.

• Le nettoyage des révisions en ligne a démarré/s’est arrêté
  • Le nettoyage des révisions en ligne se compose de trois phases : estimation, compression et nettoyage. La phase d’estimation peut forcer l’omission des phases de compression et de nettoyage si le référentiel ne contient pas suffisamment de résidus. Dans la dernière version d’AEM, le message « TarMK GC #{}: estimation started » marque le début de l’estimation, « TarMK GC #{}: compaction started, strategy={} » marque le début de la compression et « TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes » marque le début du nettoyage.
• Espace disque gagné par le nettoyage de révision
  • L’espace n’est récupéré que lorsque la phase de nettoyage est terminée. La fin de la phase de nettoyage est marquée par le message du journal « TarMK GC #{}: cleanup completed in {} ({} ms ». La taille après nettoyage est {} ({} octets) et l’espace récupéré{} ({} octets). Le poids/la profondeur de la carte de compression est {}/{} ({} octets/{}).
• Un problème s’est produit pendant le nettoyage de la révision.
  • Il existe de nombreuses conditions d’échec. Elles comportent toutes des messages AVERTISSEMENT ou ERREUR du journal commençant par « TarMK GC ».

Consultez également la section Dépannage basé sur les messages d’erreur ci-dessous.

Une vérification de l’intégrité du référentiel n’est pas nécessaire après le nettoyage des révisions en ligne.

Cependant, vous pouvez effectuer les actions suivantes pour vérifier le statut du référentiel après le nettoyage :

• Une vérification transversale du référentiel
• Utilisez l’outil oak-run une fois le processus de nettoyage terminé pour rechercher les incohérences. Pour plus d’informations sur la procédure à suivre, consultez la section Documentation Apache. Il n’est pas nécessaire de désactiver AEM pour exécuter l’outil.

Le contrôle de l’intégrité du nettoyage des révisions est intégré au Tableau de bord des opérations.

L’état est VERT si la dernière exécution de la tâche de maintenance du nettoyage des révisions en ligne s’est terminée avec succès.

Il s’agit de JAUNE si la tâche de maintenance du nettoyage des révisions en ligne a été annulée une fois.

Il s’agit de RED si la tâche de maintenance du nettoyage des révisions en ligne a été annulée trois fois de suite. Dans ce cas, une interaction manuelle est nécessaire ou le nettoyage des révisions en ligne va probablement continuer à échouer. Pour plus d’informations, reportez-vous à la section Dépannage ci-dessous.

En outre, l’état du contrôle de l’intégrité est réinitialisé après un redémarrage du système. Ainsi, une instance redémarrée récemment affiche un état vert sur le contrôle de l’intégrité du nettoyage des révisions. Des outils de surveillance externes peuvent être utilisés pour conserver les données au-delà du temps de disponibilité AEM. Consultez la documentation AEM pour joindre les vérifications d’intégrité à Nagios en tant qu’exemple d’outil de surveillance externe.

Comment surveiller le nettoyage automatique sur une instance secondaire ?

L’état, la progression et les statistiques sont présentés via JMX à l’aide de la variable SegmentRevisionGarbageCollection MBean. Consultez également la Documentation Oak qui suit.

Vous pouvez obtenir une référence du MBean à l’aide de ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

Les statistiques ne sont disponibles que depuis le dernier démarrage du système. Des outils de surveillance externes peuvent être utilisés pour conserver les données au-delà du temps de disponibilité AEM. Consultez également la documentation AEM pour joindre les contrôles d’intégrité à Nagios en tant qu’exemple d’outil de surveillance externe.

Les fichiers journaux peuvent également être utilisés pour vérifier l’état, la progression et les statistiques du nettoyage automatique.

Que doit-on surveiller pendant le nettoyage automatique sur une instance de secours ?

• L’espace disque doit être surveillé lors de l’exécution du nettoyage automatique.
• Le délai d’exécution (via les journaux) pour vous assurer que 2 heures ne sont pas dépassées.
• La taille de l’entrepôt de segments après l’exécution du nettoyage automatique. La taille de l’entrepôt de segments sur l’instance de secours doit être à peu près le même que celle de l’instance principale.

• Tout d’abord, vérifiez les entrées du journal.
  
• Selon les informations contenues dans les journaux, prenez les mesures appropriées :
  • Si les journaux montrent cinq cycles de compression ratés ainsi qu’un long délai du cycle forceCompact, programmez une fenêtre de maintenance pendant une période calme durant laquelle la quantité d’écriture du référentiel est faible. Vous pouvez vérifier les écritures du référentiel dans l’outil de surveillance des mesures du référentiel à l’adresse https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
  • Si le nettoyage s’est arrêté à la fin de la fenêtre de maintenance, assurez-vous que la configuration de la fenêtre de maintenance dans l’interface utilisateur Tâches de maintenance est suffisamment grande.
  • Si la mémoire de tas disponible n’est pas suffisante, vérifiez que l’instance dispose de suffisamment de mémoire.
  • En cas de réaction tardive, l’entrepôt de segments risque d’augmenter trop pour que le nettoyage des révisions en ligne soit terminé, même dans une fenêtre de maintenance plus longue. Par exemple, si aucun nettoyage des révisions en ligne n’a réussi au cours de la dernière semaine, il est recommandé de planifier une maintenance hors ligne et d’exécuter le nettoyage des révisions hors ligne pour ramener le magasin de segments à une taille gérable.

A SegmentNotFoundException est consigné par le TarMK lorsqu’il tente d’accéder à une unité de stockage (un segment) qu’il ne parvient pas à trouver. Trois scénarios peuvent provoquer ce problème :

1. Application qui contourne les mécanismes d’accès recommandés (tels que Sling et l’API JCR) et utilise une API/SPI de niveau inférieur pour accéder au référentiel, puis dépasse la durée de conservation d’un segment. En d’autres termes, elle conserve une référence à une entité plus longue que la durée de conservation autorisée par le nettoyage des révisions en ligne (24 heures par défaut). Ce cas est transitoire et ne conduit pas à la corruption des données. Pour effectuer une restauration, l’outil exécuté par Oak doit être utilisé pour confirmer la nature transitoire de l’exception (la vérification exécutée par Oak ne doit signaler aucune erreur). Pour ce faire, l’instance doit être mise hors ligne et redémarrée par la suite.
2. Un événement externe a provoqué la corruption des données sur le disque. Il peut s’agir d’une défaillance du disque, d’un manque d’espace disque ou d’une modification accidentelle des fichiers de données requis. Dans ce cas, l’instance doit être mise hors ligne et réparée à l’aide de la vérification oak-run. Pour plus d’informations sur la façon de procéder à la vérification exécutée par Oak, lisez la documentation Apache suivante.
3. Résolvez toutes les autres occurrences par l’intermédiaire de la variable Adobe de l’assistance clientèle.

La taille du référentiel et le nombre de révisions à nettoyer déterminent la durée du nettoyage.

• Révision Oak : Oak organise tout le contenu dans une grande hiérarchie d’arborescence qui se compose de nœuds et de propriétés. Chaque instantané ou révision de cette arborescence de contenu est immuable et les modifications apportées à l’arborescence sont exprimées sous la forme d’une séquence de nouvelles révisions. En règle générale, chaque modification de contenu déclenche une nouvelle révision. Consultez également le Lien de suivi.
• Version de page : le contrôle de version crée un « instantané » d’une page à un moment spécifique dans le temps. En règle générale, une nouvelle version est créée lorsqu’une page est activée. Pour plus d’informations, consultez la section Utilisation des versions de page.