| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Introduction
La base de métrologie de Shinken peut être fortement sollicitée sur des architectures supervisant un grand nombre d'éléments. Sa disponibilité est également importante puisqu'elle peut être source de données pour des outils externes à Shinken ( Grafana par exemple ) pouvant être mis à disposition des utilisateurs.
L'objectif de cette page de documentation est d'expliquer de manière détaillée détailler la procédure nécessaire pour la mise en place d'un cluster Graphite. Cela permet Ce qui permettra d'augmenter la disponibilité des données et d'éviter la perte de données en cas d'incident sur la machine stockant les métriques.
Architecture mise en place
Dans une installation Shinken classique, les métriques sont émises par le Broker pour être stockées dans une base de données Graphite par le Broker.
Chaque résultat de vérification contenant des données de métrologie est analysé par le Broker. Ces métriques sont enregistrées dans envoyées à Graphite par le Broker grâce au module Graphite-Perfdata.
Dans Du côté de Graphite, le nom du démon responsable de l'enregistrement des métriques sur le disque est est "carbon-cache".
| Panel |
|---|
|
Pour transformer cette architecture pour dans le but de la rendre hautement disponible, on veut faire en sorte que les données soient seront répliquées lors de leur écriture. On utilise alors plusieurs démons
Un démon "carbon-cache" qui enregistrent chacun les métriques qu'on leur envoie sur des machines différentes, et un démon "carbon-relay" qui s'occupe de distribuer relay" distribue l'enregistrement des métriques aux métriques vers plusieurs démons "carbon-cache".
Ces derniers enregistrent chacun les métriques sur une machine différente.
L'architecture qu'on obtient obtenue à la fin de la procédure décrite dans cette documentation correspond à celle présente sur le schéma ci-contre.
Notre Le cluster Graphite est constitué d'au moins 2 machines distinctes ( idéalement 3 pour répartir les performances ).
Chaque démon "carbon-cache" est sur une machine distincte, qui permettra de stockage des afin d'y stocker les métriques.
Le démon "carbon-relay" reçoit l'ensemble des métriques envoyées par le Broker. Il se charge ensuite d'envoyer de faire suivre les ordres d'écritures des métriques aux différents démons "carbon-cache". Il peut être sur une machine à part, ou sur l'une des deux machines hébergeant un démon "carbon-cache".
| Note |
|---|
Le système mis en place ici est de la réplication, et non de la répartition. Les démons "carbon-cache" stockent chacun l'ensemble des métriques envoyées par le Broker. Il faut donc que chaque machine qui héberge un démon "carbon-cache" soit capable d'enregistrer l'intégralité des métriques gérées par le Broker. |
| Note |
|---|
Procédure de configuration
Avant de commencer, voici un résumé des différentes étapes nécessaires pour la configuration du cluster Graphite:
- Installation de Shinken
- Mise en place du démon carbon-relay
- Autorisation des connexions à Graphite
- Modification de la configuration Shinken pour l'utilisation du cluster Graphite
- Redémarrage de Graphite et Shinken
Installation de Shinken
La première étape dans la mise en place d'un cluster Graphite est bien entendu l'installation de Graphite. Comme les autres dépendances de Shinken, il faut que la version de Graphite installée soit celle fournie avec l'installeur Shinken. En effet, certaines modifications ont été faites sur Graphite pour l'intégration avec Shinken, ce qui rend incompatibles les versions de Graphites qui auraient pu être installées auparavant via d'autres installeurs.
Sur chaque machine qui compose le cluster Graphite, il faudra alors procéder à une installation de Shinken.
La procédure d'installation de Shinken est décrite dans la page de documentation dédiée: Guide d'installation et de mise à jour
Pour une version de Shinken antérieure à la 02.08.02-RC015 :
Depuis la version 02.08.02-RC015, cette incompatibilité n'existe plus. Les nœuds d'un même cluster peuvent être installés sur n'importe quelle distribution supportée par Shinken. |
Procédure de configuration
Avant de commencer, voici un résumé des différentes étapes nécessaires pour la configuration du cluster Graphite:
- Installation de Shinken.
- Mise en place du démon "carbon-relay".
- Autorisation des connexions à Graphite.
- Modification de la configuration Shinken pour utiliser le cluster Graphite.
- Redémarrage de Graphite et Shinken.
Installation de Shinken
La première étape dans la mise en place d'un cluster Graphite est bien entendu l'installation de Graphite. Comme les autres dépendances de Shinken, il faut que la version de Graphite installée soit celle fournie avec l'installeur Shinken. En effet, certaines modifications ont été faites sur Graphite pour l'intégration avec Shinken, ce qui rend incompatibles les versions de Graphite qui auraient pu être installées auparavant via d'autres installeurs.
Sur chaque machine qui compose le cluster Graphite, il faudra procéder à une installation de Shinken.
La procédure d'installation de Shinken est décrite une page de documentation dédiée ( voir la page Guide d'installation et de mise à jour ).
Mise en place du démon carbon-relay
Une fois Shinken et Graphite installés, il faut procéder à la configuration de Graphite.
On commence par dire à Graphite qu'on utilise la fonctionnalité de relais
Mise en place du démon carbon-relay
Une fois Shinken et Graphite installés, il faut procéder d'abord à la configuration de Graphite.
On commence par dire à Graphite qu'on utilise la fonctionnalité de relay via le fichier /opt/graphite/conf/carbon.conf ( copier le fichier d'exemple carbon.conf.example si besoin ).
Dans la section "[relay]", on modifie la variable "DESTINATIONS" dans laquelle on décrit la liste des démons carbon-relay qui constituent le cluster Graphite.
| Code Block | ||
|---|---|---|
| ||
[relay]
...
<autres options>
...
DESTINATIONS = adresse_carbon_cache_1:2004, adresse_carbon_cache_2:2004 |
On configure ensuite le relay pour lui spécifier les adresses des carbon-cache pour l'écriture et les adresses à utiliser pour la lecture des métriques.
Cette configuration se fait via le fichier /opt/graphite/conf/relay-rules.conf ( copier le fichier d'exemple relayexemple relay-rules.conf.example si besoin ):.
On configure le relais en précisant les adresses des serveurs hébergeant les démons carbon-cache ( pour l'écriture et la lecture des métriques ).
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[default]
default = | ||||||
| Code Block | ||||||
[default]
default = true
destinations = adresse_carbon_cache_1:2004,adresse_carbon_cache_2:2004
read_destinations = adresse_carbon_cache_1:80,adresse_carbon_cache_2:80 |
Par défaut, l'installeur Shinken met en place le fichier d'initialisation pour le démon carbon-relay mais ne lui attribue pas les droits d'exécution.
| Code Block | ||
|---|---|---|
| ||
chmod +x /etc/init.d/carbon-relay |
À la fin de cette étape de configuration, le relais est correctement configuré en ce qui concerne l'écriture des données. Pour la lecture des métriques, il faut encore autoriser la lecture des métriques, ce qui est l'objectif de l'étape suivante.
Autorisation des connexions à Graphite
On configure ensuite le démon carbon-relay pour préciser la liste des carbon-cache constituant le cluster.
Pour cela éditer le fichier /opt/graphite/conf/carbon.conf ( copier le fichier d'exemple carbon.conf.example si besoin ).
Dans la section "[relay]", on modifie la variable "DESTINATIONS" dans laquelle on décrit la liste des démons carbon-cache qui constituent le cluster Graphite.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[relay]
...
<autres options>
...
DESTINATIONS = adresse_carbon_cache_1:2004, adresse_carbon_cache_2:2004 |
| Warning |
|---|
Le paramètre destinations du fichier relay-rules.conf et le paramètre DESTINATIONS modifié dans le fichier carbon.conf doivent contenir la même information. |
Par défaut, l'installeur Shinken met en place un fichier de démarrage pour le démon carbon-relay sans les droits d'exécution. Pour permettre un démarrage en tant que service du système, il faut ajouter le droit d'exécution.
Sur la machine qui va héberger le démon carbon-relay, lancer la commande suivante :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
chmod +x /etc/init.d/carbon-relay |
À ce stade de la configuration, le relais est correctement configuré en ce qui concerne l'écriture des données.
Il faut maintenant permettre la lecture des métriques.
Autorisation des connexions à Graphite
Par défaut, Graphite autorise la lecture des métriques seulement depuis l'interface locale ( 127.0.0.1 ), pour des raisons de sécurité.
Pour le fonctionnement en cluster, il faut modifier les réglages d'Apache pour autoriser la lecture depuis le réseau.
RHEL / CentOS 7 ou RHEL / Alma / Rocky 8 ou RHEL / Alma / Rocky 9
Par défaut, Graphite autorise la lecture des métriques seulement depuis une interface locale, pour des raisons de sécurité. Il faut alors sur chaque machine qui héberge un démon carbon-relay, modifier les réglages d'Apache pour autoriser la lecture sur des machines externes.
Sur chaque carbon-relay et carbon-cache, on trouve dans le fichier /etc/httpd/conf.d/graphite.conf la ligne suivante:
| Code Block | ||
|---|---|---|
| ||
<VirtualHost 127.0.0.1:80> |
Cette ligne permet de dire à Apache qu'il faut écouter les requêtes de lecture des métriques sur l'interface locale (127.0.0.1) et le port 80 seulement. Pour écouter ces requêtes sur toutes les interfaces réseau de la machine, on remplacera cette ligne par la suivante:
Sur chaque carbon-relay et carbon-cache, dans le fichier
/etc/httpd/conf.d/graphite.conf
<VirtualHost *:80>On redémarre ensuite Apache pour prendre en compte les modifications:
| Code Block | ||
|---|---|---|
| ||
# Sur CentOS 6
service httpd restart
# Sur CentOS 7 / Redhat 7-8
systemctl restart httpd |
Modification de la configuration Shinken pour l'utilisation du cluster Graphite
Comme vu dans la section présentant l'architecture haute disponibilité qu'on est en train de mettre en place, le Broker, et en particulier son module Graphite-Perfdata, doit maintenant envoyer ses informations au démon carbon-relay au lieu de les envoyer directement à un démon carbon-cache.
Il faut donc modifier la configuration actuelle de Shinken pour envoyer les métriques sur le démon carbon-relay plutôt qu'au démon carbon-cache.
Pour ça, on modifie la configuration du module Graphite-Perfdata dans le fichier /etc/shinken/modules/graphite.cfg:
| Code Block |
|---|
#======== Graphite address =========
# host: graphite server address (ip or fqdn)
host addresse_carbon_relay
# port: tcp port of the graphite server
port 2013 |
On change ici le port 2003 (port par défaut du carbon-cache) vers le port 2013 (port par défaut du carbon-relay).
Il faut également modifier les réglages de Shinken pour lui spécifier d'envoyer les requêtes de lecture des métriques sur le carbon-relay au lieu de les envoyer directement sur un démon carbon-cache.
Cette modification se fait directement dans les réglages du module WebUI, responsable de l'interface de Visualisation. Dans /etc/shinken/modules/webui.cfg, on modifie la section suivante:
| Code Block | ||
|---|---|---|
| ||
[...]
#======== Metrology access =========
# Multi-realm graphite parameter
graphite_backends *:addresse_carbon_relay
[...] |
on trouve la ligne suivante:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<VirtualHost 127.0.0.1:80> |
Cette directive indique à Apache qu'il faut écouter les requêtes de lecture des métriques sur l'interface locale ( 127.0.0.1 ) et le port 80 seulement.
Pour écouter ces requêtes sur toutes les interfaces réseau de la machine, on la remplacera par :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<VirtualHost *:80> |
On redémarre ensuite Apache pour prendre en compte les modifications :
| Code Block | ||||
|---|---|---|---|---|
| ||||
systemctl restart httpd |
Debian 13
Sur chaque carbon-relay et carbon-cache, dans le fichier /etc/apache2/sites-available/graphite.conf on trouve la ligne suivante:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<VirtualHost 127.0.0.1:80> |
Cette directive indique à Apache qu'il faut écouter les requêtes de lecture des métriques sur l'interface locale ( 127.0.0.1 ) et le port 80 seulement.
Pour écouter ces requêtes sur toutes les interfaces réseau de la machine, on la remplacera par :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<VirtualHost *:80> |
On redémarre ensuite Apache pour prendre en compte les modifications :
| Code Block | ||||
|---|---|---|---|---|
| ||||
systemctl restart apache2 |
Modification de la configuration Shinken pour l'utilisation du cluster Graphite
Écriture des métriques
L'envoi des métriques à Graphite est géré par le module Graphite-Perfdata du Broker.
Pour que les métriques soient envoyées au relais plutôt qu'au démon carbon-cache, il faut modifier la configuration du module Graphite-Perfdata ( fichier /etc/shinken/modules/graphite.cfg ) :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
# ──────────── Metrology server parameters ──────────────────────────────────────────────────────────── #
# ─── Graphite writer ( carbon ) address ───
# ─── IP address or FQDN of carbon-cache or carbon-relay instance to send metrics to ───
# ───
# Default : localhost ───
# ───
broker__module_graphite_perfdata__writer__host addresse_carbon_relay
# ─── Graphite writer ( carbon ) port ───
# ─── tcp port of carbon-cache or carbon-relay instance to send metrics to ───
# ───
# Default : 2003 ───
# ───
broker__module_graphite_perfdata__writer__port 2013 |
On change ici
- l'adresse du serveur destinataire des métriques à écrire par celle du serveur hébergeant le démon carbon-relay,
- le port 2003 ( port par défaut du carbon-cache ) vers le port 2013 ( port par défaut du carbon-relay ).
Lecture des métriques
Il faut également préciser à Shinken de passer par le relais pour la lecture des métriques.
Cette modification se fait dans les paramètres du module WebUI, responsable de l'interface de Visualisation. Dans /etc/shinken/modules/webui.cfg, on modifie la section suivante :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[...]
graphite_backends *=http://addresse_carbon_relay:80
[...] |
Redémarrage de Graphite et Shinken
Les configurations de Graphite et de Shinken ayant été modifiées pour utiliser le cluster, il faut maintenant redémarrer les différents démons pour appliquer ces changements.
On commence par démarrer le démon carbon-relay de Graphite :
Code Block language text theme Emacs service carbon-relay start
On fait en sorte que ce démon soit relancé au démarrage du serveur :
Code Block language text theme Emacs systemctl enable carbon-relayOn redémarre ensuite les démons carbon-cache sur leurs machines respectives :
Code Block language text theme Emacs service carbon-cache restart
Enfin, on redémarre l'Arbiter pour prendre en compte les modifications de configuration de Shinken:
Excerpt Include Fichier de configuration ( shinken.cfg ) Fichier de configuration ( shinken.cfg ) nopanel true
Vérification du firewall ( est-ce que l'accès à carbon-cache / carbon-relay est disponible )
En cas de problème de connexion aux démons carbon-cache / carbon-relay vérifier que le port est ouvert dans le firewall.
Liste des ports utilisés par Graphite
La liste des ports utilisés par Graphite est la suivante :
| Port | Serveur hébergeant | Fonctionnalité |
|---|---|---|
| 2003 | carbon-cache | Réception des métriques à écrite, au format texte clair. |
| 2004 | carbon-cache | Réception des métriques à écrire, au format binaire ( les données sont sérialisées ). |
| 2013 | carbon-relay | Réception des métriques à relayer, au format texte clair. |
| 2014 | carbon-relay | Réception des métriques à relayer, au format binaire ( les données sont sérialisées ). |
| 80 | carbon-relay et carbon-cache | Lecture des métriques ( protocole http ). |
| 443 | carbon-relay et carbon-cache | Lecture des métriques ( protocole https ). |
Si firewalld est présent ( firewall activé par défaut sur RHEL / Alma / Rocky )
Vérifier que les ports sont ouverts
Voici comment vérifier que les ports des démons carbon-relay / carbon-cache sont ouverts sur leurs machines respectives :
| Code Block | ||||
|---|---|---|---|---|
| ||||
firewall-cmd --list-ports |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
80/tcp 7763/tcp 7765/tcp 7766/tcp 7767/tcp 7768/tcp 7769/tcp 7770/tcp 7771/tcp 7772/tcp 7773/tcp 7777/tcp 7780/tcp 50000/tcp |
Dans cet exemple, aucun des ports de carbon-relay ( 2013/tcp ) et de carbon-cache ( 2004/tcp ) ne sont présents, ils sont donc bloqués.
Sur les serveurs carbon-relay
Si le port du démon carbon-relay n'est pas ouvert, pour autoriser le trafic vers ce port, utiliser les commandes suivantes :
| Code Block | ||||
|---|---|---|---|---|
| ||||
firewall-cmd --add-port=2013/tcp
firewall-cmd --runtime-to-permanent |
Sur les serveurs carbon-cache
Si le port du carbon-cache n'est pas ouvert, pour autoriser le trafic vers ce port, utiliser les commandes suivantes :
| Code Block | ||||
|---|---|---|---|---|
| ||||
firewall-cmd --add-port=2004/tcp
firewall-cmd --runtime-to-permanent |
Passer le cluster Graphite en HTTPS
Les étapes suivantes permettent d'activer le HTTPS d'un cluster Graphite :
- Sur chaque nœud du cluster (carbon-relay et carbon-cache), activer le HTTPS de Graphite (voir la page Base de métrologie ( Graphite ) section Activation de HTTPS pour Graphite ).
Activer HTTPS pour les communications intra-cluster. Sur la machine du carbon-relay dans le fichier de configuration /opt/graphite/webapp/graphite/local_settings.py ( copier le fichier d'exemple local_settings.py.example si besoin ), dé-commenter la clé INTRACLUSTER_HTTPS et la passer à True
Code Block language js theme Confluence title /opt/graphite/webapp/graphite/local_settings.py [ ... ] INTRACLUSTER_HTTPS = True [ ... ]
Ne pas oublier de changer, sur le serveur hébergeant le démon carbon-relay, les ports à utiliser pour la lecture des métriques ( 443 désormais au lieu de 80 ).
Cette configuration se fait via le fichier /opt/graphite/conf/relay-rules.conf ( copier le fichier d'exemple relay-rules.conf.example si besoin ) :
Code Block language js theme Confluence title /opt/graphite/conf/relay-rules.conf [default] default = true destinations = adresse_carbon_cache_1:2004,adresse_carbon_cache_2:2004 read_destinations = adresse_carbon_cache_1:443,adresse_carbon_cache_2:443Si ce n'est pas déjà fait, préciser dans le fichier de configuration de la WebUi ( /etc/shinken/modules/webui.cfg ) que le cluster Graphite communique en HTTPS. Il faut ensuite redémarrer l'Arbiter pour prendre en compte la modification.
Code Block language js theme Confluence title /etc/shinken/modules/webui.cfg [ ... ] graphite_backends *=https://CARBON_RELAY_SERVER:443 [ ... ]- Ajouter le certificat de l'autorité de certification sur chaque nœud composant le cluster ( le certificat de l'autorité de certification est celui utilisé pour générer chacun des certificats utilisés sur les différents serveurs ).
RHEL / CentOS 7 ou RHEL / Alma / Rocky 8 ou RHEL / Alma / Rocky 9
- Pour ajouter le certificat de l'autorité de certification dans la chaîne de confiance du système, il faut l'ajouter dans /etc/ssl/certs/ca-bundle.trust.crt.
- Les commandes suivantes permettent d'effectuer cette opération :
Code Block language text theme Emacs cp your_certificate.crt /etc/pki/ca-trust/source/anchors/ update-ca-trust- Ensuite, sur l'ensemble des machines redémarrer le démon apache :
Code Block language text theme Emacs service httpd restart
Debian 13
- Pour ajouter le certificat de l'autorité de certification dans la chaîne de confiance du système,, il faut le copier dans le dossier /usr/local/share/ca-certificates/ et mettre à jour la chaîne de confiance.
- Les commandes suivantes permettent de réaliser cette opération :
Code Block language text theme Emacs cp your_certificate.crt /usr/local/share/ca-certificates/ update-ca-certificates- Ensuite, sur l'ensemble des machines redémarrer le démon apache :
Code Block language text theme Emacs systemctl restart apache2
Redémarrer le démon carbon-relay de Graphite:
Code Block language text theme Emacs service carbon-relay restart
Comportement de Shinken avec un cluster Graphite
Configurer Shinken pour utiliser un cluster Graphite se fait très simplement, il suffit de changer les adresses utilisées pour la lecture et l'écriture des métriques.
Le cluster Graphite gère la haute disponibilité des données et la réplication, le changement d'architecture est transparent pour les utilisateurs de Shinken.
Outils externes ( Grafana ) et relation UUID ↔ nom
En cas d'utilisation d'outils externes ( comme Grafana par exemple ) pour consulter les métriques, il faut également :
- configurer la récupération des données de l'inventaire sur les serveurs carbon-cache,
- autoriser les connexions au serveur d'inventaire depuis les serveurs carbon-cache.
( voir la page Base de métrologie ( Graphite ) section Correspondance ID → Nom de l'élément )
Redémarrage de Graphite et Shinken
A ce stade, la configuration de Graphite a été modifiée pour utiliser un démon carbon-relay.
On a aussi effectué des modifications de configuration au niveau de Shinken pour prendre en compte ce changement d'architecture au niveau de Graphite.
La dernière étape est de redémarrer les différents démons pour prendre en compte ces changements de configuration:
On commence par démarrer le démon carbon-relay Graphite:
Code Block language bash /etc/init.d/carbon-relay startAjouter carbon-relay au démarrage du serveur
Code Block # Sur CentOS 6 chkconfig carbon-relay on # Sur CentOS 7 / Redhat 7-8 systemctl enable carbon-relay
On redémarre ensuite les démons carbon-cache sur leurs machines respectives
Code Block language bash /etc/init.d/carbon-cache restartOn redémarre ensuite l'Arbiter pour prendre en compte les modifications de configuration de Shinken:
Code Block /etc/init.d/shinken-arbiter restart
Vérification du firewall ( est que vous avez accès )
Si vous n'arrivez pas à vous connecter au carbon-cache / carbon-relay vérifier que le port est ouvert dans votre firewall.
Si vous avez firewalld ( firewall par défaut de la Redhat )
Vérifier que les ports sont ouvert
Voici comment vérifier que les ports des carbon-relay / carbon-cache sont ouvert sur leurs machines :
| Code Block |
|---|
firewall-cmd --list-ports |
| Code Block | ||||
|---|---|---|---|---|
| ||||
80/tcp 7763/tcp 7765/tcp 7766/tcp 7767/tcp 7768/tcp 7769/tcp 7770/tcp 7771/tcp 7772/tcp 7773/tcp 7777/tcp 7780/tcp 50000/tcp |
Dans cet exemple, le port 2003/tcp n'est pas listé, il est donc bloqué par défaut
Sur les serveurs carbon-relay
Si firewalld est actif sur le système, alors vérifier que le port est ouvert par le firewall ( Voir Vérifier que les ports sont ouvert ). Si il n'est pas ouvert il faut alors autoriser le trafic vers le port du carbon-relay.
Cela peut être fait avec les commandes suivantes :
| Code Block |
|---|
firewall-cmd --add-port=2013/tcp
firewall-cmd --runtime-to-permanent |
Sur les serveurs carbon-cache
Si firewalld est actif sur le système, alors vérifier que le port est ouvert par le firewall ( Voir Vérifier que les ports sont ouvert ). Si il n'est pas ouvert il faut alors autoriser le trafic vers le port ducarbon-cache
Cela peut être fait avec les commandes suivantes :
| Code Block |
|---|
firewall-cmd --add-port=2004/tcp
firewall-cmd --runtime-to-permanent |
Comportement de Shinken avec un cluster Graphite
Comme vu dans la procédure de configuration, la modification de configuration côté Shinken pour utiliser le cluster Graphite est minimale:
- on se contente de changer les adresses utilisées pour la lecture et l'écriture des métriques pour pointer sur le démon carbon-relay au lieu d'un démon carbon-cache.
- La haute disponibilité de Graphite est donc gérée entièrement par Graphite, qui s'occupe de la réplication des données entre les démons carbon-cache et de la lecture des données.
Cette modification d'architecture est invisible pour les utilisateurs.