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 artigos 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.
Vamos 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, irá impactar na busca – principalmente o full text search.
“Ok, mas Waldemar, nós não tínhamos 8GB de RAM? Por que estamos usando só 4GB?”. Jovem, não esqueça que o elastic usa oLucene em background e o lucene também faz caches em memória tanto quanto o nosso elastic. E 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 ele.
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.
Seguindo nosso uso consciente de memória, vamos dar atenção a outro ponto: o provisionamento de memória. 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.
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 está 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ã, 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
Nome do node
Sempre que um novo node é iniciado, o elastic vai pegar um nome randômico entre 3 mil 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”]
Muitas outras configurações podem ser feitas, mas essas são o básico para prepararmos nosso ambiente de produção.
Até mais, pessoal!
De 0 a 10, o quanto você recomendaria este artigo para um amigo?