{"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\/es\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"Soluci\u00f3n hiperconvergente AERODISK vAIR. La base es el sistema de archivos ARDFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Soluci\u00f3n<\/p>\n

<\/p>\n

Hola, lectores de Habr. Con este art\u00edculo comenzamos un ciclo que hablar\u00e1 sobre nuestro sistema hiperconvergente AERODISK vAIR. Inicialmente quer\u00edamos presentar todo sobre todo en el primer art\u00edculo, pero el sistema es bastante complejo, as\u00ed que vamos a comer el elefante por partes. <\/p>\n

<\/p>\n

Comenzaremos la historia de la creaci\u00f3n del sistema, profundizaremos en el sistema de archivos ARDFS, que es la base de vAIR, y tambi\u00e9n reflexionaremos un poco sobre el posicionamiento de esta soluci\u00f3n en el mercado ruso. <\/p>\n

<\/p>\n

En futuros art\u00edculos, hablaremos con m\u00e1s detalle sobre los diferentes componentes arquitect\u00f3nicos (cl\u00faster, hipervisor, balanceador de carga, sistema de monitoreo, etc.), el proceso de configuraci\u00f3n, abordaremos cuestiones de licenciamiento, mostraremos pruebas de estr\u00e9s y, por supuesto, escribiremos sobre pruebas de carga y dimensionamiento. Tambi\u00e9n dedicaremos un art\u00edculo aparte a la versi\u00f3n community de vAIR.<\/p>\n

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

\u00bfAerodisk es una historia sobre almacenamiento? \u00bfO por qu\u00e9 comenzamos a trabajar en hiperconvergencia?<\/h2>\n

<\/p>\n

La idea de crear nuestro propio hiperconvergente nos lleg\u00f3 alrededor de 2010. En aquel entonces, no exist\u00eda ni Aerodisk, ni soluciones similares (sistemas hiperconvergentes comerciales) en el mercado. Nuestro objetivo era el siguiente: a partir de un conjunto de servidores con discos locales, interconectados por protocolo Ethernet, crear un almacenamiento distribuido y ejecutar m\u00e1quinas virtuales y una red de software ah\u00ed mismo. Todo esto ten\u00eda que implementarse sin almacenamiento (porque simplemente no ten\u00edamos dinero para almacenamiento y su infraestructura, y en ese momento a\u00fan no hab\u00edamos inventado nuestro propio almacenamiento).<\/p>\n

<\/p>\n

Probamos muchas soluciones de c\u00f3digo abierto y, al final, resolvimos esta tarea, pero la soluci\u00f3n result\u00f3 ser muy complicada y dif\u00edcil de reproducir. Adem\u00e1s, esta soluci\u00f3n era del tipo '\u00bfFunciona? \u00a1No lo toques!'. Por lo tanto, al resolver esa tarea, no continuamos desarrollando la idea de convertir el resultado de nuestro trabajo en un producto completo. <\/p>\n

<\/p>\n

Despu\u00e9s de ese evento, nos alejamos de esa idea, pero a\u00fan nos quedaba la sensaci\u00f3n de que esta tarea era completamente resolvible y que los beneficios de tal soluci\u00f3n eran m\u00e1s que evidentes. En el futuro, los productos HCI lanzados por empresas extranjeras solo confirmaron esta sensaci\u00f3n. <\/p>\n

<\/p>\n

Por lo tanto, a mediados de 2016, volvimos a esta tarea ya en el contexto de la creaci\u00f3n de un producto completo. En ese momento, a\u00fan no ten\u00edamos relaciones con inversores, por lo que tuvimos que comprar el stand de desarrollo con nuestro propio dinero, que no era mucho. Comprando servidores y conmutadores de segunda mano en Avito, comenzamos con el trabajo.<\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

La tarea inicial principal era crear nuestro propio sistema de archivos, aunque simple, pero propio, que pudiera distribuir autom\u00e1ticamente y de manera uniforme los datos en forma de bloques virtuales en un n\u00famero n de nodos de un cl\u00faster, que estaban conectados por interconectores a trav\u00e9s de Ethernet. Al mismo tiempo, el sistema de archivos deb\u00eda escalar bien y f\u00e1cilmente, y ser independiente de los sistemas adyacentes, es decir, ser separable de vAIR como 'simple almacenamiento'.<\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

El primer concepto de vAIR<\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

Decidimos no usar soluciones open source listas para la organizaci\u00f3n de un almacenamiento distribuido (ceph, gluster, lustre y similares) en favor de nuestro propio desarrollo, ya que ya ten\u00edamos mucha experiencia de proyecto con ellos. Sin duda, estas soluciones son excelentes por s\u00ed solas, y hasta antes de trabajar en Aerodisco hab\u00edamos realizado m\u00e1s de un proyecto de integraci\u00f3n con ellas. Pero una cosa es realizar una tarea espec\u00edfica para un cliente, formar al personal y, posiblemente, comprar soporte de un gran vendedor, y otra muy diferente es crear un producto que sea f\u00e1cil de reproducir, que se utilice para diferentes tareas, de las que, como proveedor, posiblemente ni siquiera tengamos conocimiento. Para este segundo objetivo, los productos open source existentes no eran adecuados, por lo que decidimos desarrollar nuestro propio sistema de archivos distribuido.
\nDos a\u00f1os despu\u00e9s, gracias a varios desarrolladores (que combinaban su trabajo en vAIR con el trabajo en una matriz de disco cl\u00e1sica Engine), se logr\u00f3 un resultado determinado.<\/p>\n

<\/p>\n

Para 2018, hab\u00edamos escrito un sistema de archivos muy simple y lo hab\u00edamos complementado con el cableado necesario. El sistema un\u00eda, a trav\u00e9s de un interconector interno, discos f\u00edsicos (locales) de diferentes servidores en un \u00fanico conjunto plano y 'cortaba' estos discos en bloques virtuales; luego se creaban dispositivos de bloques a partir de los bloques virtuales con un cierto grado de tolerancia a fallos, en los que, utilizando el hipervisor KVM, se creaban y ejecutaban m\u00e1quinas virtuales. <\/p>\n

<\/p>\n

No hemos complicado mucho con el nombre del sistema de archivos y lo hemos llamado ARDFS (traten de adivinar qu\u00e9 significa))<\/p>\n

<\/p>\n

Este prototipo se ve\u00eda bien (no visualmente, por supuesto, en ese momento no hab\u00eda dise\u00f1o visual) y mostraba buenos resultados en cuanto a rendimiento y escalabilidad. Tras el primer resultado real, avanzamos con el proyecto, organizando un entorno de desarrollo completo y un equipo separado que se dedicaba exclusivamente a vAIR.<\/p>\n

<\/p>\n

Justo en ese momento, se madur\u00f3 la arquitectura global de la soluci\u00f3n, que hasta ahora no ha sufrido cambios significativos.<\/p>\n

<\/p>\n

Sumergi\u00e9ndonos en el sistema de archivos ARDFS<\/h2>\n

<\/p>\n

ARDFS es la base de vAIR, que proporciona almacenamiento de datos distribuido y tolerante a fallos para todo el cl\u00faster. Una de las (aunque no la \u00fanica) caracter\u00edsticas distintivas de ARDFS es que no utiliza ninguna servidores dedicados<\/a> subestructura ni gesti\u00f3n. As\u00ed se concibi\u00f3 desde el principio para simplificar la configuraci\u00f3n de la soluci\u00f3n y para su fiabilidad. <\/p>\n

<\/p>\n

Estructura de almacenamiento<\/h3>\n

<\/p>\n

Dentro de todos los nodos del cl\u00faster, ARDFS organiza un grupo l\u00f3gico de todo el espacio en disco disponible. Es importante entender que el grupo no son datos ni espacio formateado, sino simplemente un dise\u00f1o, es decir, cualquier nodo con vAIR instalado que se a\u00f1ada al cl\u00faster se agrega autom\u00e1ticamente al grupo com\u00fan de ARDFS y los recursos de disco se vuelven autom\u00e1ticamente comunes para todo el cl\u00faster (y disponibles para el futuro almacenamiento de datos). Este enfoque permite agregar y eliminar nodos sobre la marcha sin ning\u00fan impacto serio en el sistema ya en funcionamiento. Es decir, el sistema se puede escalar muy f\u00e1cilmente en \"ladrillos\", agregando o eliminando nodos del cl\u00faster seg\u00fan sea necesario.<\/p>\n

<\/p>\n

Sobre el grupo de ARDFS se a\u00f1aden discos virtuales (objetos de almacenamiento para m\u00e1quinas virtuales), que se construyen a partir de bloques virtuales de 4 megabytes. En los discos virtuales se almacenan directamente los datos. A nivel de discos virtuales tambi\u00e9n se establece un esquema de tolerancia a fallos. <\/p>\n

<\/p>\n

Como se podr\u00eda adivinar, para la tolerancia a fallos del subsistema de discos no utilizamos la concepci\u00f3n de RAID (Conjunto redundante de discos independientes), sino que empleamos RAIN (Conjunto redundante de nodos independientes). Es decir, la tolerancia a fallos se mide, automatiza y gestiona en funci\u00f3n de los nodos y no de los discos. Los discos, por supuesto, tambi\u00e9n son un objeto de almacenamiento, son monitoreados como cualquier otra cosa y se pueden realizar todas las operaciones est\u00e1ndar con ellos, incluyendo la creaci\u00f3n de un RAID de hardware local, pero el cl\u00faster opera precisamente con nodos. <\/p>\n

<\/p>\n

En una situaci\u00f3n en la que se desea RAID (por ejemplo, un escenario que admite m\u00faltiples fallos en cl\u00fasteres peque\u00f1os), nada impide utilizar controladores RAID locales y, sobre ellos, crear un almacenamiento extendido y una arquitectura RAIN. Este escenario es completamente viable y lo respaldamos, por lo que lo abordaremos en un art\u00edculo sobre escenarios t\u00edpicos de aplicaci\u00f3n de vAIR.<\/p>\n

<\/p>\n

Esquemas de tolerancia a fallos del almacenamiento<\/h3>\n

<\/p>\n

Existen dos esquemas de tolerancia a fallos de los discos virtuales en vAIR:<\/p>\n

<\/p>\n

1) Factor de replicaci\u00f3n o simplemente replicaci\u00f3n: este m\u00e9todo de tolerancia a fallos es tan simple como una vara y una cuerda. Se realiza una replicaci\u00f3n sincronizada entre nodos con un factor de 2 (2 copias en el cl\u00faster) o 3 (3 copias, respectivamente). RF-2 permite que el disco virtual soporte la falla de un nodo en el cl\u00faster, pero 'consume' la mitad del volumen \u00fatil, mientras que RF-3 soportar\u00e1 la falla de 2 nodos en el cl\u00faster, pero ya reservar\u00e1 2\/3 del volumen \u00fatil para sus necesidades. Este esquema se asemeja mucho a RAID-1, es decir, un disco virtual configurado en RF-2 es resistente a la falla de cualquier nodo en el cl\u00faster. En este caso, los datos estar\u00e1n en buen estado y, de hecho, la entrada\/salida no se detendr\u00e1. Cuando el nodo ca\u00eddo vuelva a estar operativo, comenzar\u00e1 la recuperaci\u00f3n\/sincronizaci\u00f3n autom\u00e1tica de los datos. <\/p>\n

<\/p>\n

A continuaci\u00f3n se presentan ejemplos de la distribuci\u00f3n de datos RF-2 y RF-3 en modo operativo y en situaciones de fallos.<\/p>\n

<\/p>\n

Tenemos una m\u00e1quina virtual con 8MB de datos \u00fanicos (\u00fatiles) que opera en 4 nodos vAIR. Es evidente que en la realidad es poco probable que haya un volumen tan bajo, pero para un esquema que refleja la l\u00f3gica de funcionamiento de ARDFS, este ejemplo es el m\u00e1s claro. AB son bloques virtuales de 4MB que contienen datos \u00fanicos de la m\u00e1quina virtual. En RF-2 se crean dos copias de estos bloques A1+A2 y B1+B2, respectivamente. Estos bloques se 'distribuyen' entre nodos, evitando la superposici\u00f3n de los mismos datos en un solo nodo, es decir, la copia A1 no estar\u00e1 en el mismo nodo que la copia A2. Lo mismo ocurre con B1 y B2.<\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

En caso de fallo de uno de los nodos (por ejemplo, el nodo n\u00ba 3, donde se encuentra la copia B1), esta copia se activar\u00e1 autom\u00e1ticamente en el nodo donde no haya copia de su copia (es decir, la copia B2). <\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

As\u00ed, el disco virtual (y la VM, respectivamente) sobrevivir\u00e1n f\u00e1cilmente al fallo de un nodo en el esquema RF-2.<\/p>\n

<\/p>\n

El esquema de replicaci\u00f3n, a pesar de su simplicidad y fiabilidad, sufre del mismo problema que RAID1: poco espacio \u00fatil.<\/p>\n

<\/p>\n

2) Codificaci\u00f3n de borrado o erasure coding (tambi\u00e9n conocido como 'c\u00f3digo redundante' o 'c\u00f3digo de paridad') existe para resolver el problema anterior. EC es un esquema de redundancia que proporciona alta disponibilidad de datos con menores costos de espacio en disco en comparaci\u00f3n con la replicaci\u00f3n. El principio de funcionamiento de este mecanismo es similar al RAID 5, 6, 6P. <\/p>\n

<\/p>\n

En el proceso de codificaci\u00f3n, el proceso EC divide un bloque virtual (por defecto 4MB) en varios 'pedazos de datos' m\u00e1s peque\u00f1os dependiendo del esquema de EC (por ejemplo, el esquema 2+1 divide cada bloque de 4MB en 2 pedazos de 2MB). A continuaci\u00f3n, este proceso genera para los 'pedazos de datos' 'pedazos de paridad' que no superen a una de las partes previamente divididas. Durante la decodificaci\u00f3n, EC genera los pedazos faltantes leyendo los 'datos sobrevivientes' en todo el cl\u00faster. <\/p>\n

<\/p>\n

Por ejemplo, un disco virtual con un esquema EC 2+1, implementado en 4 nodos del cl\u00faster, soportar\u00e1 tranquilamente la falla de un nodo en el cl\u00faster al igual que RF-2. Adem\u00e1s, los costos de operaci\u00f3n ser\u00e1n menores, especificando que el coeficiente de capacidad \u00fatil en RF-2 es 2, mientras que en EC 2+1 ser\u00e1 1.5. <\/p>\n

<\/p>\n

Si lo describimos de manera m\u00e1s simple, la esencia es que el bloque virtual se divide en 2-8 (por qu\u00e9 de 2 a 8 se explicar\u00e1 m\u00e1s adelante) 'trozos', y para estos trozos se calculan 'trozos' de paridad de volumen equivalente. <\/p>\n

<\/p>\n

En resumen, los datos y la paridad se distribuyen uniformemente entre todos los nodos del cl\u00faster. Al igual que en la replicaci\u00f3n, ARDFS distribuye autom\u00e1ticamente los datos entre los nodos de tal manera que se evite almacenar los mismos datos (copias de los datos y su paridad) en un solo nodo, para excluir la posibilidad de perder datos debido a que tanto los datos como su paridad se encuentren de repente en un solo nodo de almacenamiento que se descomponga. <\/p>\n

<\/p>\n

A continuaci\u00f3n, un ejemplo con la misma m\u00e1quina virtual de 8 MB y 4 nodos, pero ya con el esquema EC 2+1. <\/p>\n

<\/p>\n

Los bloques A y B se dividen en dos partes de 2 MB cada una (en dos porque 2+1), es decir, en A1+A2 y B1+B2. A diferencia de una r\u00e9plica, A1 no es una copia de A2, es un bloque virtual A, dividido en dos partes, lo mismo ocurre con el bloque B. En total, obtenemos dos conjuntos de 4 MB, cada uno con dos partes de dos megabytes. A continuaci\u00f3n, para cada uno de estos conjuntos se calcula la paridad, compuesta por no m\u00e1s de una parte (es decir, 2 MB), lo que nos da adicionalmente + 2 partes de paridad (A-P y B-P). En total, tenemos 4\u00d72 datos + 2\u00d72 paridad.<\/p>\n

<\/p>\n

Luego, las partes se \"distribuyen\" entre los nodos de tal manera que los datos no se crucen con su paridad. Es decir, A1 y A2 no estar\u00e1n en el mismo nodo que A-P.<\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

En caso de falla de un nodo (supongamos, el tercero), el bloque ca\u00eddo B1 se restaurar\u00e1 autom\u00e1ticamente de la paridad B-P, que se almacena en el nodo \u21162, y se activar\u00e1 en el nodo donde no hay paridad B, es decir, el fragmento B-P. En este ejemplo, este es el nodo \u21161.<\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

Estoy seguro de que surge la pregunta en el lector:<\/p>\n

<\/p>\n

\u00abTodo lo que has descrito ya ha sido implementado tanto por competidores como en soluciones de c\u00f3digo abierto, \u00bfcu\u00e1l es la diferencia de tu implementaci\u00f3n de EC en ARDFS?\u00bb<\/p><\/blockquote>\n

A continuaci\u00f3n, se presentar\u00e1n caracter\u00edsticas interesantes del funcionamiento de ARDFS.<\/p>\n

<\/p>\n

Codificaci\u00f3n de borrado con \u00e9nfasis en la flexibilidad.<\/h3>\n

<\/p>\n

Inicialmente, hemos previsto un esquema de EC X+Y bastante flexible, donde X es un n\u00famero de 2 a 8, y Y es un n\u00famero de 1 a 8, pero siempre menor o igual que X. Este esquema est\u00e1 dise\u00f1ado para flexibilidad. Aumentar el n\u00famero de fragmentos de datos (X) en los que se divide un bloque virtual permite reducir los costos generales, es decir, aumentar el espacio \u00fatil.
\nSin embargo, aumentar el n\u00famero de fragmentos de paridad (Y) incrementa la fiabilidad del disco virtual. Cuanto mayor sea el valor de Y, m\u00e1s nodos en el cl\u00faster pueden fallar. Por supuesto, aumentar el volumen de paridad reduce el volumen de capacidad \u00fatil, pero esto es el precio a pagar por la fiabilidad. <\/p>\n

<\/p>\n

La dependencia del rendimiento respecto a los esquemas EC es casi directa: cuanto m\u00e1s \"fragmentos\", menor es el rendimiento; aqu\u00ed, es evidente que se necesita una visi\u00f3n equilibrada. <\/p>\n

<\/p>\n

Este enfoque permite a los administradores configurar de forma flexible el almacenamiento distribuido. En el marco del pool ARDFS, se pueden utilizar cualquier combinaci\u00f3n de esquemas de tolerancia a fallos, lo cual tambi\u00e9n nos parece muy \u00fatil. <\/p>\n

<\/p>\n

A continuaci\u00f3n se presenta una tabla comparativa de varios (no todos los posibles) esquemas RF y EC.<\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

De la tabla se observa que incluso la combinaci\u00f3n m\u00e1s \"extrema\" EC 8+7, que permite la p\u00e9rdida simult\u00e1nea de hasta 7 nodos en el cl\u00faster, consume menos espacio \u00fatil (1,875 frente a 2) que la replicaci\u00f3n est\u00e1ndar, mientras que ofrece una protecci\u00f3n 7 veces superior, lo que hace que este mecanismo de protecci\u00f3n, aunque m\u00e1s complejo, sea significativamente m\u00e1s atractivo en situaciones donde se requiere la m\u00e1xima fiabilidad en condiciones de escasez de espacio en disco. Hay que entender que cada \"m\u00e1s\" a X o Y implica un costo adicional en rendimiento, por lo que en el tri\u00e1ngulo entre fiabilidad, ahorro y rendimiento, hay que elegir con mucho cuidado. Por esta raz\u00f3n, dedicaremos un art\u00edculo separado al dimensionamiento del codificador remoto.<\/p>\n

<\/p>\n

\"Soluci\u00f3n<\/p>\n

<\/p>\n

Fiabilidad y autonom\u00eda del sistema de archivos<\/h3>\n

<\/p>\n

ARDFS se ejecuta localmente en todos los nodos del cl\u00faster y sincroniza mediante sus propios medios a trav\u00e9s de interfaces Ethernet dedicadas. Un punto importante es que ARDFS sincroniza no solo los datos, sino tambi\u00e9n los metadatos relacionados con el almacenamiento. Durante el desarrollo de ARDFS, tambi\u00e9n estudiamos una serie de soluciones existentes y descubrimos que muchos realizan la sincronizaci\u00f3n de los metadatos del sistema de archivos utilizando una base de datos distribuida externa, que tambi\u00e9n utilizamos para la sincronizaci\u00f3n, pero solo de configuraciones y no de metadatos del sistema de archivos (sobre esto y otros subsistemas relacionados hablaremos en el pr\u00f3ximo art\u00edculo). <\/p>\n

<\/p>\n

La sincronizaci\u00f3n de los metadatos del FS mediante una base de datos externa es, por supuesto, una soluci\u00f3n viable, pero entonces la consistencia de los datos almacenados en ARDFS depender\u00eda de la base de datos externa y su comportamiento (y, para ser sinceros, es un cliente caprichoso), lo cual, desde nuestro punto de vista, es malo. \u00bfPor qu\u00e9? Si los metadatos del FS se da\u00f1an, tambi\u00e9n se podr\u00eda decir adi\u00f3s a los propios datos del FS, por lo que decidimos optar por un camino m\u00e1s complicado pero confiable. <\/p>\n

<\/p>\n

Desarrollamos nosotros mismos el subsistema de sincronizaci\u00f3n de metadatos para ARDFS, y vive absolutamente independiente de los subsistemas adyacentes. Es decir, ning\u00fan otro subsistema puede da\u00f1ar los datos de ARDFS. En nuestra opini\u00f3n, este es el camino m\u00e1s confiable y correcto, aunque el tiempo dir\u00e1 si realmente es as\u00ed. Adem\u00e1s, con este enfoque, hay una ventaja adicional. ARDFS se puede utilizar independientemente de vAIR, simplemente como un almacenamiento ampliado, lo que sin duda utilizaremos en productos futuros.<\/p>\n

<\/p>\n

Como resultado, al desarrollar ARDFS, obtuvimos un sistema de archivos flexible y confiable que permite elegir d\u00f3nde se puede ahorrar en capacidad o dedicar todos los recursos a rendimiento, o hacer que el almacenamiento sea extremadamente confiable a un costo moderado, reduciendo as\u00ed los requisitos de rendimiento. <\/p>\n

<\/p>\n

Junto con una pol\u00edtica de licencias sencilla y un modelo de entrega flexible (para adelantarnos, vAIR se licencia por nodos y se suministra ya sea como software o como un paquete), esto permite ajustar la soluci\u00f3n de manera muy precisa a los diversos requisitos de los clientes y mantener f\u00e1cilmente ese equilibrio en el futuro. <\/p>\n

<\/p>\n

\u00bfA qui\u00e9n le interesa este milagro?<\/h2>\n

<\/p>\n

Por un lado, se puede decir que ya hay jugadores en el mercado que tienen soluciones serias en el \u00e1mbito de la hiperconvergencia, y a d\u00f3nde, de hecho, estamos intentando entrar. Parece que esta afirmaci\u00f3n es correcta, PERO\u2026<\/p>\n

<\/p>\n

Por otro lado, al salir al 'campo' y hablar con los clientes, nosotros y nuestros socios vemos que no es as\u00ed en absoluto. Hay muchas tareas para la hiperconvergencia, en algunos casos la gente simplemente no sab\u00eda que exist\u00edan tales soluciones, en otros casos parec\u00eda caro, en algunos hubo pruebas fallidas de soluciones alternativas, y en otros, en general, est\u00e1n prohibidas las compras debido a sanciones. En general, el campo result\u00f3 ser inexplorado, as\u00ed que decidimos cultivarlo))). <\/p>\n

<\/p>\n

\u00bfCu\u00e1ndo es mejor un sistema de almacenamiento que un sistema de hiperconvergencia?<\/h3>\n

<\/p>\n

A lo largo de nuestro trabajo con el mercado, a menudo nos preguntan cu\u00e1ndo es mejor utilizar el esquema cl\u00e1sico con almacenamiento de datos (S\u041dD), y cu\u00e1ndo optar por el hiperescalar. Muchas empresas que fabrican soluciones hiperescalables (en particular, aquellas que no tienen S\u041dD en su cartera) dicen: \u00abEl S\u041dD se est\u00e1 volviendo obsoleto, \u00a1solo hiperescalar!\u00bb. Esta declaraci\u00f3n es audaz, pero no refleja completamente la realidad. <\/p>\n

<\/p>\n

A decir verdad, el mercado de S\u041dD realmente se est\u00e1 trasladando hacia soluciones hiperescalables y similares, pero siempre hay un 'pero'.<\/p>\n

<\/p>\n

En primer lugar, los centros de datos (CD) e infraestructuras de TI construidas con el esquema cl\u00e1sico con S\u041dD no se pueden transformar tan f\u00e1cilmente, por lo que la modernizaci\u00f3n y expansi\u00f3n de dichas infraestructuras son un legado que durar\u00e1 entre 5 y 7 a\u00f1os.<\/p>\n

<\/p>\n

En segundo lugar, la mayor\u00eda de las infraestructuras que se est\u00e1n construyendo actualmente (refiri\u00e9ndonos a Rusia) est\u00e1n siendo realizadas con el esquema cl\u00e1sico utilizando S\u041dD, no porque la gente no conozca el hiperescalar, sino porque el mercado del hiperescalar es nuevo, las soluciones y est\u00e1ndares a\u00fan no se han asentado, los especialistas en TI a\u00fan no est\u00e1n capacitados, hay poca experiencia y es necesario construir centros de datos aqu\u00ed y ahora. Y esta tendencia se mantendr\u00e1 durante 3-5 a\u00f1os m\u00e1s (y luego quedar\u00e1 otro legado, ver punto 1).<\/p>\n

<\/p>\n

En tercer lugar, existe una limitaci\u00f3n t\u00e9cnica puramente relacionada con demoras adicionales de 2 milisegundos en las escrituras (sin tener en cuenta la cach\u00e9 local, por supuesto), que son el costo del almacenamiento distribuido. <\/p>\n

<\/p>\n

Y no olvidemos el uso de grandes servidores f\u00edsicos que prefieren la escalabilidad vertical del subsistema de almacenamiento.<\/p>\n

<\/p>\n

Existen muchas tareas necesarias y populares donde el S\u041dD se comporta mejor que el hiperescalar. Por supuesto, aquellos fabricantes que no tienen S\u041dD en su cartera no coincidir\u00e1n con nosotros, pero estamos listos para argumentar de manera fundamentada. Por supuesto, como desarrolladores de ambos productos, en una de nuestras futuras publicaciones realizaremos una comparaci\u00f3n entre S\u041dD y hiperescalar, donde demostraremos claramente qu\u00e9 es mejor en qu\u00e9 condiciones.<\/p>\n

<\/p>\n

\u00bfY en qu\u00e9 casos las soluciones hiperescalables funcionan mejor que el S\u041dD?<\/h3>\n

<\/p>\n

A partir de las tesis anteriores, se pueden hacer tres conclusiones obvias: <\/p>\n

<\/p>\n

    \n
  1. All\u00ed donde las adicionales 2 milisegundos de latencia en las escrituras, que aparecen consistentemente en cualquier producci\u00f3n (esto no se refiere a la sint\u00e9tica, donde se pueden mostrar incluso nanosegundos), son no cr\u00edticas, el hiperescalar ser\u00e1 adecuado.<\/li>\n
  2. Donde la carga de grandes servidores f\u00edsicos se puede convertir en muchas peque\u00f1as m\u00e1quinas virtuales y distribuirse entre nodos, all\u00ed tambi\u00e9n el hiperconvergente funcionar\u00e1 bien.<\/li>\n
  3. Donde la escalabilidad horizontal es m\u00e1s prioritaria que la vertical, all\u00ed tambi\u00e9n el GCS tendr\u00e1 un buen rendimiento.<\/li>\n<\/ol>\n

    <\/p>\n

    \u00bfCu\u00e1les son estas soluciones?<\/h3>\n

    <\/p>\n

      \n
    1. Todos los servicios de infraestructura est\u00e1ndar (servicio de directorio, correo, gesti\u00f3n documental, servidores de archivos, sistemas ERP y BI peque\u00f1os o medianos, etc.). A esto lo llamamos 'computaci\u00f3n compartida'. <\/li>\n
    2. La infraestructura de los proveedores de nube, donde es necesario escalar horizontalmente de manera r\u00e1pida y estandarizada y 'cortar' f\u00e1cilmente una gran cantidad de m\u00e1quinas virtuales para los clientes.<\/li>\n
    3. Infraestructura escritorios virtuales<\/a> (VDI), donde muchas peque\u00f1as m\u00e1quinas virtuales de usuario se inician y 'navegan' tranquilamente dentro de un cl\u00faster uniforme.<\/li>\n
    4. Redes de filiales, donde en cada filial es necesario obtener una infraestructura est\u00e1ndar, tolerante a fallos, pero econ\u00f3mica, compuesta por 15-20 m\u00e1quinas virtuales.<\/li>\n
    5. Cualquier computaci\u00f3n distribuida (servicios de big data, por ejemplo). Donde la carga se va 'horizontalmente', no 'profundamente'. <\/li>\n
    6. Ambientes de prueba, donde se permiten ligeros retrasos adicionales, pero hay limitaciones presupuestarias, pues son pruebas.<\/li>\n<\/ol>\n

      <\/p>\n

      Actualmente, es precisamente para estas tareas que hemos creado AERODISK vAIR y nos estamos enfocando en ellas (hasta ahora exitosamente). Es posible que esto cambie pronto, ya que el mundo no se detiene.<\/p>\n

      <\/p>\n

      As\u00ed que...<\/h3>\n

      <\/p>\n

      Con esto, la primera parte de un gran ciclo de art\u00edculos ha terminado; en el siguiente art\u00edculo, hablaremos sobre la arquitectura de la soluci\u00f3n y los componentes utilizados.<\/p>\n

      <\/p>\n

      Estaremos encantados de recibir preguntas, propuestas y debates constructivos.<\/p>\n

      Fuente: 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\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\udd47Soluci\u00f3n hiperconvergente AERODISK vAIR. La base es el sistema de archivos ARDFS | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/38542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}