Guia definitivo: otimize o acesso a dados com Redis em Alta Disponibilidade

Aprenda como implantar a solução Redis para otimização de acessos em memória em Alta Disponibilidade e com a criação de um cluster com failover automatizado com Redis Sentinel

Redis é um projeto Open Source muito usado para armazenamento de dados em memória. Fundamentalmente é adotado para otimização de uso de recursos, como acesso a bancos de dados já que responde com baixa latência e alta capacidade de transferência de dados.

Essa otimização no acesso a dados pode ser feita por uso de cache de resultados de consultas em banco dentro de estruturas de dados Redis ou pelo uso de Redis como intermediário entre a gravação de fato no banco de dados e a aplicação, funcionando como mecanismo de buffering/armazenamento temporário assíncrono otimizando recursos de sistemas gerenciadores de bancos de dados.

Em outros cenários, a API simples permite que estruturas de dados como listas e chaves possam ser usados para integração entre aplicações permitindo que seja um intermediário para compartilhamento de dados
e sinalização.

Instalação

Em Red Hat Enterprise Linux ou CentOS 7, o Redis pode ser instalado através de pacotes EPEL:

sudo yum -y install epel-release
sudo yum -y install Redis

O pacote Redis instalado já vem com um cliente que pode ser usado para manusear dados.

Por padrão, o Redis recém instalado usa a porta 6379 e escuta apenas em localhost e por padrão o cliente, redis-cli, tenta conexão usando este padrão.

Assim, para conectar-se ao Redis recém instalado, basta digitar

redis-cli

E com isso, o prompt de comando do cliente Redis é exibido e aguarda comandos:

127.0.0.1:6379>

Para testar a instalação, insira um par chave valor usando o comando SET

127.0.0.1:6379> SET var0 1000
OK

e leia o valor gravado usando o comando GET:

127.0.0.1:6379> GET var0
“1000”

Para os casos de uso como armazenamento de dados para caching, a aplicação pode ser arquitetada para usar leitura direta em banco nos casos de indisponibilidade do Redis.

Nos casos de uso do Redis como mecanismo de integração ou como mecanismo de pré-gravação assíncrona, a indisponibilidade dos serviços Redis pode implicar na perda real de dados e indisponibilidade ou comportamento não esperado das aplicações.

Redis Master-Slave

Desde a versão 3.0.0-rc1 o projeto Redis possibilita a criação de cluster para replicação de dados em um modelo mestre – escravo. O Redis Cluster não precisa de software adicional e pode ser montado apenas com os pacotes nativos de Redis.

A arquitetura definida no Redis em modo mestre/escravo não promove um nó de forma nativa e precisa de uma ferramenta do próprio Redis (Sentinel) para monitorar os nós e promover escravos em mestres na configuração e notificar todos os nós Redis.

Redis Sentinel

Cenário: O Redis Cluster pode fornecer escalabilidade, mas o endereço do mestre muda quando o mestre falha e ocorre eleição.

Mais recentemente, o projeto Redis inseriu o recurso chamado Sentinel, um serviço adicional que permite verificar a saúde dos nós Redis e agir diretamente na configuração dos nós em caso de falha do mestre para eleger um novo mestre e redirecionar os nós restantes para este
novo mestre.

O Redis, tanto no Redis Sentinel usa o mecanismo de eleição entre os nós para decidir qual nó pode virar mestre e qual nó está ativo na replicação, além de resolver casos de possíveis inconsistências. É por este mecanismo de eleição que tanto o Redis Sentinel quanto o Redis Cluster devem ter pelo menos 3 nós para evitar “empates” em situações de eleição ou de validação de dados.

Essencialmente, o Redis, em modo mestre escravo, tenta garantir a replicação de dados entre nós participantes, em um número mínimo de 3 nós, enquanto o Redis Sentinel, também em um número minimo de 3 nós, tenta garantir que exista um mestre saudável através de monitoramento de sáude e reconfiguração de arquivos dos nós quando necessário. É importante saber que o Redis Sentinel não cuida de trocar endereços de rede ou nomes de rede. Assim, o mestre pode mudar de nó, mas o cliente pode não saber como acessar um endereço alternativo ou não está preparado para responder a “dicas” de “novo mestre” .

A configuração com nós Sentinel pode ser montado apenas com os pacotes nativos de Redis.

HAProxy

Problema: O cliente Redis não pode ser configurado para usar vários endereços ou não se redireciona automaticamente para um novo mestre em caso de falha.

O HAProxy é um balanceador de rede com muitos recursos, um deles é fundamental para esta arquitetura: a possibilidade de ler pacotes de rede e criar filtros baseados em strings específicas.

Isso permite usar o HAProxy para fazer o balanceamento entre os nós de Redis e ainda detectar qual deles é o nó mestre. Contudo uma instância apenas de HAProxy passa a ser o ponto de falha único da solução.

Para instalação:

yum -y install haproxy

Keepalived

Problema: Uma única instância de HAProxy é o ponto de falha único desta arquitetura

Para garantir que os clientes Redis enxerguem um endereço em alta disponibilidade, o serviço Keepalived pode gerenciar a ativação e desativação de um endereço IP em duas máquinas HAProxy. Assim, na visão dos clientes, existe um endereço IP para Redis.

No caso de falha de uma máquina HAProxy, o serviço de keepalived da outra máquina cuida de ativar o endereço IP conhecido pelos clientes. Isso aliado a replicação e garantia de saúde e eleição de mestres do conjunto Redis Cluster e Redis Sentinel garantem que será necessário falhas em multiplos pontos para causar indisponibilidade.

Para instalação:

yum -y install keepalived

Mãos a obra:

1) O setup precisaria de 8 máquinas:

2 para HAProxy em alta disponibilidade com keepalived

3 para Sentinel, uma para cada Redis Sentinel

3 para o Redis Cluter, uma para cada nó,

Aqui, a arquitetura vai ser simplificada para que cada Sentinel esteja instalado em cada máquina com nó do Redis Cluster.

Instalações Redis

Os endereços e nomes devem ser configurados em /etc/hosts, /etc/hostname e/ou DNS:

192.168.56.115 redis
192.168.56.116 redisa
192.168.56.117 redisb
192.168.56.222 redisvip

Configuração do nó redis

Inicialmente mestre configurado com /etc/redis.conf abaixo:

bind redis
port 6379
dir “/var/lib/redis”
Configuração do nó redisa

Escravo configurado em /etc/redis.conf abaixo

bind redisa
port 6379
dir “/var/lib/redis”
slaveof 192.168.56.115 6379

Configuração do nó redisb

Escravo configurado em /etc/redis.conf abaixo

bind redisb
port 6379
dir “/var/lib/redis”
slaveof 192.168.56.115 6379

Para o Redis Sentinel, o arquivo de configuração é igual em todos os nós e armazenado em cada máquina Redis em /etc/redis-sentinel.conf

bind redis
port 26379
sentinel monitor redis-cl 192.168.56.115 6379 2
sentinel down-after-milliseconds redis-cl 10000

Cada Sentinel subirá em uma porta distinta do nó de atendimento do Redis Cluster. Quem atende a requisições é o nó do Redis na porta 6379. O Sentinel cuida da verificação da saúde de nos e reconfiguração de um novo mestre em caso de falha.

Instalações HAProxy e keepalived

Preferencialmente, as máquinas devem ter endereço IP para acesso remoto em rede distinta do endereço compartilhado via keepalived. Nesta arquitetura, as máquinas tem endereço 192.168.56.101 (ativo) e 192.168.56.102 (passivo)

No endereço virtual compartilhado 192.168.56.222, o HAProxy escuta o protocolo Redis e DIRECIONA as gravações para o master Redis. O HAProxy foi usado ao invés de LVS nativo do keepalived por permitir inspecionar os pacotes e detectar quem é o master. Isso é fundamental para o cenário de múltiplos slaves Redis com múltiplos sentinels onde um novo mestre é eleito no caso de falha do primário. Dois slaves são necessários para garantir essa eleição.

HaProxy

O arquivo do HAProxy deve ser configurado em /etc/haproxy/haproxy.cfg em cada máquina HAProxy. A parte específica para esta arquitetura é o uso da opção tcp-check do HaProxy com inspeção de pacotes para verificar quem é o nó mestre através de comunicação com os nós Redis.

defaults Redis
mode tcp
timeout connect 5s
timeout server 10s
timeout client 10s
frontend RedisFrontend
  bind *:6379 name Redis
default_backend RedisBackend
backend RedisBackend
   option tcp-check
   tcp-check connect
   tcp-check send PING\r\n
   tcp-check expect string +PONG
   tcp-check send info\ replication\r\n
   tcp-check expect string role:master
   tcp-check send QUIT\r\n
   tcp-check expect string +OK
   server Redis_6379 Redis:6379 check inter 2s
   server Redisa_6379 Redisa:6379 check inter 2s
   server Redisb_6379 Redisb:6379 check inter 2s

Keepalived Nó ativo (MASTER) HaProxy

O arquivo de configuração do Keepalived estará em /etc/keepalived/keepalived.conf e neste exemplo simplificado, checa a existência de um processo HAProxy (linha sscript com checagem de processo via pidof) e dispara virada de endereço IP no caso de falha. Troque a interface de rede enp0s8 pela interface que responderá pelo endereço compartilhado. Uma autenticação simples é feita entre os nos keepalived.

global_defs {
notification_email {
consultoria@4linux.com.br
}
notification_email_from consultoria@4linux.com.br
smtp_server localhost
smtp_connect_timeout 30
}
vrrp_script chk_haproxy {
script “pidof haproxy”
interval 2
weight 2
}
vrrp_instance VRRP1 {
state MASTER
interface enp0s8
virtual_router_id 100
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 9999
}
virtual_ipaddress {
192.168.56.222/24
}
track_script {
chk_haproxy
}
}

Keepalived Nó em espera (BACKUP) HaProxy

Copie o arquivo de configuração do nó ativo (mestre acima) e altere a linha de estado:

state BACKUP

Reiniciar os serviços para efetivar as configurações desta arquitetura:

Em cada máquina HAProxy:

sudo systemctl start haproxy
sudo systemctl start keepalived

Em cada máquina Redis:

systemctl start redis
systemctl start redis-sentinel

Testes

1) Acessar redis-cli para escrita usando endereço vip haproxy e endereço direto

Acessar redis-cli usando vip haproxy e endereços diretos das instâncias redis.

redis-cli -h redisvip -p 6379
redisvip:6379> SET teste:objeto 100
redisvip:6379> INCR teste:objeto
redisvip:6379> GET teste:objeto

confirme nos outros nós redis repetindo o comando GET

Por exemplo, diretamente no mestre inicial redis:
redis-cli -h redis -p 6379

em um escravo
redis-cli -h redisa -p 6379

O comando INCR incrementa o valor de teste:objeto acima. Incremente em um endereço e use GET em outro para verificar a replicação.

Para testar a alta disponibilidade, use o redis-cli para acessar usando  sempre o endereço virtual compartilhado redisvip e:

• Desligue o nó mestre redis.
• Desligue o HAProxy ativo.

Os testes de escrita e leitura com SET e GET devem ser coerentes.

Nesta arquitetura, a queda de qualquer dos nós de Redis ou de HAProxy não causa indisponibilidade. Ocorre eleição de mestre em caso de falha e redireciomento de pacotes a partir de um endereço IP virtual compartilhado em HAProxy que também está em uma configuração simples de alta disponibilidade com keepalived.