Olá, leitores do Habr. Com este artigo abrimos uma série que falará sobre o sistema hiperconvergente AERODISK vAIR que desenvolvemos. Inicialmente queríamos contar tudo no primeiro artigo, mas o sistema é bastante complexo, então comeremos o elefante em partes.
Vamos começar a história com a história da criação do sistema, nos aprofundarmos no sistema de arquivos ARDFS, que é a base do vAIR, e também falar um pouco sobre o posicionamento desta solução no mercado russo.
Em artigos futuros falaremos com mais detalhes sobre os diferentes componentes da arquitetura (cluster, hipervisor, balanceador de carga, sistema de monitoramento, etc.), o processo de configuração, levantaremos questões de licenciamento, mostraremos separadamente os testes de colisão e, claro, escreveremos sobre testes de carga e dimensionamento. Também dedicaremos um artigo separado à versão comunitária do vAIR.
Aerodisk é uma história sobre sistemas de armazenamento? Ou por que começamos a fazer hiperconvergência?
Inicialmente, a ideia de criar a nossa própria hiperconvergência surgiu por volta de 2010. Naquela época, não havia Aerodisk nem soluções similares (sistemas comerciais hiperconvergentes em caixa) no mercado. Nossa tarefa era a seguinte: a partir de um conjunto de servidores com discos locais, unidos por uma interconexão via protocolo Ethernet, era necessário criar um armazenamento estendido e ali lançar máquinas virtuais e uma rede de software. Tudo isso teve que ser implementado sem sistemas de armazenamento (porque simplesmente não havia dinheiro para sistemas de armazenamento e seu hardware, e ainda não havíamos inventado nossos próprios sistemas de armazenamento).
Tentamos muitas soluções de código aberto e finalmente resolvemos esse problema, mas a solução era muito complexa e difícil de repetir. Além disso, esta solução estava na categoria “Funciona? Não toque! Portanto, resolvido esse problema, não desenvolvemos mais a ideia de transformar o resultado do nosso trabalho em um produto completo.
Depois desse incidente, abandonámos esta ideia, mas ainda tínhamos a sensação de que este problema era completamente solucionável e os benefícios de tal solução eram mais do que óbvios. Posteriormente, os produtos HCI lançados por empresas estrangeiras apenas confirmaram esse sentimento.
Portanto, em meados de 2016, voltamos a esta tarefa como parte da criação de um produto completo. Naquela época ainda não tínhamos relacionamento com investidores, então tivemos que comprar um estande de desenvolvimento com dinheiro próprio e não muito grande. Depois de coletar servidores e switches usados no Avito, começamos a trabalhar.
A principal tarefa inicial foi criar nosso próprio, embora simples, mas nosso próprio sistema de arquivos, que pudesse distribuir dados de forma automática e uniforme na forma de blocos virtuais no enésimo número de nós do cluster, que são conectados por uma interconexão via Ethernet. Ao mesmo tempo, o FS deve ser bem dimensionado e fácil e ser independente de sistemas adjacentes, ou seja, ser alienado do vAIR na forma de “apenas um depósito”.
Primeiro conceito vAIR
Abandonamos deliberadamente o uso de soluções de código aberto prontas para organizar armazenamento estendido (ceph, gluster, luster e similares) em favor do nosso próprio desenvolvimento, uma vez que já tínhamos muita experiência em projetos com eles. É claro que essas soluções em si são excelentes e, antes de trabalhar no Aerodisk, implementamos mais de um projeto de integração com elas. Mas uma coisa é implementar uma tarefa específica para um cliente, treinar funcionários e, talvez, comprar o suporte de um grande fornecedor, e outra coisa é criar um produto facilmente replicável que será usado para diversas tarefas, que nós, como um fornecedor, pode até saber sobre nós mesmos, não o faremos. Para o segundo propósito, os produtos de código aberto existentes não eram adequados para nós, então decidimos criar nós mesmos um sistema de arquivos distribuído.
Dois anos depois, vários desenvolvedores (que combinaram o trabalho no vAIR com o trabalho no clássico sistema de armazenamento Engine) alcançaram um certo resultado.
Em 2018, escrevemos um sistema de arquivos simples e o complementamos com o hardware necessário. O sistema combinou discos físicos (locais) de diferentes servidores em um pool plano por meio de uma interconexão interna e os “cortou” em blocos virtuais; em seguida, dispositivos de bloco com vários graus de tolerância a falhas foram criados a partir dos blocos virtuais, nos quais os virtuais foram criados e executado usando os carros hipervisores KVM.
Não nos preocupamos muito com o nome do sistema de arquivos e o chamamos sucintamente de ARDFS (adivinhe o que significa))
Este protótipo parecia bom (não visualmente, claro, ainda não havia design visual) e apresentou bons resultados em termos de desempenho e escalabilidade. Após o primeiro resultado real, colocamos este projeto em movimento, organizando um ambiente de desenvolvimento completo e uma equipe separada que lidava apenas com vAIR.
Só nessa altura a arquitectura geral da solução já tinha amadurecido, que ainda não sofreu grandes alterações.
Mergulhando no sistema de arquivos ARDFS
ARDFS é a base do vAIR, que fornece armazenamento de dados distribuído e tolerante a falhas em todo o cluster. Uma das (mas não a única) características distintivas do ARDFS é que ele não utiliza nenhum servidor dedicado adicional para metadados e gerenciamento. Isto foi originalmente concebido para simplificar a configuração da solução e para sua confiabilidade.
Estrutura de armazenamento
Dentro de todos os nós do cluster, o ARDFS organiza um pool lógico de todo o espaço em disco disponível. É importante entender que um pool ainda não é um dado ou espaço formatado, mas simplesmente uma marcação, ou seja, Quaisquer nós com vAIR instalado, quando adicionados ao cluster, são automaticamente adicionados ao pool ARDFS compartilhado e os recursos de disco tornam-se automaticamente compartilhados por todo o cluster (e disponíveis para armazenamento de dados futuro). Essa abordagem permite adicionar e remover nós dinamicamente, sem qualquer impacto sério no sistema já em execução. Aqueles. o sistema é muito fácil de escalar “em tijolos”, adicionando ou removendo nós no cluster se necessário.
Discos virtuais (objetos de armazenamento para máquinas virtuais) são adicionados ao pool ARDFS, que são construídos a partir de blocos virtuais de 4 megabytes de tamanho. Os discos virtuais armazenam dados diretamente. O esquema de tolerância a falhas também é definido no nível do disco virtual.
Como você já deve ter adivinhado, para tolerância a falhas do subsistema de disco, não usamos o conceito de RAID (matriz redundante de discos independentes), mas usamos RAIN (matriz redundante de nós independentes). Aqueles. A tolerância a falhas é medida, automatizada e gerenciada com base nos nós, não nos discos. Os discos, claro, também são um objeto de armazenamento, eles, como tudo mais, são monitorados, você pode realizar todas as operações padrão com eles, incluindo a montagem de um RAID de hardware local, mas o cluster opera especificamente em nós.
Em uma situação em que você realmente deseja RAID (por exemplo, um cenário que suporta múltiplas falhas em clusters pequenos), nada impede que você use controladores RAID locais e construa armazenamento estendido e uma arquitetura RAIN por cima. Este cenário é bastante ativo e é suportado por nós, por isso falaremos sobre ele em um artigo sobre cenários típicos de uso do vAIR.
Esquemas de tolerância a falhas de armazenamento
Pode haver dois esquemas de tolerância a falhas para discos virtuais no vAIR:
1) Fator de replicação ou simplesmente replicação - este método de tolerância a falhas é tão simples quanto um pedaço de pau e uma corda. A replicação síncrona é realizada entre nós com um fator de 2 (2 cópias por cluster) ou 3 (3 cópias, respectivamente). O RF-2 permite que um disco virtual resista à falha de um nó no cluster, mas “consome” metade do volume útil, e o RF-3 resistirá à falha de 2 nós no cluster, mas reserva 2/3 do volume útil para suas necessidades. Este esquema é muito semelhante ao RAID-1, ou seja, um disco virtual configurado no RF-2 é resistente à falha de qualquer nó do cluster. Nesse caso, tudo ficará bem com os dados e até mesmo a E/S não irá parar. Quando o nó caído retornar ao serviço, a recuperação/sincronização automática de dados começará.
Abaixo estão exemplos de distribuição de dados RF-2 e RF-3 em modo normal e em situação de falha.
Temos uma máquina virtual com capacidade de 8 MB de dados únicos (úteis), que roda em 4 nós vAIR. É claro que na realidade é improvável que haja um volume tão pequeno, mas para um esquema que reflita a lógica de funcionamento do ARDFS, este exemplo é o mais compreensível. AB são blocos virtuais de 4 MB contendo dados exclusivos de máquinas virtuais. RF-2 cria duas cópias destes blocos A1+A2 e B1+B2, respectivamente. Esses blocos são “dispostos” entre nós, evitando a intersecção dos mesmos dados no mesmo nó, ou seja, a cópia A1 não estará localizada no mesmo nó que a cópia A2. O mesmo com B1 e B2.
Se um dos nós falhar (por exemplo, o nó nº 3, que contém uma cópia de B1), esta cópia é automaticamente ativada no nó onde não há cópia de sua cópia (ou seja, uma cópia de B2).
Assim, o disco virtual (e a VM, respectivamente) pode facilmente sobreviver à falha de um nó no esquema RF-2.
O esquema de replicação, embora simples e confiável, sofre do mesmo problema do RAID1 – espaço insuficiente utilizável.
2) A codificação de eliminação ou codificação de eliminação (também conhecida como “codificação redundante”, “codificação de eliminação” ou “código de redundância”) existe para resolver o problema acima. EC é um esquema de redundância que fornece alta disponibilidade de dados com menor sobrecarga de espaço em disco em comparação com a replicação. O princípio de funcionamento deste mecanismo é semelhante ao RAID 5, 6, 6P.
Ao codificar, o processo EC divide um bloco virtual (4 MB por padrão) em vários "blocos de dados" menores dependendo do esquema EC (por exemplo, um esquema 2+1 divide cada bloco de 4 MB em 2 pedaços de 2 MB). Em seguida, este processo gera “blocos de paridade” para os “blocos de dados” que não são maiores do que uma das partes anteriormente divididas. Ao decodificar, o EC gera os pedaços ausentes lendo os dados “sobreviventes” em todo o cluster.
Por exemplo, um disco virtual com um esquema EC 2 + 1, implementado em 4 nós do cluster, resistirá facilmente à falha de um nó no cluster da mesma forma que o RF-2. Neste caso, os custos indiretos serão menores, em particular, o coeficiente de capacidade útil para RF-2 é 2 e para EC 2+1 será 1,5.
Para descrevê-lo de forma mais simples, a essência é que o bloco virtual é dividido em 2-8 (por que de 2 a 8, veja abaixo) “peças”, e para essas peças são calculadas “peças” de paridade de volume semelhante.
Como resultado, os dados e a paridade são distribuídos uniformemente por todos os nós do cluster. Ao mesmo tempo, como acontece com a replicação, o ARDFS distribui automaticamente os dados entre os nós de forma a evitar que dados idênticos (cópias de dados e sua paridade) sejam armazenados no mesmo nó, a fim de eliminar a chance de perda de dados devido ao fato de que os dados e sua paridade acabarão repentinamente em um nó de armazenamento que falhará.
Abaixo está um exemplo, com a mesma máquina virtual de 8 MB e 4 nós, mas com esquema EC 2+1.
Os blocos A e B são divididos em dois pedaços de 2 MB cada (dois porque 2+1), ou seja, A1+A2 e B1+B2. Ao contrário de uma réplica, A1 não é uma cópia de A2, é um bloco virtual A, dividido em duas partes, o mesmo do bloco B. No total, obtemos dois conjuntos de 4 MB, cada um contendo duas peças de dois MB. Além disso, para cada um desses conjuntos, a paridade é calculada com um volume não superior a uma peça (ou seja, 2 MB), obtemos + 2 peças adicionais de paridade (AP e BP). No total temos dados 4×2 + paridade 2×2.
A seguir, as peças são “dispostas” entre os nós para que os dados não se cruzem com sua paridade. Aqueles. A1 e A2 não estarão no mesmo nó que o AP.
Em caso de falha de um nó (por exemplo, também do terceiro), o bloco caído B1 será automaticamente restaurado da paridade BP, que está armazenada no nó nº 2, e será ativado no nó onde houver sem paridade B, ou seja, pedaço de PA. Neste exemplo, este é o nó nº 1
Tenho certeza de que o leitor tem uma pergunta:
“Tudo o que você descreveu foi implementado há muito tempo tanto pelos concorrentes quanto em soluções de código aberto. Qual é a diferença entre a sua implementação do EC no ARDFS?”
E então haverá recursos interessantes do ARDFS.
Codificação de eliminação com foco na flexibilidade
Inicialmente, fornecemos um esquema EC X+Y bastante flexível, onde X é igual a um número de 2 a 8 e Y é igual a um número de 1 a 8, mas sempre menor ou igual a X. Este esquema é fornecido para flexibilidade. Aumentar o número de pedaços de dados (X) em que o bloco virtual é dividido permite reduzir custos indiretos, ou seja, aumentar o espaço utilizável.
Aumentar o número de blocos de paridade (Y) aumenta a confiabilidade do disco virtual. Quanto maior o valor de Y, mais nós do cluster poderão falhar. É claro que aumentar o volume de paridade reduz a quantidade de capacidade utilizável, mas este é um preço a pagar pela confiabilidade.
A dependência do desempenho dos circuitos EC é quase direta: quanto mais “peças”, menor o desempenho; aqui, é claro, é necessária uma visão equilibrada.
Essa abordagem permite que os administradores configurem armazenamento estendido com flexibilidade máxima. Dentro do pool ARDFS, você pode usar qualquer esquema de tolerância a falhas e suas combinações, o que, em nossa opinião, também é muito útil.
Abaixo está uma tabela comparando vários esquemas de RF e EC (nem todos possíveis).
A tabela mostra que mesmo a combinação mais “terry” EC 8+7, que permite a perda de até 7 nós em um cluster simultaneamente, “consome” menos espaço utilizável (1,875 versus 2) do que a replicação padrão e protege 7 vezes melhor , o que torna este mecanismo de proteção, embora mais complexo, muito mais atrativo em situações onde é necessário garantir a máxima confiabilidade em condições de espaço em disco limitado. Ao mesmo tempo, você precisa entender que cada “mais” para X ou Y será uma sobrecarga adicional de desempenho, portanto, no triângulo entre confiabilidade, economia e desempenho, você precisa escolher com muito cuidado. Por esse motivo, dedicaremos um artigo separado ao dimensionamento da codificação de apagamento.
Confiabilidade e autonomia do sistema de arquivos
O ARDFS é executado localmente em todos os nós do cluster e os sincroniza usando meios próprios por meio de interfaces Ethernet dedicadas. O ponto importante é que o ARDFS sincroniza de forma independente não apenas os dados, mas também os metadados relacionados ao armazenamento. Enquanto trabalhávamos no ARDFS, estudamos simultaneamente uma série de soluções existentes e descobrimos que muitas sincronizam o meta do sistema de arquivos usando um SGBD distribuído externo, que também usamos para sincronização, mas apenas configurações, não metadados FS (sobre este e outros subsistemas relacionados no próximo artigo).
Sincronizar metadados FS usando um SGBD externo é, obviamente, uma solução funcional, mas então a consistência dos dados armazenados no ARDFS dependeria do SGBD externo e de seu comportamento (e, falando francamente, é uma senhora caprichosa), que em nossa opinião é ruim. Por que? Se os metadados do FS forem danificados, os próprios dados do FS também poderão ser ditos “adeus”, então decidimos seguir um caminho mais complexo, mas confiável.
Nós mesmos criamos o subsistema de sincronização de metadados para ARDFS e ele funciona de forma totalmente independente dos subsistemas adjacentes. Aqueles. nenhum outro subsistema pode corromper os dados do ARDFS. Em nossa opinião, esta é a forma mais confiável e correta, mas o tempo dirá se é realmente assim. Além disso, há uma vantagem adicional nesta abordagem. O ARDFS pode ser usado independentemente do vAIR, assim como o armazenamento estendido, que certamente usaremos em produtos futuros.
Como resultado, ao desenvolver o ARDFS, obtivemos um sistema de arquivos flexível e confiável que oferece a opção de economizar capacidade ou abrir mão de desempenho, ou criar armazenamento ultraconfiável a um custo razoável, mas reduzindo os requisitos de desempenho.
Juntamente com uma política de licenciamento simples e um modelo de entrega flexível (olhando para o futuro, o vAIR é licenciado por nó e entregue como software ou como um pacote de software), isso permite adaptar com muita precisão a solução a uma ampla variedade de requisitos do cliente e então mantenha facilmente esse equilíbrio.
Quem precisa desse milagre?
Por um lado, podemos dizer que já existem players no mercado que possuem soluções sérias no domínio da hiperconvergência, e é para onde estamos realmente a caminhar. Parece que esta afirmação é verdadeira, MAS...
Por outro lado, quando saímos para o campo e comunicamos com os clientes, nós e os nossos parceiros vemos que não é bem assim. Existem muitas tarefas para a hiperconvergência, em alguns lugares as pessoas simplesmente não sabiam que tais soluções existiam, noutros pareciam caras, noutros houve testes mal sucedidos de soluções alternativas e noutros proibiram a compra devido a sanções. Em geral o campo não estava arado, então fomos levantar solo virgem))).
Quando o sistema de armazenamento é melhor que o GCS?
Ao trabalharmos com o mercado, muitas vezes nos perguntam quando é melhor utilizar um esquema clássico com sistemas de armazenamento, e quando utilizar hiperconvergente? Muitas empresas que produzem GCS (especialmente aquelas que não possuem sistemas de armazenamento em seu portfólio) dizem: “Os sistemas de armazenamento estão se tornando obsoletos, apenas hiperconvergentes!” Esta é uma afirmação ousada, mas não reflete inteiramente a realidade.
Na verdade, o mercado de armazenamento está de facto a caminhar para a hiperconvergência e soluções semelhantes, mas há sempre um “mas”.
Em primeiro lugar, os centros de dados e as infra-estruturas de TI construídos de acordo com o esquema clássico com sistemas de armazenamento não podem ser facilmente reconstruídos, pelo que a modernização e conclusão de tais infra-estruturas ainda é um legado para 5-7 anos.
Em segundo lugar, a maior parte da infra-estrutura que está actualmente a ser construída (ou seja, a Federação Russa) é construída de acordo com o esquema clássico, utilizando sistemas de armazenamento, e não porque as pessoas não conheçam a hiperconvergência, mas porque o mercado da hiperconvergência é novo, as soluções e os padrões ainda não foram estabelecidos, o pessoal de TI ainda não está treinado, tem pouca experiência, mas precisa construir data centers aqui e agora. E esta tendência durará mais 3-5 anos (e depois outro legado, ver ponto 1).
Em terceiro lugar, há uma limitação puramente técnica em pequenos atrasos adicionais de 2 milissegundos por gravação (excluindo o cache local, é claro), que são o custo do armazenamento distribuído.
Bem, não vamos esquecer o uso de grandes servidores físicos que adoram o dimensionamento vertical do subsistema de disco.
Existem muitas tarefas necessárias e populares em que os sistemas de armazenamento se comportam melhor que o GCS. Aqui, é claro, os fabricantes que não possuem sistemas de armazenamento em seu portfólio de produtos não concordarão conosco, mas estamos prontos para argumentar razoavelmente. É claro que nós, como desenvolvedores de ambos os produtos, compararemos definitivamente os sistemas de armazenamento e o GCS em uma de nossas publicações futuras, onde demonstraremos claramente qual é o melhor em quais condições.
E onde as soluções hiperconvergentes funcionarão melhor do que os sistemas de armazenamento?
Com base nos pontos acima, três conclusões óbvias podem ser tiradas:
- Onde 2 milissegundos adicionais de latência para gravação, que ocorrem consistentemente em qualquer produto (agora não estamos falando de sintéticos, nanossegundos podem ser mostrados em sintéticos), não são críticos, hiperconvergente é adequado.
- Onde a carga de grandes servidores físicos pode ser transformada em muitos pequenos servidores virtuais e distribuída entre nós, a hiperconvergência também funcionará bem aí.
- Onde a escala horizontal é uma prioridade mais alta do que a escala vertical, o GCS também se sairá bem.
Quais são essas soluções?
- Todos os serviços de infraestrutura padrão (serviço de diretório, correio, EDMS, servidores de arquivos, sistemas ERP e BI de pequeno ou médio porte, etc.). Chamamos isso de “computação geral”.
- A infraestrutura dos provedores de nuvem, onde é necessário expandir horizontalmente de forma rápida e padronizada e “cortar” facilmente um grande número de máquinas virtuais para clientes.
- Infraestrutura de desktop virtual (VDI), onde muitas máquinas virtuais de pequenos usuários são executadas e “flutuam” silenciosamente em um cluster uniforme.
- Redes de filiais, onde cada filial precisa de uma infraestrutura padrão, tolerante a falhas, mas barata, de 15 a 20 máquinas virtuais.
- Qualquer computação distribuída (serviços de big data, por exemplo). Onde a carga não vai “em profundidade”, mas “em largura”.
- Ambientes de teste onde pequenos atrasos adicionais são aceitáveis, mas há restrições orçamentárias, porque se trata de testes.
Neste momento é para estas tarefas que fizemos o AERODISK vAIR e é nelas que nos estamos a concentrar (com sucesso até agora). Talvez isso mude em breve, porque... o mundo não fica parado.
Então ...
Isso completa a primeira parte de uma grande série de artigos; no próximo artigo falaremos sobre a arquitetura da solução e os componentes utilizados.
Aceitamos perguntas, sugestões e disputas construtivas.
Fonte: habr.com