Redis Sentinel

Suponha um cenário em que você tenha apenas uma instância Redis em sua produção e falha em algum momento devido a algum motivo. Seu aplicativo cache os dados no armazenamento de dados Redis e agora sua única fonte de dados está morta. Uma maneira de controlar esse tipo de cenário é manter a arquitetura mestre-escravo, onde os escravos podem replicar o nó mestre até que ele volte. Clusters Redis suportam alta disponibilidade até certo ponto com a abordagem mestre-replica. Redis Sentinel é outra abordagem que fornece uma maneira mais confiável de manter a alta disponibilidade de instâncias Redis. Ele monitora o nó Redis Master para falhas e desencadeia o processo de failover imediatamente, o que promoverá um nó de escravo existente para um novo mestre.

Além disso, o Redis Sentinel atua como um homem intermediário, onde os clientes se conectam e pedem o último endereço IP do nó mestre. Portanto, o Sentinel conectado fornece o endereço do nó principal imediatamente.

Além disso, uma falha do nó mestre é confirmada se vários sentinels concordaram que um determinado mestre não estiver alcançável ou disponível. Isso conclui a fase de detecção de falhas e o processo de failover começa imediatamente. Portanto, o Redis Sentinel pode ser visto como um sistema distribuído com propriedades específicas.

O acordo de Sentinels é baseado em um valor de quorum que será discutido na seção a seguir.

Valor quorum

O valor do quorum é o número máximo de sentinelas que precisam ser acordadas quando o nó mestre está inativo. Este valor é usado apenas para identificar uma falha no nó principal. O processo de failover começa com a autorização de vários nós Sentinel disponíveis para prosseguir com um Sentinel selecionado como líder.

Recursos do Redis Sentinel

O Sentinel é conhecido por fornecer um mecanismo de alta disponibilidade para o Redis Data Store. Além disso, vários outros recursos podem ser listados.

• Sentinel monitora continuamente o status dos nós mestre e escravo em seu sistema Redis.
• Sempre que há um fracasso ou algo errado com suas instâncias Redis, o Sentinel é capaz de notificar o administrador ou aplicativos conectados usando a API Sentinel.
• A fase de failover é dirigida pelo Sentinel, promovendo uma réplica como o novo mestre. Replicas restantes configuradas para usar o novo mestre. Finalmente, os clientes correspondentes serão notificados do novo endereço de nó principal.
• Além disso, o Redis Sentinel é um provedor de configuração para os clientes conectados, onde os clientes podem solicitar o endereço da instância mestre atualmente disponível e, se ocorreu um colapso repentino, o Sentinel está comprometido em pressionar o novo endereço do nó mestre imediatamente.

Na próxima seção, configuraremos o Redis Sentinels com instâncias da Mestre-Replica e usando a API Sentinel para monitorar os nós.

Configuração do Sentinel

Primeiro, criamos duas instâncias Redis nas portas 7000 e 7001. A porta 7000 será o nó principal e o outro replica o mestre. Ambas as instâncias usam os seguintes arquivos de configuração, respectivamente:

Configuração do nó principal

Porta 7000
habilitado para cluster não
nós de arquivo de configamento de cluster.conf
Tempo de nó de cluster 5000
apendonly sim

Configuração do nó escravo

Porta 7001
habilitado para cluster não
nós de arquivo de configamento de cluster.conf
Tempo de nó de cluster 5000
apendonly sim

Ambas as instâncias começarão fornecendo o arquivo de configuração associado a cada. Podemos usar o seguinte comando para iniciar instâncias Redis separadamente:

Redis-Server Redis.conf

Vamos nos conectar à instância Redis iniciada na porta 7001 da seguinte forma:

Redis -cli -p 7001

Agora, podemos fazer desta instância uma réplica do mestre que está em execução na porta 7000. A réplica do comando pode ser usada da seguinte maneira:

Réplica de 127.0.0.1 7000

Como esperado, a instância em execução na porta 7001 tornou -se o nó de réplica do mestre em execução na porta 7000.

Agora, estamos prontos para configurar três Redis Sentinels para monitorar a instância mestre acima. Precisamos ter três arquivos de configuração para criar três instâncias do Sentinel nas portas 5000, 5001 e 5002, como mostrado no seguinte.

Cada sentinela.conf O arquivo parece o seguinte, exceto que o número da porta será alterado:

porta 5000
Sentinel Monitor MasterNode 127.0.0.1 7000 2
Sentinel Down-After-milissegunds MasterNode 5000
Sentinel Failover-timeout MasterNode 60000

Agora, é hora de executar os três sentinels. Você pode usar o executável Redis-Sentinel junto com o caminho para sentinela.conf arquivo de configuração para criar uma instância do Sentinel. Caso contrário, ainda podemos chamar o Redis-Server de executável especificando o caminho para sentinela.conf e a bandeira -sentinela.

Vamos começar cada Sentinel usando o seguinte comando:

Redis-Server Sentinel.conf - -sentinel

O primeiro Sentinel foi iniciado na porta 5000. Da mesma forma, você pode começar as outras duas instâncias também.

Agora, nossa configuração Redis Sentinel está em funcionamento, conforme mostrado na seguinte ilustração:

Na seção a seguir, exploraremos mais sobre a API Sentinel e como podemos utilizá -la para recuperar informações relacionadas ao nó Redis Master.

Sentinel API

Redis fornece uma API Sentinel separada para monitorar mestres e réplicas associados, assinar as notificações e modificar as configurações do Sentinel. Além disso, vários usos estão listados no seguinte.

• Verifique o status das instâncias monitoradas do Redis Master e Slave
• Detalhes sobre outros sentinels
• Receba notificações no estilo push de Sentinels em um caso de failover

O comando Sentinel pode ser usado com seus subcomandos associados para consultar, atualizar ou definir Redis Sentinels e nós monitorados.

Verifique o status do nó mestre

É muito importante monitorar ou verificar a saúde do nó principal de tempos em tempos. O comando Sentinel API a seguir pode ser usado para recuperar detalhes mestre:

Sentinel Master

monitored_master_name: O nome do nó principal especificado no arquivo de configuração do Sentinel que criamos na etapa anterior.

Vamos usar este comando para consultar o status mestre em nossa configuração. No nosso caso, o nome do nó principal é 'MasterNode'.

Sentinel Master MasterNode

Várias informações foram recuperadas e algumas delas são importantes, como escravos, bandeiras e números-outros-sentinels.

O bandeiras A propriedade está definida como mestre o que significa que o mestre está de boa saúde. Sempre que o nó mestre está inativo, o s_down ou O_down Bandeira será exibida. A propriedade num vários-sentinelas está definido como 2, o que significa que o Redis Sentinel já reconheceu os outros dois sentinelas para o nó mestre. Além disso, o números escravos A propriedade exibe as réplicas disponíveis para o nó principal. Nesse caso, está definido como 1, pois temos apenas uma réplica.

Obtenha informações sobre réplicas conectadas

Podemos verificar as réplicas conectadas com o nó principal usando o seguinte Sub Command:

Replicas Sentinel

Neste exemplo, o nome principal é 'masternode'.

Sentinel Replicas MasterNode

Como esperado, o Sentinel detectou o nó escravo em execução na porta 7001.

Obtenha informações sobre Sentinels associados

Da mesma forma, podemos consultar os detalhes relacionados a outros sentinelas associados ao nó mestre atual usando o seguinte subcomando Sentinel:

Sentinel Sentinels

Nesse caso, estaremos buscando as informações relacionadas ao nó mestre chamado 'masternode'.

Sentinel Sentinels MasterNode

Obtenha o endereço do nó principal

Como mencionado na seção anterior, Redis Sentinel é um provedor de configuração para clientes conectados. Portanto, é capaz de fornecer o endereço IP e a porta do nó principal no momento em execução para os clientes solicitados. O seguinte subcomando Sentinel API pode ser usado para recuperar as informações mencionadas.

Sentinel Get-mestres-addr-by-name

Vamos executar o comando acima para o nosso cenário da seguinte maneira:

Sentinel Get-mestres-addr-by-name MasterNode

Discutimos apenas alguns comandos da API Sentinel. Vários outros subcomandos estão disponíveis, como Sentinel-Failover, Sentinel Info-Cache, Sentinel Masters e etc. Além disso, muitos comandos estão disponíveis para fins de administração também. Na seção a seguir, focaremos no processo de failover Redis Sentinel.

Processo de failover do Sentinel

Como o nosso Sentinel está configurado, podemos testar a fase de falha. Vamos enviar nosso nó mestre para dormir por 300 segundos, o que simula uma falha no nó mestre.

Debug Sleep 300

O nó mestre que está em execução na porta 7000 deve ser inacessível agora. Então, Sentinels associados notará que o mestre não está disponível com o +S. ROWN evento. Então, isso será definido como +Odown onde 2 sentinelas confirmam que o nó mestre está inativo de acordo com o valor do quorum. Finalmente, a fase de failover será iniciada e, idealmente, a réplica deve ser promovida ao novo mestre.

Vamos verificar o endereço IP do nó principal e a porta novamente.

Sentinel Get-mestres-addr-by-name MasterNode

Como esperado, a réplica anterior foi promovida ao novo mestre, o que significa que o processo de failover do Sentinel é bem -sucedido. Isso conclui a implantação e o teste de nossas três configurações de Sentinel para um único par mestre-replica.

Conclusão

Redis Sentinel é a abordagem mais confiável para garantir a alta disponibilidade de uma determinada instância de réplica Redis Master. Um sentinela é capaz de monitorar, notificar e iniciar failover automático sem intervenção humana. Além disso, vários sentinelas juntos concordam com o fato de que o nó principal é inacessível e o valor do quorum é usado como o número máximo de sentinelas que precisam ser acordados ao verificar a disponibilidade da instância mestre. Redis Sentinel oferece uma API fácil de usar para recuperar informações sobre a saúde do nó mestre e réplicas associadas e executar tarefas administrativas também.