Redis sentinela vs agrupamento

Eu entendo que o redis sentinel é uma forma de configurar HA (alta disponibilidade) entre várias instâncias do redis. Como vejo, há uma instância do redis atendendo ativamente às solicitações do cliente a qualquer momento. Existem dois servidores adicionais em standby (aguardando a ocorrência de uma falha, para que um deles possa entrar em ação novamente).

• É desperdício de recursos?
• Existe uma maneira melhor de usar todos os recursos disponíveis?
• O agrupamento do Redis é uma alternativa ao Redis sentinela?

Eu já pesquisei a documentação do redis para sentinela e clustering , alguém com experiência pode explicar por favor.

ATUALIZAR

ESTÁ BEM. Em meu cenário de implantação real, tenho dois servidores dedicados para redis. Eu tenho outro servidor em que meu servidor Jboss está em execução. O aplicativo em execução no Jboss é configurado para se conectar ao servidor mestre redis (M).

Cenário de failover

Idealmente, acho que quando o servidor de cache mestre falha (o processo Redis cai ou falha na máquina), o aplicativo em Jboss precisa se conectar ao servidor de cache escravo. Como configuraria os servidores redis para fazer isso?

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

Primeiro, vamos conversar, sentinela.

O Sentinel gerencia o failover, ele não configura o Redis para HA. É uma distinção importante. Em segundo lugar, o diagrama que você postou é, na verdade, uma configuração ruim - você não quer executar o Sentinel no mesmo nó que os nós do Redis que ele está gerenciando. Quando você perde aquele hospedeiro, você perde ambos.

Quanto a "É desperdício de recursos?" depende do seu caso de uso. Você não precisa de três nós do Redis nessa configuração, você só precisa de dois. Três aumenta sua redundância, mas não é obrigatório. Se você precisa da redundância adicional, então não é um desperdício de recursos. Se você não precisa de redundância, basta executar uma única instância do Redis e chamá-la de boa - pois executar mais seria "desperdiçado".

Outro motivo para executar dois escravos seria dividir as leituras. Novamente, se você precisar, não será um desperdício.

Quanto a "Existe uma maneira melhor de aproveitar ao máximo os recursos disponíveis?" não podemos responder a isso, pois é muito dependente de seu código e cenário específico. Dito isso, se a quantidade de dados a armazenar for "pequena" e a taxa de comando não for excessivamente alta, lembre-se de que você não precisa dedicar um host ao Redis.

Agora, para "O agrupamento do Redis é uma alternativa ao Redis sentinela?". Na verdade, depende inteiramente do seu caso de uso. O Redis Cluster não é uma solução HA - é uma solução de gravador múltiplo / maior que a memória RAM. Se o seu objetivo for apenas HA, provavelmente não será adequado para você. O Redis Cluster vem com limitações, especialmente em relação a operações de várias chaves, portanto, não é necessariamente uma operação direta "basta usar o cluster".

Se você acha que ter três hosts executando o Redis (e três o sentinela em execução) é um desperdício, provavelmente considerará o Cluster ainda mais desnecessário, pois requer mais recursos.

As perguntas que você fez provavelmente são muito amplas e baseadas em opiniões para sobreviver como estão escritas. Se você tiver um caso / problema específico que está resolvendo, atualize-o para que possamos fornecer assistência e informações específicas.

Atualização para detalhes:

Para o gerenciamento de failover adequado em seu cenário, eu escolheria 3 sentinelas, uma em execução em seu servidor JBoss. Se você tiver 3 nós JBoss, vá com um em cada. Eu teria um pod Redis (mestre + escravo) em nós separados e deixaria o sentinela gerenciar o failover.

A partir daí, é uma questão de conectar o JBoss / Jedis para usar o Sentinel para gerenciamento de informações e conexão. Como não os utilizo, uma busca rápida revela que o Jedis tem suporte para isso, basta configurá-lo corretamente. Alguns exemplos que encontrei estão em Procurando um exemplo de Jedis com Sentinel e https://github.com/xetorthio/jedis/issues/725 que falam sobreJedisSentinelPool ser a rota para usar um pool.

Quando o Sentinel executa um failover, os clientes serão desconectados e os Jedis irão (deveriam?) Lidar com a reconexão perguntando aos Sentinels quem é o mestre atual.

A recomendação, em todos os lugares, é começar com um número ímpar de instâncias, não usando dois ou um múltiplo de dois. Isso foi corrigido, mas vamos corrigir alguns outros pontos.

Primeiro, dizer que o Sentinel fornece failover sem HA é falso. Quando você tem failover, tem HA com o benefício adicional de estado do aplicativo sendo replicado. A diferença é que você pode ter HA em um sistema sem replicação (é HA, mas não é tolerante a falhas).

Em segundo lugar, executar uma sentinela na mesma máquina que sua instância de redis de destino não é uma "configuração ruim": se você perder sua sentinela, sua instância de redis ou a máquina inteira, os resultados serão os mesmos. Provavelmente é por isso que todos os exemplos dessas configurações mostram ambas em execução na mesma máquina.

Esta não é uma resposta direta à sua pergunta, mas pense, é uma informação útil para iniciantes no Redis, como eu. Além disso, esta pergunta aparece como o primeiro link no google ao pesquisar o "cluster Redis vs sentinela".

Redis Sentinel é o nome da solução de alta disponibilidade Redis ... Não tem nada a ver com o Redis Cluster e deve ser usado por pessoas que não precisam do Redis Cluster, mas simplesmente uma maneira de executar failover automático quando um mestre instância não está funcionando corretamente.

Retirado do rascunho de design 1.3 do Redis Sentinel

Não é óbvio quando você é novo no Redis e implementa uma solução de failover. Documentações oficiais sobre sentinela e clustering não se comparam entre si, então é difícil escolher o caminho certo sem ler toneladas de documentações.

Este é o meu entendimento depois de bater minha cabeça ao longo da documentação.

O Sentinel é uma espécie de solução hot standby onde os escravos são mantidos replicados e prontos para serem promovidos a qualquer momento. No entanto, ele não oferece suporte a nenhuma gravação de vários nós. Os escravos podem ser configurados para operações de leitura. NÃO é verdade que o Sentinel não fornecerá HA, ele tem todos os recursos de um cluster ativo-passivo típico (embora esse não seja o termo certo para usar aqui).

O cluster Redis é mais ou menos uma solução distribuída, trabalhando em cima de shards. Cada bloco de dados está sendo distribuído entre os nós mestres e escravos. Um fator de replicação mínimo de 2 garante que você tenha dois shards ativos disponíveis entre mestre e escravos. Se você conhece o sharding no Mongo ou Elasticsearch, será fácil atualizá-lo.

O Redis pode operar em cluster particionado (com muitos mestres e escravos desses mestres) ou em um modo de instância única (mestre único com escravos de réplica).
O link aqui diz:

Ao usar o Redis no modo de instância única, em que um único servidor Redis gerencia todo o banco de dados não particionado, o Redis Sentinel é usado para gerenciar sua disponibilidade

Também diz:

Um cluster Redis, no qual os dados são particionados entre várias instâncias primárias, gerencia a disponibilidade por si só e não requer componentes extras.

Portanto, a HA pode ser garantida nos 2 cenários mencionados. Espero que isso esclareça as dúvidas. O cluster Redis e as sentinelas não são alternativas entre si. Eles são usados ​​apenas para garantir HA em diferentes casos de mestre particionado ou não particionado.

O Redis Sentinel executa as réplicas de promoção de failover quando vê que um mestre está inativo. Você normalmente quer um número ímpar de nós sentinela. Para o exemplo de um mestre e uma réplica, devem ser utilizadas 3 sentinelas para que haja consenso na decisão. O ideal é que a terceira sentinela esteja em um terceiro servidor, de forma que a decisão não seja distorcida (dependendo da falha). O Sentinel se encarrega de alterar as configurações do mestre / réplica em seus nós para que a promoção e a sincronização ocorram na ordem correta e você não sobrescreva dados trazendo um mestre antigo com falha que agora contém dados mais antigos.

Depois de ter seus nós sentinela configurados para executar failovers, você precisa garantir que está apontando para a instância correta. Veja um exemplo de configuração HAProxy para isso . O HAProxy executa verificações de integridade e apontará para o novo mestre se ocorrer uma falha.

O agrupamento permitirá que você dimensione horizontalmente e pode ajudar a lidar com cargas elevadas. É preciso um pouco de trabalho para instalar e configurar antecipadamente.

Existe uma bifurcação de código aberto do Redis, “KeyDB”, que eliminou a necessidade de nós sentinela com uma opção de réplica ativa. Isso permite que o nó de réplica aceite leituras e gravações. Quando ocorre um failover, o HAProxy interrompe as leituras / gravações com o nó com falha e usa apenas o nó ativo restante que já está sincronizado. O carimbo de data / hora permite que os nós com falha se reintegrem automaticamente e sejam sincronizados novamente sem perder dados quando voltam online. A configuração é simples e, para tráfego maior, você não precisa de uma configuração inicial especial para direcionar as leituras ao nó de réplica e as leituras / gravações no mestre. Veja um exemplo de replicação ativa aqui . O KeyDB também é multi-threaded, o que para alguns aplicativos pode ser uma alternativa ao armazenamento em cluster, mas realmente depende de quais são suas necessidades.

Também há um exemplo de configuração de clustering manualmente e com a ferramenta create-cluster . Estas são as mesmas etapas se você estiver usando o Redis (substitua 'keydb' por 'redis' na instrução)

Informações adicionais para as respostas acima

Cluster Redis

• Um dos objetivos principais do cluster Redis é distribuir igualmente / uniformemente a carga de dados por fragmentação

• O Redis Cluster não usa hashing consistente, mas uma forma diferente de fragmentação em que cada chave é conceitualmente parte do que é chamado de slot de hash

• Existem 16384 slots de hash no Redis Cluster. Cada nó em um Redis Cluster é responsável por um subconjunto de slots de hash, então, por exemplo, você pode ter um cluster com 3 nós, onde:

  O nó A contém slots de hash de 0 a 5500, o nó B contém slots de hash de 5501 a 11000, o nó C contém slots de hash de 11001 a 16383

Isso nos permite adicionar e remover nós no cluster facilmente. Por exemplo, se quisermos adicionar um novo nó D, precisamos mover algum slot hash dos nós A, B, C para D

• O cluster Redis suporta a estrutura mestre-escravo, você pode criar escravos A1, B1, C2 junto com o mestre A, B, C ao criar um cluster, portanto, quando o mestre B for desativado, o escravo B1 será promovido como mestre

Você não precisa de tratamento adicional de failover ao usar o Redis Cluster e definitivamente não deve apontar as instâncias do Sentinel para qualquer um dos nós do Cluster.

Então, em termos práticos, o que você ganha com o Redis Cluster?

1. A capacidade de dividir automaticamente seu conjunto de dados entre vários nós.

2. A capacidade de continuar as operações quando um subconjunto de nós está enfrentando falhas ou não consegue se comunicar com o resto do cluster.

Redis Sentinel

• O Redis oferece suporte a vários escravos que replicam dados de um nó mestre.
• Isso fornece um backup dos dados no nó mestre.
• Redis Sentinel é um sistema projetado para gerenciar mestre e escravo. Ele funciona como um programa separado. O número mínimo de sentinelas necessárias em um sistema ideal é 3. Elas se comunicam entre si e garantem que o Mestre está vivo, se não estiver vivo promoverão um dos escravos como mestre, portanto, mais tarde, quando o nó morto girar, será atuando como um escravo para o novo mestre
• O quorum é configurável. Basicamente, é o número de sentinelas que precisam concordar quando o mestre está caído. N / 2 +1 deve concordar. N é o número de nós no pod (observe que esta configuração é chamada de pod e não é um cluster)

Então, em termos práticos, o que você ganha com o Redis Sentinel?

Ele irá garantir que o Mestre esteja sempre disponível (se o mestre cair, o escravo será promovido a mestre)

Referência:

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

https://redis.io/topics/cluster-tutorial