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.


L'objectif de cette page de documentation est d'expliquer de manière détaillée la procédure nécessaire pour la mise en place d'un cluster Graphite. Cela permet 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 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 sont analysées par le Broker. Ces métriques sont enregistrées dans Graphite par le Broker grâce au module Graphite-Perfdata.

Dans Graphite, le nom du démon responsable de l'enregistrement des métriques sur le disque est "carbon-cache".




Pour transformer cette architecture pour la rendre hautement disponible, on veut faire en sorte que les données soient répliquées lors de leur écriture. On utilise alors le logiciel Keepalived qui permet de créer une adresse IP virtuelle qui, en cas de problème sur le serveur principal, bascule sur le serveur secondaire automatiquement. Grâce à l'installation du démon "carbon-relay" sur le serveur principale ET le serveur secondaire, l'enregistrement des métriques n'est pas interrompu en cas de bascule.

L'architecture qu'on obtient à la fin de la procédure décrite dans cette documentation correspond à celle présente sur le schéma ci-contre.

Notre cluster Graphite est constitué d'au moins 2 machines distinctes (idéalement 3 pour répartir les performances). Le démon "carbon-cache" est sur toutes machine du cluster, ce qui permettra le stockage des métriques. Le démon "carbon-relay" est aussi sur toutes les machines du cluster, ce qui permettra en cas de bascule d'assurer la continuité de l'enregistrement des métriques. Sur la machine possédant la VIP, le démon "carbon-relay" reçoit l'ensemble des métriques envoyées par le Broker. Il se charge ensuite d'envoyer les ordres d'écritures des métriques aux démons "carbon-cache".

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és 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.




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
  • Installation et configuration de Keepalived
  • 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 incompatible 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

Installation et configuration de Keepalived

Installer Keepalived et ses dépendances sur tous les serveurs qui vont composer le cluster:

yum install keepalived

Une fois l'installation terminé, il faut aller éditer le fichier de configuration de Keepalived

! Configuration File for keepalived

vrrp_instance NOM_DU_SERVEUR {
# Priorité utilisée lors de l'élection d'un nouveau maître. C'est la priorité la plus élevée qui gagne l'élection
  priority 150
# ID du routeur virtuel. Doit être unique sur l'ensemble des noeuds
  virtual_router_id 255
# Option qui a pour conséquence qu’un master qui renaît ne reprendra pas l’IP si son SLAVE l’a
  nopreempt
# Interface d'écoute et d'échange des paquets multicast VRRP
  interface enp0s3
# L'état de santé des cibles est vérifié toutes les 5 secondes
  advert_int 5
# Interface réseau commune aux membres
  virtual_ipaddress {
        XXX.XXX.XXX.XXX/XX brd XXX.XXX.XXX.XXX dev enp0s3 scope global
  }
}


ATTENTION à modifier les informations suivantes :

  • vrrp_instance NOM_DU_SERVEUR : Le nom du serveur
  • priority 150 : 150 pour le serveur principal et une valeur inférieur pour les esclaves
  • interface enp0s3 : Le nom de l'interface réseau principale du serveur (commande "ip addr" ou "ifconfig")
  • virtual_ipaddress XXX.XXX.XXX.XXX/XX : En 1er l'adresse virtuelle qui va être créée. En 2ème le masque de sous réseau. En 3ème l'adresse de broadcast du sous-réseau (se termine en général par 255). En 4ème le nom de l'interface réseau du serveur.

Exemple d'un configuration avec 1 serveur maître et 1 serveur esclave


! Configuration File for keepalived

vrrp_instance SRV01 {
  priority 150
  virtual_router_id 255
  nopreempt
  interface enp0s3
  advert_int 5
  virtual_ipaddress {
        192.168.1.100/24 brd 192.168.1.255 dev enp0s3 scope global
  }
}



! Configuration File for keepalived

vrrp_instance SRV02 {
  priority 100
  virtual_router_id 255
  nopreempt
  interface enp0s3
  advert_int 5
  virtual_ipaddress {
        192.168.1.100/24 brd 192.168.1.255 dev enp0s3 scope global
  }
}



Mise en place du démon carbon-relay