{"id":38542,"date":"2019-10-31T22:24:25","date_gmt":"2019-10-31T19:24:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs\/"},"modified":"2019-10-31T22:24:25","modified_gmt":"2019-10-31T19:24:25","slug":"giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"Solu\u00e7\u00e3o hiperconvergente AERODISK vAIR. A base \u00e9 o sistema de arquivos ARDFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

Ol\u00e1, leitores do Habr. Com este artigo, iniciamos um ciclo que contar\u00e1 sobre o sistema hiperconvergente que desenvolvemos, o AERODISK vAIR. Inicialmente, quer\u00edamos que o primeiro artigo cobrisse tudo, mas o sistema \u00e9 bastante complexo, ent\u00e3o vamos devagar, pe\u00e7a por pe\u00e7a. <\/p>\n

<\/p>\n

Vamos come\u00e7ar contando a hist\u00f3ria da cria\u00e7\u00e3o do sistema, nos aprofundar no sistema de arquivos ARDFS, que \u00e9 a base do vAIR, e tamb\u00e9m discutir um pouco sobre o posicionamento dessa solu\u00e7\u00e3o no mercado russo. <\/p>\n

<\/p>\n

Nos pr\u00f3ximos artigos, falaremos mais detalhadamente sobre diferentes componentes arquitet\u00f4nicos (cluster, hipervisor, balanceador de carga, sistema de monitoramento, etc.), o processo de configura\u00e7\u00e3o, abordaremos quest\u00f5es de licenciamento, destacaremos testes de estresse e, claro, escreveremos sobre testes de carga e dimensionamento. Tamb\u00e9m dedicaremos um artigo \u00e0 vers\u00e3o community do vAIR.<\/p>\n

<\/a><\/noindex><\/p>\n

A Aerodisk \u00e9 como uma hist\u00f3ria sobre armazenamento em rede? Ou por que come\u00e7amos a nos envolver com hiperconverg\u00eancia?<\/h2>\n

<\/p>\n

A ideia de criar nosso pr\u00f3prio sistema hiperconvergente surgiu por volta de 2010. Naquela \u00e9poca, ainda n\u00e3o existia nem o Aerodisk, nem solu\u00e7\u00f5es semelhantes (sistemas hiperconvergentes comerciais) no mercado. Nossa tarefa era a seguinte: a partir de um conjunto de servidores com discos locais, interconectados por meio de Ethernet, era necess\u00e1rio criar um armazenamento distribu\u00eddo e tamb\u00e9m executar m\u00e1quinas virtuais e redes de software. Tudo isso precisava ser feito sem um sistema de armazenamento em rede, j\u00e1 que n\u00e3o havia dinheiro para um e na \u00e9poca ainda n\u00e3o hav\u00edamos desenvolvido o nosso pr\u00f3prio.<\/p>\n

<\/p>\n

Testamos muitas solu\u00e7\u00f5es open source e, de fato, resolvemos essa quest\u00e3o, mas a solu\u00e7\u00e3o era muito complexa e dif\u00edcil de replicar. Al\u00e9m disso, era do tipo \"Funciona? Ent\u00e3o n\u00e3o mexa!\". Portanto, ap\u00f3s resolver a quest\u00e3o, decidimos n\u00e3o continuar desenvolvendo a ideia de transformar o resultado do nosso trabalho em um produto completo. <\/p>\n

<\/p>\n

Depois disso, nos afastamos da ideia, mas a sensa\u00e7\u00e3o de que essa tarefa era totalmente vi\u00e1vel e que os benef\u00edcios de tal solu\u00e7\u00e3o eram mais que \u00f3bvios n\u00e3o nos deixaram. Os produtos HCI lan\u00e7ados por empresas estrangeiras posteriormente apenas confirmaram essa sensa\u00e7\u00e3o. <\/p>\n

<\/p>\n

Portanto, em meados de 2016, retornamos a essa tarefa j\u00e1 no contexto da cria\u00e7\u00e3o de um produto completo. Naquela \u00e9poca, ainda n\u00e3o t\u00ednhamos qualquer relacionamento com investidores, por isso tivemos que comprar o stand de desenvolvimento com nosso dinheiro, que n\u00e3o era muito. Ao procurar no Avito servidores e switches usados, come\u00e7amos a trabalhar.<\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

A principal tarefa inicial era criar nosso pr\u00f3prio sistema de arquivos, que, mesmo que simples, fosse capaz de distribuir automaticamente e de maneira uniforme os dados em forma de blocos virtuais em um n\u00famero n de n\u00f3s de um cluster interconectados via Ethernet. Al\u00e9m disso, o sistema de arquivos deveria escalar bem e facilmente, sendo independente de sistemas adjacentes, ou seja, deveria ser desvinculado do vAIR na forma de um \"simples armazenamento\".<\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

O primeiro conceito do vAIR<\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

Decidimos deliberadamente n\u00e3o usar solu\u00e7\u00f5es open source prontas para organizar um armazenamento distribu\u00eddo (ceph, gluster, lustre e similares) em favor do nosso pr\u00f3prio desenvolvimento, pois j\u00e1 t\u00ednhamos muita experi\u00eancia de projeto com eles. Sem d\u00favida, essas solu\u00e7\u00f5es s\u00e3o excelentes por si mesmas, e at\u00e9 trabalhamos em v\u00e1rios projetos de integra\u00e7\u00e3o com elas antes de desenvolver o Aerodisk. Mas uma coisa \u00e9 realizar uma tarefa espec\u00edfica para um cliente, treinar a equipe e, possivelmente, comprar suporte de um grande fornecedor, e outra bem diferente \u00e9 criar um produto facilmente replic\u00e1vel que ser\u00e1 utilizado para diferentes tarefas que, como fornecedor, talvez nem saibamos. Para esse segundo objetivo, os produtos open source existentes n\u00e3o serviam, ent\u00e3o decidimos desenvolver um sistema de arquivos distribu\u00eddo n\u00f3s mesmos.
\nAp\u00f3s dois anos, com a ajuda de alguns desenvolvedores (que conciliavam o trabalho no vAIR com o trabalho em um sistema de armazenamento cl\u00e1ssico Engine), conseguimos alcan\u00e7ar um resultado determinado.<\/p>\n

<\/p>\n

At\u00e9 2018, escrevemos um sistema de arquivos simples e o complementamos com a infraestrutura necess\u00e1ria. O sistema unificava, atrav\u00e9s de uma interconex\u00e3o interna, discos f\u00edsicos (locais) de diferentes servidores em um \u00fanico pool plano e 'cortava-os' em blocos virtuais; depois, desses blocos virtuais, eram criados dispositivos em bloco com diferentes n\u00edveis de toler\u00e2ncia a falhas, nos quais, com a ajuda do hipervisor KVM, eram criadas e executadas m\u00e1quinas virtuais. <\/p>\n

<\/p>\n

N\u00e3o nos aprofundamos muito no nome do sistema de arquivos e o chamamos de ARDFS (adivinhe como isso \u00e9 abreviado))<\/p>\n

<\/p>\n

Esse prot\u00f3tipo parecia bom (n\u00e3o visualmente, claro, pois n\u00e3o havia formata\u00e7\u00e3o visual na \u00e9poca) e mostrava bons resultados em termos de desempenho e escalabilidade. Ap\u00f3s o primeiro resultado real, decidimos prosseguir com o projeto, organizando um ambiente de desenvolvimento completo e uma equipe separada que se dedicava apenas ao vAIR.<\/p>\n

<\/p>\n

Naquele momento, a arquitetura geral da solu\u00e7\u00e3o estava madura, e desde ent\u00e3o n\u00e3o sofreu mudan\u00e7as significativas.<\/p>\n

<\/p>\n

Explorando o sistema de arquivos ARDFS<\/h2>\n

<\/p>\n

ARDFS \u00e9 a base do vAIR, que proporciona armazenamento de dados distribu\u00eddo e tolerante a falhas para todo o cluster. Uma das (mas n\u00e3o a \u00fanica) caracter\u00edsticas distintas do ARDFS \u00e9 que ele n\u00e3o utiliza nenhum servidores dedicados<\/a> subterf\u00fagio e gerenciamento. Isso foi planejado desde o in\u00edcio para simplificar a configura\u00e7\u00e3o da solu\u00e7\u00e3o e garantir sua confiabilidade. <\/p>\n

<\/p>\n

Estrutura de armazenamento<\/h3>\n

<\/p>\n

Dentro de todos os n\u00f3s do cluster, o ARDFS organiza um pool l\u00f3gico de todo o espa\u00e7o em disco dispon\u00edvel. \u00c9 importante entender que o pool n\u00e3o \u00e9 ainda dados e nem espa\u00e7o formatado, mas simplesmente uma demarca\u00e7\u00e3o, ou seja, quaisquer n\u00f3s com vAIR instalados, ao serem adicionados ao cluster, s\u00e3o automaticamente incorporados ao pool ARDFS, e os recursos de disco tornam-se automaticamente compartilhados por todo o cluster (e dispon\u00edveis para futuros armazenamentos de dados). Essa abordagem permite adicionar e remover n\u00f3s em tempo real sem qualquer impacto significativo no sistema j\u00e1 em funcionamento. Ou seja, o sistema \u00e9 muito f\u00e1cil de escalar 'tijolo a tijolo', adicionando ou removendo n\u00f3s no cluster conforme necess\u00e1rio.<\/p>\n

<\/p>\n

Sobre o pool ARDFS, discos virtuais (objetos de armazenamento para m\u00e1quinas virtuais) s\u00e3o adicionados, constru\u00eddos a partir de blocos virtuais de 4 megabytes. Os dados s\u00e3o armazenados diretamente nesses discos virtuais. No n\u00edvel dos discos virtuais, tamb\u00e9m \u00e9 definido um esquema de toler\u00e2ncia a falhas. <\/p>\n

<\/p>\n

Como j\u00e1 se podia imaginar, para a toler\u00e2ncia a falhas do subsistema de disco, n\u00e3o utilizamos o conceito de RAID (Conjunto Redundante de Discos Independentes), mas sim RAIN (Conjunto Redundante de N\u00f3s Independentes). Ou seja, a toler\u00e2ncia a falhas \u00e9 medida, automatizada e gerenciada com base nos n\u00f3s, e n\u00e3o nos discos. Os discos, sem d\u00favida, tamb\u00e9m s\u00e3o objetos de armazenamento, eles s\u00e3o, como tudo mais, monitorados e permitem todas as opera\u00e7\u00f5es padr\u00e3o, incluindo a cria\u00e7\u00e3o de um RAID de hardware local, mas o cluster opera especificamente com os n\u00f3s. <\/p>\n

<\/p>\n

Em uma situa\u00e7\u00e3o em que se deseja muito o RAID (por exemplo, um cen\u00e1rio que suporte m\u00faltiplas falhas em pequenos clusters), nada impede o uso de controladores RAID locais, e sobre isso pode-se criar um armazenamento distribu\u00eddo e uma arquitetura RAIN. Esse cen\u00e1rio \u00e9 totalmente vi\u00e1vel e suportado por n\u00f3s, portanto, falaremos sobre ele no artigo sobre cen\u00e1rios t\u00edpicos de aplica\u00e7\u00e3o do vAIR.<\/p>\n

<\/p>\n

Esquemas de toler\u00e2ncia a falhas de armazenamento<\/h3>\n

<\/p>\n

Pode haver dois esquemas de toler\u00e2ncia a falhas para discos virtuais no vAIR:<\/p>\n

<\/p>\n

1) Fator de replica\u00e7\u00e3o ou simplesmente replica\u00e7\u00e3o \u2013 esse m\u00e9todo de toler\u00e2ncia a falhas \u00e9 simples \"como uma vara e uma corda\". Realiza replica\u00e7\u00e3o s\u00edncrona entre n\u00f3s com fator 2 (2 c\u00f3pias por cluster) ou 3 (3 c\u00f3pias, respectivamente). O RF-2 permite que o disco virtual suporte a falha de um n\u00f3 no cluster, mas \"consome\" metade do espa\u00e7o \u00fatil, enquanto o RF-3 suportar\u00e1 a falha de 2 n\u00f3s no cluster, mas reservar\u00e1 2\/3 do espa\u00e7o \u00fatil para suas necessidades. Esse esquema se assemelha bastante ao RAID-1, ou seja, um disco virtual configurado em RF-2 \u00e9 resistente \u00e0 falha de qualquer um dos n\u00f3s do cluster. Nesse caso, os dados estar\u00e3o seguros e at\u00e9 as opera\u00e7\u00f5es de entrada e sa\u00edda n\u00e3o ser\u00e3o interrompidas. Quando o n\u00f3 falho voltar ao funcionamento, come\u00e7ar\u00e1 a recupera\u00e7\u00e3o autom\u00e1tica\/sincroniza\u00e7\u00e3o dos dados. <\/p>\n

<\/p>\n

Abaixo est\u00e3o exemplos de distribui\u00e7\u00e3o de dados RF-2 e RF-3 em condi\u00e7\u00f5es normais e em situa\u00e7\u00f5es de falhas.<\/p>\n

<\/p>\n

Temos uma m\u00e1quina virtual com 8 MB de dados \u00fanicos (\u00fateis) que opera em 4 n\u00f3s vAIR. \u00c9 claro que, na realidade, um volume t\u00e3o pequeno \u00e9 improv\u00e1vel, mas este exemplo \u00e9 o mais compreens\u00edvel para ilustrar a l\u00f3gica de opera\u00e7\u00e3o do ARDFS. AB \u2013 s\u00e3o os blocos virtuais de 4 MB contendo dados \u00fanicos da m\u00e1quina virtual. Com RF-2, s\u00e3o criadas duas c\u00f3pias desses blocos A1+A2 e B1+B2, respectivamente. Esses blocos s\u00e3o distribu\u00eddos entre os n\u00f3s, evitando a interse\u00e7\u00e3o dos mesmos dados em um \u00fanico n\u00f3, ou seja, a c\u00f3pia A1 n\u00e3o estar\u00e1 no mesmo n\u00f3 que a c\u00f3pia A2. O mesmo se aplica a B1 e B2.<\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

No caso de falha de um dos n\u00f3s (por exemplo, o n\u00f3 n\u00ba 3, onde est\u00e1 a c\u00f3pia B1), essa c\u00f3pia \u00e9 automaticamente ativada em um n\u00f3 onde n\u00e3o h\u00e1 a c\u00f3pia de sua c\u00f3pia (ou seja, a c\u00f3pia B2). <\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

Assim, o disco virtual (e, consequentemente, a VM) suportar\u00e1 facilmente a falha de um n\u00f3 no esquema RF-2.<\/p>\n

<\/p>\n

O esquema de replica\u00e7\u00e3o, apesar de sua simplicidade e confiabilidade, sofre do mesmo problema que o RAID1 \u2013 pouco espa\u00e7o \u00fatil.<\/p>\n

<\/p>\n

2) O c\u00f3digo de elimina\u00e7\u00e3o ou codifica\u00e7\u00e3o de elimina\u00e7\u00e3o (tamb\u00e9m conhecido como \"codifica\u00e7\u00e3o redundante\", \"codifica\u00e7\u00e3o de elimina\u00e7\u00e3o\" ou \"c\u00f3digo de redund\u00e2ncia\") existe precisamente para resolver o problema acima. EC \u2013 \u00e9 um esquema de redund\u00e2ncia que garante alta disponibilidade de dados com menores custos de espa\u00e7o em disco em compara\u00e7\u00e3o com a replica\u00e7\u00e3o. O princ\u00edpio de funcionamento desse mecanismo \u00e9 semelhante ao RAID 5, 6, 6P. <\/p>\n

<\/p>\n

Na codifica\u00e7\u00e3o, o processo EC divide o bloco virtual (por padr\u00e3o 4 MB) em v\u00e1rios \"pedacinhos de dados\" de acordo com o esquema EC (por exemplo, o esquema 2+1 divide cada bloco de 4 MB em 2 peda\u00e7os de 2 MB). Em seguida, esse processo gera para os \"pedacinhos de dados\" \"peda\u00e7os de paridade\" com tamanho n\u00e3o superior a uma das partes anteriormente divididas. Na decodifica\u00e7\u00e3o, o EC gera os peda\u00e7os faltantes, lendo os dados \"sobreviventes\" por todo o cluster. <\/p>\n

<\/p>\n

Por exemplo, um disco virtual com o esquema EC 2 + 1, implementado em 4 n\u00f3s do cluster, suportar\u00e1 tranquilamente a falha de um n\u00f3 no cluster, assim como o RF-2. Neste caso, os custos indiretos ser\u00e3o menores; especificamente, a taxa de utiliza\u00e7\u00e3o \u00fatil em RF-2 \u00e9 igual a 2, enquanto em EC 2+1 ser\u00e1 de 1,5. <\/p>\n

<\/p>\n

Em termos mais simples, a ess\u00eancia \u00e9 que o bloco virtual \u00e9 dividido em 2-8 (por que de 2 a 8, veja abaixo) \"peda\u00e7os\", e para esses peda\u00e7os s\u00e3o calculados \"peda\u00e7os\" de paridade de volume semelhante. <\/p>\n

<\/p>\n

No final, os dados e a paridade s\u00e3o distribu\u00eddos uniformemente por todos os n\u00f3s do cluster. Assim como na replica\u00e7\u00e3o, o ARDFS distribui automaticamente os dados pelos n\u00f3s de forma a evitar o armazenamento de dados id\u00eanticos (c\u00f3pias dos dados e sua paridade) em um \u00fanico n\u00f3, para eliminar a chance de perder dados caso os dados e sua paridade estejam repentinamente no mesmo n\u00f3 de armazenamento que falhe. <\/p>\n

<\/p>\n

Abaixo um exemplo, com a mesma m\u00e1quina virtual de 8 MB e 4 n\u00f3s, mas com o esquema EC 2+1. <\/p>\n

<\/p>\n

Os Blocos A e B s\u00e3o divididos em dois peda\u00e7os de 2 MB cada (em dois porque 2+1), ou seja, em A1+A2 e B1+B2. Ao contr\u00e1rio da r\u00e9plica, A1 n\u00e3o \u00e9 uma c\u00f3pia de A2, \u00e9 um bloco virtual A, dividido em duas partes, assim como o bloco B. No total, temos dois conjuntos de 4 MB, cada um contendo dois peda\u00e7os de dois megabytes. Em seguida, para cada um desses conjuntos, calcula-se a paridade com um volume de no m\u00e1ximo um peda\u00e7o (ou seja, 2 MB), obtendo mais 2 peda\u00e7os de paridade (A-P e B-P). Portanto, temos 4\u00d72 dados + 2\u00d72 de paridade.<\/p>\n

<\/p>\n

Os peda\u00e7os s\u00e3o ent\u00e3o \"distribu\u00eddos\" pelos n\u00f3s de modo que os dados n\u00e3o se confundam com sua paridade. Ou seja, A1 e A2 n\u00e3o estar\u00e3o no mesmo n\u00f3 que A-P.<\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

No caso de falha de um n\u00f3 (digamos, o terceiro), o bloco B1 que falhou ser\u00e1 automaticamente recuperado da paridade B-P, que est\u00e1 armazenada no n\u00f3 n\u00ba 2, e ser\u00e1 ativado em um n\u00f3 onde n\u00e3o h\u00e1 paridade B, ou seja, do peda\u00e7o B-P. Neste exemplo, isso \u00e9 o n\u00f3 n\u00ba 1.<\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

Estou certo de que o leitor deve estar se perguntando:<\/p>\n

<\/p>\n

\"Tudo o que voc\u00ea descreveu j\u00e1 foi implementado tanto por concorrentes quanto em solu\u00e7\u00f5es de c\u00f3digo aberto, qual \u00e9 a diferen\u00e7a da sua implementa\u00e7\u00e3o de EC no ARDFS?\"<\/p><\/blockquote>\n

E a seguir vir\u00e3o as caracter\u00edsticas interessantes do funcionamento do ARDFS.<\/p>\n

<\/p>\n

Codifica\u00e7\u00e3o por elimina\u00e7\u00e3o com foco na flexibilidade<\/h3>\n

<\/p>\n

Inicialmente, planejamos um esquema EC X+Y bastante flex\u00edvel, onde X varia de 2 a 8 e Y de 1 a 8, mas sempre menor ou igual a X. Este esquema \u00e9 previsto para garantir flexibilidade. O aumento do n\u00famero de peda\u00e7os de dados (X), sobre os quais um bloco virtual \u00e9 dividido, permite reduzir as sobrecargas, ou seja, aumentar o espa\u00e7o \u00fatil.
\nO aumento do n\u00famero de peda\u00e7os de paridade (Y) aumenta a confiabilidade do disco virtual. Quanto maior o valor de Y, mais n\u00f3s no cluster podem falhar. \u00c9 claro que, ao aumentar o volume de paridade, reduz-se a capacidade \u00fatil, mas esse \u00e9 o pre\u00e7o a se pagar pela confiabilidade. <\/p>\n

<\/p>\n

A depend\u00eancia de desempenho das esquemas EC \u00e9 quase direta: quanto mais \"partes\", menor o desempenho; aqui, claramente, \u00e9 necess\u00e1ria uma vis\u00e3o equilibrada. <\/p>\n

<\/p>\n

Essa abordagem permite que os administradores configurem o armazenamento distribu\u00eddo de forma bastante flex\u00edvel. Dentro do pool ARDFS, \u00e9 poss\u00edvel utilizar qualquer combina\u00e7\u00e3o de esquemas de alta disponibilidade, o que tamb\u00e9m consideramos muito \u00fatil. <\/p>\n

<\/p>\n

Abaixo est\u00e1 uma tabela de compara\u00e7\u00e3o de v\u00e1rios (n\u00e3o todos) esquemas RF e EC.<\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

Da tabela, pode-se ver que mesmo a combina\u00e7\u00e3o EC 8+7, que permite a perda de at\u00e9 7 n\u00f3s no cluster, consome menos espa\u00e7o \u00fatil (1,875 contra 2) do que a replica\u00e7\u00e3o padr\u00e3o, enquanto protege 7 vezes melhor, tornando esse mecanismo de prote\u00e7\u00e3o, embora mais complexo, significativamente mais atraente em situa\u00e7\u00f5es onde \u00e9 necess\u00e1rio garantir a m\u00e1xima confiabilidade em condi\u00e7\u00f5es de escassez de espa\u00e7o em disco. \u00c9 preciso entender que cada \"mais\" em X ou Y implicar\u00e1 em uma sobrecarga adicional no desempenho, portanto, \u00e9 crucial escolher cuidadosamente entre a confiabilidade, a economia e o desempenho. Por essa raz\u00e3o, dedicaremos um artigo ao dimensionamento da codifica\u00e7\u00e3o de elimina\u00e7\u00e3o.<\/p>\n

<\/p>\n

\"Solu\u00e7\u00e3o<\/p>\n

<\/p>\n

Confiabilidade e autonomia do sistema de arquivos<\/h3>\n

<\/p>\n

O ARDFS \u00e9 executado localmente em todos os n\u00f3s do cluster e sincroniza seus pr\u00f3prios meios atrav\u00e9s de interfaces Ethernet dedicadas. Um ponto importante \u00e9 que o ARDFS sincroniza n\u00e3o apenas dados, mas tamb\u00e9m metadados relacionados ao armazenamento. Durante o desenvolvimento do ARDFS, estudamos paralelamente v\u00e1rias solu\u00e7\u00f5es existentes e descobrimos que muitas realizam a sincroniza\u00e7\u00e3o dos metadados do sistema de arquivos usando um SGBD distribu\u00eddo externo, que tamb\u00e9m usamos para sincroniza\u00e7\u00e3o, mas apenas para configura\u00e7\u00f5es, e n\u00e3o para os metadados do sistema de arquivos (sobre isso e outras subsistemas relacionadas falaremos no pr\u00f3ximo artigo). <\/p>\n

<\/p>\n

A sincroniza\u00e7\u00e3o dos metadados do sistema de arquivos com um SGBD externo \u00e9, sem d\u00favida, uma solu\u00e7\u00e3o funcional, mas, neste caso, a consist\u00eancia dos dados armazenados no ARDFS dependeria do SGBD externo e do seu comportamento (o que, convenhamos, pode ser bastante caprichoso), o que, em nossa opini\u00e3o, \u00e9 problem\u00e1tico. Por qu\u00ea? Se os metadados do sistema de arquivos forem corrompidos, os pr\u00f3prios dados do sistema de arquivos tamb\u00e9m poder\u00e3o dizer \"adeus\", portanto, decidimos seguir um caminho mais complexo, mas confi\u00e1vel. <\/p>\n

<\/p>\n

Desenvolvemos o subsistema de sincroniza\u00e7\u00e3o de metadados para o ARDFS de forma independente, e ele opera de maneira absolutamente aut\u00f4noma em rela\u00e7\u00e3o aos subsistemas adjacentes. Ou seja, nenhum outro subsistema pode corromper os dados do ARDFS. Em nossa vis\u00e3o, esse \u00e9 o caminho mais seguro e correto, mas se \u00e9 assim na pr\u00e1tica, o tempo dir\u00e1. Al\u00e9m disso, essa abordagem oferece uma vantagem extra. O ARDFS pode ser utilizado independentemente do vAIR, simplesmente como um armazenamento expandido, o que certamente utilizaremos em futuros produtos.<\/p>\n

<\/p>\n

Como resultado do desenvolvimento do ARDFS, criamos um sistema de arquivos flex\u00edvel e confi\u00e1vel, que permite escolher onde economizar em capacidade ou priorizar o desempenho, ou ainda tornar o armazenamento superconfi\u00e1vel a um custo razo\u00e1vel, mas reduzindo as exig\u00eancias de desempenho. <\/p>\n

<\/p>\n

Juntamente com uma pol\u00edtica de licenciamento simples e um modelo de fornecimento flex\u00edvel (adiantando, o licenciamento do vAIR \u00e9 por n\u00f3, e a entrega pode ser feita tanto por software quanto como um pacote), isso permite ajustar muito precisamente a solu\u00e7\u00e3o \u00e0s mais diversas exig\u00eancias dos clientes e, no futuro, manter facilmente esse equil\u00edbrio. <\/p>\n

<\/p>\n

Quem precisa dessa maravilha?<\/h2>\n

<\/p>\n

Por um lado, pode-se dizer que j\u00e1 existem players no mercado com solu\u00e7\u00f5es robustas na \u00e1rea de hiperconverg\u00eancia, e questionar nossa entrada nesse campo. Parece que essa afirma\u00e7\u00e3o \u00e9 verdadeira, MAS...<\/p>\n

<\/p>\n

Por outro lado, ao sair \"a campo\" e conversar com os clientes, n\u00f3s e nossos parceiros percebemos que n\u00e3o \u00e9 bem assim. H\u00e1 muitas demandas para hiperconverg\u00eancia, e, em alguns casos, as pessoas simplesmente n\u00e3o sabiam que essas solu\u00e7\u00f5es existiam, em outros, parecia caro, houveram testes malsucedidos de solu\u00e7\u00f5es alternativas, e em outros lugares, a compra \u00e9 proibida, devido a san\u00e7\u00f5es. De modo geral, o campo se revelou inexplorado, portanto, decidimos desbrav\u00e1-lo))). <\/p>\n

<\/p>\n

Quando um armazenamento de dados \u00e9 melhor que uma solu\u00e7\u00e3o de armazenamento em nuvem?<\/h3>\n

<\/p>\n

Durante nosso trabalho com o mercado, muitas vezes somos questionados sobre quando \u00e9 melhor aplicar o esquema cl\u00e1ssico com armazenamento definido por software (SDS) e quando utilizar a solu\u00e7\u00e3o hiperconvergente. Muitas empresas fabricantes de SDS (especialmente aquelas que n\u00e3o t\u00eam SDS em seu portf\u00f3lio) afirmam: 'O SDS est\u00e1 obsoleto, apenas solu\u00e7\u00f5es hiperconvergentes!'. Essa \u00e9 uma afirma\u00e7\u00e3o ousada, mas n\u00e3o reflete completamente a realidade. <\/p>\n

<\/p>\n

Na verdade, o mercado de SDS realmente est\u00e1 se movendo em dire\u00e7\u00e3o a solu\u00e7\u00f5es hiperconvergentes, mas sempre h\u00e1 um 'mas'.<\/p>\n

<\/p>\n

Primeiramente, os data centers e as infraestruturas de TI constru\u00eddos segundo o esquema cl\u00e1ssico com SDS n\u00e3o podem ser facilmente reformulados, portanto, a moderniza\u00e7\u00e3o e a expans\u00e3o dessas infraestruturas ainda s\u00e3o um legado de 5 a 7 anos.<\/p>\n

<\/p>\n

Em segundo lugar, as infraestruturas que est\u00e3o sendo constru\u00eddas atualmente em massa (referindo-se \u00e0 R\u00fassia) ainda s\u00e3o feitas segundo o esquema cl\u00e1ssico utilizando SDS, n\u00e3o porque as pessoas n\u00e3o conhe\u00e7am as solu\u00e7\u00f5es hiperconvergentes, mas porque o mercado de solu\u00e7\u00f5es hiperconvergentes \u00e9 recente, os padr\u00f5es e solu\u00e7\u00f5es ainda n\u00e3o se estabeleceram, os profissionais de TI ainda n\u00e3o est\u00e3o treinados, e a experi\u00eancia \u00e9 pouca. Al\u00e9m disso, \u00e9 necess\u00e1rio construir data centers aqui e agora. Essa tend\u00eancia dever\u00e1 persistir por mais 3 a 5 anos (e depois ser\u00e1 mais um legado, veja ponto 1).<\/p>\n

<\/p>\n

Em terceiro lugar, h\u00e1 uma limita\u00e7\u00e3o t\u00e9cnica pura nas pequenas lat\u00eancias adicionais de 2 milissegundos na grava\u00e7\u00e3o (sem considerar o cache local, claro), que s\u00e3o o pre\u00e7o a pagar pelo armazenamento distribu\u00eddo. <\/p>\n

<\/p>\n

E n\u00e3o vamos esquecer do uso de grandes servidores f\u00edsicos, que favorecem a escalabilidade vertical dos subsistemas de armazenamento.<\/p>\n

<\/p>\n

Existem muitas tarefas necess\u00e1rias e populares nas quais o SDS se comporta melhor do que as solu\u00e7\u00f5es hiperconvergentes. Claro que os fabricantes que n\u00e3o t\u00eam SDS em seu portf\u00f3lio n\u00e3o concordar\u00e3o com isso, mas estamos prontos para argumentar de forma fundamentada. Como desenvolvedores de ambos os produtos, em uma de nossas futuras publica\u00e7\u00f5es, realizaremos uma compara\u00e7\u00e3o entre SDS e solu\u00e7\u00f5es hiperconvergentes, onde demonstraremos claramente em quais condi\u00e7\u00f5es cada um \u00e9 melhor.<\/p>\n

<\/p>\n

E onde as solu\u00e7\u00f5es hiperconvergentes funcionar\u00e3o melhor que o SDS?<\/h3>\n

<\/p>\n

Com base nos enunciados acima, podemos tirar tr\u00eas conclus\u00f5es \u00f3bvias: <\/p>\n

<\/p>\n

    \n
  1. Onde os adicionais 2 milissegundos de lat\u00eancia na grava\u00e7\u00e3o, que ocorrem de forma consistente em qualquer ambiente produtivo (agora n\u00e3o estamos falando de testes sint\u00e9ticos, em que pode-se demonstrar nanosegundos), n\u00e3o s\u00e3o cr\u00edticas, a solu\u00e7\u00e3o hiperconvergente ser\u00e1 adequada.<\/li>\n
  2. Onde a carga dos grandes servidores f\u00edsicos pode ser transformada em muitas pequenas m\u00e1quinas virtuais e distribu\u00edda por n\u00f3s, a hyperconverg\u00eancia tamb\u00e9m se encaixa bem.<\/li>\n
  3. Onde a escalabilidade horizontal \u00e9 mais priorit\u00e1ria do que a vertical, a HCI tamb\u00e9m se adapta perfeitamente.<\/li>\n<\/ol>\n

    <\/p>\n

    Quais s\u00e3o essas solu\u00e7\u00f5es?<\/h3>\n

    <\/p>\n

      \n
    1. Todos os servi\u00e7os de infraestrutura padr\u00e3o (servi\u00e7o de diret\u00f3rios, e-mail, GED, servidores de arquivos, pequenos ou m\u00e9dios sistemas ERP e BI, etc.). Chamamos isso de 'computa\u00e7\u00e3o comum'. <\/li>\n
    2. Infraestrutura de provedores de nuvem, onde \u00e9 necess\u00e1rio expandir horizontalmente de forma r\u00e1pida e padronizada e facilmente 'fatiar' um grande n\u00famero de m\u00e1quinas virtuais para os clientes.<\/li>\n
    3. Infraestrutura para \u00e1reas de trabalho virtuais<\/a> (VDI), onde muitas pequenas m\u00e1quinas virtuais de usu\u00e1rios s\u00e3o iniciadas e flutuam tranquilamente dentro de um cluster uniforme.<\/li>\n
    4. Redes filiais, onde em cada filial \u00e9 necess\u00e1rio obter uma infraestrutura padr\u00e3o, resiliente e, ao mesmo tempo, econ\u00f4mica, composta por 15-20 m\u00e1quinas virtuais.<\/li>\n
    5. Qualquer computa\u00e7\u00e3o distribu\u00edda (servi\u00e7os de big data, por exemplo). Onde a carga n\u00e3o vai 'em profundidade', mas 'em largura'. <\/li>\n
    6. Ambientes de teste, onde pequenas lat\u00eancias adicionais s\u00e3o aceit\u00e1veis, mas existem limita\u00e7\u00f5es or\u00e7ament\u00e1rias, pois s\u00e3o testes.<\/li>\n<\/ol>\n

      <\/p>\n

      Neste momento, especialmente para essas tarefas, desenvolvemos o AERODISK vAIR e \u00e9 sobre isso que estamos focando (at\u00e9 agora com sucesso). Isso pode mudar em breve, pois o mundo n\u00e3o para.<\/p>\n

      <\/p>\n

      Ent\u00e3o\u2026<\/h3>\n

      <\/p>\n

      Com isso, a primeira parte de um grande ciclo de artigos chega ao fim, no pr\u00f3ximo artigo falaremos sobre a arquitetura da solu\u00e7\u00e3o e os componentes utilizados.<\/p>\n

      <\/p>\n

      Ficaremos felizes em receber perguntas, sugest\u00f5es e discuss\u00f5es construtivas.<\/p>\n

      Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28919,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Solu\u00e7\u00e3o hyperconvergente AERODISK vAIR. A base \u00e9 o sistema de arquivos ARDFS | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0413\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 AERODISK vAIR. \u041e\u0441\u043d\u043e\u0432\u0430 \u2014 \u0444\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 ARDFS | ProHoster","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:24:25+00:00","article:modified_time":"2019-10-31T19:24:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38542","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 13:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:07:40","updated":"2026-02-09 13:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/38542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}