Primeiro, o Sentinel não é um balanceador de carga ou um proxy para Redis.
Em segundo lugar, nem todas as falhas são a morte do host. Às vezes, o servidor trava brevemente, às vezes um cabo de rede é desconectado etc. Por causa disso, não é uma boa prática executar o Sentinel nos mesmos hosts que sua instância do Redis. Se você estiver usando o Sentinel para gerenciar o failover, qualquer coisa menor que três sentinelas em execução em nós que não sejam o mestre e o escravo do Redis está pedindo problemas.
O Sentinel usa um mecanismo de quorum para votar em um failover e escravo. Com menos de dois sentinelas, você corre o risco de dividir o cérebro onde dois ou mais servidores Redis pensam que são mestres.
Imagine o cenário em que você executa dois servidores e executa o sentinela em cada um. Se você perder um, perderá o recurso de failover confiável.
Os clientes só se conectam ao Sentinel para saber as informações atuais da conexão mestre. Sempre que o cliente perde conectividade, ele repete esse processo. O Sentinel não é um proxy para o Redis - os comandos do Redis vão diretamente para o Redis.
O único motivo confiável para executar o Sentinel com menos de três sentinelas é para descoberta de serviço, o que significa não usá-lo para gerenciamento de failover.
Considere o cenário de dois hosts:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Se o Host B perder temporariamente a conectividade de rede com o Host A neste cenário, o HostB se promoverá a mestre. Agora você tem:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Todos os clientes que se conectarem ao Sentinel 2 serão informados que o Host B é o mestre, enquanto os clientes que se conectarem ao Sentinel 1 serão informados ao Host A como mestre (o que, se você tiver seus Sentinels atrás de um balanceador de carga, significa metade de seus clientes).
Assim, o que você precisa executar para obter um gerenciamento de failover confiável mínimo aceitável é:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Seus clientes se conectam aos sentinelas e obtêm o mestre atual para a instância do Redis (por nome) e, em seguida, conectam-se a ele. Se o mestre for interrompido, a conexão deverá ser interrompida pelo cliente e, assim, o cliente se conectará/deverá se conectar ao Sentinel novamente e obter as novas informações.
O quão bem cada biblioteca cliente lida com isso depende da biblioteca.
Idealmente, os hosts C, D e E estão nos mesmos hosts de onde você se conecta ao Redis (ou seja, o host do cliente). ou representam uma boa amostragem consegui-los. O principal objetivo aqui é garantir que você esteja verificando de onde precisa se conectar ao Redis. Se isso falhar, coloque-os no mesmo DC/Rack/Região que os clientes.
Se você deseja que seus clientes conversem com um balanceador de carga, tente ter seus Sentinels nesses nós LB, se possível, adicionando hosts não LB adicionais conforme necessário para obter um número ímpar de sentinelas> 2. Uma exceção a isso é se o seu os hosts do cliente são dinâmicos, pois o número deles é inconsistente (eles aumentam para tráfego, diminuem para períodos lentos, por exemplo). Nesse cenário, você deve executar seus Sentinels em hosts não clientes e não servidores redis.
Observe que, se você fizer isso, precisará escrever um daemon que monitore o canal Sentinel PUBSUB para o evento de switch mestre para atualizar o LB - que você deve configurar para conversar apenas com o mestre atual (nunca tente conversar com ambos). Dá mais trabalho fazer isso mas faz uso do Sentinel transparente para o cliente - que só sabe falar com o IP/Porta do LB.
