Engenharia

Como projetar a sua arquitetura de armazenamento de dados do Elasticsearch para ampliação

Com o Elasticsearch, você pode armazenar, buscar e analisar grandes quantidades de dados estruturados e não estruturados. Essa velocidade, escala e flexibilidade tornam o Elastic Stack uma solução poderosa para uma ampla variedade de casos de uso, como observabilidade do sistema, segurança (detecção e prevenção de ameaças), busca empresarial e muito mais. Devido a essa flexibilidade, é extremamente importante arquitetar com eficiência o armazenamento de dados da sua implantação para ampliação.

No entanto, é lógico que cada caso de uso do Elasticsearch é diferente. Seu próprio caso de uso/implantação/situação dos negócios terá certas tolerâncias e limites para fatores como: custo total de propriedade, desempenho da ingestão, desempenho das consultas, quantidade e tamanho dos backups, tempo médio de recuperação, entre outros.

Assim, quando você começa a pensar nesses vários fatores, há três perguntas que você pode considerar para ajudar a fechar esta que, de outra forma, poderia ser uma matriz de decisão complexa:

  • Qual é o volume de perda de dados que o seu caso de uso/implantação pode aguentar?
  • O quanto o desempenho influencia seus objetivos de negócios?
  • Quanto tempo de inatividade o seu projeto pode suportar?

Neste post do blog, analisaremos diversas opções de armazenamento de dados que você pode usar e discutiremos os prós e os contras de cada um. Ao final deste post, você terá uma melhor compreensão de como arquitetar o armazenamento de dados da sua própria (e exclusiva) implantação do Elasticsearch para ampliação.

Não quer se preocupar com nada disso? Uma boa notícia: com a adoção do Elasticsearch Service no Elastic Cloud, nós cuidaremos da arquitetura para você.

Visão geral das opções

Veja abaixo uma referência rápida das opções para arquitetar o seu armazenamento de dados com o Elasticsearch que abordaremos neste post do blog. Descreveremos os prós e os contras com mais detalhes e analisaremos o que esperar em relação à perda de dados, ao desempenho e ao tempo de inatividade.

RAID 0RAID 1RAID 5RAID 6Múltiplos caminhos de dados
Proteção dos dados Nenhuma 1 falha de disco 1 falha de disco 2 falhas de disco Nenhuma
Desempenho* NX X/2 (N - 1)X (N - 2)X 1X a NX
Capacidade 100% 50% 67% a 94% 50% a 88% 100%
Prós • Fácil configuração

• Alto desempenho

• Alta capacidade

• O Elasticsearch vê apenas 1 disco
• Alta proteção dos dados

• Fácil recuperação

• O Elasticsearch vê apenas 1 disco
• Média proteção dos dados

• Fácil recuperação

• Capacidade média a alta

• Ganho médio a alto de desempenho

• O Elasticsearch vê apenas 1 disco
• Alta proteção dos dados

• Fácil recuperação

• Capacidade média a alta

• Ganho médio a alto de desempenho

• O Elasticsearch vê apenas 1 disco
• Fácil configuração

• Adição de discos

• Alta capacidade
Contras • Sem tolerância a falhas

• Recuperação longa

• Potencial para perda permanente dos dados se não houver shards de réplica
• Baixa capacidade

• Sem ganho de desempenho para gravações

• Só pode usar 2 discos
• Alguma perda de capacidade

• Apenas 1 disco pode falhar antes que a matriz falhe

• Recuperação potencialmente longa

• Se mais de 1 disco falha, existe a possibilidade de perda de dados

• Durante a recuperação, o desempenho da matriz é reduzido
• Pequena a média perda de capacidade

• Recuperação potencialmente longa

• Durante a recuperação, o desempenho da matriz é reduzido
• Shards não balanceados entre os caminhos

• Um watermark atingido em um único disco afeta todo o nó

• O desempenho não é uniforme

• Não é possível fazer hot swap dos discos

• A adição de um disco pode gerar desempenho irregular e aumento do tempo de espera dos dados (hotspotting)
* N representa o número de discos no volume. X representa o número de IOPS de leitura/gravação que um único disco é capaz de gerar. Números mais altos significam mais desempenho.

Quando você começa a considerar a ampliação da sua capacidade do disco, há algumas boas opções para escolher. Vamos dar uma olhada em algumas delas e discutir os prós e os contras de cada uma. Como cada situação é única, não há um único caminho que possa funcionar idealmente para todas.

RAID 0

Há décadas o RAID é a arquitetura fundamental para a combinação de vários discos. O RAID tem três componentes: espelhamento, striping e paridade. Cada número no RAID indica uma combinação exclusiva desses componentes.

O número 0 representa o striping no RAID. O striping consiste em dividir os dados em blocos e gravar esses blocos em todos os discos do volume.

Desempenho e capacidade

O striping melhora o desempenho de leitura/gravação, pois todos os discos podem gravar em paralelo. Na verdade, isso multiplicará suas gravações e leituras pela quantidade de discos que houver na matriz. Portanto, se você tiver 6 discos em uma matriz RAID 0, terá ~6x a velocidade de leitura/gravação.

Recuperação

O RAID 0 não oferece recuperação; portanto, o Elasticsearch precisa fazer a recuperação por meio de snapshots ou réplicas. Dependendo do tamanho dos discos e do mecanismo de transporte usado para copiar os dados para a matriz, isso poderá levar muito tempo. Durante a etapa de recuperação, o tráfego de rede e o desempenho dos outros nós serão afetados.

Ressalvas

Como os índices do Elasticsearch são compostos de muitos shards, qualquer índice que tenha um shard em um volume RAID 0 que sofrer uma falha de disco também poderá ser corrompido se não houver outras réplicas. Isso resultará em perda permanente dos dados se você não tiver gestão de ciclo de vida de snapshot (SLM) para gerenciar os backups ou se não tiver configurado o Elasticsearch para ter réplicas.

Prós e contras

Prós (+) Contras (-)
  • Fácil de configurar
  • Alto desempenho, pois pode usar 100% da velocidade de leitura e gravação disponível nos discos
  • Alta capacidade, pois a matriz pode usar toda a capacidade dos discos para armazenamento
  • O Elasticsearch vê a matriz como um único disco grande. Portanto, os níveis de watermark e a distribuição de shards funcionam como esperado.
  • Se um disco falhar, todos os dados da matriz inteira serão perdidos, não apenas de um disco. Isso poderá afetar muitos índices.
  • A recuperação exigirá que o cluster copie os shards de réplica para uma nova matriz e consumirá muito tempo e recursos.
  • Potencial de perda permanente dos dados se não houver shards de réplica

RAID 1

Desempenho e capacidade

O espelhamento é representado no RAID com o número 1. Espelhamento é o processo de gravar os mesmos dados em outro disco. Isso, na verdade, cria uma cópia dos dados. Embora os dados sejam gravados nos dois discos, a maioria das implementações de RAID não usa os dois discos para a leitura. Assim, o desempenho de leitura e gravação é efetivamente reduzido pela metade. Como os mesmos dados são gravados nos dois discos, você também perde metade da sua capacidade.

Recuperação

O RAID 1 é feito para abranger apenas dois discos. Portanto, se um disco falhar, os dados ainda serão preservados no outro disco. Isso cria alta redundância de dados ao custo de desempenho e capacidade. Quando um disco falha, basta substituí-lo, e os dados são copiados para o novo disco.

Ressalvas

Na maioria dos casos, o RAID 1 é usado junto com o RAID 0, pois o RAID 1 trabalha apenas com dois discos. Isso significa que você combinaria vários volumes de RAID 1 com um RAID 0 com striping. Isso se chama RAID 10 e é usado quando você tem quatro discos ou mais.

Com isso, você tem alguns dos benefícios de desempenho do RAID 0 combinados com a redundância do RAID 1. O desempenho do RAID 10 depende de quantos discos há na matriz. O desempenho do RAID 10 é Nx/2.

Prós e contras

Prós (+) Contras (-)
  • Alta proteção dos dados, pois todos os dados são espelhados em outro disco.
  • Recuperação fácil quando um disco falha —- basta substituir o disco com falha, e os dados serão copiados para ele.
  • A Elastic vê a matriz como um único disco.
  • Baixa capacidade, pois o RAID 1 ocupará 50% de sua capacidade total de disco para redundância de dados.
  • Isso representa efetivamente uma redução de 50% no desempenho total de leitura/gravação
  • Abrange apenas 2 discos, a menos que esteja usando RAID 10

RAID 5, 6

Desempenho e capacidade

A paridade é representada no RAID com vários números: 2, 3, 4, 5, 6. Vamos nos concentrar no 5 e no 6, pois o 2, o 4 e o 3 são, na maioria das vezes, substituídos por outros RAIDs. A paridade é uma maneira de os computadores corrigirem ou calcularem dados ausentes devido a uma falha no disco. A paridade adiciona proteção de dados ao desempenho do striping. No entanto, a recuperação dos dados tem um custo. O RAID 5 usa a capacidade de um disco para paridade, e o RAID 6 usa a capacidade de dois discos.

Recuperação

Outros pontos a serem considerados no RAID 5 e 6 são os tempos de reconstrução para recuperação. Uma reconstrução acontece quando um novo disco é adicionado novamente à matriz, substituindo um disco anterior. No caso dos discos rígidos giratórios, adicione mais discos em vez de adicionar capacidade de disco. Mais discos aumentarão os tempos de leitura e gravação, bem como os tempos de reconstrução. No caso de SSDs, você precisará verificar se os discos de maior capacidade também apresentam desempenho superior de leitura e gravação. Muitos discos SSD de maior capacidade têm desempenho mais alto de leitura/gravação. Se for esse o caso, os discos de maior capacidade ajudarão no desempenho de leitura/gravação. O RAID 5 pode sofrer uma única falha de disco antes de perder dados da matriz. O RAID 6 pode sofrer duas falhas de disco.

Ressalvas

Embora o RAID 5 e o 6 possam aguentar uma falha de disco, ela não ocorre sem consequências. Para o RAID 5, isso significa estar efetivamente tão frágil quanto com um RAID 0 até que um novo disco seja adicionado. Se outro disco falhar, todos os dados na matriz serão perdidos e precisarão ser recuperados de outros shards ou de um snapshot. Por esse motivo, muitos recomendam a execução no RAID 6, pois lotes de discos podem falhar quase ao mesmo tempo. Como mencionamos no começo, entender a tolerância do projeto ao desempenho e à integridade dos dados é essencial para decidir entre esses dois.

A perda de um disco também afetará muito o desempenho do RAID 5 e do 6, pois a matriz precisará usar a paridade para recalcular os dados que estiverem sendo lidos dos discos.

Prós e contras

Prós (+) Contras (-)
  • Média proteção dos dados. A matriz pode calcular e reconstruir os dados ausentes de um único disco com falha.
  • Recuperação fácil quando um disco falha —- basta adicionar outro disco, e os dados serão reconstruídos.
  • Capacidade média a alta. Você perde apenas a capacidade de armazenamento de um disco no RAID 5 e de dois no RAID 6 para a paridade.
  • Ganho médio a alto de desempenho. Você perde apenas o desempenho de gravação de um disco no RAID 5 e no 6 para a paridade.
  • A Elastic vê a matriz como um único disco.
  • Pequena a média perda de capacidade devido à paridade.
  • O RAID 5 pode sofrer apenas uma única falha de disco. O RAID 6 pode sofrer apenas duas falhas de disco.
  • Dependendo do tamanho dos discos, a restauração de um disco pode levar mais de 24 horas.
  • Enquanto uma restauração estiver em andamento, você correrá o risco de perda total dos dados se um disco falhar no RAID 5 e se dois falharem no RAID 6.
  • Enquanto estiver em uma restauração, a matriz operará com desempenho reduzido de leitura/gravação.

Múltiplos caminhos de dados (MDP) no Elasticsearch

O Elasticsearch tem uma configuração chamada path.data, que é usada para configurar os locais do sistema de arquivos para os arquivos de dados do Elasticsearch. Quando uma lista é especificada para path.data, o Elasticsearch usa vários locais para armazenar arquivos de dados. Por exemplo, se o seu elasticsearch.yml contiver o seguinte:

path.data: [ /mnt/path1, /mnt/path2, /mnt/path3 ]

O Elasticsearch gravará em vários locais do sistema de arquivos. Cada um desses caminhos poderia ser um disco separado.

A definição de múltiplos caminhos de dados permite que o usuário configure o Elasticsearch para trabalhar com vários armazenamentos de dados.

Desempenho e capacidade

O Elasticsearch divide os dados por shards, e os shards são gravados no caminho de dados com o maior espaço livre. Se um shard receber a maior parte das gravações, o seu desempenho será limitado à velocidade de um único caminho de dados. Se, no entanto, seus dados estiverem sendo gravados uniformemente nos caminhos de dados, você obterá a velocidade de gravação de todos os discos que estiverem sendo usados. O Elasticsearch não garante que as gravações abranjam muitos caminhos de dados; por isso, o desempenho é variável e não uniforme.

O MDP não inclui nenhum espelhamento ou paridade dos dados. Isso significa que toda a capacidade dos discos poderá ser usada para armazenar dados, exceto se um watermark for atingido. Mais explicações sobre isso são fornecidas na seção de prós e contras. Para usar a capacidade total do disco, você precisará de, pelo menos, uma quantidade equivalente de shards e de caminhos de dados.

A adição de um novo caminho de dados em um nó que já tenha dados em outros caminhos poderá gerar desempenho irregular e aumento do tempo de espera dos dados (hotspotting) no novo disco. Pelo fato de o Elasticsearch não fazer balanceamento de shards entre os caminhos de dados, todos os novos shards serão enviados para o novo caminho, já que ele tem o maior espaço livre. Como o Elasticsearch apenas lê as atualizações do elasticsearch.yml na inicialização, a adição de qualquer disco exigirá uma reinicialização completa do nó.

Recuperação

Os discos ficarão ruins. Quando um dispositivo de armazenamento que faz parte dos múltiplos caminhos de dados morre, o nó fica amarelo, e os dados localizados nesse dispositivo tornam-se inacessíveis. No entanto, o Elasticsearch pode continuar gravando nesse caminho de dados com falha que está gerando IOExceptions. Para impedir que isso ocorra, é importante remover da configuração do nó do Elasticsearch o caminho de dados com problema fazendo o seguinte:

  1. Desabilite a alocação de shard.
  2. Pare o nó.
  3. Remova da configuração do Elasticsearch o caminho de dados com problema.
  4. Reinicie o nó.
  5. Reabilite a alocação de shard.

Para impedir a perda permanente dos dados, verifique se o Elasticsearch está configurado com a replicação habilitada. O padrão é ter uma réplica por shard.

Então, o Elasticsearch rebalanceará os shards de outros nós. O Elasticsearch não faz balanceamento de shards entre os caminhos de dados. Consulte a seção de ressalvas para saber mais detalhes. Se não houver capacidade suficiente no cluster para o rebalanceamento, o nó permanecerá amarelo.

Para substituir um novo disco, tenha o cuidado de desmontar o disco e desativar quaisquer grupos de LVM. Isso ajuda a garantir que o sistema operacional possa lidar adequadamente com o novo disco. Assim que o novo disco for instalado, você precisará adicionar o caminho novamente à configuração path.data do Elasticsearch. Após a substituição do disco defeituoso, o Elasticsearch começará a usar o novo caminho.

Ressalvas

Quando um dispositivo especificado em uma configuração de múltiplos caminhos de dados morre, o caminho é ignorado para a próxima alocação de shard. No entanto, as rodadas subsequentes considerarão o caminho elegível para alocações de shard novamente. Isso poderá levar a erros de IOException, a menos que as etapas mencionadas acima sejam executadas.

O Elasticsearch lida com os watermarks em cada nó. É importante estar ciente disso, porque se um caminho de dados atingir o watermark alto, isso também ocorrerá com o nó inteiro, mesmo se os outros caminhos de dados tiverem espaço livre suficiente. Ou seja, o nó que atingiu o watermark parará de aceitar novos shards, os moverá ativamente para fora do nó ou entrará em um estado somente de leitura.

Como exemplo, vamos pegar um nó com 6 caminhos de dados de 500 GB e capacidade total de cerca de 3 TB. É possível que um único caminho de dados atinja 90% de utilização do disco. Isso faria com que o nó inteiro atingisse o watermark de estágio de atenção, colocando o nó em estado somente de leitura. Isso acontecerá mesmo com outros discos no nó que tenham menos de 50% de utilização.

O Elasticsearch não lida com balanceamento de shards em um único nó, ou seja, não fará o balanceamento dos shards entre os caminhos de dados. Portanto, se um usuário estiver usando múltiplos caminhos de dados, o Elasticsearch colocará os shards no disco com o maior espaço livre disponível no momento. Se um shard receber mais dados que outros e encher um disco, o Elasticsearch não fará o balanceamento dos shards. Isso poderá levar a uma distribuição desigual da carga de entrada e saída caso você não esteja ciente desse detalhe. Além disso, adicionar um novo disco a um nó que contenha dados em outros caminhos poderá gerar uma alta carga de entrada e saída no novo caminho.

Prós e contras

Prós (+) Contras (-)
  • Fácil de configurar
  • Possibilidade de adicionar discos a qualquer momento
  • Alta utilização da capacidade de disco
  • O Elasticsearch não fará um balanceamento entre os caminhos de dados
  • Quando um único armazenamento de dados atingir um watermark, o nó inteiro será afetado
  • O desempenho depende de como os dados são distribuídos entre os armazenamentos de dados
  • Não é possível fazer hot swap dos discos
  • A adição de discos pode provocar sobrecarga do disco

Conclusão

É empolgante chegar ao ponto em que você precisa começar a aumentar seus dados! Embora tenhamos falado sobre muitas opções e ferramentas neste post do blog, lembre-se de que não existe uma solução única quando se trata de projetar a arquitetura do seu armazenamento de dados para ampliação.

Caso ainda tenha dúvidas ou preocupações sobre como arquitetar o armazenamento da sua implantação do Elasticsearch para ampliação, eu e uma comunidade crescente de usuários estaremos à disposição para ajudar em nossos fóruns de discussão.

Melhor ainda — se você não quiser gerenciar tudo isso por conta própria, repetirei a boa notícia que mencionei anteriormente: o Elastic Cloud gerenciará tudo isso para você. Expandir é tão fácil quanto adicionar outro nó. Não há servidores para desembalar, colocar no rack e gerenciar. E ele funciona onde você (provavelmente) já está — na Amazon Web Services, no Google Cloud Platform e no Microsoft Azure. Que tal fazer um test drive hoje mesmo?