Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

Elasticsearch Clusterizado

Gostaria de entender qual seria a melhor forma de implementar um elasticsearch em Cluster:

Dúvidas:

1ª) Caso eu tenha 5 servidores de Elastisearch, a melhor prática seria uma réplica para cada shard?

Exemplo conf elasticsearch.yml:

node.master: true node.data: true discovery.zen.ping.unicast.hosts: ["SERVIDOR1","SERVIDOR12","SERVIDOR3","SERVIDOR4","SERVIDOR5"] discovery.zen.minimum_master_nodes: 3

PUT /my_index/_settings

{

"number_of_replicas": 1

}

2ª) Uma vez que eu resolva configurar apenas uma réplica para cada shard, corre o risco do dado (informação/registro) se perder?

3ª) Em um ambiente produtivo se tratando de requisições http, há como boa prática de ter um balanceador(Ngix,apache,F5,ACE) para distribuir a carga entre os servidores? Esse conceito se aplica no elasticsearch?

Quando configurei o Kibana por exemplo, o arquivo kibana.yml ficou com o parâmetro elasticsearch.url: "http://servidor1:9200".

Pelo o que eu entendi, toda vez que o kibana realizar uma consulta a infra (processador/memória) consumida será apenas do servidor 1 e teoricamente os demais servidores ficariam sem uso. Essa informação é verdadeira?

4ª) Se caso não for um balanceador responsável por esse papel, qual seria a melhor prática para usar os recursos de todos os 5 servidores ?

Desde já agradeço atenção.

1 resposta
solução!

Olá Ramon,

Primeiro, excelente pergunta! Mostra que esta querendo levar seus conhecimentos, não só de Elasticsearch, mas de computação distribuída a um nível mais profissional.

Elogios a parte, vamos ao que interessa.

Master Nodes x Data Nodes

Antes vamos dar um passo para trás. Primeiro precisamos entender a diferença entre master e data nodes. Data Nodes: Armazenam dados e executam todo tipo de computação pesada, como filtros e agregações. As máquinas que você vai escolher para este tipo de nó devem ser muito boas para operações que demandam bastante de CPU (intensive computation), bastante memória RAM (algumas dezenas de GBs) e possuir um storage para leitura rápida (SSD e praticamente um must-have). Cada data node vai armazenar pedaços de dados de diferente indices, que é o que chamamos de shards. Shards podem ser primárias (onde as escritas acontecem) ou réplicas. Master Nodes: Funcionam como o cérebro do seu cluster. Devem ser nós separados (nunca utilize a mesma máquina para master e data node) e cuidam do metadado do seu cluster. Master nodes sabem quais shards estão em quais máquinas físicas. Importantíssimo ter um número ímpar de master nodes maior que 1. Se tiver apenas um master e ele morrer, seu cluster já era. Se tiver 2, poder cair no caso de split brain, onde os nós não entram em acordo e não tem como definir quem esta certo - again, seu cluster já era. Com 3, tem uma situação melhor, pois se um morrer, você ainda consegue substituir. Se um ficar doido, vc ainda possui outros 2 para manter o consenso.

Número de Réplicas

O número de réplicas depende de vários fatores, mas para a grande maioria dos casos, basta utilizar 2 réplicas. Deste modo, se você perder 2 hosts, tem garantias de que não perde informação alguma. Se tiver apenas uma réplica, corre o risco de ficar sem cópias em caso de falhas simples. É o mesmo caso de você ter apenas um backup - vai que o backup falha e ai?

Produção

Seus data nodes devem estar por trás de um load balancer, caso contrario vai criar um single point of failure e forçar todos os requests irem para a mesma máquina. Seus master nodes não são expostos - a comunicação entre data nodes e master nodes (e também, apenas entre data node) funciona via node to node communication (dai o seu unicast). Sugiro também não utilizar unicast mas sim multicast (a menos que tenha ips fixos e, no caso de falhar, as novas máquinas vão assumir os mesmos ips, caso contrário quando subir seu cluster, as máquinas não vão se achar).

Eu te sugiro que, ao invés de montar seu cluster para produção, que você utilize algum serviço na nuvem (basta procurar no google - hosted elasticsearch). Vai ser mais barato e você vai ter muito menos dores de cabeça. Manter um cluster exige conhecimento de muitos detalhes que, ao meu ver, só valem o investimento se você tiver razões legais.

Abraços.