Redis Sentinel: Alta Disponibilidade em Ambientes Cloud

Introdução à Alta Disponibilidade com Redis Sentinel

A infraestrutura moderna exige resiliência e tolerância a falhas. Em ambientes de cloud hosting, onde a escalabilidade é fundamental, o uso de bancos de dados NoSQL como o Redis tornou-se padrão para cache, filas de mensagens e sessões de usuário. No entanto, uma instância única de Redis representa um ponto único de falha (SPOF). Se o servidor cair, sua aplicação perde acesso aos dados em memória instantaneamente.

Para mitigar esse risco, a solução robusta é implementar Redis Sentinel. O Sentinel é um sistema que monitora seus servidores Redis e realiza operações de failover automático quando uma instância primária falha. Ele combina as capacidades do redis replication (replicação) com a capacidade de eleger um novo mestre automaticamente, garantindo que sua aplicação continue funcionando sem intervenção humana.

Neste tutorial, configuraremos um cluster de alta disponibilidade composto por três servidores Linux: um nó Primário (Master), dois Réplicas (Slaves) e três nós de Sentinel. Esta arquitetura distribui a carga e garante que o sistema sobreviva à queda de múltiplos nós, desde que a maioria esteja online.

Arquitetura do Ambiente

Vamos utilizar seis instâncias em total, distribuídas da seguinte forma para fins didáticos (em produção, você pode consolidar Sentinels nos próprios nós de dados se houver recursos suficientes):

• Nó Master: redis-master (192.168.1.10)
• Nó Replica 1: redis-replica-1 (192.168.1.11)
• Nó Replica 2: redis-replica-2 (192.168.1.12)
• Sentinel 1: sentinel-node-1 (192.168.1.13)
• Sentinel 2: sentinel-node-2 (192.168.1.14)
• Sentinel 3: sentinel-node-3 (192.168.1.15)

Todos os nós devem rodar uma distribuição Linux compatível (Ubuntu, Debian ou CentOS) com o serviço firewall configurado para permitir comunicação na porta 6379 (Redis) e 26379 (Sentinel).

Passo 1: Instalação e Configuração do Redis no Nó Master

A primeira etapa é instalar o servidor Redis em todos os nós. Para simplificar, assumiremos que o comando de instalação é universal para sua distribuição.

sudo apt update
sudo apt install redis-server -y

Após a instalação, precisamos configurar o nó Master. Edite o arquivo /etc/redis/redis.conf. A configuração padrão geralmente permite conexões apenas de localhost. Para permitir que os réplicas e sentinel se conectem, altere a diretiva bind.

Encontre a linha:

bind 127.0.0.1 ::1

Altere para o endereço IP do Master ou use 0.0.0.0 se sua rede interna for confiável e segura via firewall:

bind 0.0.0.0 -::1

É altamente recomendável proteger a comunicação com uma senha, especialmente em ambientes cloud. Defina um masterauth e uma requirepass.

requirepass MinhaSenhaSegura123
masterauth MinhaSenhaSegura123

O parâmetro masterauth é crucial: ele diz ao Redis como se autenticar quando ele próprio atua como réplica de outro nó. Salve o arquivo e reinicie o serviço.

sudo systemctl restart redis-server
sudo systemctl enable redis-server

Passo 2: Configuração dos Nós Réplica (Slaves)

Agora, vamos configurar os nós que receberão os dados do Master. Repita a instalação do Redis nos nós redis-replica-1 e redis-replica-2.

No arquivo de configuração /etc/redis/redis.conf de cada réplica, faça as seguintes alterações:

1. Altere o bind para permitir conexões externas, assim como no Master.
2. Defina a mesma senha de requisição: requirepass MinhaSenhaSegura123.
3. Defina o mesmo masterauth: masterauth MinhaSenhaSegura123.
4. Configure a diretiva replicaof (ou slaveof, dependendo da versão) apontando para o IP do Master.

replicaof 192.168.1.10 6379
masterauth MinhaSenhaSegura123
requirepass MinhaSenhaSegura123

Reinicie o Redis em ambos os réplicas.

sudo systemctl restart redis-server

Para verificar se a replicação está funcionando, conecte-se ao Master e execute:

redis-cli -a MinhaSenhaSegura123 info replication

Você deve ver uma seção connected_slaves: 2 listando os IPs dos dois réplicas. Se o status mostrar slave: online, a configuração básica de banco de dados vps está concluída.

Passo 3: Configuração do Redis Sentinel

O Sentinel não precisa ser um nó dedicado, mas separá-lo melhora a resiliência. Crie o arquivo /etc/redis/sentinel.conf em cada um dos três nós de Sentinel (13, 14 e 15). A configuração é idêntica para todos eles.

O conteúdo do sentinel.conf deve ser:

port 26379
dir /tmp

# Monitorar o Master chamado "mymaster"
# O sentinel espera que pelo menos 2 outros sentinels concordem que o master está down
sentinel monitor mymaster 192.168.1.10 6379 2

# Senha do Master para autenticação
sentinel auth-pass mymaster MinhaSenhaSegura123

# Tempo em milissegundos para considerar o master down (failover)
sentinel down-after-milliseconds mymaster 5000

# Tempo máximo que um novo slave deve tentar replicar após o failover
sentinel parallel-syncs mymaster 1

# Timeout da conexão com o master durante o failover
sentinel failover-timeout mymaster 60000

Tuning Redis Sentinel: O parâmetro quorum (o número "2" na linha monitor) é vital. Ele define quantos sentinel devem concordar que o master está inativo para iniciar um failover. Com 3 sentinel, 2 é a maioria. Isso evita split-brain em caso de particionamento de rede.

Inicie o serviço Sentinel em cada nó usando:

sudo redis-sentinel /etc/redis/sentinel.conf

Para torná-lo persistente, crie um systemd service ou adicione ao /etc/rc.local, dependendo da sua distribuição.

Passo 4: Testando a Alta Disponibilidade

Agora vem o momento da verdade. Vamos simular uma falha no Master e observar o comportamento do sistema.

Primeiro, verifique quem é o mestre atual via um dos sentinel:

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

O resultado deve ser (nil) inicialmente ou o IP do seu master. Vamos parar o serviço Redis no nó 192.168.1.10.

sudo systemctl stop redis-server

Aguarde cerca de 5 a 10 segundos. Em seguida, verifique novamente o endereço do mestre:

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

Você deve ver que o IP mudou para um dos réplicas (ex: 192.168.1.11). O Sentinel detectou a falha, promoveu um novo Master e atualizou os outros nós.

Atenção: Sua aplicação precisa estar configurada para consultar o Sentinel, e não o IP fixo do Master. Se estiver usando uma biblioteca cliente Redis (como redis-py, node-redis, jedis), configure-a para apontar para os IPs dos Sentinels e usar o nome "mymaster" como alvo.

Passo 5: Monitoramento Redis e Tuning de Performance

A configuração básica está feita, mas um ambiente de produção requer monitoramento contínuo e ajustes finos (tuning redis). O redis-cli oferece ferramentas poderosas para isso.

Monitoramento em Tempo Real

Use o comando INFO para obter métricas detalhadas:

redis-cli -a MinhaSenhaSegura123 info memory
redis-cli -a MinhaSenhaSegura123 info stats

Para monitorar as operações em tempo real, use MONITOR. Cuidado: isso é pesado para a CPU.

redis-cli MONITOR

Ajustes de Configuração (Tuning)

O arquivo redis.conf possui dezenas de opções. As mais críticas para performance em VPS são:

• maxmemory: Defina um limite máximo de memória RAM que o Redis pode usar. Sem isso, ele pode consumir toda a RAM do servidor e causar OOM (Out of Memory) kills pelo kernel Linux. Exemplo: maxmemory 2gb.
• maxmemory-policy: Define como o Redis se comporta quando atinge o limite. Para cache, use allkeys-lru (Least Recently Used). Para filas, use noeviction para retornar erro em vez de perder dados.
• tcp-keepalive: Mantém conexões abertas ativas. Um valor de 300 segundos ajuda a evitar timeouts em balanceadores de carga.

Após alterar redis.conf, aplique as mudanças sem reiniciar (se o comando for suportado pela versão) ou reinicie o serviço:

redis-cli -a MinhaSenhaSegura123 config set maxmemory 2gb
redis-cli -a MinhaSenhaSegura123 config rewrite

O comando config rewrite atualiza o arquivo de configuração em disco para refletir as mudanças dinâmicas.

Boas Práticas e Considerações Finais

A implementação de Redis Sentinel é um passo essencial para profissionais de TI que buscam robustez. No entanto, lembre-se das seguintes práticas:

1. Dados Efêmeros: O Redis é otimizado para memória. Se você usa o Redis como banco de dados persistente principal, certifique-se de configurar RDB snapshots ou AOF (Append Only File) no arquivo redis.conf. Sem isso, ao reiniciar um nó após uma falha, ele perderá os dados recentes.
2. Segurança: Sempre use requirepass. Em ambientes cloud, nunca exponha a porta 6379 na internet. Use VPCs ou redes privadas para a comunicação entre Master, Slaves e Sentinels.
3. Latência de Rede: O Sentinel depende de mensagens heartbeat. Se sua infraestrutura linux estiver em zonas de disponibilidade diferentes com alta latência, ajuste o down-after-milliseconds para evitar failovers desnecessários (flapping).

A combinação de redis replication, automação do Sentinel e monitoramento adequado transforma uma instância vulnerável em um serviço de infraestrutura linux altamente disponível. Com essa base, sua aplicação estará preparada para lidar com picos de tráfego e falhas de hardware sem interrupção perceptível para o usuário final.

Agora que você domina a configuração básica, explore integrações com ferramentas como Prometheus e Grafana para visualização gráfica do estado do seu cluster Redis em cloud hosting.