Show Menu
SUJETS×

Exécution d’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.
La fonction Cold Standby permet de sécuriser les scénarios dans lesquels un niveau de disponibilité élevé est requis pour les instances d’ auteur . Pour les situations où un niveau de disponibilité élevé est requis sur les instances de publication à l’aide du micronoyau Tar, Adobe recommande d’utiliser une ferme de publication.
Pour plus d’informations sur les déploiements disponibles, consultez la page Déploiements recommandés .

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.
Les instances de secours ne reçoivent aucun type de requête, car elles fonctionnent uniquement en mode de synchronisation. La seule section disponible sur une instance de secours est la console web, afin de faciliter le regroupement et la configuration des services.
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.

Les performances

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.
Il est recommandé d’ajouter un équilibreur de charge entre le dispatcher et les serveurs qui font partie de la configuration Coldy Standby. L’équilibreur de charge doit être configuré pour diriger le trafic des utilisateurs uniquement vers l’instance principale , pour assurer la régularité et empêcher la copie du contenu sur l’instance de secours par des moyens autres que le mécanisme Cold Standby.

Création d’une configuration AEM TarMK Cold Standby

Le PID de la boutique de nœuds de segment et le service de stockage Standby a changé dans AEM 6.3 par rapport aux versions précédentes :
  • de org.apache.jackrabbit.oak. plugins .segment.standby.store.StandbyStoreService vers org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService
  • de org.apache.jackrabbit.oak. plugins .segment.SegmentNodeStoreService vers org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
Assurez-vous d’effectuer les réglages de configuration nécessaires pour refléter ces modifications.
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. You can then start each instance with a runmode that will specify its role ( primary or standby ).
Consultez ci-dessous la procédure devant être suivie afin de créer une installation avec un maître et une instance de secours :
  1. Installer 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. Check and delete any preivous OSGi configurations you might have under aem-primary/crx-quickstart/install
    2. Create a folder called install.primary under aem-primary/crx-quickstart/install
    3. Create the required configurations for the prefered node store and data store under 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, voir Configuration .
    5. If you are using an AEM TarMK instance with an external data store, create a folder named crx3 under aem-primary/crx-quickstart/install named crx3
    6. Placez le fichier de configuration de l’entrepôt de données dans le dossier crx3 . Par exemple, si vous exécutez une instance AEM TarMK avec un entrepôt 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 deorg.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, voir 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. Delete any files you might have under aem-standby/crx-quickstart/install .
    2. Create a new folder called install.standby under 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. Create a new folder called crx3 under aem-standby/crx-quickstart/install
    5. Create the data store configuration and place it under 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. Going to the Web Console at: https://serveraddress:serverport/system/console/configMgr
  2. Looking for a service called Apache Jackrabbit Oak Segment Tar Cold Standby Service and double click it to edit the settings.
  3. Enregistrez les paramètres et redémarrez les instances pour que les nouveaux paramètres puissent prendre effet.
Vous pouvez vérifier le rôle d’une instance à tout moment en vérifiant la présence des modes d’exécution principaux ou de secours dans la console web des paramètres Sling.
This can be done by going to https://localhost:4502/system/console/status-slingsettings and checking the "Run Modes" line.

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 suivantes :
*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 de production afin que la configuration principale ne soit pas effectuée par l’instance de secours.
  • mode Mode ( ) : vous choisirez alors le mode d’exécution de l’instance.
  • Port (port) : le port à utiliser pour la communication. La valeur par défaut est 8023 .
  • primary.host Hôte principal ( ) : - hôte de l'instance principale. Ce paramètre s’applique uniquement à l’instance de secours.
  • interval Intervalle de synchronisation ( ) : - ce paramètre détermine l'intervalle entre la demande de synchronisation et s'applique uniquement à l'instance de secours.
  • primary.allowed-client-ip-ranges Plages IP autorisées ( ) : - les plages d'adresses IP à partir desquelles le serveur principal autorise les connexions.
  • secure Sécurisé ( ) : Activez le chiffrement SSL. Pour que ce paramètre fonctionne, il doit être activé sur toutes les instances.
  • standby.readtimeout Délai d’expiration de lecture en attente ( ) : Délai d’expiration pour les demandes émises par l’instance de secours en millisecondes. La valeur recommandée pour le délai d’expiration est 43200000. Il est généralement recommandé de définir le délai d’expiration sur au moins 12 heures.
  • standby.autoclean Nettoyage automatique de secours ( ) : Appelez la méthode de nettoyage si la taille de la boutique augmente lors d’un cycle de synchronisation.
Il est vivement conseillé d’attribuer des ID de référentiel différents aux instances principale et de secours pour pouvoir bien les identifier séparément pour les services comme le déchargement. La meilleure façon de procéder est de supprimer le fichier sling.id sur l’instance de secours, puis de redémarrer l’instance.

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 :
Les fichiers de configuration doivent également être modifiés afin qu’ils correspondent aux paramètres utilisés pour une instance principale.
  1. Accédez à l’emplacement de l’instance de secours sur votre ordinateur et arrêtez-la.
  2. Si vous avez un équilibreur de charge configuré, 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. Restart the instance using the primary runmode:
    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 de secours à froid en accédant à la console JMX et en utilisant **org.apache.jackrabbit.oak : État ("En attente")**bean. For more information on how to do this, see the section on Monitoring .
  2. Arrêtez l’instance Cold Standby.
  3. Installez le correctif sur l’instance principale. For more details on how to install a hotfix, see How to Work With Packages .
  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 . The information can be found in an MBean of type org.apache.jackrabbit.oak:type="Standby" named 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 est en cours d’exécution ou non.
  • Mode: Client : suivi de l’UUID utilisé pour identifier l’instance. Notez que cet UUID change chaque fois que la configuration est mise à jour.
  • Status: une représentation textuelle de l’état actuel (comme running ou stopped ).
  • FailedRequests: nombre d’erreurs consécutives.
  • SecondsSinceLastSuccess: nombre de secondes écoulées depuis la dernière communication réussie avec le serveur. It will display -1 if no successful communication has been made.
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 en mode veille.
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: affichera 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: ID du client.
  • LastSeenTimestamp: l’horodatage de la dernière requête dans une représentation textuelle.
  • LastRequest: dernière requête du client.
  • RemoteAddress: adresse IP du client.
  • RemotePort: port utilisé par le client pour la dernière requête.
  • TransferredSegments: nombre total de segments transférés vers ce client.
  • TransferredSegmentBytes: nombre total d’octets transférés vers ce client.

Maintenance du référentiel Cold Standby

Nettoyage des révisions

Si vous exécutez Nettoyage des révisions en ligne sur l’instance principale, la procédure manuelle présentée ci-dessous n’est pas nécessaire. Additionally, if you are using Online Revision Cleanup, the cleanup () operation on the standby instance will pe performed automatically.
N’exécutez pas le nettoyage de révisions hors ligne sur l’instance de secours. Cela n’est pas nécessaire et ne réduit pas la taille de l’entrepôt de segments.
Adobe conseille d’exécuter régulièrement la maintenance afin d’éviter une croissance excessive du 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 de secours sur l’instance de secours 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. For more details, see Maintaining the Repository .
  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. Run the cleanup() operation on the standby instance, using the same JMX bean as described in the first step.
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.

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

Il est important d’exécuter de temps en temps le nettoyage de la mémoire sur les instances de l’entrepôt 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 exécuter la collecte des déchets, procédez comme suit :
  1. Run cold standby repository maintenance as described in the section above .
  2. Une fois le processus de maintenance terminé et les instances relancées, procédez comme suit :
    • On the primary, run the data store garbage collection via the relevant JMX bean as described in this article .
    • On the standby, the data store garbage collection is available only via the BlobGarbageCollection MBean - startBlobGC() . **RepositoryManagement **MBean n’est pas disponible en mode veille.
    Si vous n’utilisez pas d’entrepôt 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.