Redis sentinel vs clustering

Capisco che redis sentinel sia un modo per configurare HA (alta disponibilità) tra più istanze redis. Come vedo, c'è un'istanza di redis che serve attivamente le richieste del client in un dato momento. Ci sono due server aggiuntivi in ​​standby (in attesa che si verifichi un errore, quindi uno di loro può essere di nuovo in azione).

• È uno spreco di risorse?
• Esiste un modo migliore per utilizzare appieno le risorse disponibili?
• Il clustering di Redis è un'alternativa a Redis sentinel?

Ho già cercato la documentazione di Redis per sentinel e clustering , qualcuno che ha esperienza può spiegare per favore.

AGGIORNARE

OK. Nel mio scenario di implementazione reale ho due server dedicati per redis. Ho un altro server in esecuzione sul mio server Jboss. L'applicazione in esecuzione in Jboss è configurata per connettersi al server master redis (M).

Scenario di failover

Idealmente, penso che quando il server cache master si guasta (il processo Redis si interrompe o il computer non funziona) l'applicazione in Jboss deve connettersi al server cache slave. Come configurare i server redis per ottenere questo risultato?

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

Configuration: quorum = 1

Per prima cosa, parliamo sentinella.

Sentinel gestisce il failover, non configura Redis per HA. È una distinzione importante. In secondo luogo, il diagramma che hai pubblicato è in realtà una configurazione errata: non vuoi eseguire Sentinel sullo stesso nodo dei nodi Redis che gestisce. Quando perdi quell'host, perdi entrambi.

Quanto a "è uno spreco di risorse?" dipende dal tuo caso d'uso. Non hai bisogno di tre nodi Redis in quella configurazione, te ne servono solo due. Tre aumenta la tua ridondanza, ma non è necessario. Se hai bisogno della ridondanza aggiuntiva, non è uno spreco di risorse. Se non è necessaria la ridondanza, è sufficiente eseguire una singola istanza Redis e definirla valida, poiché eseguirne di più sarebbe "sprecato".

Un altro motivo per eseguire due slave sarebbe la divisione delle letture. Ancora una volta, se ne hai bisogno, non sarebbe uno spreco.

Quanto a "Esiste un modo migliore per utilizzare appieno le risorse disponibili?" non possiamo rispondere in quanto dipende troppo dallo scenario e dal codice specifici. Detto questo, se la quantità di dati da archiviare è "piccola" e la velocità di comando non è eccessivamente alta, ricorda che non è necessario dedicare un host a Redis.

Ora per "Il cluster di Redis è un'alternativa a Redis sentinel?". Dipende davvero interamente dal tuo caso d'uso. Redis Cluster non è una soluzione HA: è una soluzione con più writer / più grande della ram. Se il tuo obiettivo è solo HA, probabilmente non sarà adatto a te. Redis Cluster presenta limitazioni, in particolare per le operazioni multi-chiave, quindi non è necessariamente un'operazione semplice "usa solo il cluster".

Se pensi che avere tre host che eseguono Redis (e tre che eseguono sentinel) sia uno spreco, probabilmente riterrai che Cluster sia ancora di più in quanto richiede più risorse.

Le domande che hai posto sono probabilmente troppo ampie e basate sull'opinione pubblica per sopravvivere come scritte. Se hai un caso / problema specifico che stai risolvendo, aggiornalo in modo che possiamo fornire assistenza e informazioni specifiche.

Aggiornamento per specifiche:

Per una corretta gestione del failover nel tuo scenario, sceglierei 3 sentinelle, una in esecuzione sul tuo server JBoss. Se hai 3 nodi JBoss, scegli uno su ciascuno. Avrei un pod Redis (master + slave) su nodi separati e avrei lasciato che sentinel gestisse il failover.

Da lì è una questione di collegare JBoss / Jedis per utilizzare Sentinel per le sue informazioni e la gestione della connessione. Dato che non uso quelli che una ricerca rapida rivela che Jedis ha il supporto per esso, devi solo configurarlo correttamente. Alcuni esempi che ho trovato sono in Looking for an example of Jedis with Sentinel e https://github.com/xetorthio/jedis/issues/725 che parlano di JedisSentinelPoolessere il percorso per l'utilizzo di una piscina.

Quando Sentinel esegue un failover, i client verranno disconnessi e Jedis gestirà (dovrebbe?) La riconnessione chiedendo alle Sentinelle chi è l'attuale master.

La raccomandazione, ovunque, è di iniziare con un numero dispari di istanze, non utilizzando due o un multiplo di due. È stato corretto, ma correggiamo alcuni altri punti.

Innanzitutto, affermare che Sentinel fornisce il failover senza HA è falso. Quando si ha il failover, si ha HA con l'ulteriore vantaggio di replicare lo stato dell'applicazione. La differenza è che puoi avere HA in un sistema senza replica (è HA ma non è tollerante ai guasti).

Secondo, eseguire un sentinel sulla stessa macchina dell'istanza redis di destinazione non è una "cattiva configurazione": se perdi la tua sentinel, o la tua istanza redis, o l'intera macchina, i risultati sono gli stessi. Questo è probabilmente il motivo per cui ogni esempio di tali configurazioni mostra entrambi in esecuzione sulla stessa macchina.

Questa non è una risposta diretta alla tua domanda, ma pensa, è un'informazione utile per i neofiti di Redis, come me. Anche questa domanda appare come il primo collegamento in Google durante la ricerca "Redis cluster vs sentinel".

Redis Sentinel è il nome della soluzione ad alta disponibilità Redis ... Non ha nulla a che fare con Redis Cluster ed è pensato per essere utilizzato da persone che non hanno bisogno di Redis Cluster, ma semplicemente un modo per eseguire il failover automatico quando un master l'istanza non funziona correttamente.

Tratto dalla bozza di progetto Redis Sentinel 1.3

Non è ovvio quando sei nuovo in Redis e stai implementando una soluzione di failover. Le documentazioni ufficiali su sentinel e clustering non sono paragonabili tra loro, quindi è difficile scegliere la strada giusta senza leggere tonnellate di documentazioni.

Questa è la mia comprensione dopo aver sbattuto la testa in tutta la documentazione.

Sentinel è una sorta di soluzione hot standby in cui gli slave vengono mantenuti replicati e pronti per essere promossi in qualsiasi momento. Tuttavia, non supporterà alcuna scrittura multi-nodo. Gli slave possono essere configurati per operazioni di lettura. NON è vero che Sentinel non fornirà HA, ha tutte le caratteristiche di un tipico cluster attivo-passivo (anche se non è il termine giusto da usare qui).

Il cluster Redis è più o meno una soluzione distribuita, che funziona su frammenti. Ogni blocco di dati viene distribuito tra i nodi master e slave. Un fattore di replica minimo di 2 garantisce la disponibilità di due frammenti attivi tra master e slave. Se conosci lo sharding in Mongo o Elasticsearch, sarà facile recuperare.

Redis può operare in cluster partizionati (con molti master e slave di tali master) o in modalità singola istanza (master singolo con replica slave).
Il link qui dice:

Quando si utilizza Redis in modalità a istanza singola, in cui un singolo server Redis gestisce l'intero database non partizionato, Redis Sentinel viene utilizzato per gestirne la disponibilità

Dice anche:

Un cluster Redis, in cui i dati sono partizionati tra più istanze primarie, gestisce la disponibilità da solo e non richiede componenti aggiuntivi.

Quindi l'HA può essere garantito nei 2 scenari menzionati. Spero che questo cancelli i dubbi. Il cluster e le sentinelle Redis non sono alternativi l'uno all'altro. Sono utilizzati solo per garantire HA in diversi casi di master partizionato o non partizionato.

Redis Sentinel esegue il failover promuovendo le repliche quando rileva che un master è inattivo. In genere si desidera un numero dispari di nodi sentinella. Per l'esempio di un master e una replica, dovrebbero essere utilizzate 3 sentinelle in modo che possa esserci un consenso sulla decisione. Idealmente la terza sentinella si trova su un terzo server quindi la decisione non è distorta (a seconda del fallimento). Sentinel si occupa di modificare le impostazioni di configurazione master / replica sui tuoi nodi in modo che la promozione e la sincronizzazione avvengano nell'ordine corretto e tu non sovrascrivi i dati portando su un vecchio master guasto che ora contiene dati meno recenti.

Dopo aver impostato i nodi sentinella per eseguire i failover, è necessario assicurarsi di puntare all'istanza corretta. Vedi un esempio di configurazione HAProxy per questo . HAProxy esegue controlli di integrità e punterà al nuovo master se si verifica un errore.

Il raggruppamento ti consentirà di ridimensionare orizzontalmente e può aiutare a gestire carichi elevati. Ci vuole un po 'di lavoro per impostare e configurare in anticipo.

Esiste un fork open source di Redis, "KeyDB" che ha eliminato la necessità di nodi sentinella con un'opzione di replica attiva. Ciò consente al nodo di replica di accettare letture e scritture. Quando si verifica un failover, HAProxy interrompe le letture / scritture con il nodo non riuscito e utilizza solo il nodo attivo rimanente che è già sincronizzato. Il timestamp consente ai nodi non riusciti di ricongiungersi automaticamente e di risincronizzarsi senza perdere i dati quando tornano online. La configurazione è semplice e per un traffico più elevato non è necessaria una configurazione iniziale speciale per indirizzare le letture al nodo di replica e le operazioni di lettura / scrittura sul master. Vedere l'esempio di replica attiva qui . KeyDB è anche multi-threaded che per alcune applicazioni potrebbe essere un'alternativa al clustering, ma in realtà dipende dalle tue esigenze.

C'è anche un esempio di impostazione del clustering manualmente e con lo strumento create-cluster . Questi sono gli stessi passaggi se stai usando Redis (sostituisci 'keydb' con 'redis' nelle istruzioni)

Ulteriori informazioni alle risposte precedenti

Redis Cluster

• Uno degli scopi principali del cluster Redis è distribuire in modo uniforme / uniforme il carico di dati tramite sharding

• Redis Cluster non utilizza hashing coerente, ma una forma diversa di sharding in cui ogni chiave è concettualmente parte di ciò che viene chiamato hash slot

• Ci sono 16384 hash slot in Redis Cluster, Ogni nodo in un Redis Cluster è responsabile di un sottoinsieme degli hash slot, quindi, ad esempio, potresti avere un cluster con 3 nodi, dove:

  Il nodo A contiene slot hash da 0 a 5500, il nodo B contiene slot hash da 5501 a 11000, il nodo C contiene slot hash da 11001 a 16383

Questo ci consente di aggiungere e rimuovere facilmente i nodi nel cluster. Ad esempio, se vogliamo aggiungere un nuovo nodo D, dobbiamo spostare alcuni hash slot dai nodi A, B, C a D

• Il cluster Redis supporta la struttura master-slave, puoi creare slave A1, B1, C2 insieme al master A, B, C durante la creazione di un cluster, quindi quando il master B si spegne, lo slave B1 viene promosso come master

Non è necessaria una gestione aggiuntiva del failover quando si utilizza Redis Cluster e non è assolutamente necessario puntare le istanze di Sentinel su nessuno dei nodi del cluster.

Quindi, in termini pratici, cosa ottieni con Redis Cluster?

1.La capacità di dividere automaticamente il set di dati tra più nodi.

2.La capacità di continuare le operazioni quando un sottoinsieme dei nodi sta riscontrando errori o non è in grado di comunicare con il resto del cluster.

Redis Sentinel

• Redis supporta più slave che replicano i dati da un nodo master.
• Ciò fornisce un backup per i dati nel nodo master.
• Redis Sentinel è un sistema progettato per gestire master e slave. Funziona come programma separato. Il numero minimo di sentinelle richiesto in un sistema ideale è 3. Comunicano tra di loro e si assicurano che il Master sia vivo, se non vivo promuoveranno uno degli schiavi come master, quindi più tardi quando il nodo morto ruoterà sarà agendo come uno schiavo per il nuovo padrone
• Il quorum è configurabile. Fondamentalmente è il numero di sentinelle che deve essere d'accordo poiché il comandante è a terra. N / 2 +1 dovrebbe essere d'accordo. N è il numero di nodi nel pod (nota che questa configurazione è chiamata pod e non è un cluster)

Quindi, in termini pratici, cosa ottieni con Redis Sentinel?

Si assicurerà che il Master sia sempre disponibile (se il master va giù, lo slave sarà promosso come master)

Riferimento:

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

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