Cónsul - Eventos de conmutación por error

En este capítulo, aprenderemos sobre los eventos de conmutación por error en Consul. Esto se hará con la ayuda de las siguientes funcionalidades:

  • Fallo de un solo grupo
  • Prueba de Jepsen
  • Fallo de varios clústeres
  • Tomando instantáneas

Entendamos cada uno de estos en detalle.

Fallo de un solo grupo

En una falla de un solo clúster, el clúster ubicado en uno de los centros de datos comienza a fallar. En todos los casos, es importante asegurarse de que, en caso de una conmutación por error, el sistema no solo pueda evitarlo, sino que también tenga una copia de seguridad en la que pueda confiar. Para prevenir los eventos de conmutación por error de Consul, usaremos algo llamado alertas de Consul. El proyecto principal se puede encontrar en -https://github.com/AcalephStorage/consul-alerts.

Consul-alerts es un demonio de alta disponibilidad para enviar notificaciones y recordatorios basados ​​en las comprobaciones de Consul Health. Este proyecto ejecuta un demonio y una API en localhost: 9000 y se conecta al agente de cónsul local (localhost: 8500) con el centro de datos predeterminado (dc1).

Hay dos métodos para comenzar con el proyecto. El primer método es instalarlo a través deGO. Los usuarios que tengan GO instalado y configurado, pueden seguir los pasos que se indican a continuación:

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

El último comando se puede usar fácilmente para anular los puertos predeterminados para consul-alert, opción de centro de datos, token de consul-acl, etc. El comando también se puede escribir como se indica a continuación:

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

El segundo método implica que el usuario utilice Docker. Ambos métodos son igualmente útiles en diferentes escenarios. Para usar las alertas de Consul sobre Docker, extraigamos la imagen de Docker Hub usando el siguiente comando.

$ docker pull acaleph/consul-alerts

En el método Docker, podemos considerar las siguientes tres opciones:

  • Utilizando Consul Agent que está integrado en el propio contenedor.
  • Utilizando Consul Agent que se ejecuta sobre otro contenedor de Docker.
  • Uso de las alertas de Consul para vincular a través de una instancia de Consul remota.

Analicemos ahora ambos en detalle.

Usando Consul Agent que está integrado en el propio contenedor

Iniciemos el agente cónsul usando el siguiente comando:

$ 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

Aquí, anulamos el entrypoint para Cónsul como lo menciona la bandera --entrypoint. Junto con él, estamos iniciando el cliente al mencionar el puerto utilizado mediante el uso de-p flag, data directory /data utilizando el indicador -data-dir y el cliente como 0.0.0.0.

En una nueva ventana de terminal, iniciemos la opción de alertas de cónsul.

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

Aquí, en los pasos anteriores, estamos ejecutando las alertas de cónsul para comenzar en el modo interactivo. El puerto de dirección de alerta se menciona como 9000. El reloj comprueba si los agentes del cónsul están habilitados o no junto con los controles del cónsul.

Podemos ver claramente que las alertas del cónsul se han iniciado fácilmente y se ha registrado un nuevo chequeo de salud con la adición del agente del cónsul. El centro de datos se toma como dc1, que se puede cambiar según el usuario.

Uso del agente Consul que se ejecuta sobre otro contenedor de Docker

Aquí, puede utilizar cualquier tipo de imagen de cónsul para que se ejecute sobre el contenedor de Docker. Usando la imagen de las alertas del cónsul, podemos vincular fácilmente el contenedor del cónsul con el contenedor de alertas del cónsul. Esto se hace usando el--link flag.

Note - Antes de usar el siguiente comando, asegúrese de que el contenedor cónsul ya se esté ejecutando en otra 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

Uso de las alertas de Consul para vincular a través de una instancia de Consul remota

Aquí, deberíamos usar el siguiente comando para usar las alertas de Consul para vincular sobre una instancia de cónsul remota.

$ 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

Prueba de Jepsen

Jespen es una herramienta escrita para probar la tolerancia parcial y la conexión en red en cualquier sistema. Prueba el sistema creando algunas operaciones aleatorias en el sistema.Jepsen is written in Clojure. Desafortunadamente, para la demostración, las pruebas de Jepsen requieren un gran nivel de formación de clústeres con sistemas de bases de datos y, por lo tanto, están fuera del alcance de ser cubierto aquí.

Jepsen funciona configurando el almacén de datos bajo prueba en cinco hosts diferentes. Crea un cliente, para el almacén de datos bajo prueba, apuntando a cada uno de los cinco nodos para enviar solicitudes. También crea una serie especial de cliente (s) llamados "Nemesis", que causan estragos en el clúster, cortando enlaces entre nodos usandoiptables. Luego procede a realizar solicitudes simultáneamente en diferentes nodos mientras particiona y repara alternativamente la red.

Al final de la ejecución de prueba, repara el clúster, espera a que se recupere y luego verifica si el estado intermedio y final del sistema es el esperado. Se han tomado algunos extractos de aquí .

Para obtener más información sobre las pruebas de Jepsen, compruébalo aquí .

Fallo de varios clústeres

Durante un evento de conmutación por error de varios clústeres, los clústeres implementados en varios centros de datos no son compatibles con los servicios que ofrece el cliente. Consul nos permite asegurarnos de que cuando ocurra una de estas condiciones, Consul tenga características que lo ayuden a habilitar los servicios en ese tipo de condiciones.

Para que esto suceda, analizaremos un proyecto que nos ayuda a habilitar la replicación de Consul de One Cluster a Multiple Clusters. El proyecto nos proporciona una forma de replicar pares K / V en múltiples centros de datos de Consul utilizando el demonio consul-replicate. Puede ver este proyecto de Hashicorp en -https://github.com/hashicorp/consul-replicate. Algunos de los requisitos previos para probar este proyecto incluyen:

  • Golang
  • Docker
  • Consul
  • Git

Comencemos con los siguientes comandos:

Note - Antes de ejecutar el siguiente comando, asegúrese de tener Git correctamente instalado y configurado en su máquina.

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

La salida sería como se muestra en la siguiente captura de pantalla.

$ cd consul-replicate
$ make

La salida sería como se muestra en la siguiente captura de pantalla.

Si tiene problemas para compilar el binario, también puede intentar extraer las imágenes de Docker manualmente mediante el siguiente comando:

$ docker pull library/golang:1.7.4

El comando mencionado anteriormente creará bin / consul-replicate, que se puede invocar como binario. La siguiente tabla muestra la lista completa de subcomandos que cubre:

Opción Descripción
auth El nombre de usuario de autenticación básica (y contraseña opcional), separados por dos puntos. No existe un valor predeterminado.
cónsul * La ubicación de la instancia de cónsul para consultar (puede ser una dirección IP o FQDN) con puerto.
max-rancio La máxima obsolescencia de una consulta. Si se especifica, Consule distribuirá el trabajo entre todos los servidores en lugar de solo el líder. El valor predeterminado es 0 (ninguno).
ssl Use HTTPS mientras habla con Consul. Requiere que el servidor de la consola esté configurado para conexiones seguras del servidor. El valor predeterminado es falso.
ssl-verificar Verifique los certificados al conectarse a través de SSL. Esto requiere el uso de -ssl. El valor por defecto es verdadero.
syslog Envíe la salida del registro a syslog (además de stdout y stderr). El valor predeterminado es falso.
instalación de syslog La facilidad que se utiliza al enviar a syslog. Esto requiere el uso de -syslog. El valor predeterminado es LOCAL
simbólico El token de la API de Consul. No existe un valor predeterminado.
prefijo * El prefijo de origen, incluido el prefijo de destino de opciones, separado por dos puntos (:). Esta opción es aditiva y se puede especificar varias veces para que se repliquen varios prefijos.
excluir Un prefijo para excluir durante la replicación. Esta opción es aditiva y se puede especificar varias veces para excluir varios prefijos.
Espere El mínimo (: máximo) para esperar la estabilidad antes de replicar, separado por dos puntos (:). Si se omite el valor máximo opcional, se supone que es 4 veces el valor mínimo requerido. No existe un valor predeterminado.
rever La cantidad de tiempo que se debe esperar si Consule devuelve un error al comunicarse con la API. El valor predeterminado es 5 segundos.
config La ruta a un archivo de configuración o directorio de archivos de configuración en el disco, en relación con el directorio de trabajo actual. Los valores especificados en la CLI tienen prioridad sobre los valores especificados en el archivo de configuración. No existe un valor predeterminado.
nivel de registro El nivel de registro para la salida. Esto se aplica al registro stdout / stderr así como al registro syslog (si está habilitado). Los valores válidos son "debug", "info", "advertir" y "err". El valor predeterminado es "advertir".
una vez Ejecute Consule Replicate una vez y salga (a diferencia del comportamiento predeterminado del daemon). (Solo CLI)
versión Muestra la información de la versión y sal. (Solo CLI)

Tomando instantáneas

Las instantáneas son una parte esencial e importante para administrar el clúster de Consul en caso de respaldos. De forma predeterminada, Consul nos proporciona una forma de guardar instantáneas del clúster de cónsul. Consul nos proporciona cuatro subcomandos separados con los que podemos usar consul para crear instantáneas, que son:

  • Guardar instantánea de cónsul
  • Agente de instantáneas de cónsul
  • Inspección de instantánea de cónsul
  • Restauración de instantáneas de cónsul

Entendamos cada uno de estos en detalle.

Guardar instantánea de Consul

Este comando está configurado para recuperar una instantánea atómica y puntual del estado de los servidores Consul, que incluye entradas de clave / valor, catálogo de servicios, consultas preparadas, sesiones y ACL. La instantánea se guarda con el nombre de archivo mencionado.

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

La salida sería como se muestra en la siguiente captura de pantalla.

Para verificar la presencia del archivo en el directorio actual, verifíquelo ejecutándolo en su directorio actual. En el caso de un nodo no líder, ejecute el siguiente comando:

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

Agente de instantáneas de cónsul

Este subcomando inicia un proceso que toma instantáneas del estado de los servidores Consul y las guarda localmente, o las envía a un servicio de almacenamiento remoto opcional.

Inspección de instantáneas del cónsul

Se utiliza para inspeccionar la instantánea puntual del estado de los servidores Consul, que incluye entradas de clave / valor, catálogo de servicios, consultas preparadas, sesiones y ACL. El comando se puede ejecutar de la siguiente manera:

Note - Recuerde que el siguiente comando solo se puede ejecutar en el Directorio, donde se guarda la instantánea.

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

La salida sería como se muestra en la siguiente captura de pantalla.

Restauración de instantáneas de cónsul

El comando de restauración de instantáneas se utiliza para restaurar una instantánea puntual del estado de los servidores Consul, que incluye entradas de clave / valor, catálogo de servicios, consultas preparadas, sesiones y ACL. La instantánea se lee del archivo de respaldo guardado.

Note - Recuerde que el siguiente comando solo se puede ejecutar en el directorio donde se guarda la instantánea.

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

La salida sería como se muestra en la siguiente captura de pantalla.

Si está trabajando en Consul con AWS, este proyecto puede ayudarlo a ahorrar algo de tiempo: https://github.com/pshima/consul-snapshot.