Redis fornece alta disponibilidade via sistema distribuído Redis Sentinel. Sentinel ajuda a monitorar instâncias Redis, detectar falhas e realizar trocas de papéis automaticamente, possibilitando que uma implantação Redis resista a qualquer tipo de falha.
Ele oferece monitoramento de instâncias Redis (mestre e réplicas), suporta notificação de outros serviços/processos ou do administrador do sistema via script, failover automático para promover uma réplica a mestre quando o mestre falha e fornece configuração para clientes descobrirem o mestre atual que oferece um serviço específico.
Este artigo demonstra como configurar Redis para alta disponibilidade com Redis Sentinel no CentOS 8, incluindo a configuração de sentinelas, verificação do status da configuração e teste de um failover do Sentinel.
Pré-requisito:
Configuração do Ambiente de Test
Master Server and Sentinel1: 10.42.0.247 Redis Replica1 and Sentinel2: 10.42.0.21 Redis Replica2 and Sentinel3: 10.42.0.34
De acordo com a documentação do Redis Sentinel, é necessário ter pelo menos três instâncias do Sentinel para uma implantação robusta. Considerando nossa configuração acima, se o master falhar, os Sentinels2 e Sentinel3 concordarão sobre a falha e serão capazes de autorizar uma troca, permitindo que as operações do cliente continuem.
Passo 1: Iniciando e Habilitando o Serviço do Redis Sentinel
1. No CentOS 8, o serviço do Redis Sentinel é instalado junto com o servidor do Redis (o que já fizemos na Configuração de Replicação do Redis).
Para iniciar o serviço do Redis sentinel e habilitá-lo para iniciar automaticamente no boot do sistema, utilize os seguintes comandos do systemctl. Além disso, confirme que está em execução verificando seu status (faça isso em todos os nós):
# systemctl start redis-sentinel # systemctl enable redis-sentinel # systemctl status redis-sentinel
Passo 2: Configurando o Redis Sentinel em Todos os Nós do Redis
2. Nesta seção, explicamos como configurar o Sentinel em todos os nossos nós. O serviço do Sentinel possui um formato de configuração semelhante ao servidor do Redis. Para configurá-lo, utilize o arquivo de configuração auto-documentado /etc/redis-sentinel.conf.
Primeiramente, faça um backup do arquivo original e abra-o para edição.
# cp /etc/redis-sentinel.conf /etc/redis-sentinel.conf.orig # vi /etc/redis-sentinel.conf
3. Por padrão, o Sentinel escuta na porta 26379, verifique isso em todas as instâncias. Observe que você deve deixar o parâmetro bind comentado (ou definido como 0.0.0.0).
port 26379
4. Em seguida, informe ao Sentinel para monitorar nosso master, e considerá-lo no estado de “Objetivamente Inativo” somente se pelo menos 2 sentinelas de quórum concordarem. Você pode substituir “mymaster” por um nome personalizado.
#On Master Server and Sentinel1 sentinel monitor mymaster 127.0.0.1 6379 2 #On Replica1 and Sentinel2 sentinel monitor mymaster 10.42.0.247 6379 2 #On Replica1 and Sentinel3 sentinel monitor mymaster 10.42.0.247 6379 2
Importante: A declaração de monitoramento do sentinel DEVE ser colocada antes da declaração auth-pass do sentinel para evitar o erro “Nenhum mestre com o nome especificado” ao reiniciar o serviço do sentinel.
5. Se o mestre Redis a ser monitorado tiver uma senha definida (no nosso caso, o mestre tem), forneça a senha para que a instância do Sentinel possa autenticar-se com a instância protegida.
sentinel auth-pass mymaster Securep@55Here
6. Em seguida, defina o número de milissegundos que o mestre (ou qualquer réplica ou sentinel anexado) deve estar inacessível para considerá-lo no estado de “Subjetivamente Inativo”.
A configuração a seguir significa que o mestre será considerado falhando assim que não recebermos nenhuma resposta de nossos pings dentro de 5 segundos (1 segundo é equivalente a 1000 milissegundos).
sentinel down-after-milliseconds mymaster 5000
7. Em seguida, defina o tempo limite de failover em milissegundos que define muitas coisas (leia a documentação do parâmetro no arquivo de configuração).
sentinel failover-timeout mymaster 180000
8. Em seguida, defina o número de réplicas que podem ser reconfiguradas para usar o novo mestre após uma falha ao mesmo tempo. Como temos duas réplicas, vamos definir uma réplica como a outra será promovida para o novo mestre.
sentinel parallel-syncs mymaster 1
Observe que os arquivos de configuração no Redis Replica1 e Sentinel2, e Reddis Replica1 e Sentinel2 devem ser idênticos.
9. Em seguida, reinicie os serviços do Sentinel em todos os nós para aplicar as alterações recentes.
# systemctl restart redis-sentinel
10. Em seguida, abra a porta 26379 no firewall em todos os nós para permitir que as instâncias do Sentinel comecem a se comunicar, receber conexões das outras instâncias do Sentinel, usando o firewall-cmd.
# firewall-cmd --zone=public --permanent --add-port=26379/tcp # firewall-cmd --reload
11. Todas as réplicas serão descobertas automaticamente. É importante observar que o Sentinel atualizará automaticamente a configuração com informações adicionais sobre as réplicas. Você pode confirmar isso abrindo o arquivo de configuração do Sentinel para cada instância e verificando-o.
Por exemplo, quando você olha para o final do arquivo de configuração do mestre, você deve ver as declarações known-sentinels e known-replica como mostrado na captura de tela a seguir.
Deve ser o mesmo caso em replica1 e replica2.
Observe que a configuração do Sentinel também é reescrita/atualizada sempre que uma réplica é promovida ao status de mestre durante uma falha e sempre que um novo Sentinel é descoberto na configuração.
Passo 3: Verificar o Status da Configuração do Redis Sentinel
12. Agora verifique o status/informações do Sentinel no master, usando o comando info sentinel da seguinte forma.
# redis-cli -p 26379 info sentinel
A partir da saída do comando conforme visto na captura de tela a seguir, temos dois replicas/escravos e três sentinelas.
13. Para mostrar informações detalhadas sobre o master (chamado mymaster), use o comando sentinel master.
# redis-cli -p 26379 sentinel master mymaster
14. Para mostrar informações detalhadas sobre os escravos e sentinelas, use os comandos sentinel slaves e sentinel sentinels respectivamente.
# redis-cli -p 26379 sentinel slaves mymaster # redis-cli -p 26379 sentinel sentinels mymaster
15. Em seguida, pergunte o endereço do master pelo nome a partir das instâncias escravas usando o comando sentinel get-master-addr-by-name da seguinte forma.
A saída deve ser o endereço IP e porta da instância master atual:
# redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
Passo 4: Testar a Failover do Sentinel
16. Por fim, vamos testar a failover automática em nossa configuração do Sentinel. No master do Redis/Sentinel, faça o Redis master (rodando na porta 6379) dormir por 60 segundos. Em seguida, consulte o endereço do master atual nos replicas/escravos da seguinte forma.
# redis-cli -p 6379 127.0.0.1:6379> AUTH Securep@55Here 127.0.0.1:6379> debug sleep 60 # redis-cli -p 26379 sentinel get-master-addr-by-name mymaster # redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
A partir da saída da consulta, o novo master agora é replica/escravo2 com o endereço IP 10.42.0.34 conforme visto na captura de tela a seguir.
Você pode obter mais informações na documentação do Redis Sentinel. Mas se você tiver algum pensamento para compartilhar ou dúvidas, o formulário de feedback abaixo é sua porta de entrada para nós.
Na próxima e última parte desta série, vamos ver como configurar um Cluster Redis no CentOS 8. Será um artigo independente dos dois primeiros.
Source:
https://www.tecmint.com/setup-redis-high-availability-with-sentinel-in-centos-8/