Innanzitutto, Sentinel non è un sistema di bilanciamento del carico o un proxy per Redis.
In secondo luogo, non tutti i fallimenti sono la morte dell'ospite. A volte il server si blocca brevemente, a volte un cavo di rete viene scollegato, ecc. Per questo motivo, non è buona norma eseguire Sentinel sugli stessi host dell'istanza Redis. Se stai utilizzando Sentinel per gestire il failover, qualsiasi cosa meno di tre sentinelle in esecuzione su nodi diversi dal master Redis e dagli slave richiede problemi.
Sentinel utilizza un meccanismo di quorum per votare un failover e uno slave. Con meno di due sentinelle corri il rischio di dividere il cervello in cui due o più server Redis pensano di essere padroni.
Immagina lo scenario in cui esegui due server e gestisci sentinella su ciascuno. Se ne perdi uno, perdi la capacità di failover affidabile.
I client si connettono a Sentinel solo per conoscere le informazioni sulla connessione master corrente. Ogni volta che il client perde la connettività, ripete questo processo. Sentinel non è un proxy per Redis:i comandi per Redis vanno direttamente a Redis.
L'unico motivo affidabile per eseguire Sentinel con meno di tre sentinelle è il rilevamento del servizio, il che significa non utilizzarlo per la gestione del failover.
Considera lo scenario dei due host:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Se l'host B perde temporaneamente la connettività di rete all'host A in questo scenario, l'host B si promuoverà a master. Ora hai:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
A tutti i client che si connettono a Sentinel 2 verrà detto che l'host B è il master, mentre ai client che si connettono a Sentinel 1 verrà detto all'host A il master (che, se hai le tue Sentinel dietro un sistema di bilanciamento del carico, significa metà dei tuoi client).
Pertanto, ciò che è necessario eseguire per ottenere una gestione del failover affidabile minima accettabile è:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
I tuoi clienti si connettono alle sentinelle e ottengono il master corrente per l'istanza Redis (per nome), quindi si connettono ad essa. Se il master si interrompe, la connessione dovrebbe essere interrotta dal client, dopodiché il client si connetterà nuovamente a Sentinel e otterrà le nuove informazioni.
La capacità di gestione di ciascuna libreria client dipende dalla libreria.
Idealmente, gli host C,D ed E si trovano sugli stessi host da cui ci si connette a Redis (ovvero l'host client). o rappresentano una buona campionatura li ho presi. La spinta principale qui è assicurarti di controllare da dove devi connetterti a Redis. In caso contrario, posizionarli nello stesso controller di dominio/rack/regione dei client.
Se desideri che i tuoi clienti parlino con un sistema di bilanciamento del carico, prova ad avere le tue Sentinelle su quei nodi LB, se possibile, aggiungendo ulteriori host non LB se necessario per ottenere un numero dispari di sentinelle> 2. Un'eccezione a questa è se il tuo gli host client sono dinamici in quanto il numero di essi è incoerente (ad esempio, aumentano per il traffico, diminuiscono per periodi di rallentamento). In questo scenario è praticamente necessario eseguire le Sentinelle su host non client e non server Redis.
Nota che se lo fai, dovrai quindi scrivere un demone che monitori il canale PUBSUB di Sentinel per l'evento di commutazione principale per aggiornare il LB, che devi configurare per parlare solo con il master corrente (non provare mai a parlare con entrambi). È più difficile farlo, ma rende l'uso di Sentinel trasparente per il client, che sa solo parlare con l'IP/porta LB.
