Consul - Événements de basculement

Dans ce chapitre, nous découvrirons les événements de basculement dans Consul. Cela se fera à l'aide des fonctionnalités suivantes -

  • Panne de cluster unique
  • Test Jepsen
  • Échec de plusieurs clusters
  • Prendre des instantanés

Comprenons chacun de ces éléments en détail.

Panne de cluster unique

En cas de défaillance d'un seul cluster, le cluster placé dans l'un des centres de données commence à échouer. Dans tous les cas, il est important de s'assurer qu'en cas de basculement, le système non seulement l'empêche, mais dispose également d'une sauvegarde sur laquelle il peut compter. Pour éviter les événements de basculement Consul, nous allons utiliser quelque chose appelé alertes Consul. Le projet principal se trouve sur -https://github.com/AcalephStorage/consul-alerts.

Consul-alertes est un démon hautement disponible pour l'envoi de notifications et de rappels basés sur les vérifications de l'état de Consul. Ce projet exécute un démon et une API sur localhost: 9000 et se connecte à l'agent consul local (localhost: 8500) avec le centre de données par défaut (dc1).

Il existe deux méthodes pour démarrer le projet. La première méthode consiste à l'installer viaGO. Pour les utilisateurs qui ont installé et configuré GO, ils peuvent suivre les étapes ci-dessous -

$ go get github.com/AcalephStorage/consul-alerts
$ go install
$ consul-alerts start

La dernière commande peut être facilement utilisée pour remplacer les ports par défaut pour consul-alert, option de centre de données, jeton consul-acl, etc. La commande peut également être écrite comme indiqué ci-dessous -

$ consul-alerts start --alert-addr = localhost:9000 --consul-addr = localhost:8500
--consul-dc = dc1 --consul-acl-token = ""

La deuxième méthode implique que l'utilisateur utilise Docker. Les deux méthodes sont également utiles dans différents scénarios. Pour utiliser les alertes Consul sur Docker, tirons l'image du Docker Hub en utilisant la commande suivante.

$ docker pull acaleph/consul-alerts

Dans la méthode Docker, nous pouvons considérer les trois options suivantes -

  • Utilisation de l'Agent Consul intégré au conteneur lui-même.
  • Utilisation de l'agent Consul s'exécutant sur un autre conteneur Docker.
  • Utilisation des alertes Consul pour créer un lien sur une instance de consul distant.

Laissez-nous maintenant discuter de ces deux en détail.

Utilisation de l'Agent Consul intégré au conteneur lui-même

Commençons l'agent consul en utilisant la commande suivante -

$ docker run -ti \
   --rm -p 9000:9000 \
   --hostname consul-alerts \
   --name consul-alerts \  
   --entrypoint = /bin/consul \
   acaleph/consul-alerts \
   agent -data-dir /data -server -bootstrap -client = 0.0.0.0

Ici, nous annulons le entrypoint pour le consul tel que mentionné par le drapeau --entrypoint. Parallèlement, nous amorçons le client en mentionnant le port utilisé en utilisant-p flag, data directory /data en utilisant l'indicateur -data-dir et le client comme 0.0.0.0.

Sur une nouvelle fenêtre de terminal, commençons l'option consul-alertes.

$ docker exec -ti consul-alerts /bin/consul-alerts start --alertaddr = 0.0.0.0:9000
--log-level = info --watch-events --watch-checks

Ici, dans les étapes ci-dessus, nous exécutons les alertes-consul pour démarrer en mode interactif. Le port d'adresse d'alerte est mentionné comme 9000. La montre vérifie si les agents consuls sont activés ou non avec les contrôles consul.

Nous pouvons clairement voir que les alertes consul ont facilement commencé et il a enregistré un nouveau bilan de santé avec l'ajout de l'agent consul. Le centre de données est considéré comme dc1, qui peut être modifié en fonction de l'utilisateur.

Utilisation de l'agent Consul s'exécutant sur un autre conteneur Docker

Ici, vous pouvez utiliser n'importe quel type d'image consul à exécuter sur le conteneur Docker. En utilisant l'image consul-alertes, nous pouvons facilement relier le conteneur consul au conteneur consul-alertes. Ceci est fait en utilisant le--link flag.

Note - Avant d'utiliser la commande suivante, veuillez vous assurer que le conteneur consul est déjà en cours d'exécution sur un autre terminal.

$ docker run -ti \
   -p 9000:9000 \
   --hostname consul-alerts \
   --name consul-alerts \
   --link consul:consul \
   acaleph/consul-alerts start \
   --consul-addr=consul:8500 \
   --log-level = info --watch-events --watch-checks

Utilisation des alertes Consul pour créer un lien sur une instance de consul distant

Ici, nous devrions utiliser la commande suivante pour utiliser les alertes de consul pour établir un lien sur une instance de consul distante.

$ docker run -ti \
   -p 9000:9000 \
   --hostname consul-alerts \
   --name consul-alerts \
   acaleph/consul-alerts start \
   --consul-addr = remote-consul-server.domain.tdl:8500 \
   --log-level = info --watch-events --watch-checks

Test Jepsen

Jespen est un outil écrit pour tester la tolérance partielle et la mise en réseau dans n'importe quel système. Il teste le système en créant des opérations aléatoires sur le système.Jepsen is written in Clojure. Malheureusement, pour la démonstration, les tests Jepsen nécessitent un niveau énorme de formation de cluster avec des systèmes de base de données et sont donc hors de portée pour être couverts ici.

Jepsen fonctionne en configurant le magasin de données testé sur cinq hôtes différents. Il crée un client, pour le magasin de données testé, pointant chacun des cinq nœuds pour envoyer des requêtes. Il crée également une série spéciale de clients appelés «Nemesis», qui font des ravages dans le cluster comme, coupant les liens entre les nœuds en utilisantiptables. Ensuite, il procède à des demandes simultanées contre différents nœuds tout en partitionnant et en réparant alternativement le réseau.

À la fin de l'exécution du test, il guérit le cluster, attend la récupération du cluster, puis vérifie si l'état intermédiaire et final du système est comme prévu. Certains extraits ont été tirés d' ici .

Pour plus d'informations sur les tests Jepsen, consultez-le ici .

Échec de plusieurs clusters

Lors d'un événement de basculement de plusieurs clusters, les clusters déployés dans plusieurs centres de données ne prennent pas en charge les services pris en charge par le client. Consul nous permet de nous assurer que lorsqu'une de ces conditions se produit, Consul dispose de fonctionnalités qui vous aident à activer les services dans ce type de conditions.

Pour que cela se produise, nous examinerons un projet qui nous aide à permettre la réplication de Consul d'un cluster à plusieurs clusters. Le projet nous fournit un moyen de répliquer des paires K / V dans plusieurs centres de données Consul à l'aide du démon consul-replicate. Vous pouvez voir ce projet Hashicorp sur -https://github.com/hashicorp/consul-replicate. Certaines des conditions préalables pour essayer ce projet incluent:

  • Golang
  • Docker
  • Consul
  • Git

Commençons par les commandes suivantes -

Note - Avant d'exécuter la commande suivante, assurez-vous que Git est correctement installé et configuré sur votre machine.

$ git clone - https://github.com/hashicorp/consul-replicate.git

La sortie serait comme indiqué dans la capture d'écran suivante.

$ cd consul-replicate
$ make

La sortie serait comme indiqué dans la capture d'écran suivante.

Si vous rencontrez des difficultés pour construire le binaire, vous pouvez également essayer d'extraire les images Docker manuellement en utilisant la commande suivante -

$ docker pull library/golang:1.7.4

La commande mentionnée ci-dessus créera bin / consul-replicate, qui peut être appelée en tant que binaire. Le tableau suivant montre la liste complète des sous-commandes qu'il couvre -

Option La description
auth Le nom d'utilisateur d'authentification de base (et le mot de passe facultatif), séparés par deux points. Il n'y a aucune valeur par défaut.
consul * L'emplacement de l'instance consul à interroger (peut être une adresse IP ou un nom de domaine complet) avec le port.
max-stale L'obsolescence maximale d'une requête. Si spécifié, Consule distribuera le travail entre tous les serveurs au lieu du seul leader. La valeur par défaut est 0 (aucune).
ssl Utilisez HTTPS lorsque vous parlez à Consul. Nécessite que le serveur de consule soit configuré pour des connexions sécurisées de serveur. La valeur par défaut est false.
ssl-verify Vérifiez les certificats lors de la connexion via SSL. Cela nécessite l'utilisation de -ssl. La valeur par défaut est true.
syslog Envoyez la sortie du journal à syslog (en plus de stdout et stderr). La valeur par défaut est false
installation syslog La fonction à utiliser lors de l'envoi vers syslog. Cela nécessite l'utilisation de -syslog. La valeur par défaut est LOCAL
jeton Le jeton de l'API Consul. Il n'y a aucune valeur par défaut.
préfixe * Le préfixe source comprenant le, avec les options préfixe de destination, séparé par deux-points (:). Cette option est additive et peut être spécifiée plusieurs fois pour plusieurs préfixes à répliquer.
exclure Un préfixe à exclure lors de la réplication. Cette option est additive et peut être spécifiée plusieurs fois pour plusieurs préfixes à exclure.
attendez Le minium (: maximum) à attendre la stabilité avant de répliquer, séparé par deux points (:). Si la valeur maximale facultative est omise, elle est supposée être 4x la valeur minimale requise. Il n'y a aucune valeur par défaut.
réessayez Délai d'attente si Consule renvoie une erreur lors de la communication avec l'API. La valeur par défaut est de 5 secondes.
config Le chemin vers un fichier de configuration ou un répertoire de fichiers de configuration sur le disque, par rapport au répertoire de travail actuel. Les valeurs spécifiées sur l'interface de ligne de commande sont prioritaires sur les valeurs spécifiées dans le fichier de configuration. Il n'y a aucune valeur par défaut.
niveau journal Le niveau de journal pour la sortie. Cela s'applique à la journalisation stdout / stderr ainsi qu'à la journalisation syslog (si activée). Les valeurs valides sont "debug", "info", "warn" et "err". La valeur par défaut est "warn".
une fois que Exécutez Consule Replicate une fois et quittez (contrairement au comportement par défaut du démon). (CLI uniquement)
version Sortez les informations de version et quittez. (CLI uniquement)

Prendre des instantanés

Les instantanés sont une partie essentielle et importante de la gestion du cluster Consul en cas de sauvegardes. Par défaut, Consul nous fournit un moyen de sauvegarder des instantanés du cluster consul. Consul nous fournit quatre sous-commandes distinctes à l'aide desquelles nous pouvons utiliser consul pour créer des instantanés, qui sont -

  • Sauvegarde de l'instantané du consul
  • Agent d'instantané du consul
  • Instantané du consul inspecter
  • Restauration de l'instantané du consul

Comprenons chacun de ces éléments en détail.

Enregistrer un instantané du consul

Cette commande est configurée pour récupérer un instantané atomique et instantané de l'état des serveurs Consul, qui comprend les entrées de clé / valeur, le catalogue de services, les requêtes préparées, les sessions et les ACL. L'instantané est enregistré sous le nom de fichier mentionné.

$ consul snapshot save <name-of-the-file>.snap

La sortie serait comme indiqué dans la capture d'écran suivante.

Pour vérifier la présence du fichier dans le répertoire courant, veuillez le vérifier en l'exécutant dans votre répertoire actuel. Dans le cas d'un nœud non leader, veuillez exécuter la commande suivante -

$ consul snapshot save -stale <name-of-file>.snap

Agent d'instantané Consul

Cette sous-commande démarre un processus qui prend des instantanés de l'état des serveurs Consul et les enregistre localement, ou les pousse vers un service de stockage distant en option.

Inspection des instantanés du consul

Il est utilisé pour inspecter l'instantané instantané de l'état des serveurs Consul, qui comprend les entrées de clé / valeur, le catalogue de services, les requêtes préparées, les sessions et les ACL. La commande peut être exécutée comme suit -

Note - N'oubliez pas que la commande suivante ne peut être exécutée que dans le répertoire, où l'instantané est enregistré.

$ consul snapshot save <name-of-the-file>.snap

La sortie serait comme indiqué dans la capture d'écran suivante.

Restauration de l'instantané du consul

La commande snapshot restore est utilisée pour restaurer un instantané instantané de l'état des serveurs Consul, qui comprend les entrées de clé / valeur, le catalogue de services, les requêtes préparées, les sessions et les ACL. L'instantané est lu à partir du fichier de sauvegarde enregistré.

Note - N'oubliez pas que la commande suivante ne peut être exécutée que dans le répertoire où le snapshot est enregistré.

$ consul snapshot restore <name-of-the-file>.snap

La sortie serait comme indiqué dans la capture d'écran suivante.

Si vous travaillez sur Consul avec AWS, ce projet peut vous aider à gagner du temps - https://github.com/pshima/consul-snapshot.