Este artículo fue escrito para ayudarlo a elegir la solución adecuada para usted y comprender las diferencias entre SDS como Gluster, Ceph y Vstorage (Virtuozzo).
El texto utiliza enlaces a artículos con una divulgación más detallada de ciertos problemas, por lo que las descripciones serán lo más breves posible, utilizando puntos clave sin tonterías innecesarias e información introductoria que, si lo desea, puede obtener de forma independiente en Internet.
De hecho, por supuesto, los temas planteados requieren el tono del texto, pero en el mundo moderno cada vez a más personas no les gusta leer mucho))), por lo que puedes leer rápidamente y elegir, y si algo es no está claro, siga los enlaces o busque en Google palabras poco claras))), y este artículo es como un envoltorio transparente para estos temas profundos, mostrando el relleno: los principales puntos clave de cada decisión.
Brillo
Comencemos con Gluster, que es utilizado activamente por los fabricantes de plataformas hiperconvergentes con SDS basadas en código abierto para entornos virtuales y que se puede encontrar en el sitio web de RedHat en la sección de almacenamiento, donde se puede elegir entre dos opciones de SDS: Gluster o Ceph.
Gluster consta de una pila de traductores, servicios que realizan todo el trabajo de distribución de archivos, etc. Brick es un servicio que da servicio a un disco, Volumen es un volumen (grupo) que une estos ladrillos. Luego viene el servicio para distribuir archivos en grupos utilizando la función DHT (tabla hash distribuida). No incluiremos el servicio Sharding en la descripción ya que los enlaces a continuación describirán los problemas asociados con él.
Al escribir, el archivo completo se almacena en un bloque y su copia se escribe simultáneamente en un bloque en el segundo servidor. A continuación, el segundo archivo se escribirá en el segundo grupo de dos bloques (o más) en servidores diferentes.
Si los archivos tienen aproximadamente el mismo tamaño y el volumen consta de un solo grupo, entonces todo está bien, pero en otras condiciones surgirán los siguientes problemas a partir de las descripciones:
- el espacio en los grupos se utiliza de manera desigual, depende del tamaño de los archivos y si no hay suficiente espacio en el grupo para escribir un archivo, recibirá un error, el archivo no se escribirá y no se redistribuirá a otro grupo. ;
- al escribir un archivo, IO va solo a un grupo, el resto está inactivo;
- no se puede obtener IO de todo el volumen al escribir un archivo;
- y el concepto general parece menos productivo debido a la falta de distribución de datos en bloques, donde es más fácil equilibrar y resolver el problema de la distribución uniforme, y no como ahora todo el archivo va en un bloque.
De la descripción oficial También llegamos involuntariamente a comprender que gluster funciona como almacenamiento de archivos además del RAID de hardware clásico. Ha habido intentos de desarrollo de cortar archivos (Sharding) en bloques, pero todo esto es una adición que impone pérdidas de rendimiento en el enfoque arquitectónico ya existente, además del uso de componentes distribuidos libremente con limitaciones de rendimiento como Fuse. No existen servicios de metadatos, lo que limita el rendimiento y las capacidades de tolerancia a fallos del almacenamiento al distribuir archivos en bloques. Se pueden observar mejores indicadores de rendimiento con la configuración “Replicada distribuida” y el número de nodos debe ser al menos 6 para organizar una réplica confiable 3 con una distribución de carga óptima.
Estos hallazgos también están relacionados con la descripción de la experiencia del usuario. y en comparación con , y también se describe la experiencia que conduce a la comprensión de esta configuración más productiva y confiable.
La imagen muestra la distribución de carga al escribir dos archivos, donde las copias del primer archivo se distribuyen entre los primeros tres servidores, que se combinan en el grupo del volumen 0, y tres copias del segundo archivo se colocan en el segundo grupo, volumen 1 de tres. servidores. Cada servidor tiene un disco.
La conclusión general es que se puede utilizar Gluster, pero entendiendo que habrá limitaciones de rendimiento y tolerancia a fallos que crearán dificultades en determinadas condiciones de una solución hiperconvergente, donde también se necesitan recursos para las cargas informáticas de los entornos virtuales.
También hay algunos indicadores de desempeño de Gluster que se pueden lograr bajo ciertas condiciones, limitados a
Ceph
Ahora veamos a Ceph a partir de las descripciones de arquitectura que pude También hay una comparación entre , donde puede comprender de inmediato que es recomendable implementar Ceph en servidores separados, ya que sus servicios requieren todos los recursos de hardware bajo carga.
Arquitectura Es más complejo que Gluster y existen servicios como servicios de metadatos, pero toda la pila de componentes es bastante compleja y poco flexible para usarla en una solución de virtualización. Los datos se almacenan en bloques, lo que parece más productivo, pero en la jerarquía de todos los servicios (componentes) hay pérdidas y latencia bajo ciertas cargas y condiciones de emergencia, por ejemplo las siguientes
De la descripción de la arquitectura, el corazón es CRUSH, gracias al cual se selecciona la ubicación para almacenar datos. Luego viene PG: esta es la abstracción (grupo lógico) más difícil de entender. Se necesitan PG para que CRUSH sea más eficaz. El objetivo principal de PG es agrupar objetos para reducir el consumo de recursos, aumentar el rendimiento y la escalabilidad. Dirigir objetos directamente, individualmente, sin combinarlos en un PG, sería muy costoso. OSD es un servicio para cada disco individual.
Un clúster puede tener uno o varios grupos de datos para diferentes propósitos y con diferentes configuraciones. Los grupos se dividen en grupos de ubicación. Los grupos de ubicación almacenan objetos a los que acceden los clientes. Aquí es donde termina el nivel lógico y comienza el nivel físico, porque a cada grupo de ubicación se le asigna un disco principal y varios discos de réplica (cuántos dependen exactamente del factor de replicación del grupo). En otras palabras, en el nivel lógico, el objeto se almacena en un grupo de ubicación específico, y en el nivel físico, en los discos que se le asignan. En este caso, los discos pueden estar ubicados físicamente en diferentes nodos o incluso en diferentes centros de datos.
En este esquema, los grupos de colocación parecen un nivel necesario para la flexibilidad de toda la solución, pero al mismo tiempo, como un eslabón extra en esta cadena, lo que involuntariamente sugiere una pérdida de productividad. Por ejemplo, al escribir datos, el sistema necesita dividirlos en estos grupos y luego, a nivel físico, en el disco principal y los discos de réplica. Es decir, la función Hash funciona al buscar e insertar un objeto, pero tiene un efecto secundario: estos son costos muy altos y restricciones para reconstruir el hash (al agregar o quitar un disco). Otro problema de hash es la ubicación claramente definida de los datos que no se pueden cambiar. Es decir, si de alguna manera el disco está bajo una mayor carga, entonces el sistema no tiene la oportunidad de no escribir en él (seleccionando otro disco), la función hash obliga a ubicar los datos de acuerdo con la regla, sin importar cuán malos sean. el disco lo es, por lo que Ceph consume mucha memoria al reconstruir el PG en caso de autorreparación o aumento del almacenamiento. La conclusión es que Ceph funciona bien (aunque lentamente), pero sólo cuando no hay escalamiento, situaciones de emergencia o actualizaciones.
Por supuesto, existen opciones para aumentar el rendimiento mediante el almacenamiento en caché y el uso compartido de caché, pero esto requiere un buen hardware y aún así habrá pérdidas. Pero en general, Ceph parece más tentador que Gluster en términos de productividad. Además, al utilizar estos productos, es necesario tener en cuenta un factor importante: este es un alto nivel de competencia, experiencia y profesionalismo con gran énfasis en Linux, ya que es muy importante implementar, configurar y mantener todo correctamente. lo que impone aún más responsabilidad y carga al administrador.
Almacenamiento
La arquitectura parece aún más interesante. , que se puede utilizar junto con un hipervisor en los mismos nodos, en el mismo , pero es muy importante configurar todo correctamente para conseguir un buen rendimiento. Es decir, implementar un producto de este tipo desde la caja en cualquier configuración sin tener en cuenta las recomendaciones de acuerdo con la arquitectura será muy fácil, pero no productivo.
Lo que puede coexistir para el almacenamiento junto a los servicios del hipervisor kvm-qemu, y estos son solo algunos servicios donde se ha encontrado una jerarquía óptima compacta de componentes: servicio de cliente montado a través de FUSE (modificado, no de código abierto), servicio de metadatos MDS (Servicio de metadatos), servicio de bloques de datos del servicio Chunk, que a nivel físico equivale a un disco y eso es todo. En términos de velocidad, por supuesto, es óptimo usar un esquema tolerante a fallas con dos réplicas, pero si usa almacenamiento en caché y registros en unidades SSD, entonces la codificación tolerante a errores (borrar codificación o raid6) se puede overclockear decentemente en un esquema híbrido o incluso mejor en todo flash. Existe una desventaja con EC (codificación de borrado): al cambiar un bloque de datos, es necesario volver a calcular las cantidades de paridad. Para evitar las pérdidas asociadas con esta operación, Ceph escribe en EC de manera diferida y pueden ocurrir problemas de rendimiento durante una determinada solicitud, cuando, por ejemplo, es necesario leer todos los bloques y, en el caso de Virtuozzo Storage, se escriben los bloques modificados. utilizando el enfoque de “sistema de archivos estructurado en registros”, que minimiza los costos de cálculo de paridad. Para estimar aproximadamente las opciones con aceleración del trabajo con y sin EC, existen – las cifras pueden ser aproximadas dependiendo del coeficiente de precisión del fabricante del equipo, pero el resultado de los cálculos es una buena ayuda a la hora de planificar la configuración.
Un diagrama simple de los componentes de almacenamiento no significa que estos componentes no absorban pero si calcula todos los costes de antemano, podrá contar con la colaboración junto al hipervisor.
Existe un esquema para comparar el consumo de recursos de hardware de los servicios de almacenamiento de Ceph y Virtuozzo.
Si antes era posible comparar Gluster y Ceph utilizando artículos antiguos, utilizando sus líneas más importantes, entonces con Virtuozzo es más difícil. No hay muchos artículos sobre este producto y la información sólo se puede obtener de la documentación sobre o en ruso si consideramos Vstorage como almacenamiento utilizado en algunas soluciones hiperconvergentes en empresas como y Acronis.
Intentaré ayudar con una descripción de esta arquitectura, por lo que habrá un poco más de texto, pero lleva mucho tiempo comprender la documentación usted mismo y la documentación existente solo se puede usar como referencia revisando la tabla. de contenidos o búsqueda por palabra clave.
Consideremos el proceso de grabación en una configuración de hardware híbrida con los componentes descritos anteriormente: la grabación comienza a ir al nodo desde el que la inició el cliente (el servicio de punto de montaje FUSE), pero el componente maestro del servicio de metadatos (MDS), por supuesto, lo hará. dirige al cliente directamente al servicio de fragmento deseado (bloques CS del servicio de almacenamiento), es decir, MDS no participa en el proceso de grabación, sino que simplemente dirige el servicio al fragmento requerido. En general, podemos dar una analogía con la grabación vertiendo agua en barriles. Cada barril es un bloque de datos de 256 MB.
Es decir, un disco es una cierta cantidad de dichos barriles, es decir, el volumen del disco dividido por 256 MB. Cada copia se distribuye a un nodo, la segunda casi en paralelo a otro nodo, etc... Si tenemos tres réplicas y hay discos SSD para caché (para leer y escribir registros), entonces la confirmación de la escritura se producirá después de escribir. el registro al SSD y el reinicio paralelo desde el SSD continuará en el HDD, como si estuviera en segundo plano. En el caso de tres réplicas, el registro se confirmará después de la confirmación del SSD del tercer nodo. Puede parecer que la suma de las velocidades de escritura de tres SSD se puede dividir por tres y obtendremos la velocidad de escritura de una réplica, pero las copias se escriben en paralelo y la velocidad de latencia de la red suele ser mayor que la del SSD. y de hecho el rendimiento de escritura dependerá de la red. En este sentido, para ver IOPS reales, debe cargar correctamente todo el Vstorage mediante , es decir, probar la carga real, y no la memoria y el caché, donde es necesario tener en cuenta el tamaño correcto del bloque de datos, el número de subprocesos, etc.
El registro de grabación en el SSD mencionado anteriormente funciona de tal manera que tan pronto como ingresan datos, el servicio los lee inmediatamente y los escribe en el HDD. Hay varios servicios de metadatos (MDS) por clúster y su número está determinado por un quórum, que funciona según el algoritmo de Paxos. Desde el punto de vista del cliente, el punto de montaje FUSE es una carpeta de almacenamiento del clúster que es visible simultáneamente para todos los nodos del clúster; cada nodo tiene un cliente montado de acuerdo con este principio, por lo que este almacenamiento está disponible para cada nodo.
Para el desempeño de cualquiera de los enfoques descritos anteriormente, es muy importante, en la etapa de planificación e implementación, configurar correctamente la red, donde habrá equilibrio debido a la agregación y el ancho de banda del canal de red seleccionado correctamente. En conjunto, es importante elegir el modo de hash y los tamaños de marco correctos. También hay una diferencia muy fuerte con respecto a la SDS descrita anteriormente: se fusiona con la tecnología de ruta rápida en Virtuozzo Storage. Lo cual, además del fusible modernizado, a diferencia de otras soluciones de código abierto, aumenta significativamente el IOPS y permite no estar limitado por el escalado horizontal o vertical. En general, en comparación con las arquitecturas descritas anteriormente, ésta parece más poderosa, pero para tal placer, por supuesto, es necesario comprar licencias, a diferencia de Ceph y Gluster.
En resumen, podemos destacar el primero de los tres: Virtuozzo Storage ocupa el primer lugar en términos de rendimiento y confiabilidad de la arquitectura, Ceph ocupa el segundo lugar y Gluster ocupa el tercer lugar.
Los criterios por los cuales se seleccionó Virtuozzo Storage: es un conjunto óptimo de componentes arquitectónicos, modernizados para este enfoque Fuse con ruta rápida, un conjunto flexible de configuraciones de hardware, menor consumo de recursos y la capacidad de compartir con computación (computación/virtualización). es decir, es completamente adecuado para una solución hiperconvergente, de la que forma parte. El segundo lugar lo ocupa Ceph por ser una arquitectura más productiva en comparación con Gluster, debido a su operación en bloques, además de escenarios más flexibles y la capacidad de trabajar en clusters más grandes.
Hay planes para escribir una comparación entre vSAN, Space Direct Storage, Vstorage y Nutanix Storage, probando Vstorage en equipos HPE y Huawei, así como escenarios para integrar Vstorage con sistemas de almacenamiento de hardware externos, por lo que si le gustó el artículo, sería Es bueno recibir comentarios suyos, lo que podría aumentar la motivación para nuevos artículos, teniendo en cuenta sus comentarios y deseos.
Fuente: habr.com