SolidFire - Almacenamiento para aquellos ** almacenamiento de odio cking

Están surgiendo más y más soluciones que se están alejando del enfoque tradicional de almacenamiento unificado. Estos son almacenes especializados que se adaptan a las tareas de un área comercial determinada. Anteriormente, hablé sobre el sistema Infinidat InfiniBox F2230. Hoy en el centro de mi revisión de SolidFire.

"Quién diablos odia el almacenamiento" @ Dave Heats, fundador de NetApp

A finales de 2015, NetApp anunció la compra del inicio de SolidFire, que se fundó en 2010. El interés en estos sistemas se debe a su enfoque diferente para administrar los almacenes de datos y su rendimiento predecible.

Las soluciones SolidFire complementaron la línea de productos de NetApp, que incluía All Flash FAS (AFF), EF y E Series. También permitió un año y medio más tarde lanzar al mercado un nuevo producto: NetApp HCI (Hyper Converged Infrastructure), que utiliza SolidFire como subsistema de almacenamiento.

“Estamos desarrollando un nuevo sistema de almacenamiento diseñado para centros de datos de computación en la nube muy grandes. Básicamente, la idea es que muchas compañías transfieran la informática desde sus oficinas o sus propios centros de datos a estos grandes centros de datos de computación en la nube, donde tienen decenas de miles de clientes con toda su información en un solo lugar. Por lo tanto, estamos creando un nuevo sistema de almacenamiento diseñado para dar servicio a estos grandes centros de datos ".

Dave Wright, CEO de SolidFire, 2012
Recientemente, hay cada vez más soluciones que se están alejando del enfoque tradicional de los almacenes unificados que pueden resolver cualquier problema, a almacenes especializados diseñados para resolver problemas de un área comercial determinada.

No hace mucho tiempo, ya hablé sobre el sistema Infinidat InfiniBox F2230 , que es perfecto para las tareas de los proveedores de servicios. El participante de hoy en nuestra revisión de SolidFire también se puede atribuir a esta clase de dispositivos. El fundador de SolidFire, Dave Wright, y su equipo provienen de RackSpace, donde estaban desarrollando un sistema de almacenamiento eficiente que proporcionaría un rendimiento lineal en un entorno con muchos usuarios, mientras que era simple, fácilmente escalable y tenía capacidades de automatización flexibles. En un intento por resolver este problema, nació SolidFire.

Hasta la fecha, la línea de SolidFire consta de cuatro modelos con diferentes relaciones IOPS / TB.


10 SSD (MLC) se utilizan para el almacenamiento de datos, y Radian RMS-200 como NVRAM. Es cierto que ya hay planes para pasar a los módulos NVDIMM .


De interés aquí es cómo SolidFire recupera y almacena datos. Todos conocemos el recurso limitado de las unidades SSD, por lo tanto, es lógico que para su mejor preservación, la compresión y la deduplicación se realicen sobre la marcha, antes de grabar en SSD. Cuando SolidFire recibe datos del host, los divide en bloques de 4K, después de lo cual este bloque se comprime y almacena en NVRAM. Luego se produce la replicación sincrónica de este bloque en NVRAM al nodo "vecino" del clúster. Después de eso, SolidFire recibe el hash de este bloque comprimido y busca este valor hash en su índice de datos almacenados en todo el clúster. Si ya existe un bloque con dicho hash, SolidFire actualiza solo sus metadatos con un enlace a este bloque, si el bloque contiene datos únicos, se escribe en el SSD, y los metadatos también se escriben para él. Este mecanismo para almacenar datos y metadatos es muy similar al mecanismo de operación del almacenamiento de objetos.

Nuestro grupo de prueba de cuatro nodos

Ya han aparecido rumores de que esta línea pronto se actualizará. Vale la pena señalar una cosa muy importante: el clúster SolidFire puede trabajar con nodos con diferentes "densidades IOP / TB" y combinar nodos de diferentes generaciones dentro de un clúster. En primer lugar, hace que el uso de este sistema sea más predecible en términos de soporte de hardware, y también facilita la transición de los nodos antiguos a los nuevos, cuando simplemente agrega nuevos y elimina los antiguos del clúster en tiempo real (esperando solo la reconstrucción del clúster) sin tiempo de inactividad, porque Hay soporte para Scale Out y Scale Back.

SolidFire se puede entregar como tres soluciones:

  • SolidFire como un producto independiente basado en servidores Dell / EMC,
  • como parte de FlexPod SF en servidores Cisco,
  • como parte de NetApp HCI en su plataforma.

Como puede ver en la tabla de características, los nodos solo admiten la conexión iSCSI, y para la conexión FC hay un tipo separado de nodo: Fabric Interconnect, que a su vez contiene cuatro puertos para datos FC y cuatro puertos iSCSI para conectarse a nodos, así como 64 GB de memoria del sistema nativo / caché de lectura.


La tabla de características también muestra el rendimiento de cada uno de los nodos. Este es uno de esos casos cuando conoce el rendimiento de su sistema de almacenamiento en la etapa de compra. Este rendimiento está garantizado (con un perfil de carga de 4Kb, 80/20) para cada nodo.

En consecuencia, al comprar un grupo de nodos X o expandir una solución existente, comprende cuánto volumen y qué tipo de rendimiento obtendrá al final. Por supuesto, puede exprimir más rendimiento de cada nodo bajo ciertas condiciones, pero esto no es para lo que esta solución fue diseñada. Si desea obtener millones de IOPS en 2U en un solo volumen, es mejor que preste atención a otros productos, como AFF. El mayor rendimiento en SolidFire se puede obtener con una gran cantidad de volúmenes y sesiones.

Interfaz de inicio

La gestión del almacenamiento es bastante simple. De hecho, tenemos dos grupos de recursos: volumen e IOPS. Al identificar uno de los tipos de recursos y conocer su número final, entendemos claramente las otras capacidades de nuestro sistema. Esto nuevamente hace que expandir el sistema sea una tarea extremadamente fácil. ¿Necesitas más rendimiento? Considere SF4805 o SF19210 con una relación IOPS / TB "menos densa". ¿Necesitas volumen? Miramos hacia SF9605 y SF38410, que proporcionan menos IOPS en Gb.

Desde el punto de vista del administrador de almacenamiento, el sistema parece bastante aburrido. Cosas como la deduplicación y la compresión funcionan por defecto.

La replicación y las instantáneas también están disponibles, y la replicación se puede organizar para toda la gama de productos de NetApp (excepto la serie E). Es esta simplicidad, en mi opinión, la que se revela detrás de la cita de Dave Heats del título del artículo. Dado que este sistema implica la integración con varios sistemas de asignación dinámica de recursos, sin la participación de un administrador y sin costos de mano de obra adicionales, pronto generalmente olvidará cómo se ve la interfaz SolidFire. Pero hablaremos más sobre integración.

En Onlanta realizamos pruebas de estrés para asegurarnos de las 200 mil IOPS prometidas. No es que no le creamos al vendedor, sino que estamos acostumbrados a probar todo por nuestra cuenta. No nos propusimos el objetivo de exprimirnos del sistema más de lo que se indicó. También pudimos verificar por nuestra propia experiencia que el sistema da un buen resultado precisamente con una gran cantidad de flujos. Para hacer esto, organizamos 10 volúmenes de 1TB en SolidFire, en el que colocamos una máquina virtual de prueba. Ya en la etapa de preparación del entorno de prueba, nos sorprendió gratamente el trabajo de deduplicación. A pesar de que el esquema de su trabajo es bastante estándar, la calidad del trabajo dentro del clúster resultó ser extremadamente efectiva. Los discos antes de las pruebas se llenaron con datos aleatorios.

Para hacerlo más rápido, generamos un bloque de 10 mb, luego lo llenaron. Además, en cada máquina virtual, este bloque se generó por separado, es decir En todos los automóviles, el patrón es diferente. De 10 TB llenos de datos, el espacio ocupado real en la matriz era de 4 TB. La eficiencia de deduplicación es 1: 2.5, en FAS con este enfoque, la eficiencia de deduplicación en línea tendió a 0. Pudimos obtener 190k IOPS con una respuesta de ~ 1 ms en nuestro banco de pruebas.



Me gustaría señalar que las características arquitectónicas de la solución no permiten obtener un alto nivel de rendimiento en una pequeña cantidad de subprocesos. Una pequeña luna o solo una máquina virtual de prueba no podrá mostrar resultados altos. Pudimos obtener esta cantidad de IOPS utilizando toda la capacidad del sistema y con un aumento gradual en la cantidad de máquinas virtuales que crean una carga utilizando fio. Aumentamos su número hasta que los retrasos no superaron los 1,5 ms, después de lo cual nos detuvimos y quitamos los indicadores de rendimiento.

La plenitud del subsistema de disco también afecta el rendimiento. Como dije antes, antes de ejecutar las pruebas, llenamos los discos con datos aleatorios. Si ejecuta la prueba sin llenar primero los discos, el rendimiento será mucho mayor con el mismo nivel de retraso.


También realizamos nuestra prueba de tolerancia a fallas favorita apagando uno de los nodos. Para obtener el mejor efecto, se seleccionó un nodo maestro para deshabilitar. Debido al hecho de que cada servidor cliente establece su propia sesión con el nodo del clúster, y no a través de algún punto único, al desconectar uno de los nodos, no todas las máquinas virtuales se degradan, sino solo aquellas que trabajaron con este nodo. En consecuencia, desde el lado del almacenamiento, solo vemos una caída parcial en el rendimiento.


Por supuesto, por parte de los hosts de virtualización, en algunos almacenes de datos, la caída del rendimiento fue de hasta 0. Pero en 30 segundos, el rendimiento se restableció sin pérdida de rendimiento (debe tenerse en cuenta que la carga en el momento de la caída era de 120k iops, que tres podrían producir potencialmente de cuatro nodos, respectivamente, no deberíamos haber visto una pérdida en el rendimiento).

En el lado de SolidFire, comenzó la reconstrucción de la matriz. El temporizador está mintiendo un poco, y el proceso tomó aproximadamente 55 minutos, lo que se ajusta a la hora prometida por el vendedor. Al mismo tiempo, nadie eliminó la carga del sistema de almacenamiento y permaneció en el mismo nivel de 120k IOPS.

La tolerancia a fallos se proporciona no solo a nivel de disco, sino también a nivel de nodo. El clúster admite la falla simultánea de un nodo, después de lo cual se inicia el proceso de reconstrucción del clúster. Teniendo en cuenta el uso de SSD y que todos los nodos están involucrados en la reconstrucción, la recuperación del clúster tarda aproximadamente una hora (la reconstrucción en caso de una falla del disco tarda unos 10 minutos). Debe tenerse en cuenta que cuando un nodo falla, pierde tanto el rendimiento como la cantidad de espacio utilizable. En consecuencia, siempre debe tener espacio libre en la cantidad de un nodo. El tamaño mínimo del clúster es de cuatro nodos. Esta configuración le permitirá evitar problemas si uno de los nodos falla antes de esperar a que llegue el reemplazo.

Como con la mayoría de los sistemas de almacenamiento, la supervisión del rendimiento se muestra aquí solo en tiempo real. Para tener acceso a los datos históricos, debe implementar el denominado Nodo de administración, que se compromete a tomar datos API de SolidFire y cargarlos en Active IQ. Si ya ha trabajado con los sistemas de NetApp, es posible que ya haya encontrado este portal. Tiene la oportunidad de trabajar con datos sobre productividad, eficiencia, incluidas las previsiones de crecimiento. A qué puede acceder a estos datos incluso desde su dispositivo móvil, desde cualquier lugar del mundo.





Como mencioné el trabajo de deduplicación en línea, también diré sobre la eficiencia del almacenamiento en general. Al igual que con la serie AFF, NetApp proporciona una relación de eficiencia de almacenamiento garantizada basada en el tipo de datos almacenados.


Como puede ver, los tipos de datos y los coeficientes garantizados son ligeramente diferentes. Por ejemplo, SolidFire tiene exactamente nuestro caso: infraestructura virtual con un coeficiente 4: 1. Y esto no tiene en cuenta el uso de instantáneas.

La arquitectura de la solución se basa en la calidad de servicio (QoS), que realmente garantiza un rendimiento garantizado para cada volumen.


QoS es una de las funciones críticas para los proveedores de servicios y otras empresas que necesitan proporcionar un nivel garantizado de rendimiento de almacenamiento. Alguien dirá que QoS no es algo nuevo y que muchos otros proveedores lo implementan. Otra pregunta es cómo funciona. Si en el almacenamiento tradicional es más probable que priorice y limite la velocidad, entonces SolidFire, a su vez, utiliza un enfoque integrado para lograr un rendimiento garantizado.

  • El uso de un SSD completo le permite lograr una baja latencia para E / S.
  • El escalado horizontal predice fácilmente las métricas de rendimiento.
  • Falta de RAID clásico: rendimiento predecible con
  • fallas de hardware
  • Una distribución de carga equilibrada elimina los cuellos de botella en el sistema.
  • QoS ayuda a evitar "vecinos ruidosos".

Además de la capacidad de establecer el rendimiento máximo y mínimo, es posible proporcionar ese rendimiento más allá del límite máximo (Ráfaga). Cada volumen tiene un cierto sistema condicional de préstamos. Cuando su productividad está por debajo de la marca máxima, se le acreditan estos préstamos, gracias a los cuales, durante un cierto tiempo, puede superar la marca máxima de productividad. Este enfoque le permite colocar una gran cantidad de aplicaciones que requieren un alto rendimiento en el almacenamiento y, al mismo tiempo, protegerlas de los efectos negativos entre sí. Lo más interesante es que QoS es compatible no solo a nivel de volumen de la matriz, sino también a nivel de VMware VV, lo que permite la asignación granular de recursos para cada máquina virtual. El soporte completo para VAAI y la API VASA proporciona una estrecha integración de matriz con el virtualizador.

Hablando de integración, la solución de VMware está lejos de terminar.


Quizás SolidFire pueda llamarse el sistema de almacenamiento más automatizado que puede integrarse con cualquier sistema moderno, sistemas de virtualización / contenedorización, admite sistemas de gestión de configuración, SDK está disponible para varios idiomas.

Yo, como siempre, miro lo primero que es el SDK para Python con el que automatizo mis propios flujos de trabajo. Por lo tanto, necesitamos crear 15 volúmenes de 1 TB y obtener iqn en la salida, que pasaremos a los administradores de VMware para agregar almacenes de datos. Ya tenemos grupos de acceso creados previamente en los que se registran nuestros hosts VMware y políticas de QoS creadas previamente.

#!/usr/bin/env python # -*- coding:utf-8 -*- from solidfire.factory import ElementFactory sfe = ElementFactory.create('ip', 'log', 'pass') for i in range(1,51): create_volume_result = sfe.create_volume(name='vol'+str(i), account_id=2, total_size=1099511627776, enable512e=True, qos_policy_id=1) id = create_volume_result.volume_id sfe.add_volumes_to_volume_access_group(volume_access_group_id=2, volumes=[id]) volumes = sfe.list_volumes(accounts=[2], limit=100).volumes for volume in volumes: print volume.iqn 

O aquí hay un video de demostración de Python SDK más detallado de SolidFire:


Este enfoque de automatización hace que SolidFire sea conveniente no solo para proveedores de nube y tareas similares, sino que de acuerdo con el concepto de integración y entrega continua (CI / CD) le permite optimizar el proceso de desarrollo.

Como mencioné, WebUI funciona a través de la API, y puede ver todas las solicitudes y respuestas a través del Registro de API.

Si está interesado en aprender más sobre SolidFire, sobre su comparación con la competencia, sobre cómo trabajar con el sistema, etc., quiero recomendar su canal de YouTube , que tiene una cantidad bastante grande de videos útiles, desde útiles. Por ejemplo, el ciclo "Comparación de arquitecturas modernas de todo flash".

Entre las buenas características del sistema se encuentra el mecanismo incorporado para hacer copias de seguridad de las instantáneas en un almacenamiento externo compatible con S3. Esto le permite utilizar instantáneas como copias de seguridad y almacenarlas en repositorios externos tanto en su sitio como en recursos externos, por ejemplo, en Amazon. Por supuesto, este enfoque difícilmente se puede llamar flexible, desde el punto de vista de la recuperación de datos, pero en algunos casos esta solución puede ser útil y bastante aplicable. Hay otro punto interesante: puede cargar datos al almacenamiento S3 de dos maneras:

  • Nativo: en este caso, los datos ya deduplicados se verterán, pero al mismo tiempo, este volumen solo se puede restaurar al mismo sistema con el que se vierte.
  • Sin comprimir: ya se ha vertido un conjunto completo de bloques, lo que le permite restaurar esta luna en cualquier otro clúster de SolidFire.



En general, estábamos más que satisfechos con nuestra comunicación con SolidFire. Obtuvimos el rendimiento prometido, el trabajo de deduplicación en línea está más allá de los elogios, las capacidades de integración y automatización también dejaron una impresión extremadamente positiva. La influencia de la falla de los nodos, o más bien su efecto mínimo sobre el rendimiento del sistema en su conjunto, la distribución de la carga y la ausencia de un solo punto de falla, que podría afectar en gran medida el rendimiento, hacen que este sistema sea extremadamente atractivo. A pesar de que el clúster solo puede funcionar en iSCSI, la presencia del nodo de transporte FC hace que este sistema sea más universal.

Me gustaría expresar un agradecimiento especial en las pruebas a Yevgeny Krasikov de NetApp y Arthur Alikulov de Merlion. Por cierto, Arthur tiene un maravilloso canal de Telegram para todos los que quieran estar al tanto de las noticias de la dirección de almacenamiento y de NetApp en particular. Puede encontrar una gran cantidad de materiales útiles en él, y quien solo necesita leer, pero también quiere hablar, también hay un chat de discusiones almacenadas .

Si aún tiene preguntas o si aparecen nuevas de repente, lo invito a visitar NetApp Directions 2018, que se llevará a cabo el 17 de julio de 2018 en Hyatt Regency Petrovsky Park, donde Arthur y yo hablaremos sobre SolidFire en una de las sesiones. Inscripción para el evento y todos los detalles.

Y en nuestra empresa hay una vacante.

Source: https://habr.com/ru/post/es415967/


All Articles