Exécuter AEM avec TarMK Cold Standby

Présentation

La fonction Cold Standby du micronoyau Tar permet à une ou plusieurs instances AEM de secours de se connecter à une instance principale. Le processus de synchronisation est à sens unique, c’est à dire qu’il s’exécute de l’instance principale aux instances de secours.

Le but des instances de secours est de garantir une copie des données en direct du référentiel principal et de garantir un basculement rapide sans perte de données si le référentiel principal n’est plus disponible pour une raison quelconque.

Le contenu est synchronisé de façon linéaire entre une instance principale et les instances de secours, sans aucune vérification de l’intégrité pour la corruption de fichier ou du référentiel. En raison de cette conception, les instances de secours sont des copies exactes de l’instance principale et ne peuvent pas limiter les incohérences des instances principales.

Fonctionnement

Sur l’instance AEM principale, un port TCP s’ouvre pour écouter les messages entrants. Actuellement, il existe deux types de messages que les esclaves envoient au maître :

• Un message demandant l’ID de segment de l’en-tête actuelle
• Un message demandant les données de segment avec un ID spécifié

L’instance de secours demande de manière périodique l’ID de segment de l’en-tête actuelle de l’instance principale. Si le segment est inconnu au niveau local, il est récupéré. S’il est déjà présent, les segments sont comparés et les segments référencés sont également demandés, si nécessaire.

Un déploiement classique du processus TarMK Cold Standby :

Autres fonctionnalités

Robustesse

Le flux de données est conçu pour détecter et traiter automatiquement la connexion et les problèmes liés au réseau. Tous les modules sont regroupés avec des sommes de contrôle. Dès que vous rencontrez des problèmes liés à la connexion ou des modules endommagés, des mécanismes enclenchent de nouvelles tentatives.

Performance

L’activation du processus TarMK Cold Standby sur l’instance principale n’a presque aucun impact mesurable sur les performances. La consommation supplémentaire de processeur est très faible et le disque dur et le réseau E/S supplémentaires ne doivent pas poser de problème de performance.

Sur les instances de secours, attendez-vous à un niveau élevé de consommation de processeur pendant le processus de synchronisation. Comme la procédure ne comporte pas plusieurs threads, on ne peut pas l’accélérer en utilisant plusieurs cœurs. Si aucune donnée n’est modifiée ni transférée il n’y aura aucune activité mesurables. La vitesse de connexion varie selon l’environnement matériel et réseau, mais elle ne dépend pas de la taille du référentiel ou de l’utilisation SSL. Gardez cela à l’esprit lorsque vous évaluez le temps nécessaire pour la synchronisation initiale ou lorsque de nombreuses données ont été modifiées entre-temps sur le nœud principal.

Sécurité

En supposant que toutes les instances s’exécutent dans la même zone de sécurité intranet, le risque d’une violation de la sécurité est considérablement réduit. Toutefois, vous pouvez ajouter une couche supplémentaire de sécurité en activant les connexions SSL entre les esclaves et le maître. Cela réduit le risque de compromission des données par un intermédiaire.

En outre, vous pouvez spécifier les instances de secours qui sont autorisées à se connecter en limitant l’adresse IP des requêtes entrantes. Cela devrait garantit que personne au sein de l’intranet ne peut copier le référentiel.

Création d’une configuration AEM TarMK Cold Standby

Pour créer une configuration TarMK Cold Standby, vous devez d’abord créer des instances de secours en effectuant une copie du système de fichiers du dossier d’installation complet de l’instance principale vers un nouvel emplacement. Vous pouvez ensuite démarrer chaque instance avec un mode d’exécution spécifiant son rôle (primary ou standby).

Consultez ci-dessous la procédure devant être suivie afin de créer une installation avec une instance principale et une instance de secours :

1. Installez AEM.

2. Fermez votre instance, puis copiez son dossier d’installation à l’emplacement où l’instance Cold Standby sera exécutée. Même si l’exécution s’effectue à partir de différents ordinateurs, veillez à donner à chaque dossier un nom descriptif (comme aem-principal ou aem-de-secours) pour différencier les instances.

3. Accédez au dossier d’installation de l’instance principale puis :

   1. Vérifiez et supprimez toutes les configurations OSGi précédentes qui pourraient être répertoriées sous aem-primary/crx-quickstart/install.

   2. Créez un fichier appelé install.primary sous aem-primary/crx-quickstart/install.

   3. Créez les configurations requises pour le magasin de nœuds et l’entrepôt de données de votre choix sous aem-primary/crx-quickstart/install/install.primary.

   4. Créez un fichier nommé org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config au même emplacement et configurez-le conformément aux exigences. Pour plus d’informations sur les options de configuration, consultez la section Configuration.

   5. Si vous utilisez une instance AEM TarMK avec magasin de données externe, créez un dossier nommé crx3 sous aem-primary/crx-quickstart/install, nommé crx3.

   6. Placez le fichier de configuration du magasin de données dans le dossier crx3.

   Par exemple, si vous exécutez une instance AEM TarMK avec un magasin de données de fichiers externe, vous aurez besoin de ces fichiers de configuration :

   • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
   • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
   • aem-primary/crx-quickstart/install/crx3/org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

   Vous trouverez ci-dessous des exemples de configuration pour une instance principale :

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

   org.apache.sling.installer.configuration.persist=B"false"
   customBlobStore=B"true"
   standby=B"false"
   

   Exemple de org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

   org.apache.sling.installer.configuration.persist=B"false"
   mode="primary"
   port=I"8023"
   

   Exemple de org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

   org.apache.sling.installer.configuration.persist=B"false"
   path="./crx-quickstart/repository/datastore"
   minRecordLength=I"16384"
   

4. Démarrez l’instance principale en veillant à spécifier le mode d’exécution principal :

   java -jar quickstart.jar -r primary,crx3,crx3tar
   

5. Créez un enregistreur de journalisation Apache Sling pour module org.apache.jackrabbit.oak.segment.. Définissez le niveau du journal sur « Déboguer », puis orientez la sortie du journal vers un fichier journal distinct, tel que /logs/tarmk-coldstandby.log. Pour plus d’informations, consultez la section Journalisation.

6. Accédez à l’emplacement de l’instance de secours et démarrez-la en exécutant le fichier jar.

7. Créez la même configuration de journalisation que pour l’instance principale. Ensuite, arrêtez l’instance.

8. Préparez l’instance de secours. Vous pouvez le faire en suivant le même processus que pour l’instance principale :

   1. Supprimez tous les fichiers que vous pouvez avoir sous aem-standby/crx-quickstart/install.

   2. Créez un dossier nommé install.standby sous aem-standby/crx-quickstart/install.

   3. Créez deux fichiers de configuration nommés :

      • org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
      • org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

   4. Créez dossier nommé crx3 sous aem-standby/crx-quickstart/install

   5. Créer une configuration de magasin de données et placez-la sous aem-standby/crx-quickstart/install/crx3. Dans cet exemple, le fichier que vous devez créer est :

      • org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

   6. Modifiez les fichiers et créez les configurations nécessaires.

   Vous trouverez ci-dessous des exemples fichiers de configuration pour une instance de secours standard :

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

   org.apache.sling.installer.configuration.persist=B"false"
   name="Oak-Tar"
   service.ranking=I"100"
   standby=B"true"
   customBlobStore=B"true"
   

   Exemple de org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

   org.apache.sling.installer.configuration.persist=B"false"
   mode="standby"
   primary.host="127.0.0.1"
   port=I"8023"
   secure=B"false"
   interval=I"5"
   standby.autoclean=B"true"
   

   Exemple de org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

   org.apache.sling.installer.configuration.persist=B"false"
   path="./crx-quickstart/repository/datastore"
   minRecordLength=I"16384"
   

9. Démarrez l’instance de secours à l’aide du mode d’exécution de secours :

   java -jar quickstart.jar -r standby,crx3,crx3tar
   

Le service peut également être configuré par le biais de la console web, comme suit :

1. Accédez à la console web : https://serveraddress:serverport/system/console/configMgr.
2. Recherchez un service nommé Service Apache Jackrabbit Oak de reprise progressive des segments Tar et cliquez deux fois dessus pour modifier les paramètres.
3. Enregistrez les paramètres et redémarrez les instances pour que les nouveaux paramètres puissent prendre effet.

Première synchronisation

Une fois que la préparation est complète et que l’instance de secours démarre pour la première fois, attendez-vous à un trafic de réseau élevé entre les instances, le temps que l’instance de secours se mette au niveau de l’instance principale. Vous pouvez consulter les journaux pour contrôler l’état de la synchronisation.

Sur l’instance de secours tarmk-coldstandby.log, vous verrez des entrées de ce type :

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore trying to read segment ec1f739c-0e3c-41b8-be2e-5417efc05266

    *DEBUG* [nioEventLoopGroup-3-1] org.apache.jackrabbit.oak.segment.standby.codec.SegmentDecoder received type 1 with id ec1f739c-0e3c-41b8-be2e-5417efc05266 and size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore got segment ec1f739c-0e3c-41b8-be2e-5417efc05266 with size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment ec1f739c-0e3c-41b8-be2e-5417efc05266 to /mnt/crx/author/crx-quickstart/repository/segmentstore/data00016a.tar

Dans le fichier error.log de l’instance de secours, vous devez voir une entrée de ce type :

*INFO* [FelixStartLevel] org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService started standby sync with 10.20.30.40:8023 at 5 sec.

Dans l’extrait de journal ci-dessus, 10.20.30.40 est l’adresse IP de l’instance principale.

Sur l’instance principale tarmk-coldstandby.log, vous verrez des entrées de ce type :

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver got message ‘s.d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd’ from client c7a7ce9b-1e16-488a-976e-627100ddd8cd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler request segment id d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler sending segment d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd to /10.20.30.40:34998

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver did send segment with 262144 bytes to client c7a7ce9b-1e16-488a-976e-627100ddd8cd

Dans ce cas, le « client » mentionné dans le journal est l’instance de secours.

Une fois que ces entrées cessent de s’afficher dans le journal, sachez que le processus de synchronisation est terminé.

Bien que les entrées ci-dessus indiquent que le mécanisme d’interrogation fonctionne correctement, il est souvent utile d’identifier s’il existe bien des données en cours de synchronisation pendant que le processus d’interrogation a lieu. Pour ce faire, recherchez les entrées comme suit :

*DEBUG* [defaultEventExecutorGroup-156-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment 3a03fafc-d1f9-4a8f-a67a-d0849d5a36d5 to /<<CQROOTDIRECTORY>>/crx-quickstart/repository/segmentstore/data00014a.tar

De même, lorsque l’exécution a lieu avec un fichier FileDataStore non partagé, des messages comme celui-ci confirmeront que les fichiers binaires sont correctement transmis :

*DEBUG* [nioEventLoopGroup-228-1] org.apache.jackrabbit.oak.segment.standby.codec.ReplyDecoder received blob with id eb26faeaca7f6f5b636f0ececc592f1fd97ea1a9#169102 and size 169102

Configuration

Les paramètres OSGi suivants sont disponibles pour le service Cold Standby :

• Continuer la configuration : si ce paramètre est activé, la configuration est stockée dans le référentiel plutôt que les fichiers de configuration OSGi traditionnels. Il est recommandé de garder ce paramètre désactivé sur des systèmes d’exploitation afin que la configuration principale ne soit pas effectuée par l’instance de secours.

• Mode (mode) : permet de sélectionner le mode d’exécution d’une instance.

• Port (port) : le port à utiliser pour la communication. La valeur par défaut est 8023.

• Hôte principal (primary.host) : l’hôte de l’instance principale. Ce paramètre s’applique uniquement à l’instance de secours.

• Intervalle de synchronisation (interval) : ce paramètre détermine l’intervalle entre la requête de synchronisation et s’applique uniquement à l’instance de secours.

• Plages IP autorisées (primary.allowed-client-ip-ranges) : plages IP sur lesquelles l’instance principale autorisera la connexion.

• **Sécuriser (secure) ** : active le chiffrement SSL. Pour que ce paramètre fonctionne, il doit être activé sur toutes les instances.

• Délai d’expiration de lecture Standby (standby.readtimeout) : délai d’expiration pour les demandes provenant de l’instance de secours, en millisecondes. La valeur par défaut utilisée est de 60 000 (une minute).

• Nettoyage automatique de secours (standby.autoclean) : appelez cette méthode de nettoyage si la taille du magasin augmente lors d’un cycle de synchronisation…

Procédures de basculement

Si l’instance principale échoue, vous pouvez choisir l’une des instances de secours pour la remplacer, en modifiant le mode d’exécution de lancement, tel qu’expliqué ci-après :

1. Accédez à l’emplacement de l’instance de secours sur votre ordinateur et arrêtez-la.

2. Si vous avez configuré un équilibreur de charge, vous pouvez supprimer l’instance principale à partir de la configuration de l’équilibreur de charge.

3. Sauvegardez le dossier crx-quickstart depuis le dossier d’installation de secours. Cela peut être utilisé comme point de départ lors de la configuration d’une nouvelle instance de secours.

4. Redémarrez l’instance à l’aide du mode d’exécution primary :

   java -jar quickstart.jar -r primary,crx3,crx3tar
   

5. Ajoutez une nouvelle instance principale à l’équilibreur de charge.

6. Créez et lancez une instance de secours. Pour plus d’informations, reportez-vous à la procédure ci-dessus de la section Création d’une configuration AEM TarMK Cold Standby.

Application de correctifs à une configuration Cold Standby

La méthode recommandée pour appliquer des correctifs à une configuration Cold Stanbdy consiste à les installer sur l’instance principale, puis à la copier dans une nouvelle instance Cold Standby avec les correctifs installés.

Vous pouvez le faire en suivant les étapes décrites ci-dessous :

1. Arrêtez le processus de synchronisation sur l’instance Cold Standby en accédant à la console JMX et en utilisant le bean org.apache.jackrabbit.oak: Status ("Standby"). Pour plus d’informations sur la façon de procéder, reportez-vous à la section Surveillance.
2. Arrêtez l’instance Cold Standby.
3. Installez le correctif sur l’instance principale. Pour plus d’informations sur la façon d’installer un correctif, consultez la section Fonctionnement des modules.
4. Après l’installation, vérifiez si les problèmes persistent sur l’instance.
5. Supprimez l’instance Cold Standby en supprimant son dossier d’installation.
6. Arrêtez l’instance principal et clonez-la en copiant le système de fichiers de son dossier d’installation complet à l’emplacement de Cold Standby.
7. Reconfigurez le clone nouvellement créé pour qu’il se comporte comme une instance Cold Standby. Pour plus de détails, voir Création d’une configuration AEM TarMK Cold Standby.
8. Démarrez les instances principale et de secours.

Surveillance

La fonction affiche les informations à l’aide de JMX ou des MBeans. Cela vous permet d’analyser l’état actuel de l’instance de secours et du maitre à l’aide de la console JMX. Ces informations se trouvent dans un MBean de type org.apache.jackrabbit.oak:type="Standby" nommé Status.

Instance de secours

L’observation d’une instance de secours vous permet d’identifier un nœud. L’ID est généralement un UUID générique.

Ce nœud possède cinq attributs en lecture seule :

• Running: valeur booléenne indiquant si le processus de synchronisation fonctionne.

• Mode: client : suivi des UUID utilisés pour identifier une instance. Notez que cet UUID change chaque fois que la configuration est mise à jour.

• Status: représentation textuelle du statut actuel (par exemple running ou stopped).

• FailedRequests: le nombre d’erreurs consécutives.

• SecondsSinceLastSuccess: nombre de secondes depuis la dernière communication réussie avec le serveur. La valeur -1 s’affiche si aucune communication n’a réussie.

Il existe également trois méthodes invocables :

• start(): lance le processus de synchronisation.
• stop(): arrête le processus de synchronisation.
• cleanup(): exécute l’opération de nettoyage de l’instance de secours.

Instance principale

L’observation de l’instance principale permet d’identifer certaines informations générales via un MBean dont la valeur ID correspond au numéro de port que le service de secours TarMK utilise (8023 par défaut). La plupart des méthodes et des attributs sont les mêmes que pour l’instance de secours, mais certains diffèrent :

• Mode: affiche toujours la valeur primary.

Des informations supplémentaires pour jusqu’à 10 clients (instances de secours) connectés au maître peuvent être récupérées. L’ID du MBean est l’UUID de l’instance. Il n’existe pas de méthode invocable pour ces MBeans, mais certains attributs en lecture seule très utiles :

• Name: l’ID du client.
• LastSeenTimestamp: l’horodatage de la dernière demande dans une représentation textuelle.
• LastRequest: la dernière demande du client.
• RemoteAddress: l’adresse IP du client.
• RemotePort: le port que le client a utilisé pour la dernière demande.
• TransferredSegments: le nombre total de segments transférés à ce client.
• TransferredSegmentBytes: le nombre total d’octets transférés à ce client.

Maintenance du référentiel Cold Standby

Nettoyage de révision

Adobe recommande d’exécuter une maintenance régulière pour éviter l’augmentation excessive de référentiel au fil du temps. Pour exécuter manuellement la maintenance du référentiel Cold Standby, procédez comme suit :

1. Arrêtez le processus secondaire sur l’instance secondaire en accédant à la console JMX et en utilisant le bean org.apache.jackrabbit.oak: Status ("Standby"). Pour plus d’informations sur cette procédure, reportez-vous à la section Surveillance ci-dessous.

2. Arrêtez l’instance principale AEM.

3. Exécutez l’outil de compression Oak sur l’instance principale. Pour plus d’informations, consultez la section Maintenance du référentiel.

4. Démarrez l’instance principale.

5. Lancez le processus de secours sur l’instance de secours à l’aide du bean JMX décrit dans la première étape.

6. Observez les journaux et attendez la fin de la synchronisation. Il se peut qu’une augmentation substantielle au niveau du référentiel de secours se produise à ce moment-là.

7. Exécutez l’opération cleanup() sur l’instance de secours, en utilisant le bean JMX décrit dans la première étape.

Il se peut que la synchronisation de l’instance de secours avec l’instance principale prenne plus de temps que prévu, car la compression hors ligne consiste à réécrire l’historique du référentiel, augmentant ainsi substantiellement le temps de calcul des modifications du référentiel. Notez également qu’une fois ce processus terminé, le référentiel sur l’instance de secours aura approximativement la même taille que le référentiel sur l’instance principale.

Comme alternative, le référentiel principal peut être copié manuellement sur l’instance de secours après l’exécution de la compression sur l’instance principale. L’instance de secours est ainsi reconstituée à chaque compression.

Récupérer de l’espace mémoire du magasin de données

Il est important d’exécuter de temps en temps le nettoyage de la mémoire sur les instances du magasin de données des fichiers. Autrement, les fichiers binaires supprimés resteront sur le système de fichiers, ce qui contribue à surcharger le lecteur. Pour lancer la récupération de l’espace mémoire, suivez la procédure ci-dessous :

1. Exécutez le processus de maintenance du référentiel Cold Standby, comme expliqué dans la section ci-dessus.

2. Une fois le processus de maintenance terminé et les instances relancées, procédez comme suit :

   • Sur l’instance principale, exécutez le nettoyage de la mémoire du magasin de données via le bean JMX approprié, tel que décrit dans cet article.
   • Sur l’instance de secours, le nettoyage de la mémoire du magasin de données est uniquement disponible via le MBean BlobGarbageCollection - startBlobGC(). Le RepositoryManagement MBean n’est pas disponible sur l’instance de secours.
   REMARQUE

   Si vous n’utilisez pas de magasin de données partagé, le nettoyage de la mémoire doit d’abord être exécuté sur l’instance principale, puis sur l’instance de secours.

Ressources Business.Adobe.com

Style System Targeted Content Personalized Experiences Content As A Service Web Content Management Digital Asset Management