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 0 | RAID 1 | RAID 5 | RAID 6 | Mú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) |
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 (-) |
|
|
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 (-) |
|
|
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ú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:
- Desabilite a alocação de shard.
- Pare o nó.
- Remova da configuração do Elasticsearch o caminho de dados com problema.
- Reinicie o nó.
- 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 (-) |
|
|
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?