Consul - Eventos de Failover

Neste capítulo, aprenderemos sobre os eventos de failover no Consul. Isso será feito com a ajuda das seguintes funcionalidades -

  • Falha de cluster único
  • Teste Jepsen
  • Falha de múltiplos clusters
  • Tirando fotos

Vamos entender cada um deles em detalhes.

Falha de cluster único

Em uma única falha de cluster, o cluster colocado em um dos datacenter começa a falhar. Em todos os cenários, é importante garantir que, em caso de failover, o sistema não apenas evite, mas também tenha um backup em que possa confiar. Para evitar eventos de failover do Consul, usaremos algo chamado de alertas do Consul. O projeto principal pode ser encontrado em -https://github.com/AcalephStorage/consul-alerts.

Consul-alerts é um daemon altamente disponível para o envio de notificações e lembretes com base nas verificações do Consul Health. Este projeto executa um daemon e API em localhost: 9000 e se conecta ao agente cônsul local (localhost: 8500) com o datacenter padrão (dc1).

Existem dois métodos para iniciar o projeto. O primeiro método é instalá-lo viaGO. Para usuários que têm GO instalado e configurado, eles podem seguir as etapas fornecidas abaixo -

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

O último comando pode ser facilmente usado para substituir as portas padrão para cônsul-alerta, opção de datacenter, cônsul-acl token, etc. O comando também pode ser escrito conforme fornecido abaixo -

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

O segundo método envolve o usuário no uso do Docker. Ambos os métodos são igualmente úteis em diferentes cenários. Para usar alertas Consul sobre Docker, vamos extrair a imagem do Docker Hub usando o seguinte comando.

$ docker pull acaleph/consul-alerts

No método Docker, podemos considerar as três opções a seguir -

  • Usando o Consul Agent que é construído no próprio contêiner.
  • Usando o Consul Agent em execução em outro Docker Container.
  • Usando os alertas do Consul para conectar-se a uma instância remota do Consul.

Vamos agora discutir ambos em detalhes.

Usando o Consul Agent que é construído no próprio contêiner

Vamos iniciar o agente cônsul usando o seguinte 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

Aqui, estamos substituindo o entrypoint para Consul como mencionado pela bandeira --entrypoint. Junto com ele, estamos inicializando o cliente, mencionando a porta usada usando-p flag, data directory /data usando o sinalizador -data-dir e client como 0.0.0.0.

Em uma nova janela de terminal, vamos iniciar a opção 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

Aqui, nas etapas acima, estamos executando os alertas-cônsules para iniciar no modo interativo. A porta do endereço de alerta é mencionada como 9000. O relógio verifica se os agentes do cônsul estão habilitados ou não junto com as verificações do cônsul.

Podemos ver claramente que os alertas cônsules foram iniciados facilmente e foi registrado um novo exame de saúde com a adição do agente cônsul. O datacenter é considerado dc1, podendo ser alterado de acordo com o usuário.

Usando o Consul Agent em execução em outro Docker Container

Aqui, você pode usar qualquer tipo de imagem de cônsul para ser executada no Docker Container. Usando a imagem de alertas do cônsul, podemos conectar facilmente o contêiner dos alertas do cônsul ao contêiner dos alertas do cônsul. Isso é feito usando o--link flag.

Note - Antes de usar o seguinte comando, certifique-se de que o container cônsul já esteja rodando em outro 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

Usando os alertas do Consul para conectar-se a uma instância remota do Consul

Aqui, devemos usar o seguinte comando para usar os alertas do Cônsul para conectar-se a uma instância remota do Cônsul.

$ 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

Teste Jepsen

Jespen é uma ferramenta escrita para testar a tolerância parcial e a rede em qualquer sistema. Ele testa o sistema criando algumas operações aleatórias no sistema.Jepsen is written in Clojure. Infelizmente, para demonstração, o teste Jepsen requer um grande nível de formação de cluster com sistemas de banco de dados e, portanto, está fora do escopo de ser abordado aqui.

Jepsen funciona configurando o armazenamento de dados em teste em cinco hosts diferentes. Ele cria um cliente, para o armazenamento de dados em teste, apontando cada um dos cinco nós para enviar solicitações. Ele também cria uma série especial de cliente (s) chamado (s) de "Nemesis", que causa estragos no cluster, como cortar links entre nós usandoiptables. Em seguida, ele prossegue para fazer solicitações simultaneamente em nós diferentes, ao mesmo tempo que particiona e corrige alternadamente a rede.

No final da execução do teste, ele recupera o cluster, aguarda a recuperação do cluster e verifica se o estado intermediário e final do sistema é o esperado. Alguns trechos foram retirados daqui .

Para obter mais informações sobre os testes Jepsen, verifique aqui .

Falha de múltiplos clusters

Durante um evento de failover de vários clusters, os clusters implantados em vários datacenters falham em oferecer suporte aos serviços com suporte para o cliente. A Consul nos permite garantir que, quando ocorrer uma dessas condições, a Consul tenha recursos que o ajudem a habilitar os serviços neste tipo de condições.

Para que isso aconteça, examinaremos um projeto que nos ajuda a habilitar a replicação do Consul de um cluster para vários clusters. O projeto nos fornece uma maneira de replicar pares K / V em vários centros de dados do Consul usando o daemon de replicação do consul. Você pode ver este projeto da Hashicorp em -https://github.com/hashicorp/consul-replicate. Alguns dos pré-requisitos para experimentar este projeto incluem:

  • Golang
  • Docker
  • Consul
  • Git

Vamos começar com os seguintes comandos -

Note - Antes de executar o seguinte comando, certifique-se de ter o Git instalado e configurado corretamente em sua máquina.

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

A saída seria conforme mostrado na captura de tela a seguir.

$ cd consul-replicate
$ make

A saída seria conforme mostrado na captura de tela a seguir.

Se você estiver tendo problemas para construir o binário, também pode tentar extrair as imagens do Docker manualmente usando o seguinte comando -

$ docker pull library/golang:1.7.4

O comando mencionado acima criará bin / consul-replicate, que pode ser chamado como um binário. A tabela a seguir mostra a lista completa de subcomandos que cobre -

Opção Descrição
auth O nome de usuário de autenticação básica (e senha opcional), separados por dois pontos. Não há valor padrão.
cônsul * A localização da instância do cônsul a ser consultada (pode ser um endereço IP ou FQDN) com a porta.
max-velho A desatualização máxima de uma consulta. Se especificado, o Consule distribuirá o trabalho entre todos os servidores, em vez de apenas o líder. O valor padrão é 0 (nenhum).
ssl Use HTTPS ao falar com o Consul. Requer que o servidor consule seja configurado para conexões seguras do servidor. O valor padrão é falso.
ssl-verificar Verifique os certificados ao conectar-se via SSL. Isso requer o uso de -ssl. O valor padrão é verdadeiro.
syslog Envie a saída de log para syslog (além de stdout e stderr). O valor padrão é falso
instalação de syslog A facilidade a ser usada ao enviar para o syslog. Isso requer o uso de -syslog. O padrão é LOCAL
símbolo O token Consul API. Não há valor padrão.
prefixo * O prefixo de origem, incluindo o prefixo de destino, com opções, separado por dois pontos (:) Esta opção é aditiva e pode ser especificada várias vezes para que vários prefixos sejam replicados.
excluir Um prefixo a ser excluído durante a replicação. Esta opção é aditiva e pode ser especificada várias vezes para que vários prefixos sejam excluídos.
esperar O mínimo (: máximo) a esperar pela estabilidade antes de replicar, separado por dois pontos (:) Se o valor máximo opcional for omitido, será considerado 4x o valor mínimo exigido. Não há valor padrão.
tentar novamente A quantidade de tempo de espera se o Consule retornar um erro ao se comunicar com a API. O valor padrão é 5 segundos.
config O caminho para um arquivo de configuração ou diretório de arquivos de configuração no disco, relativo ao diretório de trabalho atual. Os valores especificados na CLI têm precedência sobre os valores especificados no arquivo de configuração. Não há valor padrão.
nível de registro O nível de registro para saída. Isso se aplica ao registro stdout / stderr, bem como ao registro syslog (se ativado). Os valores válidos são "debug", "info", "warn e" err ". O valor padrão é" warn ".
uma vez Execute o Consule Replicate uma vez e saia (ao contrário do comportamento padrão do daemon). (Somente CLI)
versão Gerar informações sobre a versão e sair. (Somente CLI)

Tirando fotos

Os instantâneos são uma parte essencial e importante para gerenciar o cluster Consul em caso de backups. Por padrão, o Consul nos fornece uma maneira de salvar instantâneos do cluster do consul. O Consul nos fornece quatro subcomandos separados, usando os quais podemos usar o consul para criar instantâneos, que são -

  • Salvar instantâneo do cônsul
  • Agente instantâneo do cônsul
  • Inspecionar instantâneo do cônsul
  • Restauração instantânea do Consul

Vamos entender cada um deles em detalhes.

Cônsul Instantâneo Salvar

Este comando é configurado para recuperar um instantâneo atômico de um momento específico do estado dos Servidores Consul, que inclui Entradas de Chave / Valor, Catálogo de Serviços, Consultas Preparadas, Sessões e ACLs. O instantâneo é salvo com o nome de arquivo mencionado.

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

A saída seria conforme mostrado na captura de tela a seguir.

Para verificar a presença do arquivo no diretório atual, verifique-o executando-o no diretório atual. No caso de um nó não líder, execute o seguinte comando -

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

Agente Instantâneo Cônsul

Este subcomando inicia um processo que tira instantâneos do estado dos servidores Consul e os salva localmente ou os envia para um serviço de armazenamento remoto opcional.

Consulta Instantânea Inspeção

Ele é usado para inspecionar o instantâneo point-in-time do estado dos servidores Consul, que inclui entradas de chave / valor, catálogo de serviços, consultas preparadas, sessões e ACLs. O comando pode ser executado da seguinte forma -

Note - Lembre-se de que o seguinte comando só pode ser executado no Diretório onde o instantâneo é salvo.

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

A saída seria conforme mostrado na captura de tela a seguir.

Cônsul Snapshot Restore

O comando snapshot restore é usado para restaurar um instantâneo point-in-time do estado dos servidores Consul, que inclui entradas de chave / valor, catálogo de serviço, consultas preparadas, sessões e ACLs. O instantâneo é lido do arquivo de backup salvo.

Note - Lembre-se de que o seguinte comando só pode ser executado no diretório onde o instantâneo foi salvo.

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

A saída seria conforme mostrado na captura de tela a seguir.

Se você está trabalhando no Consul com a AWS, este projeto pode ajudá-lo a economizar algum tempo - https://github.com/pshima/consul-snapshot.