Enfrentamiento del sistema económico TrueNAS CORE

Hace unos meses comenzamos nuestra Competición de construcción de $800 TrueNAS. En pocas palabras, Brian, Ben, Kevin tomaron $ 800 y construyeron su propio sistema NAS aprovechando TrueNAS CORE como sistema operativo. Gracias a Western Digital, los muchachos no tuvieron que preocuparse por el almacenamiento, WD proporcionó un bandada de SSD y Opciones de disco duro para que los chicos elijan. Queríamos ver qué podía hacer nuestro equipo construyendo cada sistema diferente y cómo se comparan entre sí. Gastaron el dinero, hablaron basura y probaron sus sistemas, veamos cómo lo hicieron.

Como preparación para aquellos que no han estado siguiendo, hicimos un video sobre nuestra pequeña competencia que se puede encontrar incrustado aquí o en nuestra página de YouTube:

Además de esto, necesita saber más al respecto.

Presupuesto TrueNAS CORE Systems

La estructura de Ben el pasante fue probablemente el más DIY del lote. Fue a Cincinnati Computer Cooperative and MicroCenter y compró todas las piezas por separado y las ensambló él mismo. Sus piezas incluyeron una fuente de alimentación OCZ GSX600, una placa base ASRock B550, G.Skill Ripjaws V 64 GB (2 x 32 GB) DDR4-3600 RAM, un Ryzen 5 3600, un Chelsio 111-00603+A0 y una carcasa para PC Lian Li Liancool 205 . Con los pocos dólares extra que le sobraron, arrojó algunas tiras de LED en su construcción.

presupuesto truenas núcleo

Kevin aprovechó HPE MicroServer Gen10 Plus con su procesador Xeon y memoria ECC. Kevin también agregó una tarjeta Mellanox ConnectX-100 de 5 GbE para obtener una ventaja sobre las otras compilaciones, al mismo tiempo que facilita la configuración de redes. Mientras que las otras compilaciones usan una NIC de dos puertos, Kevin solo necesita configurar una interfaz de 100 GbE.

El NAS de Kevin con una unidad Western Digital

la construcción de Brian está en algún lugar entre los otros dos. Comenzó con la placa Supermicro M11SDV-8CT-LN4F, que le proporcionó un procesador SoC AMD EPYC 3201 y cuatro puertos de 1 GbE que le quitaron una gran parte del presupuesto. Para RAM, Brain aprovechó dos módulos DRAM SK hynix PC4-2400T-RD1-11 DDR4 ECC de 8 GB. También instaló una fuente de alimentación Thermaltake de 500 W y una tarjeta de 10 GbE. Todo esto se colocó dentro de un recinto de Fractal Design Node 304. Si bien la tarjeta de 10 GbE que Brian encontró a un precio fantástico, finalmente no la reconocería ni funcionaría con el software TrueNAS, por lo que tuvo que volver a una NIC Emulex de laboratorio de repuesto. La DRAM usada de China también fue un problema y tuvo que ser reemplazada.

TrueNAS CORE AMD EPYC frontal

Sistema económico TrueNAS CORE: rendimiento

Vayamos a la verdadera razón por la que todos están aquí: ¿cuál de los tres es mejor? Además de nuestras tres construcciones de bricolaje, también tenemos un TrueNAS Mini que por cierto estamos regalando. La compilación iXsystem usa RAIDZ2 ya que se suministró con 5 HDD. La plataforma iXsystems TrueNAS Mini X+ ofrece la mejor combinación de tamaño de chasis y compatibilidad con unidades. Admite cinco HDD de 3.5″ e incluso tiene dos bahías de 2.5″ para SSD. Entonces, ¿por qué no probarlo como referencia? Simple, el Mini X+ está ajustado para la máxima resistencia de datos, no para el rendimiento. Los otros tres fueron ajustados para ser los más rápidos en este enfrentamiento, aunque eso conlleva algunos riesgos. Si iXsystems quisiera vencer a nuestros competidores, podría aplastarlos con una construcción.

Mini bahías iXsystems TrueNAS

Una palabra rápida sobre las configuraciones de RAID: TrueNAS admite varias según la compilación. Dado que usamos compilaciones radicalmente diferentes, habrá diferentes configuraciones de RAID. Las compilaciones de Ben y Kevin usan RAIDZ en cuatro SSD, y la compilación de Brian usa Mirror en cuatro HDD.

Solo analizamos el protocolo de intercambio de archivos SMB para este enfrentamiento. Un elemento interesante a mencionar es la importancia que tiene la configuración de la placa base y el chasis. La plataforma de escritorio de Ben que podría decirse que se ve mejor, solo tiene dos bahías para unidades de 3.5″ y también es la caja más grande con diferencia.

El gabinete de Brian admite hasta seis bahías para unidades de 3.5″ con atención a la refrigeración, pero su placa base solo tiene cuatro puertos SATA integrados. La construcción de microservidor HPE de Kevin como una construcción estándar tiene cuatro bahías y cuatro puertos, pero así es como está diseñada la plataforma.

El almacenamiento también es un poco diferente en diferentes modelos. En la versión de Brian, había cuatro discos duros WD Red de 10 TB; lamentablemente, el puerto M.2 NVMe no funcionó exactamente como se esperaba. Tanto las compilaciones de Ben como las de Kevin aprovecharon cuatro SSD WD Red de 4 TB.

Es importante tener en cuenta en la sección de rendimiento que la configuración de RAID tiene un papel muy importante en la forma en que se mide el rendimiento, más allá de la selección de la unidad en sí. RAIDZ tendrá menos gastos generales que RAIDZ2, y Mirror tendrá incluso menos gastos generales que RAIDZ. Dicho esto, la configuración de RAID debe tener en cuenta cuál es la aplicación final final, cuánta capacidad necesita y qué tan resistente a fallas desea que su construcción. Al final, estos resultados no están orientados a mostrar qué NAS es más rápido, sino cómo funcionan las configuraciones de TrueNAS en versiones similares, algunas con las mismas unidades, en diferentes configuraciones de RAID.

Análisis de carga de trabajo sintética empresarial

Nuestro proceso empresarial de pruebas comparativas de disco duro y almacenamiento compartido condiciona previamente cada unidad a un estado estable con la misma carga de trabajo con la que se probará el dispositivo bajo una carga pesada de 16 subprocesos con una cola pendiente de 16 por subproceso, y luego se probará en intervalos establecidos en múltiples Perfiles de profundidad de subprocesos/colas para mostrar el rendimiento con un uso ligero y pesado. Dado que las soluciones NAS alcanzan su nivel de rendimiento nominal muy rápidamente, solo representamos gráficamente las secciones principales de cada prueba.

Pruebas de preacondicionamiento y de estado estacionario primario:

Rendimiento (lectura+escritura de IOPS agregado)
Latencia promedio (latencia de lectura y escritura promediadas juntas)
Latencia máxima (máxima latencia de lectura o escritura)
Desviación estándar de latencia (desviación estándar de lectura+escritura promediada)

Nuestro análisis de carga de trabajo sintético empresarial incluye cuatro perfiles basados en tareas del mundo real. Estos perfiles se han desarrollado para facilitar la comparación con nuestros puntos de referencia anteriores, así como con valores ampliamente publicados, como una velocidad máxima de lectura y escritura de 4k y 8k 70/30, que se usa comúnmente para unidades empresariales.

- 100 % de lectura o 100 % de escritura
- 100% 4K
8K 70/30
- 70% lectura, 30% escritura
- 100% 8K
8K (secuencial)
- 100 % de lectura o 100 % de escritura
- 100% 8K
128K (secuencial)
- 100 % de lectura o 100 % de escritura
- 100% 128K

Primero está nuestra prueba de rendimiento de lectura/escritura de 4K. Para lectura, el mejor desempeño fue Ben's con 14,865 IOPS. Kevin quedó en segundo lugar con 11,476. Brian llegó tercero con 595 IOPS. En escritura, Kevin ocupó el primer lugar con 3,868 IOPS. Ben quedó en segundo lugar con 2,517 IOPS. Brian se quedó en tercer lugar con 923 IOPS.

Gran parte de esto se debe al tipo de RAID implementado, aunque, con el microservidor de Kevin frente a la compilación casera de Ben, la diferencia de IOPS influye en la velocidad de la CPU en cada compilación.

El siguiente paso es la latencia promedio de 4K. Aquí vemos la misma colocación que la anterior. En lectura, Ben gana con 17.2 ms, Kevin ocupa el segundo lugar con 22.31 ms y Brian va muy por detrás con 429.2 ms. Cambiando a escribir, Kevin se quedó con el primer puesto con 66.21 ms, Ben ocupó el segundo lugar con 101.66 ms y Brian estaba un poco más cerca con 276.89 ms en tercer lugar.

La latencia máxima de 4K experimentó un pequeño cambio en la colocación. Para leer, Ben ocupó el primer lugar con 263.96 ms, Kevin estaba justo detrás de él con 273.44 ms y Brian estaba tercero con 1,091.3 ms. En escritura, Kevin ocupó el primer lugar con 1,195 ms, Brian ocupó el segundo lugar para variar con 2,092.5 ms y Ben se deslizó hasta el tercero con 2,431.7 ms.

Nuestra última prueba 4K es la desviación estándar. Para leer, Ben tomó el primer lugar con 5.94 ms, Kevin estaba muy cerca con 7.11 ms y Brian estaba muy por detrás de Kevin con 171.75 ms. Con las escrituras, Kevin ocupó el primer lugar con 117.02, Ben no se quedó atrás con 201.58 ms y Brian no se quedó atrás con 271.13 ms.

Nuestro próximo punto de referencia mide un rendimiento secuencial de 100K del 8 % con una carga de 16T16Q en operaciones de lectura al 100 % y escritura al 100 %. La construcción de Ben tomó la delantera en lectura con 47,699 44,848 IOPP, Kevin estuvo muy cerca con 29,767 83,866 IOPS y Brian tuvo 51,020 33,448 IOPS. En escritura, Ben nuevamente ocupó el primer lugar con XNUMX XNUMX IOPS, Kevin quedó en segundo lugar con XNUMX XNUMX IOPS y Brian se mantuvo tercero con XNUMX XNUMX IOPS.

En comparación con la carga de trabajo máxima fija de 16 subprocesos y 16 colas que realizamos en la prueba de escritura 100 % 4K, nuestros perfiles de carga de trabajo mixtos escalan el rendimiento en una amplia gama de combinaciones de subprocesos/colas. En estas pruebas, abarcamos la intensidad de la carga de trabajo desde 2 subprocesos/2 colas hasta 16 subprocesos/16 colas. El tipo de unidad y la configuración de RAID juegan un papel muy importante aquí. La paridad agregada para admitir fallas en la unidad tiene un impacto en el rendimiento. Con el rendimiento, Ben comenzó en lo más alto y alcanzó el pico más alto en todo momento con 17,317 XNUMX IOPS, aunque su construcción disminuyó un poco cerca del final. Si bien la estructura de Brian comenzó más alta que la de Kevin, Kevin pudo superarlo en segundo lugar.

Con una latencia promedio, las tres compilaciones de StorageReview comenzaron con una latencia de menos de un milisegundo. Mientras corrían bastante cerca, puedes ver que la construcción de Ben se adelanta gradualmente a la de Kevin y que ambos se alejan de la construcción de Brain. Ben terminó con 15.8 ms, Kevin con 18.3 ms y Brian con 31.2 ms.

Para latencia máxima, Kevin comenzó mejor y él y Ben intercambiaron el primer lugar de un lado a otro. Al final, la construcción de Kevin tuvo 221 ms y la de Ben 285 ms. Brian estuvo muy por detrás en tercer lugar en todo momento.

La desviación estándar mostró claramente la construcción de Ben por delante en todo momento. Kevin tuvo aproximadamente 3 veces la latencia y Brian tuvo aproximadamente 4 veces.

El último punto de referencia de Enterprise Synthetic Workload es nuestra prueba 128K, que es una prueba secuencial de bloques grandes que muestra la velocidad de transferencia secuencial más alta para un dispositivo. En lectura, Kevin ocupó el primer lugar con 2.32 GB/s, Ben estaba justo detrás de él con 1.81 GB/s, y la construcción de Brian debe haber perdido el pistoletazo de salida con 734 MB/s. En escritura, Kevin una vez más tomó el primer puesto con 2.77 GB/s, Ben y Brian estaban casi empatados con 1.42 GB/s y 1.41 GB/s respectivamente.

Elegir la configuración correcta para sus necesidades...

Entonces, ¿quién ganó? Realmente depende de lo que le dé más valor a su implementación. La compilación más rápida en lo que respecta al rendimiento de E/S tenía solo dos bahías para unidades y una CPU/RAM de consumo. Con ZFS, realmente desea que los componentes empresariales como la memoria ECC hagan uso de la pila de integridad de datos avanzada, por lo que está prácticamente descalificado para todas las implementaciones, excepto las que no son de producción.

A continuación, observamos la construcción de Brian, que se acerca mucho más a lo que necesita desde el punto de vista del hardware y más bahías para unidades en el chasis, pero la placa base solo admite cuatro unidades de disco duro. También estaba lleno hasta el borde con el exceso de cables de la fuente de alimentación. Resultó que la llamada para ir a eBay por NIC y DRAM usadas fue mala y la estabilidad general del sistema fue claramente un paso y medio en las categorías de "cambio" y/o "importante".

Para la multitud de bricolaje, realmente se redujo a la construcción de Kevin usando un microservidor estándar. El Microserver tiene una huella más pequeña y un precio de entrada más bajo. También están todos los componentes empresariales y cosas como iLo para la gestión fuera de banda. Sin embargo, el sistema tiene un límite de almacenamiento, con solo 4 bahías y todas son SATA, por lo que no hay ventajas de alta velocidad. Aun así, ofrece el camino de menor resistencia cuando se trata de rodar un sistema TrueNAS CORE económico de bricolaje.

¿Quizás un TrueNAS Mini?

Donde el TrueNAS Mini X+ encajar en esto? Para el rendimiento, no lo hace. La construcción particular que tenemos es para la resiliencia de datos. Sin embargo, el Mini X+ tiene varias características interesantes, como 10 GbE integrado. El Mini + también tiene, sin duda, la mayor capacidad de almacenamiento y flexibilidad, con un total de 7 bahías para unidades.

Además de clasificar los sistemas de bricolaje en términos de rendimiento, este concurso también presenta una imagen clara de lo que se puede hacer dentro del sistema operativo TrueNAS CORE y con un presupuesto limitado (dejando de lado que obtuvimos almacenamiento de WD como parte de este trabajo). Sin embargo, obtener una unidad lista para usar siempre es la apuesta más segura para las pequeñas empresas que necesitan garantías (soporte) de los proveedores. Claramente, algunas de nuestras construcciones sufrieron un poco al ir por la ruta del bricolaje.

El valor de un sistema llave en mano no se puede enfatizar lo suficiente si se trata de un caso de uso de producción. El iXsystems Mini + tiene un precio más alto, pero admite 3 discos adicionales que las plataformas de bricolaje y no tiene dudas sobre el soporte del controlador de componentes. Por supuesto, también hay soporte empresarial para el hardware y el software, algo que ninguna de las compilaciones de bricolaje podría proporcionar. Al final, solo depende de lo que quieras. TrueNAS CORE es lo suficientemente flexible como para manejar casi cualquier hardware.

Gracias a iXsystems, regalamos el TrueNAS Mini, más detalles sobre cómo registrarse aquí.

Obtenga los aspectos más destacados en nuestro video de aspectos más destacados de rendimiento a continuación.