Redis é um sistema de gerenciamento de banco de dados da classe NoSQL (DBMSs não relacionais) colocado inteiramente na RAM. Para acessar os dados, é usado o modelo “chave” - “valor”. Esse DBMS é frequentemente usado para armazenar caches em serviços escalonáveis, para armazenar imagens e dados pequenos.
O Redis DBMS é amplamente utilizado devido a:
- alta velocidade, porque todos os dados são armazenados na RAM;
- multiplataforma;
- distribuição sob a licença BSD (aplica-se ao software de código aberto).
A amplitude da distribuição e aplicabilidade do Redis pode ser estimada pela enorme quantidade de documentação com todos os tipos de casos no
site oficial do projeto .
Se você usar o dimensionamento horizontal dos serviços DirectumRX, deverá usar a instalação à prova de falhas do Redis para funcionar corretamente com o serviço de armazenamento DirectumRX e o serviço de acesso à web DirectumRX.
O Redis armazenará dados operacionais, caches e outras informações necessárias para a operação dos serviços no modo de escala, para que o processo de interação do usuário com o sistema não dependa da instalação com a qual ele está trabalhando atualmente.
O Redis não armazenará dados confidenciais e não estará sob carga pesada. Porém, no caso de uma falha do Redis, os usuários sofrerão muitos erros ao alternar entre instalações.
No site oficial da Redis, existem duas maneiras de garantir escala horizontal e tolerância a falhas:
- Usando Redis Sentiel .
- Usando o Redis Cluster .
Considere personalizar essas opções.
Configurar Redis Sentiel
A opção usando o Redis Sentiel (Redis Tracking Node) foi implementada no Redis 2.4 e consiste em usar o serviço Redis Sentiel adicional para monitorar a disponibilidade do assistente. Ele também executa a configuração de nós de réplica em caso de falha do assistente. Determina qual dos nós SLAVE se tornará MASTER e executará a reconfiguração em movimento.
Implementa o esquema clássico:
Pode haver muitos nós SLAVE (até 1000, de acordo com o site oficial). Para um trabalho produtivo, é recomendável usar pelo menos dois nós SLAVE.
Normalmente, o esquema é configurado de forma que o serviço Redis Sentiel seja configurado nos nós MASTER e SLAVE e, se o nó MASTER falhar, os nós de monitoramento restantes decidirão introduzir um novo MASTER.
A versão atual do Redis está disponível para download no
site oficial do desenvolvedor do produto . No entanto, o site de distribuição está disponível apenas para Linux. Ao mesmo tempo,
o projeto da Microsoft para portar o Redis para Windows estava em desenvolvimento, mas no momento o projeto parou de ser desenvolvido na versão 3.2.100, portanto, neste artigo, consideraremos a opção de implantação mais relevante - no Linux.
Como nós de teste, usaremos dois hosts virtuais redis1 e redis2 com a distribuição Linux instalada do Debian 10.
Primeiro, atualize as listas de pacotes do repositório padrão e instale o Redis:
apt-get update && apt-get upgrade apt install redis-server
Verifique a versão:
root@redis1:/home/user
Permita que redis1 atue como um nó MASTER e redis2 atue como um nó ESCRAVO.
Para isso, escrevemos nos arquivos de configuração Redis os parâmetros necessários que permitirão criar uma réplica (ainda não tolerante a falhas).
Para redis1 no arquivo de configuração /etc/redis/redis.conf, especifique:
Para redis2 no arquivo de configuração /etc/redis/redis.conf, especifique:
Reinicie os serviços redis-server nos dois nós:
root@redis1:/etc/redis
Verificamos, no lado MASTER, que os nós se tornaram réplicas e receberam as funções necessárias:
root@redis1:/etc/redis
No lado ESCRAVO, vemos a mesma situação:
root@redis2:/etc/redis
Agora você precisa configurar a réplica para que ela seja restaurada automaticamente em caso de falha de um dos nós. Para isso, precisamos do serviço de rastreamento Redis Sentinel.
Com base na
documentação , o serviço de monitoramento Redis Sentinel pode executar as seguintes operações:
- Verifica a disponibilidade dos nós MASTER e SLAVE e pode enviar alertas sobre a inacessibilidade dos nós.
- Se o nó MASTER falhar, o nó testemunha poderá colocar o nó SLAVE no modo MASTER, reconfigurar os nós restantes do SLAVE e eles começarão a trabalhar com o novo MASTER.
- Faz alterações nos arquivos de configuração dos nós MASTER e SLAVE.
Para a pureza do experimento, colocaremos um serviço de testemunha em uma VM redis3 separada.
Conectamos o repositório Redis da mesma maneira e instalamos o pacote redis-sentinel:
apt install redis-sentinel
Após a instalação, é necessário fazer as configurações no arquivo de configuração do nó de monitoramento /etc/redis/sentinel.conf:
Reinicie o serviço depois de fazer as configurações:
root@redis3:/etc/redis
Verifique se o serviço de rastreamento viu MASTER e SLAVE:
root@redis3:/etc/redis
Começamos os experimentos.
Simulamos uma falha, paramos o serviço redis-server no nó redis1 e obtemos as informações atuais do nó testemunha:
root@redis3:/etc/redis
Vemos que o MASTER mudou.
Vamos restaurar a operação do nó redis1 e verificar seu estado:
root@redis3:/var/log/redis
Vemos que o nó recebeu a função SLAVE e o nó redis2 é um nó MASTER.
Simule a falha do nó redis2 e verifique o status do nó testemunha:
root@redis3:/var/log/redis
E o estado do nó redis1:
root@redis3:/var/log/redis
Ótimo, o mecanismo funciona. Mas agora surgiu a questão de como conectaremos nossos serviços DirectumRX, porque eles precisam de um endereço de nó único. Resolveremos a situação usando o serviço HAProxy.
Proxying de Nó Redis
Qualquer serviço de proxy tcp pode atuar como um proxy reverso para nós Redis. Neste artigo, consideraremos o uso do HAProxy, pois é uma ferramenta especializada projetada para fornecer alta disponibilidade e balanceamento de carga e é usada por serviços online universalmente conhecidos. Leia mais sobre o HAProxy
na página do desenvolvedor .
Instale o HAProxy no nó redis3:
root@redis3:/var/log/redis
No arquivo de configuração HAProxy /etc/haproxy/haproxy.cfg, adicione as configurações para solicitações de proxy nos nós Redis:
… frontend ft_redis bind *:6379 name redis mode tcp default_backend bk_redis backend bk_redis mode tcp option tcp-check tcp-check connect
Nesta configuração, é indicado que iremos proxy todos os pedidos que chegarem a todas as interfaces da máquina virtual atual no endereço na porta 6379. Transferiremos pedidos para o nó que responderá que possui a função MASTER.
Reinicie o serviço haproxy:
root@redis3:/etc/haproxy
Vamos tentar conectar usando o cliente redis-cli e criar uma chave de teste:
root@redis3:/etc/haproxy
Pare o nó redis1 e consulte novamente a lista de chaves:
127.0.0.1:6379> info keyspace Error: Server closed the connection (3.01s) 127.0.0.1:6379> info keyspace
Vimos que por algum tempo a conexão foi desconectada, mas a conexão foi restaurada novamente e todos os dados permaneceram no local.
Agora é suficiente registrar o endereço do proxy reverso nos arquivos de configuração dos serviços DirectumRX para conectar-se ao Redis.
Configurar Redis Cluster
A opção de cluster do Redis Cluster, implementada para a versão redis 3.0 e superior, é uma solução para criar e gerenciar um cluster com segmentação e replicação de dados. Executa tarefas de gerenciamento de nó, replicação, sincronização de dados nos nós e garante o acesso do aplicativo cliente ao nó MASTER no caso de falha de um dos vários nós MASTER.
O Redis Cluster funciona no modo multimaster, cada nó MASTER pode ter um ou mais nós SLAVE (até 1000).
A escala é a principal função do cluster. Além disso, o cluster pode garantir a tolerância a falhas do serviço Redis:
- se alguns nós não funcionarem, o cluster redistribuirá a carga deles para outros nós;
- se os nós principais não funcionarem, o cluster inteiro será encerrado.
Uma situação pode surgir quando o Cliente 2 grava no nó M2. M2 responde "OK" e tenta escrever para S2. Ao mesmo tempo, o M2 não espera a conclusão correta da troca de dados com o S2, mas responde ao cliente imediatamente. Nesse caso, a réplica S2 pode não ter todos os dados. Portanto, é recomendável usar várias réplicas SLAVE.
Uma situação também pode surgir quando M1, M3 deixam de "ver" M2 e o cliente ainda continua a gravar dados em M2. Se a indisponibilidade continuar por algum tempo (o parâmetro cluster-node-timeout), nesse caso, o S2 será colocado no modo MASTER e o M2 deixará de funcionar por conta própria.
A documentação oficial recomenda o uso de 6 nós - uma instância do Redis por nó, o que permite maior confiabilidade, mas ninguém proíbe o uso de três nós com a seguinte topologia de conexão:
Se um dos nós físicos falhar, as réplicas correspondentes do SLAVE entrarão no modo MASTER e a operação não será interrompida.
Implementamos 3 máquinas virtuais (redis1, redis2 e redis3) na bancada de testes, cada uma das quais executará 2 instâncias Redis.
O aplicativo cliente se conectará a uma porta específica especificada no arquivo de configuração do cliente; portanto, os pares MASTER - SLAVE devem funcionar nas mesmas portas.
Para o par M1 - S1, usaremos a porta 6381
Para o par M2 - S2, usaremos a porta 6382
Para o par M3 - S3, usaremos a porta 6383
Prepare os arquivos de configuração
Em redis1:
cp /etc/redis/redis.conf /etc/redis/m1_redis.conf cp /etc/redis/redis.conf /etc/redis/s2_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Em redis2:
cp /etc/redis/redis.conf /etc/redis/m2_redis.conf cp /etc/redis/redis.conf /etc/redis/s3_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Em redis3:
cp /etc/redis/redis.conf /etc/redis/m3_redis.conf cp /etc/redis/redis.conf /etc/redis/s1_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Preencha os arquivos de configuração de acordo com o modelo:
bind <IP- > protected-mode no
Vamos lançar os nós Redis:
Nó redis1:
root@redis1:/etc/redis
Nó Redis2:
root@redis2:/etc/redis
Nó Redis3:
root@redis3:/etc/redis
Para configurar o cluster, você deve usar o utilitário cliente redis-cli, passando uma lista de pares de servidores ip: port que desempenharão as funções de MASTER e SLAVE:
redis-cli --cluster create redis1-ip:6381 redis2-ip:6382 redis3-ip:6383 redis1-ip:6382 redis2-ip:6383 redis3-ip:6381 --cluster-replicas 1
, onde a opção --cluster-replicas 1 informa quantos ESCRAVOS cada mestre terá e eles são selecionados automaticamente na lista de réplicas transferidas.
root@redis1:~/redis/src
O cluster está construído corretamente. Vamos exibir informações sobre o cluster:
root@redis1:~/redis/src
Para testar uma réplica específica, como no Redis Sentiel, você pode usar o comando de replicação INFO:
root@redis1:~/redis/src
Vamos tentar criar várias chaves e verificar se essas chaves apareceram nas réplicas:
192.168.9.51:6381> SET key1 test1 -> Redirected to slot [9189] located at 192.168.9.52:6382 OK 192.168.9.52:6382> SET key2 test2 -> Redirected to slot [4998] located at 192.168.9.51:6381 OK 192.168.9.51:6381> SET key3 test3 OK 192.168.9.51:6381>
Verifique no M2:
root@redis2:/home/user
E no M3:
root@redis3:/home/user
Desabilitaremos o nó redis1 e verificaremos como o S1 funciona:
192.168.9.52:6382> CLUSTER NODES <b>182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave,fail d499af3672b3063c7239572ec311ad3160f280ae 1569509904727 1569509900000 4 connected</b> 485ffb786e9763955e6f10ffc59247690ad9bc11 <i>192.168.9.53:6381@16381 master</i> - 0 1569510017272 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569510018274 5 connected <b>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 master,fail - 1569509906731 1569509901721 1 connected</b> 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569510019275 3 connected 10923-16383 d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 myself,master - 0 1569510017000 2 connected 5461-10922
Vemos informações sobre a falha de M1 e S2 e que o S3 mudou para o modo MASTER.
Verifique onde as chaves estão armazenadas:
192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6381> GET key3 "test3" 192.168.9.53:6381>
As chaves que foram armazenadas anteriormente no redis1 agora estão disponíveis no redis3.
Restaure a operação do nó redis1 e verifique o estado dos nós M1 e S2:
192.168.9.53:6381> CLUSTER NODES <i>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 slave 485ffb786e9763955e6f10ffc59247690ad9bc11 0 1569511658217 7 connected 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave d499af3672b3063c7239572ec311ad3160f280ae 0 1569511657000 4 connected</i> d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 master - 0 1569511656000 2 connected 5461-10922 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569511656000 3 connected 10923-16383 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381@16381 myself,master - 0 1569511656000 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569511657216 5 connected
A saúde de M1 e S2 se recuperou, mas agora M1 está no modo ESCRAVO.
E as chaves também estão no nó redis3:
192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6383> GET key3 -> Redirected to slot [935] located at 192.168.9.53:6381 "test3"
O cluster está configurado e a recuperação Redis é testada.
Para acessar os serviços do DirectumRX, você também precisará configurar proxies reversos, como no caso do Redis Sentiel.
Em vez de uma conclusão
Este artigo não considerou ainda outra maneira de aumentar a tolerância a falhas do Redis - usando um gerenciador de recursos de cluster de terceiros, por exemplo,
Pacemaker . Nesse caso, será possível conviver com dois nós, mas há uma alta probabilidade de perda de dados em caso de emergência.
Para um proxy reverso (neste caso, HAProxy), também é desejável fornecer tolerância a falhas, mas esse problema também estava além do escopo deste artigo. Se você estiver interessado no tópico, essas opções de implantação também poderão ser consideradas em artigos separados com o ajuste passo a passo e o teste dos resultados.
Você pode encontrar os links abaixo para saber mais sobre o tópico:
Tutorial do cluster RedisDocumentação do Redis SentinelManual de configuração HAProxy .