Non è necessario utilizzare un servizio di bilanciamento del carico con ElasticSearch?

Question

Ho un cluster di 3 nodi ElasticSearch in esecuzione su AWS EC2. Questi nodi vengono impostati utilizzando OpsWorks/Chef. Il mio intento è di progettare questo cluster per essere molto elastico ed elastico (i nodi possono entrare ed uscire quando necessario).

Da tutto quello che ho letto su ElasticSearch, sembra che nessuno consiglia di mettere un bilanciamento del carico di fronte al cluster; invece, sembra che la raccomandazione è di fare una delle due cose:

1. punto il vostro cliente l'URL/IP di un nodo, lasciate ES fare il bilanciamento del carico per voi e la speranza che il nodo non va giù.

2. Hard-code gli URL/IP di TUTTI i tuoi nodi nell'app client e chiedi all'app di gestire la logica di failover.

Il mio background è per lo più in aziende agricole web dove è solo buon senso per creare una grande piscina di web server autonomi, gettare un ELB di fronte a loro e lasciare che il bilanciamento del carico decidere quali nodi sono vivi o morti. Perché ES non sembra supportare questa stessa architettura?

Answer 1

Non è necessario un sistema di bilanciamento del carico: ES fornisce già tale funzionalità. Avresti solo un altro componente, che potrebbe comportarsi male e che aggiungerebbe un hop di rete non necessario.

ES divide i dati (per impostazione predefinita in 5 frammenti), che tenterà di distribuire uniformemente tra le istanze. Nel tuo caso 2 istanze dovrebbero avere 2 frammenti e 1 solo uno, ma potresti voler cambiare i frammenti a 6 per una distribuzione equa.

Per impostazione predefinita, la replica è impostata su "number_of_replicas":1, quindi una replica di ogni frammento. Supponendo che si sta utilizzando 6 frammenti, che potrebbe sembrare qualcosa di simile (R è un frammento replicato):

• node0: 1, 4, R3, R6
• Node1: 2, 6, R1, R5
• node2: 3, 5, R2, R4

Supponendo nodo1 muore, il cluster cambierebbe la seguente configurazione:

• node0: 1, 4, 6, R3 + nuove repliche R5, R2
• NODE2: 3, 5, 2, R4 + nuove repliche R1, R6

seconda delle impostazioni di connessione, è possibile connettersi a un'istanza (client di trasporto) o si potrebbe aggiungere al cluster (nodo client). Con il client del nodo eviterai il doppio salto, dal momento che ti connetteresti sempre al frammento/indice corretto. Con il client di trasporto, le richieste verranno indirizzate all'istanza corretta.

Quindi non c'è niente da bilanciare da soli, basta aggiungere un sovraccarico. L'auto-clustering è probabilmente il più grande punto di forza di ES.

Answer 2

Hai perfettamente ragione di voler progettare per il "failover", e in AWS, ecco come ti consiglio di farlo.

1) Limitare i nodi nel cluster che possono essere eletti master. Per il resto, imposta node.client: true.Basa la tua scelta su quanti nodi elettrici eleggibili hai su quanti ne vuoi disponibili per il failover.

2) Creare un ELB che includa solo i nodi master eleggibili.

3) Nella Route 53, creare un CNAME per il cluster, con il valore impostato sul nome DNS del proprio ELB.

Answer 3

Credo bilanciamento un cluster elasticsearch carico è una buona idea

Per architetto il cluster avrete bisogno di base sui due funzioni primarie di elasticsearch (progettazione di un sistema fault tolerant, resistente al singolo guasto del nodo.): 1. Scrittura e aggiornamento dei documenti e 2. Richiesta di documenti.

documenti di scrittura/indicizzazione in elasticsearch:

1. Quando un nuovo documento entra in elasticsearch da indicizzare, elasticsearch determina il "frammento primario" il documento dovrebbe essere assegnato utilizzando il "Algoritmo Shard Routing"
2. Il processo Lucene associato al frammento "mappa" i campi nel documento;
3. Il processo Lucene aggiunge il documento all'indice "indice invertito" del frammento di Lucena
4. Qualsiasi "frammento di replica" riceve il documento; il frammento replica "mappe" del documento e aggiunge il documento per Lucene del frammento di replica "indice invertito"

documenti Interrogazione a elasticsearch:

1. Per impostazione predefinita, quando una query viene inviata a elasticsearch , la query colpisce un nodo - questo diventa il "nodo di query" o la "query node Gateway" per quella query
2. il nodo trasmette la query ad ogni frammento nell'indice (primario & replica)
3. ogni frammento esegue una query sull'indice invertito Lucene locale di shard.
4. ciascun frammento restituisce i 10 - 20 risultati al "query node Gateway"
5. "Gateway nodo query" allora esegui una merge-sort sui risultati combinati restituiti dagli altri frammenti,
6. volta l'unione -sort è finito, il "query node Gateway" e restituisce i risultati al client
   • il merge-sort è CPU e risorse di memoria pesante

Architect a Load Balancer per scritture/indicizzazione/aggiornamenti

Elasticsearch gestisce autonomamente la posizione dei frammenti sui nodi. Il "nodo principale" mantiene e aggiorna la "tabella di routing shard". Il "nodo principale" fornisce una copia della tabella di routing shard ad altri nodi nel cluster.

Generalmente, non si desidera che il nodo principale esegua molto di più dei controlli di integrità per il cluster e l'aggiornamento delle tabelle di routing e la gestione dei frammenti.

Probabilmente è meglio puntare il bilanciamento del carico per le scritture sui "nodi dati" (i nodi dati sono nodi che contengono dati = shard) e lasciare che i nodi di dati utilizzino le loro tabelle di routing shard per ottenere le scritture sui frammenti corretti.

progettare per le query

elasticsearch ha creato uno speciale tipo di nodo: "nodo client", che contiene "nessun dato", e non può diventare un "nodo master". La funzione del nodo client è eseguire l'unione pesante-ordinamento delle risorse finali alla fine della query.

per AWS si sarebbe probabilmente usare un C3 o tipo di istanza c4 come un "nodo client"

Le migliori pratiche è quello di puntare il bilanciamento del carico per le query ai nodi client.

Cheers!

Riferimenti:

1. Elasticsearch Node Types
2. Elasticsearch: Shard Routing Algorithm
3. Elasticsearch: Replica Shards
4. Elasticsearch: Cluster State i.e. the Shard Routing Table
5. ElasticHQ - Introduction to Elasticsearch Video
6. Elasticsearch: Shard numbers and Cluster Scaling