Vous consultez actuellement l'aide de la version:

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.

Remarque :

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.

Remarque :

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 :

chlimage_1

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.

Remarque :

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

Attention :

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 à org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService 
  • de org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService à 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. Vous pouvez ensuite démarrer chaque instance avec un mode d’exécution spécifiant son rôle (principale ou de secours).

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. 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 la boutique 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, voir Configuration.
    5. Si vous utilisez une instance AEM TarMK avec entrepôt de données externe, créez un dossier nommé crx3 sous aem-primary/crx-quickstart/install, nommé 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 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=false
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"4096"
  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. Supprimez tous les fichiers que vous pouvez avoir sous aem-standby/crx-quickstart/install .
    2. Créez 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 un fichier nommé crx3 sous aem-standby/crx-quickstart/install.
    5. Créer une configuration d’entrepôt 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=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=false
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"1024"
  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 : http://serveraddress:serverport/system/console/configMgr.
  2. Recherchez un service nommé TarMK Cold Standby 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.

Remarque :

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.

Ceci peut être effectué en accédant à http://localhost:4502/system/console/status-slingsettings et en vérifiant la ligne « modes d’exécution ».

 

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 de production 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.
  • L’hôte principal (primary.host ) : l’hôte de l’instance principale. Ce paramètre s’applique uniquement à l’instance de secours.
  • L’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 auxquelles 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 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.
  • Nettoyage automatique Standby (standby.autoclean) : appelez cette méthode de nettoyage si la taille de l’entrepôt augmente lors d’un cycle de synchronisation..

 

Remarque :

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 :

  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. Redémarrez l’instance à l’aide du mode d’exécution principal :

    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, voir 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 (Exécution cours) : 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 (État) : représentation textuel de l’état actuel (par exemple en cours d’exécution ou arrêté).
  • FailedRequests : le nombre d’erreurs consécutives.
  • SecondsSinceLastSuccess : le 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 () : commence le processus de synchronisation.
  • stop () : arrête le processus de synchronisation.
  • nettoyage () : 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 principale.

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 :

  • Nom : 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

Remarque :

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. Par ailleurs, si vous utilisez ce processus, l’opération cleanup () sur l’instance de secours sera effectuée automatiquement.

Remarque :

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 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 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. Pour plus d’informations, voir Maintien 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.

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 lancer le processus de nettoyage, 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 d’entrepôt 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 d’entrepôt de données est uniquement disponible via le MBean BlobGarbageCollection - startBlobGC(). Le MBean RepositoryManagement n’est pas disponible sur l’instance de secours.

    Remarque :

    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.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne