Hola lectores de Habr. Con este artículo abrimos una serie que hablará sobre el sistema hiperconvergente AERODISK vAIR que hemos desarrollado. Inicialmente queríamos contarlo todo en el primer artículo, pero el sistema es bastante complejo, por lo que nos comeremos el elefante en partes.
Comencemos la historia con la historia de la creación del sistema, profundicemos en el sistema de archivos ARDFS, que es la base de vAIR, y también hablemos un poco sobre el posicionamiento de esta solución en el mercado ruso.
En futuros artículos hablaremos con más detalle sobre los diferentes componentes arquitectónicos (clúster, hipervisor, balanceador de carga, sistema de monitoreo, etc.), el proceso de configuración, plantearemos problemas de licencia, mostraremos pruebas de choque por separado y, por supuesto, escribiremos sobre pruebas de carga y dimensionamiento. También dedicaremos un artículo aparte a la versión comunitaria de vAIR.
¿Aerodisk es una historia sobre sistemas de almacenamiento? ¿O por qué empezamos a hacer hiperconvergencia en primer lugar?
Inicialmente, la idea de crear nuestra propia hiperconvergencia nos surgió alrededor de 2010. En aquel momento no existía Aerodisk ni soluciones similares (sistemas hiperconvergentes en caja comerciales) en el mercado. Nuestra tarea era la siguiente: a partir de un conjunto de servidores con discos locales, unidos por una interconexión a través del protocolo Ethernet, era necesario crear un almacenamiento ampliado y ejecutar allí máquinas virtuales y una red de software. Todo esto tuvo que implementarse sin sistemas de almacenamiento (porque simplemente no había dinero para los sistemas de almacenamiento y su hardware, y todavía no habíamos inventado nuestros propios sistemas de almacenamiento).
Probamos muchas soluciones de código abierto y finalmente resolvimos este problema, pero la solución era muy compleja y difícil de repetir. Además, esta solución estaba en la categoría de “¿Funciona?” ¡No toques! Por lo tanto, una vez resuelto ese problema, no desarrollamos más la idea de transformar el resultado de nuestro trabajo en un producto completo.
Después de ese incidente, nos alejamos de esta idea, pero todavía teníamos la sensación de que este problema era completamente solucionable y los beneficios de tal solución eran más que obvios. Posteriormente, los productos HCI lanzados por empresas extranjeras no hicieron más que confirmar esta sensación.
Por lo tanto, a mediados de 2016 volvimos a esta tarea como parte de la creación de un producto completo. En aquel momento todavía no teníamos ninguna relación con inversores, por lo que tuvimos que comprar un stand de desarrollo por nuestra cuenta, que no era mucho dinero. Después de recolectar servidores y conmutadores usados en Avito, nos pusimos manos a la obra.
La principal tarea inicial fue crear nuestro propio sistema de archivos, aunque simple, que pudiera distribuir datos de manera automática y uniforme en forma de bloques virtuales en el enésimo número de nodos del clúster, que están conectados por una interconexión a través de Ethernet. Al mismo tiempo, el FS debería escalar bien y fácilmente y ser independiente de los sistemas adyacentes, es decir ser enajenado de vAIR en forma de “simplemente una instalación de almacenamiento”.
Primer concepto vAIR
Abandonamos deliberadamente el uso de soluciones de código abierto listas para usar para organizar el almacenamiento extendido (ceph, gluster, lustre y similares) en favor de nuestro propio desarrollo, ya que ya teníamos mucha experiencia en proyectos con ellas. Por supuesto, estas soluciones en sí mismas son excelentes y antes de trabajar en Aerodisk, implementamos más de un proyecto de integración con ellas. Pero una cosa es implementar una tarea específica para un cliente, capacitar al personal y, tal vez, comprar el soporte de un gran proveedor, y otra muy distinta es crear un producto fácilmente replicable que se utilizará para diversas tareas, que nosotros, como proveedor, es posible que incluso sepamos sobre nosotros mismos, pero no lo sabremos. Para el segundo propósito, los productos de código abierto existentes no eran adecuados para nosotros, por lo que decidimos crear nosotros mismos un sistema de archivos distribuido.
Dos años más tarde, varios desarrolladores (que combinaron el trabajo en vAIR con el trabajo en el clásico sistema de almacenamiento Engine) lograron un resultado determinado.
En 2018, habíamos escrito un sistema de archivos simple y lo habíamos complementado con el hardware necesario. El sistema combinó discos físicos (locales) de diferentes servidores en un grupo plano a través de una interconexión interna y los "cortó" en bloques virtuales, luego se crearon dispositivos de bloque con distintos grados de tolerancia a fallas a partir de los bloques virtuales, sobre los cuales se crearon los virtuales. y ejecutado utilizando los coches del hipervisor KVM.
No nos preocupamos demasiado con el nombre del sistema de archivos y lo llamamos sucintamente ARDFS (adivinen qué significa))
Este prototipo se veía bien (no visualmente, por supuesto, aún no había un diseño visual) y mostró buenos resultados en términos de rendimiento y escalamiento. Después del primer resultado real, pusimos en marcha este proyecto, organizando un entorno de desarrollo completo y un equipo separado que se ocupaba únicamente de vAIR.
Justo en ese momento había madurado la arquitectura general de la solución, que aún no ha sufrido cambios importantes.
Sumergirse en el sistema de archivos ARDFS
ARDFS es la base de vAIR, que proporciona almacenamiento de datos distribuido y tolerante a fallos en todo el clúster. Una de las características distintivas (pero no la única) de ARDFS es que no utiliza servidores dedicados adicionales para metadatos y administración. Esto fue concebido originalmente para simplificar la configuración de la solución y por su confiabilidad.
Estructura de almacenamiento
Dentro de todos los nodos del clúster, ARDFS organiza un grupo lógico a partir de todo el espacio en disco disponible. Es importante comprender que un grupo aún no son datos ni espacio formateado, sino simplemente marcas, es decir, Cualquier nodo con vAIR instalado, cuando se agrega al clúster, se agrega automáticamente al grupo ARDFS compartido y los recursos del disco se comparten automáticamente en todo el clúster (y están disponibles para almacenamiento de datos en el futuro). Este enfoque le permite agregar y eliminar nodos sobre la marcha sin ningún impacto grave en el sistema que ya se está ejecutando. Aquellos. El sistema es muy fácil de escalar "en ladrillos", agregando o eliminando nodos en el clúster si es necesario.
Los discos virtuales (objetos de almacenamiento para máquinas virtuales) se agregan encima del grupo ARDFS, que se construyen a partir de bloques virtuales de 4 megabytes de tamaño. Los discos virtuales almacenan datos directamente. El esquema de tolerancia a fallos también se establece a nivel del disco virtual.
Como ya habrás adivinado, para la tolerancia a fallos del subsistema de disco, no utilizamos el concepto de RAID (matriz redundante de discos independientes), sino que utilizamos RAIN (matriz redundante de nodos independientes). Aquellos. La tolerancia a fallos se mide, automatiza y gestiona en función de los nodos, no de los discos. Los discos, por supuesto, también son un objeto de almacenamiento, ellos, como todo lo demás, se monitorean, con ellos se pueden realizar todas las operaciones estándar, incluido el ensamblaje de un RAID de hardware local, pero el clúster opera específicamente en nodos.
En una situación en la que realmente desea RAID (por ejemplo, un escenario que admite múltiples fallas en clústeres pequeños), nada le impide usar controladores RAID locales y crear almacenamiento ampliado y una arquitectura RAIN en la parte superior. Este escenario es bastante real y cuenta con el respaldo de nosotros, por lo que hablaremos de ello en un artículo sobre escenarios típicos para usar vAIR.
Esquemas de tolerancia a fallos de almacenamiento
Puede haber dos esquemas de tolerancia a fallos para discos virtuales en vAIR:
1) Factor de replicación o simplemente replicación: este método de tolerancia a fallas es tan simple como un palo y una cuerda. La replicación síncrona se realiza entre nodos con un factor de 2 (2 copias por grupo) o 3 (3 copias, respectivamente). RF-2 permite que un disco virtual resista la falla de un nodo en el clúster, pero "consume" la mitad del volumen útil, y RF-3 resistirá la falla de 2 nodos en el clúster, pero reserva 2/3 del Volumen útil para sus necesidades. Este esquema es muy similar a RAID-1, es decir, un disco virtual configurado en RF-2 es resistente al fallo de cualquier nodo del clúster. En este caso, todo estará bien con los datos e incluso la E/S no se detendrá. Cuando el nodo caído vuelva al servicio, comenzará la recuperación/sincronización automática de datos.
A continuación se muestran ejemplos de la distribución de datos RF-2 y RF-3 en modo normal y en una situación de falla.
Disponemos de una máquina virtual con capacidad de 8MB de datos únicos (útiles), que se ejecuta en 4 nodos vAIR. Está claro que en realidad es poco probable que exista un volumen tan pequeño, pero para un esquema que refleja la lógica del funcionamiento de ARDFS, este ejemplo es el más comprensible. AB son bloques virtuales de 4 MB que contienen datos únicos de máquinas virtuales. RF-2 crea dos copias de estos bloques A1+A2 y B1+B2, respectivamente. Estos bloques están "dispuestos" entre nodos, evitando la intersección de los mismos datos en el mismo nodo, es decir, la copia A1 no se ubicará en el mismo nodo que la copia A2. Lo mismo con B1 y B2.
Si uno de los nodos falla (por ejemplo, el nodo número 3, que contiene una copia de B1), esta copia se activa automáticamente en el nodo donde no hay ninguna copia de su copia (es decir, una copia de B2).
Por lo tanto, el disco virtual (y la VM, en consecuencia) puede sobrevivir fácilmente a la falla de un nodo en el esquema RF-2.
El esquema de replicación, aunque simple y confiable, sufre el mismo problema que RAID1: no hay suficiente espacio utilizable.
2) La codificación de borrado o codificación de borrado (también conocida como “codificación redundante”, “codificación de borrado” o “código de redundancia”) existe para resolver el problema anterior. EC es un esquema de redundancia que proporciona alta disponibilidad de datos con una menor sobrecarga de espacio en disco en comparación con la replicación. El principio de funcionamiento de este mecanismo es similar al RAID 5, 6, 6P.
Al codificar, el proceso EC divide un bloque virtual (4 MB de forma predeterminada) en varios "fragmentos de datos" más pequeños según el esquema EC (por ejemplo, un esquema 2+1 divide cada bloque de 4 MB en 2 fragmentos de 2 MB). A continuación, este proceso genera "fragmentos de paridad" para los "fragmentos de datos" que no son más grandes que una de las partes previamente divididas. Al decodificar, EC genera los fragmentos faltantes leyendo los datos "sobrevivientes" en todo el clúster.
Por ejemplo, un disco virtual con un esquema 2 + 1 EC, implementado en 4 nodos del clúster, resistirá fácilmente la falla de un nodo del clúster de la misma manera que RF-2. En este caso, los gastos generales serán menores, en particular, el coeficiente de capacidad útil para RF-2 es 2 y para EC 2+1 será 1,5.
Para describirlo de manera más simple, la esencia es que el bloque virtual se divide en 2-8 (por qué de 2 a 8, ver más abajo) "piezas", y para estas piezas se calculan "piezas" de paridad de un volumen similar.
Como resultado, los datos y la paridad se distribuyen uniformemente entre todos los nodos del clúster. Al mismo tiempo, al igual que con la replicación, ARDFS distribuye automáticamente datos entre nodos de tal manera que evita que se almacenen datos idénticos (copias de datos y su paridad) en el mismo nodo, para eliminar la posibilidad de perder datos debido al hecho de que los datos y su paridad terminarán repentinamente en un nodo de almacenamiento que falla.
A continuación se muestra un ejemplo, con la misma máquina virtual de 8 MB y 4 nodos, pero con un esquema EC 2+1.
Los bloques A y B se dividen en dos trozos de 2 MB cada uno (dos porque 2+1), es decir, A1+A2 y B1+B2. A diferencia de una réplica, A1 no es una copia de A2, es un bloque virtual A, dividido en dos partes, lo mismo que el bloque B. En total, obtenemos dos conjuntos de 4 MB, cada uno de los cuales contiene dos piezas de dos MB. A continuación, para cada uno de estos conjuntos, se calcula la paridad con un volumen de no más de una pieza (es decir, 2 MB), obtenemos + 2 piezas adicionales de paridad (AP y BP). En total tenemos datos 4×2 + paridad 2×2.
A continuación, se “disponen” las piezas entre los nodos para que los datos no se crucen con su paridad. Aquellos. A1 y A2 no estarán en el mismo nodo que AP.
En caso de falla de un nodo (por ejemplo, también el tercero), el bloque B1 caído se restaurará automáticamente a partir de la paridad de BP, que está almacenada en el nodo No. 2, y se activará en el nodo donde hay sin paridad B, es decir pedazo de BP. En este ejemplo, este es el nodo número 1.
Estoy seguro de que el lector tiene una pregunta:
"Todo lo que usted describió ha sido implementado durante mucho tiempo tanto por la competencia como en soluciones de código abierto, ¿cuál es la diferencia entre su implementación de EC en ARDFS?"
Y luego habrá características interesantes de ARDFS.
Codificación de borrado centrada en la flexibilidad
Inicialmente, proporcionamos un esquema EC X+Y bastante flexible, donde X es igual a un número del 2 al 8 e Y es igual a un número del 1 al 8, pero siempre menor o igual que X. Este esquema se proporciona por flexibilidad. Incrementar el número de piezas de datos (X) en las que se divide el bloque virtual permite reducir los costos generales, es decir, aumentar el espacio utilizable.
Aumentar el número de fragmentos de paridad (Y) aumenta la confiabilidad del disco virtual. Cuanto mayor sea el valor de Y, más nodos del clúster pueden fallar. Por supuesto, aumentar el volumen de paridad reduce la cantidad de capacidad utilizable, pero este es un precio a pagar por la confiabilidad.
La dependencia del rendimiento de los circuitos EC es casi directa: cuantas más “piezas”, menor es el rendimiento; aquí, por supuesto, se necesita una visión equilibrada.
Este enfoque permite a los administradores configurar el almacenamiento ampliado con la máxima flexibilidad. Dentro del grupo ARDFS, puede utilizar cualquier esquema de tolerancia a fallos y sus combinaciones, lo que, en nuestra opinión, también es muy útil.
A continuación se muestra una tabla que compara varios (no todos posibles) esquemas RF y EC.
La tabla muestra que incluso la combinación más "felpa" EC 8+7, que permite la pérdida de hasta 7 nodos en un clúster simultáneamente, "consume" menos espacio utilizable (1,875 frente a 2) que la replicación estándar y protege 7 veces mejor , lo que hace que este mecanismo de protección, aunque más complejo, sea mucho más atractivo en situaciones en las que es necesario garantizar la máxima confiabilidad en condiciones de espacio en disco limitado. Al mismo tiempo, debe comprender que cada "más" de X o Y será una sobrecarga de rendimiento adicional, por lo que en el triángulo entre confiabilidad, ahorro y rendimiento debe elegir con mucho cuidado. Por este motivo, dedicaremos un artículo aparte al tamaño de la codificación de borrado.
Fiabilidad y autonomía del sistema de archivos.
ARDFS se ejecuta localmente en todos los nodos del clúster y los sincroniza por sus propios medios a través de interfaces Ethernet dedicadas. El punto importante es que ARDFS sincroniza de forma independiente no solo los datos, sino también los metadatos relacionados con el almacenamiento. Mientras trabajábamos en ARDFS, estudiamos simultáneamente una serie de soluciones existentes y descubrimos que muchas sincronizan los metadatos del sistema de archivos utilizando un DBMS distribuido externo, que también usamos para la sincronización, pero solo para las configuraciones, no para los metadatos de FS (sobre este y otros subsistemas relacionados). en el próximo artículo).
Sincronizar metadatos de FS utilizando un DBMS externo es, por supuesto, una solución que funciona, pero entonces la consistencia de los datos almacenados en ARDFS dependería del DBMS externo y su comportamiento (y, francamente, es una dama caprichosa), que en Nuestra opinión es mala. ¿Por qué? Si los metadatos de FS se dañan, también se puede decir "adiós" a los datos de FS en sí, por lo que decidimos tomar un camino más complejo pero confiable.
Nosotros mismos creamos el subsistema de sincronización de metadatos para ARDFS y vive de manera completamente independiente de los subsistemas adyacentes. Aquellos. ningún otro subsistema puede dañar los datos ARDFS. En nuestra opinión, esta es la forma más fiable y correcta, pero el tiempo dirá si realmente es así. Además, este enfoque ofrece una ventaja adicional. ARDFS se puede utilizar independientemente de vAIR, al igual que el almacenamiento ampliado, que sin duda utilizaremos en productos futuros.
Como resultado, al desarrollar ARDFS, obtuvimos un sistema de archivos flexible y confiable que brinda la opción de ahorrar capacidad o renunciar a todo en rendimiento, o crear un almacenamiento ultra confiable a un costo razonable, pero reduciendo los requisitos de rendimiento.
Junto con una política de licencia simple y un modelo de entrega flexible (de cara al futuro, vAIR tiene licencia por nodo y se entrega como software o como paquete de software), esto le permite adaptar con mucha precisión la solución a una amplia variedad de requisitos del cliente y entonces mantenga fácilmente este equilibrio.
¿Quién necesita este milagro?
Por un lado, podemos decir que ya hay actores en el mercado que tienen soluciones serias en el campo de la hiperconvergencia, y hacia allí nos dirigimos. Parece que esta afirmación es cierta, PERO...
Por otro lado, cuando salimos al campo y nos comunicamos con los clientes, nosotros y nuestros socios vemos que no es así en absoluto. Las tareas de la hiperconvergencia son muchas, en algunos lugares la gente simplemente no sabía que existían tales soluciones, en otros parecían costosas, en otros hubo pruebas fallidas de soluciones alternativas y en otros prohíben comprar en absoluto debido a las sanciones. En general, el campo resultó sin arar, así que fuimos a levantar tierra virgen))).
¿Cuándo es mejor el sistema de almacenamiento que GCS?
Cuando trabajamos con el mercado, a menudo nos preguntan cuándo es mejor utilizar un esquema clásico con sistemas de almacenamiento y cuándo utilizar un hiperconvergente. Muchas empresas que producen GCS (especialmente aquellas que no tienen sistemas de almacenamiento en su cartera) dicen: "¡Los sistemas de almacenamiento se están volviendo obsoletos, sólo hiperconvergentes!" Esta es una afirmación audaz, pero no refleja del todo la realidad.
En verdad, el mercado del almacenamiento avanza hacia la hiperconvergencia y soluciones similares, pero siempre hay un “pero”.
En primer lugar, los centros de datos y las infraestructuras de TI construidos según el esquema clásico con sistemas de almacenamiento no se pueden reconstruir fácilmente, por lo que la modernización y finalización de dichas infraestructuras sigue siendo un legado de entre 5 y 7 años.
En segundo lugar, la infraestructura que se está construyendo actualmente en su mayor parte (es decir, la Federación de Rusia) se construye según el esquema clásico utilizando sistemas de almacenamiento, y no porque la gente no sepa acerca de la hiperconvergencia, sino porque el mercado de la hiperconvergencia es nuevo, soluciones y Aún no se han establecido estándares, el personal de TI aún no está capacitado, tiene poca experiencia, pero necesitan construir centros de datos aquí y ahora. Y esta tendencia durará otros 3-5 años (y luego otro legado, ver punto 1).
En tercer lugar, existe una limitación puramente técnica en pequeños retrasos adicionales de 2 milisegundos por escritura (excluyendo el caché local, por supuesto), que son el costo del almacenamiento distribuido.
Bueno, no nos olvidemos del uso de grandes servidores físicos a los que les encanta el escalado vertical del subsistema de disco.
Hay muchas tareas necesarias y populares en las que los sistemas de almacenamiento se comportan mejor que GCS. En este caso, por supuesto, aquellos fabricantes que no tienen sistemas de almacenamiento en su cartera de productos no estarán de acuerdo con nosotros, pero estamos dispuestos a discutir razonablemente. Por supuesto, nosotros, como desarrolladores de ambos productos, compararemos los sistemas de almacenamiento y GCS en una de nuestras futuras publicaciones, donde demostraremos claramente cuál es mejor y en qué condiciones.
¿Y dónde funcionarán mejor las soluciones hiperconvergentes que los sistemas de almacenamiento?
Con base en los puntos anteriores, se pueden sacar tres conclusiones obvias:
- Cuando 2 milisegundos adicionales de latencia para la grabación, que ocurre constantemente en cualquier producto (ahora no estamos hablando de sintéticos, los nanosegundos se pueden mostrar en sintéticos), no son críticos, la hiperconvergente es adecuada.
- Cuando la carga de grandes servidores físicos puede convertirse en muchos servidores virtuales pequeños y distribuirse entre nodos, la hiperconvergencia también funcionará bien allí.
- Cuando el escalado horizontal tiene mayor prioridad que el escalado vertical, GCS también funcionará bien allí.
¿Cuáles son estas soluciones?
- Todos los servicios de infraestructura estándar (servicio de directorio, correo, EDMS, servidores de archivos, sistemas ERP y BI pequeños o medianos, etc.). A esto lo llamamos "computación general".
- La infraestructura de los proveedores de la nube, donde es necesario expandir horizontalmente de manera rápida y estandarizada y "cortar" fácilmente una gran cantidad de máquinas virtuales para los clientes.
- Infraestructura de escritorio virtual (VDI), donde se ejecutan muchas máquinas virtuales de usuarios pequeños y "flotan" silenciosamente dentro de un clúster uniforme.
- Redes de sucursales, donde cada sucursal necesita una infraestructura estándar, tolerante a fallas pero económica, de 15 a 20 máquinas virtuales.
- Cualquier informática distribuida (servicios de big data, por ejemplo). Donde la carga no va "en profundidad", sino "a lo ancho".
- Entornos de prueba donde se aceptan pequeños retrasos adicionales, pero existen restricciones presupuestarias, porque se trata de pruebas.
Por el momento, es para estas tareas que hemos creado AERODISK vAIR y es en ellas en las que nos estamos enfocando (con éxito hasta ahora). Quizás esto cambie pronto, porque... el mundo no se detiene.
Así que ...
Esto completa la primera parte de una gran serie de artículos; en el próximo artículo hablaremos sobre la arquitectura de la solución y los componentes utilizados.
Damos la bienvenida a preguntas, sugerencias y disputas constructivas.
Fuente: habr.com