Ola, lectores de Habr. Con este artigo abrimos unha serie que falará do sistema hiperconverxente AERODISK vAIR que desenvolvemos. Inicialmente, queriamos contar todo sobre todo no primeiro artigo, pero o sistema é bastante complexo, polo que comeremos o elefante por partes.
Comecemos a historia coa historia da creación do sistema, afondamos no sistema de ficheiros ARDFS, que é a base de vAIR, e tamén falemos un pouco sobre o posicionamento desta solución no mercado ruso.
En próximos artigos falaremos con máis detalle sobre os diferentes compoñentes arquitectónicos (clúster, hipervisor, equilibrador de carga, sistema de vixilancia, etc.), o proceso de configuración, plantexaremos problemas de licenza, mostraremos por separado probas de fallo e, por suposto, escribiremos sobre probas de carga e dimensionamento. Tamén dedicaremos un artigo separado á versión comunitaria de vAIR.
Aerodisk é unha historia sobre sistemas de almacenamento? Ou por que comezamos a facer hiperconverxencia en primeiro lugar?
Inicialmente, a idea de crear a nosa propia hiperconverxencia xurdiunos arredor de 2010. Nese momento, non había no mercado nin Aerodisk nin solucións similares (sistemas hiperconverxentes en caixas comerciais). A nosa tarefa foi a seguinte: a partir dun conxunto de servidores con discos locais, unidos por unha interconexión a través do protocolo Ethernet, foi necesario crear un almacenamento estendido e lanzar alí máquinas virtuais e unha rede de software. Todo isto tivo que implementarse sen sistemas de almacenamento (porque simplemente non había cartos para os sistemas de almacenamento e o seu hardware, e aínda non tiñamos inventado os nosos propios sistemas de almacenamento).
Probamos moitas solucións de código aberto e finalmente resolvemos este problema, pero a solución era moi complexa e difícil de repetir. Ademais, esta solución estaba na categoría de “Funciona? Non toques! Polo tanto, unha vez resolto ese problema, non desenvolvemos máis a idea de transformar o resultado do noso traballo nun produto completo.
Despois daquel incidente, afastámonos desta idea, pero aínda tiñamos a sensación de que este problema era completamente solucionable, e os beneficios de tal solución eran máis que evidentes. Posteriormente, os produtos HCI lanzados de empresas estranxeiras só confirmaron este sentimento.
Por iso, a mediados de 2016, volvemos a esta tarefa como parte da creación dun produto completo. Nese momento aínda non tiñamos ningunha relación con investidores, polo que tivemos que mercar un posto de desenvolvemento para o noso diñeiro non moi grande. Despois de recoller servidores e interruptores usados en Avito, puxémonos mans á obra.
A principal tarefa inicial foi crear o noso propio, aínda que sinxelo, pero o noso propio sistema de ficheiros, que puidese distribuír de forma automática e uniforme os datos en forma de bloques virtuais no número enésimo de nodos do clúster, que están conectados por unha interconexión vía Ethernet. Ao mesmo tempo, o FS debería escalar ben e facilmente e ser independente dos sistemas adxacentes, é dicir. estar alienado de vAIR en forma de "só unha instalación de almacenamento".
Primeiro concepto de vAIR
Abandonamos deliberadamente o uso de solucións de código aberto preparadas para organizar o almacenamento estendido (ceph, gluster, luster e similares) en favor do noso propio desenvolvemento, xa que xa tiñamos moita experiencia con eles. Por suposto, estas solucións son excelentes, e antes de traballar en Aerodisk, implementamos máis dun proxecto de integración con elas. Pero unha cousa é implementar unha tarefa específica para un cliente, formar o persoal e, quizais, mercar o apoio dun gran provedor, e outra ben distinta é crear un produto facilmente replicable que se utilizará para varias tarefas, que nós, como provedor, pode que mesmo saibamos de nós mesmos non o faremos. Para o segundo propósito, os produtos de código aberto existentes non eran axeitados para nós, polo que decidimos crear nós mesmos un sistema de ficheiros distribuído.
Dous anos despois, varios desenvolvedores (que combinaron o traballo en vAIR co traballo no clásico sistema de almacenamento do motor) lograron un certo resultado.
En 2018, tiñamos escrito un sistema de ficheiros sinxelo e complementámolo co hardware necesario. O sistema combinou discos físicos (locais) de diferentes servidores nunha agrupación plana a través dunha interconexión interna e "cortáronos" en bloques virtuais, despois creáronse dispositivos de bloqueo con diferentes graos de tolerancia a fallos a partir dos bloques virtuais, nos que se crearon os virtuais. e executado usando os coches hipervisores KVM.
Non nos preocupamos moito co nome do sistema de ficheiros e chamámoslle de forma sucinta ARDFS (adiviña o que significa))
Este prototipo tiña bo aspecto (non visualmente, por suposto, aínda non había deseño visual) e mostrou bos resultados en canto a rendemento e escala. Despois do primeiro resultado real, puxemos en marcha este proxecto, organizando un ambiente de desenvolvemento completo e un equipo separado que só se ocupaba de vAIR.
Xusto nese momento xa madurara a arquitectura xeral da solución, que aínda non sufriu grandes cambios.
Mergullo no sistema de ficheiros ARDFS
ARDFS é a base de vAIR, que proporciona almacenamento de datos distribuído e tolerante a fallos en todo o clúster. Unha das características distintivas (pero non as únicas) de ARDFS é que non usa ningún servidor dedicado adicionais para os metadatos e a xestión. Este foi concibido orixinalmente para simplificar a configuración da solución e para a súa fiabilidade.
Estrutura de almacenamento
Dentro de todos os nodos do clúster, ARDFS organiza un grupo lóxico a partir de todo o espazo de disco dispoñible. É importante entender que un pool aínda non é un espazo de datos ou formato, senón simplemente un marcado, é dicir. Calquera nodo con vAIR instalado, cando se engade ao clúster, engádese automaticamente ao grupo ARDFS compartido e os recursos de disco compártense automaticamente en todo o clúster (e están dispoñibles para o almacenamento de datos futuro). Este enfoque permítelle engadir e eliminar nós sobre a marcha sen ningún impacto serio no sistema que xa está en execución. Eses. o sistema é moi fácil de escalar "en ladrillos", engadindo ou eliminando nós no clúster se é necesario.
Os discos virtuais (obxectos de almacenamento para máquinas virtuais) engádense á parte superior do grupo ARDFS, que se constrúen a partir de bloques virtuais de 4 megabytes de tamaño. Os discos virtuais almacenan datos directamente. O esquema de tolerancia a fallos tamén se establece a nivel de disco virtual.
Como xa adiviñarás, para a tolerancia a fallos do subsistema de discos, non usamos o concepto de RAID (Matriz redundante de discos independentes), senón que usamos RAIN (Matriz redundante de nodos independentes). Eses. A tolerancia a fallos mídese, automatízase e xestionase en función dos nodos, non dos discos. Os discos, por suposto, tamén son un obxecto de almacenamento, eles, como todo o demais, son monitorizados, pode realizar todas as operacións estándar con eles, incluíndo a montaxe dun RAID de hardware local, pero o clúster opera especificamente en nós.
Nunha situación na que realmente quere RAID (por exemplo, un escenario que admite múltiples fallos en clústeres pequenos), nada lle impide usar controladores RAID locais e construír un almacenamento estendido e unha arquitectura RAIN enriba. Este escenario está bastante vivo e é apoiado por nós, polo que falaremos del nun artigo sobre escenarios típicos de uso de vAIR.
Esquemas de tolerancia a fallos de almacenamento
Pode haber dous esquemas de tolerancia a fallos para os discos virtuais en vAIR:
1) Factor de replicación ou simplemente replicación: este método de tolerancia a fallos é tan sinxelo coma un pau e unha corda. A replicación síncrona realízase entre nodos cun factor de 2 (2 copias por clúster) ou 3 (3 copias, respectivamente). RF-2 permite que un disco virtual resista a falla dun nodo do clúster, pero "come" a metade do volume útil, e RF-3 soportará a falla de 2 nodos do clúster, pero reserva 2/3 do volume útil para as súas necesidades. Este esquema é moi semellante ao RAID-1, é dicir, un disco virtual configurado en RF-2 é resistente ao fallo de calquera nodo do clúster. Neste caso, todo estará ben cos datos e mesmo a E/S non parará. Cando o nodo caído volva ao servizo, comezará a recuperación/sincronización automática de datos.
A continuación móstranse exemplos da distribución de datos RF-2 e RF-3 en modo normal e nunha situación de fallo.
Temos unha máquina virtual cunha capacidade de 8 MB de datos únicos (útiles), que se executa en 4 nodos vAIR. Está claro que en realidade é pouco probable que haxa un volume tan pequeno, pero para un esquema que reflicte a lóxica do funcionamento de ARDFS, este exemplo é o máis comprensible. AB son bloques virtuais de 4 MB que conteñen datos únicos da máquina virtual. RF-2 crea dúas copias destes bloques A1+A2 e B1+B2, respectivamente. Estes bloques están "dispostos" entre nós, evitando a intersección dos mesmos datos no mesmo nodo, é dicir, a copia A1 non estará situada no mesmo nodo que a copia A2. O mesmo con B1 e B2.
Se un dos nodos falla (por exemplo, no no 3, que contén unha copia de B1), esta copia actívase automaticamente no nodo onde non hai copia da súa copia (é dicir, unha copia de B2).
Así, o disco virtual (e a máquina virtual, en consecuencia) poden sobrevivir facilmente á falla dun nodo no esquema RF-2.
O esquema de replicación, aínda que é sinxelo e fiable, sofre o mesmo problema que o RAID1: non hai espazo útil suficiente.
2) A codificación de borrado ou a codificación de borrado (tamén coñecida como "codificación redundante", "codificación de borrado" ou "código de redundancia") existe para resolver o problema anterior. EC é un esquema de redundancia que ofrece unha alta dispoñibilidade de datos con menor sobrecarga de espazo en disco en comparación coa replicación. O principio de funcionamento deste mecanismo é semellante ao RAID 5, 6, 6P.
Ao codificar, o proceso EC divide un bloque virtual (4MB por defecto) en varios "anacos de datos" máis pequenos dependendo do esquema EC (por exemplo, un esquema 2+1 divide cada bloque de 4MB en 2 anacos de 2MB). A continuación, este proceso xera "anacos de paridade" para os "anacos de datos" que non son máis grandes que unha das partes divididas anteriormente. Ao decodificar, EC xera os anacos que faltan lendo os datos "sobrevivintes" en todo o clúster.
Por exemplo, un disco virtual cun esquema 2 + 1 EC, implementado en 4 nodos do clúster, soportará facilmente a falla dun nodo do clúster do mesmo xeito que RF-2. Neste caso, os custos xerais serán inferiores, en particular, o coeficiente de capacidade útil para RF-2 é 2, e para EC 2+1 será de 1,5.
Para describilo de forma máis sinxela, a esencia é que o bloque virtual divídese en 2-8 (por que de 2 a 8, ver a continuación) "pezas", e para estas pezas calcúlanse "pezas" de paridade de volume similar.
Como resultado, os datos e a paridade distribúense uniformemente en todos os nodos do clúster. Ao mesmo tempo, como ocorre coa replicación, ARDFS distribúe automaticamente os datos entre os nodos de forma que se impida que se almacenen datos idénticos (copias de datos e a súa paridade) no mesmo nodo, co fin de eliminar a posibilidade de que se perdan datos debidos. ao feito de que os datos e a súa paridade acabarán de súpeto nun nodo de almacenamento que falla.
A continuación móstrase un exemplo, coa mesma máquina virtual de 8 MB e 4 nodos, pero cun esquema EC 2+1.
Os bloques A e B divídense en dúas pezas de 2 MB cada unha (dous porque 2+1), é dicir, A1+A2 e B1+B2. A diferenza dunha réplica, A1 non é unha copia de A2, é un bloque virtual A, dividido en dúas partes, o mesmo co bloque B. En total, obtemos dous conxuntos de 4MB, cada un dos cales contén dúas pezas de dous MB. A continuación, para cada un destes conxuntos, a paridade calcúlase cun volume de non máis dunha peza (é dicir, 2 MB), obtemos un adicional + 2 pezas de paridade (AP e BP). En total temos datos 4×2 + paridade 2×2.
A continuación, as pezas son "dispostas" entre os nós para que os datos non se crucen coa súa paridade. Eses. A1 e A2 non estarán no mesmo nodo que AP.
En caso de falla dun nodo (por exemplo, tamén do terceiro), o bloque caído B1 restaurarase automaticamente desde a paridade BP, que se almacena no nodo número 2, e activarase no nodo onde hai sen paridade B, é dicir. peza de BP. Neste exemplo, este é o nodo número 1
Estou seguro de que o lector ten unha pregunta:
"Todo o que describiches foi implementado durante moito tempo tanto polos competidores como en solucións de código aberto, cal é a diferenza entre a túa implementación de EC en ARDFS?"
E despois haberá características interesantes de ARDFS.
Borrado de codificación con foco na flexibilidade
Inicialmente, proporcionamos un esquema EC X+Y bastante flexible, onde X é igual a un número de 2 a 8 e Y é igual a un número de 1 a 8, pero sempre menor ou igual a X. Este esquema ofrécese. pola flexibilidade. Aumentar o número de pezas de datos (X) nas que se divide o bloque virtual permite reducir os custos xerais, é dicir, aumentar o espazo útil.
O aumento do número de anacos de paridade (Y) aumenta a fiabilidade do disco virtual. Canto maior sexa o valor Y, máis nodos poden fallar no clúster. Por suposto, aumentar o volume de paridade reduce a cantidade de capacidade utilizable, pero este é un prezo a pagar pola fiabilidade.
A dependencia do rendemento dos circuítos EC é case directa: cantas máis "pezas", menor será o rendemento; aquí, por suposto, é necesaria unha visión equilibrada.
Este enfoque permite aos administradores configurar o almacenamento estendido coa máxima flexibilidade. Dentro do grupo ARDFS, pode usar calquera esquema de tolerancia a fallos e as súas combinacións, o que, na nosa opinión, tamén é moi útil.
A continuación móstrase unha táboa que compara varios (non todos os posibles) esquemas de RF e EC.
A táboa mostra que incluso a combinación máis "terry" EC 8+7, que permite a perda de ata 7 nodos nun clúster simultaneamente, "come" menos espazo útil (1,875 fronte a 2) que a replicación estándar e protexe 7 veces mellor , o que fai que este mecanismo de protección, aínda que máis complexo, sexa moito máis atractivo en situacións nas que é necesario garantir a máxima fiabilidade en condicións de espazo limitado en disco. Ao mesmo tempo, cómpre entender que cada "máis" de X ou Y será unha sobrecarga de rendemento adicional, polo que no triángulo entre fiabilidade, aforro e rendemento debes escoller con moito coidado. Por este motivo, dedicaremos un artigo separado a borrar o tamaño da codificación.
Fiabilidade e autonomía do sistema de ficheiros
ARDFS execútase localmente en todos os nodos do clúster e sincronízaos mediante os seus propios medios mediante interfaces Ethernet dedicadas. O punto importante é que ARDFS sincroniza de forma independente non só os datos, senón tamén os metadatos relacionados co almacenamento. Mentres traballabamos en ARDFS, estudamos simultáneamente varias solucións existentes e descubrimos que moitas sincronizan o meta do sistema de ficheiros mediante un DBMS externo distribuído, que tamén usamos para a sincronización, pero só as configuracións, non os metadatos FS (sobre este e outros subsistemas relacionados). no seguinte artigo).
Sincronizar metadatos FS usando un DBMS externo é, por suposto, unha solución de traballo, pero entón a coherencia dos datos almacenados en ARDFS dependería do DBMS externo e do seu comportamento (e, francamente, é unha dama caprichosa), que en a nosa opinión é mala. Por que? Se os metadatos de FS danan, os propios datos de FS tamén se poden dicir "adeus", polo que decidimos tomar un camiño máis complexo pero fiable.
Creamos nós mesmos o subsistema de sincronización de metadatos para ARDFS, e vive de forma totalmente independente dos subsistemas adxacentes. Eses. ningún outro subsistema pode corromper os datos ARDFS. Na nosa opinión, esta é a forma máis fiable e correcta, pero o tempo dirá se isto é realmente así. Ademais, hai unha vantaxe adicional con este enfoque. ARDFS pódese usar independentemente de vAIR, igual que o almacenamento estendido, que seguramente usaremos en produtos futuros.
Como resultado, ao desenvolver ARDFS, recibimos un sistema de ficheiros flexible e fiable que permite escoller onde podes aforrar capacidade ou renunciar a todo o rendemento, ou facer almacenamento ultra fiable a un custo razoable, pero reducindo os requisitos de rendemento.
Xunto cunha política de licenzas sinxela e un modelo de entrega flexible (de cara ao futuro, vAIR ten licenza por nodo e entrégase como software ou como paquete de software), isto permítelle adaptar a solución con gran precisión a unha gran variedade de requisitos dos clientes e entón manteña facilmente este equilibrio.
Quen necesita este milagre?
Por unha banda, podemos dicir que xa hai actores no mercado que teñen solucións serias no eido da hiperconverxencia, e é a onde realmente imos. Parece que esta afirmación é certa, PERO...
Por outra banda, cando saímos ao campo e nos comunicamos cos clientes, nós e os nosos socios vemos que non é así. Hai moitas tarefas para a hiperconverxencia, nalgúns lugares a xente simplemente non sabía que existían tales solucións, noutros parecían caros, noutros houbo probas de solucións alternativas sen éxito e noutros prohiben a compra por mor de sancións. En xeral, o campo resultou estar sen arar, polo que fomos levantar terra virxe))).
Cando é mellor o sistema de almacenamento que GCS?
Mentres traballamos co mercado, moitas veces nos preguntan cando é mellor usar un esquema clásico con sistemas de almacenamento e cando usar hiperconverxentes? Moitas empresas que producen GCS (especialmente aquelas que non teñen sistemas de almacenamento na súa carteira) din: "Os sistemas de almacenamento están quedando obsoletos, só hiperconverxentes!" Esta é unha afirmación ousada, pero non reflicte totalmente a realidade.
En realidade, o mercado de almacenamento está a avanzar cara á hiperconverxencia e solucións similares, pero sempre hai un "pero".
En primeiro lugar, os centros de datos e as infraestruturas informáticas construídas segundo o esquema clásico con sistemas de almacenamento non se poden reconstruír facilmente, polo que a modernización e finalización destas infraestruturas segue sendo un legado durante 5-7 anos.
En segundo lugar, a infraestrutura que se está construíndo na súa maioría (é dicir, a Federación Rusa) constrúese segundo o esquema clásico utilizando sistemas de almacenamento, e non porque a xente non coñeza a hiperconverxencia, senón porque o mercado da hiperconverxencia é novo, solucións e solucións. Os estándares aínda non se estableceron, os informáticos aínda non están formados, teñen pouca experiencia, pero necesitan construír centros de datos aquí e agora. E esta tendencia durará outros 3-5 anos (e despois outro legado, ver o punto 1).
En terceiro lugar, hai unha limitación puramente técnica en pequenos atrasos adicionais de 2 milisegundos por escritura (excluíndo a caché local, por suposto), que son o custo do almacenamento distribuído.
Ben, non esquezamos o uso de grandes servidores físicos que adoran a escala vertical do subsistema de discos.
Hai moitas tarefas necesarias e populares nas que os sistemas de almacenamento se comportan mellor que GCS. Aquí, por suposto, aqueles fabricantes que non teñen sistemas de almacenamento na súa carteira de produtos non estarán de acordo con nós, pero estamos preparados para argumentar razoablemente. Por suposto, nós, como desenvolvedores de ambos produtos, compararemos definitivamente os sistemas de almacenamento e GCS nunha das nosas futuras publicacións, onde demostraremos claramente cal é mellor en que condicións.
E onde funcionarán mellor as solucións hiperconverxentes que os sistemas de almacenamento?
A partir dos puntos anteriores, pódense extraer tres conclusións obvias:
- Onde 2 milisegundos adicionais de latencia para a gravación, que ocorren constantemente en calquera produto (agora non falamos de sintéticos, os nanosegundos pódense mostrar en sintéticos), non son críticos, a hiperconverxencia é adecuada.
- Onde a carga dos grandes servidores físicos pode converterse en moitos pequenos virtuais e distribuírse entre nós, a hiperconverxencia tamén funcionará ben alí.
- Cando o escalado horizontal é unha prioridade superior ao escalado vertical, GCS tamén funcionará ben.
Cales son estas solucións?
- Todos os servizos de infraestrutura estándar (servizo de directorio, correo, EDMS, servidores de ficheiros, pequenos ou medianos sistemas ERP e BI, etc.). Chamámoslle a isto "computación xeral".
- A infraestrutura dos provedores de nube, onde é necesario expandir horizontalmente de forma rápida e estandarizada e "cortar" facilmente un gran número de máquinas virtuais para os clientes.
- Infraestrutura de escritorio virtual (VDI), onde moitas máquinas virtuais de usuarios pequenos funcionan e "flotan" silenciosamente dentro dun clúster uniforme.
- Redes de sucursais, onde cada sucursal necesita unha infraestrutura estándar, tolerante a fallos, pero barata de 15-20 máquinas virtuais.
- Calquera computación distribuída (servizos de big data, por exemplo). Onde a carga non vai "en profundidade", senón "en amplitude".
- Contornos de proba nos que se aceptan pequenos atrasos adicionais, pero hai restricións orzamentarias, porque son probas.
Nestes momentos, é para estas tarefas que fixemos AERODISK vAIR e é neles nos que nos estamos centrando (con éxito ata agora). Quizais isto cambie pronto, porque... o mundo non se queda parado.
Entón ...
Completa así a primeira parte dunha gran serie de artigos; no seguinte artigo falaremos da arquitectura da solución e dos compoñentes empregados.
Aceptamos preguntas, suxestións e disputas construtivas.
Fonte: www.habr.com