Nettoyage de révision

Le format de persistance de TarMK change avec AEM 6.5. Ces modifications ne nécessitent aucune étape de migration proactive. Les référentiels existants font l’objet d’une migration progressive, un processus totalement transparent 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 initiée, le référentiel ne peut plus être rétabli au format de persistance AEM 6.3 précédent.

Dans AEM 6.3, des changements au format de l'enregistrement étaient nécessaires, en particulier pour améliorer le rendement et l'efficacité du nettoyage de la révision en ligne. Ces modifications ne sont pas rétrocompatibles, et les référentiels créés avec l’ancien Oak Segment (AEM 6.2 et versions antérieures) doivent être migrés.

Autres avantages liés au changement de format du stockage :

• Meilleure évolutivité (taille de segment optimisée).
• Nettoyage plus rapide de la mémoire d’entrepôt de données.
  
• Travail de base pour les prochaines améliorations.

Alors que le nettoyage des révisions en ligne récupère les deux dernières générations, le processus hors ligne ne récupère que la dernière génération. Dans le cas d’un tout nouveau référentiel, le nettoyage en ligne ne récupère aucun espace lorsqu’il est exécuté pour la première fois après le nettoyage hors ligne, car il n’y a 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 ce chapitre.

Le nettoyage de la révision en ligne est disponible uniquement avec AEM versions 6.3 et ultérieures. Aussi, si vous utilisez une ancienne version d’AEM, vous devrez effectuer une migration vers le nouvel Oak Segment Tar.

• Taille du référentiel
• Charge sur le système (demandes par minute, surtout les 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 passe en dessous d’une certaine valeur, le processus est annulé. La valeur critique par défaut est de 25 % de l’encombrement sur le disque du référentiel, et elle n’est pas configurable.

Il est recommandé d’opter pour une taille de disque au moins deux à trois fois supérieure à celle estimée initialement pour le référentiel.

L’espace de tas libre est surveillé en permanence lors du processus de nettoyage. Si l’espace de tas disponible passe en dessous d’une certaine valeur, 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 sur le dimensionnement du tas de compression minimal ne sont pas séparées des recommandations sur le dimensionnement de la mémoire AEM. En règle générale : si une instance AEM est suffisamment bien dimensionnée pour gérer les cas d’utilisation et la charge utile attendue, le processus de nettoyage obtiendra suffisamment de mémoire.

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

Le nettoyage des révisions requiert une phase d’estimation pour décider s’il y a suffisamment de contenu inutilisé à nettoyer. L’estimateur compare la taille actuelle à la taille du référentiel après la dernière compression. Si la taille dépasse le delta configuré, le nettoyage sera effectué. Le delta de taille est défini à 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 de révision sera ignorée.

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

• Révision Le GC sera exécuté : Le delta de taille est N% ou N/N (octets N/N), donc l'exécution de compaction
• Le GC de révision sera non exécuté : Le delta de taille est N% ou N/N (octets N/N), de sorte que la compaction est ignorée 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 passe en mode forceCompact, comme expliqué plus en détail dans la documentation sur le chêne. Pendant la compression forcée, un dispositif exclusif de verrouillage de l’écriture est acquis pour effectuer les modifications sans aucune écriture simultanée perturbatrice. Pour limiter l’impact sur les délais de réponse, une valeur de délai d’expiration peut être définie. Cette valeur est définie sur 1 minute par défaut, ce qui signifie que si la compression en force ne se termine pas dans un délai d’une minute, le processus de compression sera interrompu au profit d’autres commits simultanés.

La durée du pacte de force dépend des facteurs suivants :

• matériel : spécifiquement IOPS. La durée décroît lorsqu’il y a plus d’IOPS.
• taille de l’entrepôt de segments : la durée augmente en fonction de la taille de l’entrepôt 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 Secondaire est le nettoyage automatique, ce qui correspond à la phase de nettoyage de la révision en ligne. Le nettoyage automatique est exécuté sur l’instance de secours après l’exécution du nettoyage des révisions en ligne sur l’instance principale.

Les phase de compression et d’estimation ne sont pas exécutées sur l’instance de secours.

Le nettoyage des révisions hors ligne peut supprimer instantanément les anciennes révisions, alors que le nettoyage des révisions en ligne doit tenir compte des anciennes révisions qui sont toujours référencées par la pile de l’application. Le premier peut donc supprimer les résidus de manière plus agressive que le second, où l’effet est amortit au bout 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 ce chapitre.

• Sur les environnements Windows, l’accès régulier aux fichiers est toujours appliqué, de sorte que l’accès mappé à la mémoire n’est pas utilisé. En règle générale, toute la RAM disponible doit être allouée au tas et la taille de segmentCache doit être augmentée. Vous augmentez le segmentCache en ajoutant 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 non Windows, augmentez la taille de la mémoire physique pour améliorer le mappage de mémoire du référentiel.

• L'espace disque doit être surveillé lorsque le nettoyage de révision en ligne est activé. S’il n’y a pas sufisamment d’espace disque, soit le processus de nettoyage ne sera pas lancé, ou il sera arrêté de manière préventive.
• 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 contôle durant l’exécution de la compression, il est recommandé de nettoyer les points de contôle.

Vous pouvez vérifier si le nettoyage de la révision en ligne s'est terminé correctement en vérifiant les journaux.

Par exemple, "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" signifie l’étape de compactage terminée avec succès, sauf si elle est précédée du message "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", ce qui signifie qu’il y a eu trop de charges simultanées.

En conséquence, un message "TarMK GC #{}: cleanup completed in {} ({} ms" indique que l’étape de nettoyage a été terminée avec succès.

Le statut, les progrès et les statistiques sont exposés via JMX (SegmentRevisionGarbageCollection MBean). Pour plus d'informations sur le SegmentRevisionGarbageCollection MBean, consultez le paragraphe suivant.

L'avancement peut être suivi via l'attribut EstimatedRevisionGCCompletion de la variable SegmentRevisionGarbageCollection MBean.

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”.

N’oubliez pas que les statistiques sont dospnibles uniquement avec le dernier démarrage de système. L’outil de surveillance externe peut être utilisé pour conserver les données au-delà de la disponibilité d’AEM. Voir la documentation AEM pour l'attachement des contrôles d'intégrité à Nagios comme exemple pour un outil de surveillance externe.

• Le nettoyage de la révision en ligne a démarré / arrêté
  • Le nettoyage de la révision en ligne se compose de trois phases : estimation, compaction et nettoyage. La phase d’estimation peut forcer l’omission des phases de compression et de nettoyager si le référentiel ne contient pas suffisament de résidus. Dans la dernière version de AEM, le message "TarMK GC #{}: estimation started" marque le début de l'estimation, "TarMK GC #{}: compaction started, strategy={}" marque le début de compaction et "TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes" le début de nettoyage.
• Espace disque gagné par le nettoyage de la révision
  • L'espace n'est récupéré que lorsque la phase de nettoyage est terminée. L'achèvement de la phase de nettoyage est marqué par le message du journal "TarMK GC #{}: cleanup completed in {} ({} ms". La dimension 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 lors du nettoyage de la révision
  • Il y a de nombreuses conditions d'échec, toutes sont marquées par des messages de journal WARN ou ERROR commençant par "TarMK GC".

Consultez également la section Résolution des problèmes en fonction des 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 de la révision en ligne.

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

• Référentiel vérification de la traversée
• Utilisez l'outil d'exécution de chêne une fois le processus de nettoyage terminé pour vérifier les incohérences. Pour plus d’informations sur la façon de procéder, consultez la documentation Apache. Vous n'avez pas besoin de fermer AEM pour exécuter l'outil.

Le contrôle d'intégrité du nettoyage de la révision fait partie du Tableau de bord d'exploitation .

L'état est VERT si la dernière exécution de la tâche de maintenance de nettoyage de révision en ligne est terminée.

Il sera JAUNE si la tâche de maintenance de nettoyage de révision en ligne a été annulée une fois.

Il sera RED si la tâche de maintenance de nettoyage de révision en ligne a été annulée trois fois de suite. Dans ce cas, une interaction manuelle est nécessaire ou le nettoyage de la révision en ligne est susceptible d'échouer à nouveau. Pour plus d'informations, consultez la section Dépannage ci-dessous.

Veuillez aussi noter que l’état de la vérification de l’intégrité sera réinitialisé après le redémarrage du système. Par conséquent, une instance fraîchement redémarrée affiche un état vert sur la vérification d’intégrité du nettoyage des révisions. L’outil de surveillance externe peut être utilisé pour conserver les données au-delà de la disponibilité d’AEM. Voir la documentation AEM pour l'attachement des contrôles d'intégrité à Nagios comme exemple pour un outil de surveillance externe.

Comment surveiller le nettoyage automatique sur une instance Secondaire ?

Le statut, les progrès et les statistiques sont exposés via JMX en utilisant le SegmentRevisionGarbageCollection MBean. Voir aussi la documentation sur les chênes suivante.

Vous pouvez obtenir une référence du MBean en utilisant ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”.

Notez que les statistiques sont disponibles uniquement à partir du dernier démarrage du système. L’outil de surveillance externe peut être utilisé pour conserver les données au-delà de la disponibilité d’AEM. Voir aussi la documentation AEM pour l'attachement des contrôles d'intégrité à Nagios comme exemple d'outil de surveillance externe.

Les fichiers de journal peuvent aussi être utilisés pour vérifier l’état, le progrès et les statistiques du nettoyage automatique.

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

• 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.
• Taille de la banque 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.
  
• En fonction des informations contenues dans les journaux, prenez une mesure appropriée :
  • Si les journaux indiquent cinq cycles compacts manqués et un dépassement de délai sur le cycle forceCompact, programmez la fenêtre de maintenance à un moment calme lorsque la quantité d'écritures 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 situé à l’adresse https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html.
  • Si le nettoyage 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 des tâches de maintenance est suffisamment volumineuse.
  • Si la mémoire disponible est insuffisante, assurez-vous que l’instance contienne suffisament de mémoire.
  • En cas de délai de réponse, l’entrepôt de segments peut augmenter de façon excessive au point où il devient impossible d’effectuer un nettoyage des révisions en ligne, même avec 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’effectuer le nettoyage des révisions hors ligne en vue de convertir la taille de l’entrepôt de segments à une dimension plus gérable.

Un SegmentNotFoundException est consigné par le TarMK lorsqu'il tente d'accéder à une unité d'enregistrement (un segment) qu'il ne trouve pas. Il existe trois scénarios pouvant causer ce problème :

1. Une application qui contourne les systèmes d’accès recommandés (comme Sling et l’API JCR) et utilise un niveau API/SPI plus bas pour accéder au référentiel, puis dépasse la période de validité d’un segment. En d’autres termes, il conserve une référence à une entité plus longue que la durée de rétention octroyé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 récupérer, l'outil d'exécution de chêne doit être utilisé pour confirmer la nature transitoire de l'exception (la vérification d'exécution de chêne ne doit pas signaler d'erreurs). Pour ce faire, l’instance doit être mise hors ligne et redémarrée ensuite.
2. Un événement externe a causé la corruption des données sur le disque. Il peut s’agir d’une panne du disque, d’un espace disque saturé ou d’une modification accidentelle des fichiers de données requis. Dans ce cas, une instance doit être déconnectée et réparée avec la vérification exécutée par Oak. Pour plus d'informations sur la façon d'effectuer la vérification de l'exécution du chêne, consultez la documentation Apache suivante.
3. Toutes les autres occurrences doivent être traitées par le service à la clientèle Adobe.

La taille du référentiel et la quantité de révisions devant être nettoyées déterminent la durée du nettoyage.

• Révision en chêne : Oak organise tout le contenu dans une grande arborescence composée de noeuds et de propriétés. Chaque aperçu ou révision de cet ensemble de contenus inaltérables, ainsi que les modifications de l’arborescence sont indiqués sous forme de séquence de nouvelles révisions. En règle générale, chaque modification de contenu déclenche une nouvelle révision. Voir aussi Suivre le lien.
• Version de la page : le contrôle de version crée un "instantané" d’une page à un moment donné. En règle générale, une nouvelle version est créée lorsqu’une page est activée. Pour plus d’informations, voir Utilisation des versions de page.