:::: MENU ::::

Elasticsearch na produção

Olá pessoal, beleza?

Bom, depois de muita sombra, sol e aguá fresca (não necessariamente nesta ordem) está na hora de começar a tentar cumprir as promessas para o novo ano que chega (mesmo que por no máximo um mês). Vou tentar ser mais ativo nos meus posts, e também dividir mais coisas sobre as tecnologias que ando estudando, então hoje vou começar passando algumas dicas importantes para usarmos o elasticsearch na produção.

Estamos acostumados a fazer a instalação e já sair usando o elastic pois ele vem praticamente pronto, mas quando falamos de produção temos que dar atenção a alguns pontos que irão nos ajudar no desempenho do mesmo e também nas dores de cabeça desnecessárias e aquela infeliz sensação de tristeza eterna momentânea.

Let’s começar então?

Bom, sempre que uma dica estiver na documentação eu vou postar o link para quem quiser ler a versão da própria.

Basicamente vamos dar atenção a informações de hardware e rede.

Configurações de Memória

Espero que todos saibam que o elasticsearch roda em uma jvm (Java Virtual Machine) e é possível configurar o quanto de memória esse nosso processo irá usar -Xms e -Xmx para mínimo e máximo. Neste caso, em um mundo perfeito, o ideal seria o uso de uma máquina com 64GB de Memória RAM mas máquinas com 16GB e 8GB são bem comuns.

Digamos que temos uma ou várias máquinas no cluster com 8GB de memória, vamos fazer uma configuração de memória usando este numero.

O primeiro ponto é setar o -Xms e -Xmx que ficarão assim: -Xms 4gb -Xmx 4gb; o mínimo e o máximo devem ser iguais, se forem diferentes a memória terá que ser escalada em tempo de execução e é claro ira impactar na busca, principalmente o full text search. Tá mas Waldemar nós não tínhamos 8GB de RAM? por que estamos usando só 4GB? Jovem, não esqueça o elastic usa o Lucene em background e o lucene também faz caches em memória tanto quanto o nosso elastic, ele também irá precisar de memória, então segundo a própria documentação do elastic é aconselhavel usar somente metade da memória para o elastic.

The standard recommendation is to give 50% of the available memory to Elasticsearch heap, while leaving the other 50% free. It won’t go unused; Lucene will happily gobble up whatever is left over.

 

Documentação sobre Heap:

https://www.elastic.co/guide/en/elasticsearch/guide/1.x/heap-sizing.html#heap-sizing

Documentação sobre memória para o Lucene

https://www.elastic.co/guide/en/elasticsearch/guide/1.x/heap-sizing.html#_give_half_your_memory_to_lucene

Seguindo nosso uso consciente de memória vamos dar atenção a outro ponto, o provisionamento de memória, pois não adianta eu dizer para meu serviço que ele poder usar 4GB e ele ter que brigar com outros serviços por esse espaço. Para isso temos a configuração de lock no elasticsearch.yml.

bootstrap.mlockall: true

Mais informações sobre heap e sizing podem ser encontradas aqui: https://www.elastic.co/guide/en/elasticsearch/guide/1.x/heap-sizing.html#heap-sizing

Configurações de CPU

Quando falamos de CPU a dica é ter de 2 a 8 cores, e quando tiver de escolher entre processamento ou núcleos sempre opte por ter mais núcleos pois a concorrência vai ser superior ao clock singular de um processador.

If you need to choose between faster CPUs or more cores, choose more cores. The extra concurrency that multiple cores offers will far outweigh a slightly faster clock speed

Leia mais: https://www.elastic.co/guide/en/elasticsearch/guide/1.x/hardware.html#_cpus

Configurações de I/O

Embora muitos pensem que não, o disco tem uma grande participação no lifecycle do elasticsearch. Eles precisam ler e escrever os clusters no baixo nível do sistema, o mais aconselhado seria o uso de SSDs mas se não for possível é bom ter discos com 15k de RPM (Revolutions Per Minute).

Outro ponto importante aqui no disco é o I/O Schelduler que tem a configuração padrão de cfq (Completely Fair Queuing), ou seja, ele cria uma fila com intervalos de tempo para escrever no disco, quando usamos um SSD essa configuração não faz sentido pois SSDs não são do tipo spinning então pode ser usado algo como deadline ou noop como estratégia de escrita para o disco.

Leia mais: https://www.elastic.co/guide/en/elasticsearch/guide/1.x/hardware.html#_disks

Configurações Gerais

Bom, aqui a nossas máquinas ja estão lindas, nosso cluster rodando liso, tudo verde, agora temos algumas configurações que vão nos auxiliar no dia a dia.

Nome do Cluster

Nomear o cluster é necessário pois o elasticsearch sempre inicia o cluster nomeado como elasticsearch então digamos que algum outro cluster entre na rede com o mesmo nome, isso pode dar problema (pode não, dará).

Simplesmente altere a configuração abaixo no elasticsearch.yml

cluster.name: elasticsearch_custom_name

Leia mais: https://www.elastic.co/guide/en/elasticsearch/guide/current/_important_configuration_changes.html#_assign_names

Nome do Node

Sempre que um novo node é iniciado o elastic vai pegar um nome randômico entre 3000 personagens marvel, legal né? ter o thor e o hulk no mesmo cluster. Quando falamos de produção nomes randômicos nunca são legais, é importante termos certeza de qual node estamos mexendo e também que ele se mantenha com o mesmo nome, por isso precisamos configurar um nome estático pra ele também.

node:

   name: <NAME OF YOUR NODE>

Leia mais: https://www.elastic.co/guide/en/elasticsearch/reference/1.7/setup-configuration.html#node-name

Unicast

Por padrão o elastic vem configurado de forma multicast ou seja, ele fica “pingando” a rede intermitentemente em busca de novos nodes para se juntar no cluster, esse processo é interessante, mas em produção é muito perigoso, imaginem que o sobrinho entra na rede e automaticamente o elastic da merge dos dados dele no nosso cluster de produção? ninguém quer isso.

Então o bacana aqui é mudarmos para unicast ou seja, vamos dizer para o elastic quais serão os hosts autorizados a serem “pingados” assim vamos manter o merge automatico de nodes na nossa rede mas vamos prevenir que maquinas indesejadas se unam a nosso cluster sem o nosso controle.

discovery.zen.ping.multicast.enabled: false

discovery.zen.ping.unicast.hosts: [“host1”, “host2:port”]

Leia mais: https://www.elastic.co/guide/en/elasticsearch/guide/current/_important_configuration_changes.html#_prefer_unicast_over_multicast

 

Muitas outras configurações podem ser feitas, mas essas são o básico para prepararmos nosso ambiente de produção.

Até mais pessoal!