Este artigo foi escrito para axudarche a escoller a solución correcta para ti e comprender as diferenzas entre SDS como Gluster, Ceph e Vstorage (Virtuozzo).
O texto utiliza ligazóns a artigos cunha divulgación máis detallada de certos problemas, polo que as descricións serán o máis breves posible, utilizando puntos clave sen pelusas innecesarias e información introdutoria que pode, se o desexa, obter de forma independente en Internet.
De feito, por suposto, os temas abordados requiren os tons do texto, pero no mundo moderno cada vez máis xente non lle gusta ler moito))), polo que podes ler rapidamente e escoller, e se hai algo non está claro, siga as ligazóns ou google palabras pouco claras))), e este artigo é como un envoltorio transparente para estes temas profundos, mostrando o recheo: os principais puntos clave de cada decisión.
Brillo
Comecemos por Gluster, que é utilizado activamente polos fabricantes de plataformas hiperconverxentes con SDS baseadas en código aberto para contornas virtuais e que se pode atopar na páxina web de RedHat na sección de almacenamento, onde podes escoller entre dúas opcións de SDS: Gluster ou Ceph.
Gluster consiste nunha pila de tradutores: servizos que realizan todo o traballo de distribución de ficheiros, etc. Brick é un servizo que dá servizo a un disco, Volume é un volume (pool) que une estes ladrillos. A continuación vén o servizo de distribución de ficheiros en grupos mediante a función DHT (taboa hash distribuída). Non incluiremos o servizo Sharding na descrición xa que as ligazóns que aparecen a continuación describirán os problemas asociados a el.
Ao escribir, todo o ficheiro gárdase en brick e a súa copia escríbese simultáneamente en brick no segundo servidor. A continuación, o segundo ficheiro escribirase no segundo grupo de dous ladrillos (ou máis) en servidores diferentes.
Se os ficheiros teñen aproximadamente o mesmo tamaño e o volume só consta dun grupo, entón todo está ben, pero noutras condicións xurdirán os seguintes problemas coas descricións:
- o espazo en grupos é utilizado de forma desigual, depende do tamaño dos ficheiros e se non hai espazo suficiente no grupo para escribir un ficheiro, recibirá un erro, o ficheiro non se escribirá e non se redistribuirá a outro grupo. ;
- ao escribir un ficheiro, IO só vai a un grupo, o resto está inactivo;
- non pode obter IO de todo o volume ao escribir un ficheiro;
- e o concepto xeral parece menos produtivo debido á falta de distribución de datos en bloques, onde é máis fácil equilibrar e resolver o problema da distribución uniforme, e non como agora todo o ficheiro vai nun bloque.
Da descrición oficial tamén involuntariamente chegamos a entender que gluster funciona como almacenamento de ficheiros enriba do clásico RAID de hardware. Houbo intentos de desenvolvemento de cortar ficheiros (Sharding) en bloques, pero todo isto é un engadido que impón perdas de rendemento ao enfoque arquitectónico xa existente, ademais do uso de compoñentes de distribución libre con limitacións de rendemento como Fuse. Non hai servizos de metadatos, o que limita o rendemento e as capacidades de tolerancia a fallos do almacenamento ao distribuír ficheiros en bloques. Pódense observar mellores indicadores de rendemento coa configuración "Replicado distribuído" e o número de nodos debe ser polo menos 6 para organizar unha réplica fiable 3 cunha distribución de carga óptima.
Estes achados tamén están relacionados coa descrición da experiencia do usuario e cando se compara con , e tamén hai unha descrición da experiencia que leva a comprender esta configuración máis produtiva e fiable
A imaxe mostra a distribución de carga ao escribir dous ficheiros, onde as copias do primeiro ficheiro distribúense nos tres primeiros servidores, que se combinan no grupo do volume 0, e tres copias do segundo ficheiro colócanse no volume do segundo grupo de tres. servidores. Cada servidor ten un disco.
A conclusión xeral é que se pode utilizar Gluster, pero tendo en conta que haberá limitacións no rendemento e na tolerancia a fallos que crean dificultades en determinadas condicións dunha solución hiperconverxente, onde tamén se necesitan recursos para as cargas informáticas dos contornos virtuais.
Tamén hai algúns indicadores de rendemento de Gluster que se poden acadar baixo determinadas condicións, limitadas a
ceph
Agora vexamos Ceph a partir das descricións de arquitectura que puiden facer Tamén hai unha comparación entre , onde podes comprender inmediatamente que é recomendable implantar Ceph en servidores separados, xa que os seus servizos requiren todos os recursos de hardware baixo carga.
Arquitectura máis complexo que Gluster e hai servizos como os servizos de metadatos, pero toda a pila de compoñentes é bastante complexa e non moi flexible para usalo nunha solución de virtualización. Os datos gárdanse en bloques, o que parece máis produtivo, pero na xerarquía de todos os servizos (compoñentes), hai perdas e latencia en determinadas cargas e condicións de emerxencia, por exemplo as seguintes
A partir da descrición da arquitectura, o corazón é CRUSH, grazas ao cal se selecciona a localización para almacenar datos. A continuación vén PG: esta é a abstracción (grupo lóxico) máis difícil de entender. Os PG son necesarios para facer CRUSH máis eficaz. O propósito principal de PG é agrupar obxectos para reducir o consumo de recursos, aumentar o rendemento e a escalabilidade. Dirixir obxectos directamente, individualmente, sen combinalos nun PG sería moi caro. OSD é un servizo para cada disco individual.
Un clúster pode ter un ou varios conxuntos de datos para diferentes fins e con diferentes configuracións. As piscinas divídense en grupos de colocación. Os grupos de colocación almacenan obxectos aos que acceden os clientes. Aquí é onde remata o nivel lóxico e comeza o nivel físico, porque a cada grupo de colocación se lle asigna un disco principal e varios discos de réplica (cantos dependen exactamente do factor de replicación do grupo). Noutras palabras, a nivel lóxico o obxecto gárdase nun grupo de colocación específico e, a nivel físico, nos discos que se lle asignan. Neste caso, os discos pódense localizar fisicamente en diferentes nodos ou mesmo en diferentes centros de datos.
Neste esquema, os grupos de colocación semellan un nivel necesario para a flexibilidade de toda a solución, pero ao mesmo tempo, como un elo extra desta cadea, o que involuntariamente suxire unha perda de produtividade. Por exemplo, ao escribir datos, o sistema necesita dividilos nestes grupos e despois a nivel físico no disco principal e nos discos para as réplicas. É dicir, a función Hash funciona ao buscar e inserir un obxecto, pero hai un efecto secundario: son custos moi elevados e restricións para reconstruír o hash (ao engadir ou eliminar un disco). Outro problema de hash é a localización claramente cravada dos datos que non se poden cambiar. É dicir, se dalgunha forma o disco está baixo unha maior carga, entón o sistema non ten a oportunidade de non escribir nel (seleccionando outro disco), a función hash obriga a localizar os datos segundo a regra, por moi malo que sexa. o disco é, polo que Ceph come moita memoria ao reconstruír o PG en caso de autocuración ou de aumentar o almacenamento. A conclusión é que Ceph funciona ben (aínda que lentamente), pero só cando non hai escala, situacións de emerxencia ou actualizacións.
Por suposto, hai opcións para aumentar o rendemento a través da caché e a compartición da caché, pero isto require un bo hardware e aínda haberá perdas. Pero en xeral, Ceph parece máis tentador que Gluster para a produtividade. Ademais, ao usar estes produtos, é necesario ter en conta un factor importante: este é un alto nivel de competencia, experiencia e profesionalidade con gran énfase en Linux, xa que é moi importante implementar, configurar e manter todo correctamente. o que lle impón aínda máis responsabilidade e carga ao administrador.
Valmacenamento
A arquitectura parece aínda máis interesante , que se pode usar xunto cun hipervisor nos mesmos nodos, no mesmo , pero é moi importante configuralo todo correctamente para conseguir un bo rendemento. É dicir, implantar un produto deste tipo desde a caixa en calquera configuración sen ter en conta as recomendacións de acordo coa arquitectura será moi sinxelo, pero non produtivo.
O que pode coexistir para o almacenamento xunto aos servizos do hipervisor kvm-qemu, e estes son só algúns servizos onde se atopou unha xerarquía óptima de compoñentes compactas: servizo ao cliente montado mediante FUSE (modificado, non de código aberto), servizo de metadatos MDS (Servizo de metadatos), bloques de datos do servizo Chunk, que a nivel físico é igual a un disco e iso é todo. En termos de velocidade, por suposto, é óptimo usar un esquema tolerante a fallos con dúas réplicas, pero se usa caché e rexistros en unidades SSD, a codificación tolerante a erros (borrar a codificación ou raid6) pódese overclockear decentemente nun esquema híbrido ou aínda mellor en todos os flash. Hai algunha desvantaxe con EC (borrar codificación): ao cambiar un bloque de datos, é necesario volver calcular as cantidades de paridade. Para evitar as perdas asociadas a esta operación, Ceph escribe a EC de forma diferida e poden producirse problemas de rendemento durante unha determinada solicitude, cando, por exemplo, hai que ler todos os bloques e, no caso de Virtuozzo Storage, lévase a cabo a escritura de bloques modificados. usando o enfoque de "sistema de ficheiros estruturados por rexistro", que minimiza os custos de cálculo de paridade. Para estimar aproximadamente as opcións con aceleración de traballo con e sen EC, existen – as cifras poden ser aproximadas dependendo do coeficiente de precisión do fabricante do equipo, pero o resultado dos cálculos é unha boa axuda na planificación da configuración.
Un diagrama simple de compoñentes de almacenamento non significa que estes compoñentes non absorban pero se calculas todos os custos de antemán, podes contar coa colaboración xunto ao hipervisor.
Existe un esquema para comparar o consumo de recursos de hardware dos servizos de almacenamento Ceph e Virtuozzo.
Se antes era posible comparar Gluster e Ceph usando artigos antigos, usando as liñas máis importantes deles, entón con Virtuozzo é máis difícil. Non hai moitos artigos sobre este produto e só se pode obter información da documentación ou en ruso se consideramos Vstorage como almacenamento empregado nalgunhas solucións hiperconverxentes en empresas como e Acronis.
Tentarei axudar cunha descrición desta arquitectura, polo que haberá un pouco máis de texto, pero leva moito tempo entender a documentación por si mesmo, e a documentación existente só se pode usar como referencia revisando a táboa. de contidos ou busca por palabra clave.
Consideremos o proceso de gravación nunha configuración de hardware híbrida cos compoñentes descritos anteriormente: a gravación comeza a dirixirse ao nodo desde o que o cliente a iniciou (o servizo de punto de montaxe FUSE), pero o compoñente mestre do servizo de metadatos (MDS) será, por suposto. dirixe o cliente directamente ao servizo de fragmentos desexado (bloques CS do servizo de almacenamento), é dicir, MDS non participa no proceso de gravación, senón que simplemente dirixe o servizo ao fragmento necesario. En xeral, podemos dar unha analoxía á gravación con verter auga en barrís. Cada barril é un bloque de datos de 256 MB.
É dicir, un disco é un determinado número de tales barrís, é dicir, o volume do disco dividido por 256 MB. Cada copia distribúese a un nodo, a segunda case en paralelo a outro nodo, etc... Se temos tres réplicas e hai discos SSD para a caché (para ler e escribir rexistros), entón a confirmación da escritura producirase despois de escribir. o rexistro no SSD e o restablecemento paralelo desde o SSD continuarán no HDD, coma se fose en segundo plano. No caso de tres réplicas, o rexistro confirmarase despois da confirmación do SSD do terceiro nodo. Pode parecer que a suma da velocidade de escritura de tres SSD pódese dividir por tres e obteremos a velocidade de escritura dunha réplica, pero as copias escríbense en paralelo e a velocidade de latencia da rede adoita ser maior que a do SSD. e de feito o rendemento de escritura dependerá da rede. Neste sentido, para ver IOPS reais, debes cargar correctamente todo o Vstorage , é dicir, probar a carga real, e non a memoria e a caché, onde é necesario ter en conta o tamaño correcto do bloque de datos, o número de fíos, etc.
O rexistro de gravación mencionado anteriormente no SSD funciona de tal xeito que, tan pronto como os datos entran nel, o servizo le inmediatamente e escríbese no HDD. Existen varios servizos de metadatos (MDS) por clúster e o seu número está determinado por un quórum, que funciona segundo o algoritmo de Paxos. Desde o punto de vista do cliente, o punto de montaxe FUSE é un cartafol de almacenamento do clúster que é visible simultaneamente para todos os nodos do clúster, cada nodo ten un cliente montado segundo este principio, polo que este almacenamento está dispoñible para cada nodo.
Para a realización de calquera dos enfoques descritos anteriormente, é moi importante, na fase de planificación e implantación, configurar correctamente a rede, onde haberá un equilibrio debido á agregación e ao ancho de banda da canle de rede seleccionado correctamente. Na agregación, é importante escoller o modo de hash e os tamaños de cadro correctos. Tamén hai unha diferenza moi forte coa SDS descrita anteriormente, esta é a fusión coa tecnoloxía de ruta rápida en Virtuozzo Storage. O que, ademais do fusible modernizado, a diferenza doutras solucións de código aberto, aumenta significativamente o IOPS e permite non estar limitado pola escala horizontal ou vertical. En xeral, en comparación coas arquitecturas descritas anteriormente, esta parece máis potente, pero para tal pracer, por suposto, cómpre mercar licenzas, a diferenza de Ceph e Gluster.
Para resumir, podemos destacar o primeiro dos tres: Virtuozzo Storage ocupa o primeiro lugar en canto a rendemento e fiabilidade da arquitectura, Ceph ocupa o segundo lugar e Gluster ocupa o terceiro lugar.
Os criterios polos que se seleccionou Virtuozzo Storage: é un conxunto óptimo de compoñentes arquitectónicos, modernizados para este enfoque de Fuse con ruta rápida, un conxunto flexible de configuracións de hardware, menor consumo de recursos e capacidade de compartir con computación (informática/virtualización), é dicir, é completamente axeitado para unha solución hiperconverxente, da que forma parte. O segundo lugar está Ceph por ser unha arquitectura máis produtiva en comparación con Gluster, polo seu funcionamento en bloques, así como por escenarios máis flexibles e pola capacidade de traballar en clusters máis grandes.
Hai plans para escribir unha comparación entre vSAN, Space Direct Storage, Vstorage e Nutanix Storage, probando Vstorage en equipos HPE e Huawei, así como escenarios para integrar Vstorage con sistemas de almacenamento de hardware externos, polo que se che gustou o artigo, sería Encantado de recibir comentarios de ti, o que podería aumentar a motivación para novos artigos, tendo en conta os teus comentarios e desexos.
Fonte: www.habr.com