Agrandar
/
Ni el cronómetro ni la chaqueta vaquera son estrictamente necesarios, si somos honestos al respecto.
Aurich Lawson / Getty
comentarios del lector
259
con la participación de 108 carteles, incluido el autor de la historia
Comparte esta historia
Compartir en Facebook
Compartir en Twitter
Compartir en Reddit
Fundamentos de almacenamiento
OpenZFS 2.1 ya está disponible; hablemos de sus nuevos vdevs dRAID
Volver a RAID: los lectores de Ars "¿Y si?" edición
ZFS versus RAID: ocho discos Ironwolf, dos sistemas de archivos, un ganador
ZFS 101: comprensión del almacenamiento y el rendimiento de ZFS
Comprensión de RAID: cómo se escala el rendimiento de un disco a ocho
Ver más historias
Esto ha tardado mucho tiempo en prepararse, es el momento de obtener los resultados de las pruebas. Para comprender realmente los fundamentos del almacenamiento informático, es importante
explorar el impacto de varios RAID convencionales
(Matriz redundante de discos económicos) topologías de rendimiento. También es importante
comprender qué es ZFS y cómo funciona
. Pero en algún momento, la gente (especialmente los entusiastas de las computadoras en Internet) quiere números.
Primero, una nota rápida: esta prueba, naturalmente, se basa en esos fundamentos. Vamos a aprovechar en gran medida las lecciones aprendidas a medida que exploramos las topologías de ZFS aquí. Si aún no está completamente seguro de la diferencia entre pools y vdevs o qué significan un cambio y un tamaño de registro,
fuertemente
Le recomiendo que vuelva a visitar esos explicadores antes de sumergirse en las pruebas y los resultados.
Y aunque a todo el mundo le encanta ver los números brutos, instamos a un enfoque adicional en
cómo
estas cifras se relacionan entre sí. Todos nuestros gráficos relacionan el rendimiento de las topologías de agrupaciones de ZFS en tamaños de dos a ocho discos con el rendimiento de un solo disco. Si cambia el modelo de disco, sus números sin procesar cambiarán en consecuencia, pero en su mayor parte, su relación con el rendimiento de un solo disco no lo hará.
Equipo probado
Sí, trabajo en un sótano en gran parte sin terminar. Al menos tengo ventanas que dan al patio. No me @.
Este es el Hot Rod de almacenamiento de verano de 2019, con las doce bahías cargadas y calientes. Los primeros cuatro son mis propios materiales; los últimos ocho son los dispositivos que se están probando hoy. (La máquina de arriba es banshee, mi estación de trabajo Ryzen 7 3700X, en un chasis idéntico de 12 bahías).
Otras lecturas
Actualicé mi viejo y crujiente servidor Pentium G, vale la pena compartir los resultados
Usamos las ocho bahías vacías en nuestro
Verano 2019 Storage Hot Rod
para esta prueba. Tiene montones de RAM y potencia de CPU más que suficiente para realizar estas pruebas de almacenamiento sin sudar.
Resumen de especificaciones: Hot Rod de almacenamiento de verano de 2019, según lo probado
SO
Ubuntu 18.04.4 LTS
UPC
AMD Ryzen 7 2700X—
$ 250 en Amazon
RAM
Kit UDIMM DDR4 ECC de 64 GB—
$ 459 en Amazon
Adaptador de almacenamiento
Adaptador de bus de host de 8 puertos LSI-9300-8i
$ 148 en Amazon
Almacenamiento
8x 12 TB Seagate Ironwolf—
$ 320 c / u en Amazon
tarjeta madre
Asrock Rack X470D4U—
$ 260 en Amazon
Fuente de alimentación
PSU semimodular EVGA 850GQ
$ 140 en Adorama
Chasis
Rosewill RSV-L4112—
Normalmente $ 260
, actualmente no disponible debido a CV19
El Storage Hot Rod también tiene un
LSI-9300-8i
Adaptador de bus de host (HBA) que no se usa para nada más que los discos bajo prueba. Las primeras cuatro bahías del chasis tienen nuestros propios datos de respaldo, pero estuvieron inactivas durante todas las pruebas aquí y están conectadas al controlador SATA de la placa base, completamente aislado de nuestras matrices de prueba.
Anuncio publicitario
Como probamos
Otras lecturas
¿Qué tan rápidos son sus discos? Descubra la forma de código abierto, con fio
Como siempre, usamos
fio
para realizar todas nuestras pruebas de almacenamiento. Los ejecutamos localmente en el Hot Rod y usamos tres tipos básicos de prueba de acceso aleatorio: lectura, escritura y escritura sincronizada. Cada una de las pruebas se ejecutó con tamaños de bloque de 4K y 1M, y ejecuté las pruebas con un solo proceso y iodepth = 1, así como con ocho procesos con iodepth = 8.
Para todas las
pruebas, usamos ZFS en Linux 0.7.5, como se encuentra en los repositorios principales de Ubuntu 18.04 LTS. Vale la pena señalar que ZFS en Linux 0.7.5 ya tiene dos años; hay características y mejoras de rendimiento en las versiones más recientes de OpenZFS que no estaban disponibles en 0.7.5.Probamos con 0.7.5 de todos modos, para disgusto de al menos un desarrollador de OpenZFS muy experimentado, porque cuando ejecutamos las pruebas, 18.04 era el Ubuntu LTS más actual y una de las distribuciones estables más actualizadas en general. En el próximo artículo de esta serie, sobre optimización y ajuste de ZFS, actualizaremos al nuevo Ubuntu 20.04 LTS y un ZFS mucho más nuevo en Linux 0.8.3.
Configuración inicial: ZFS vs mdraid / ext4
Cuando probamos mdadm y ext4, realmente no usamos todo el disco; creamos una partición de 1TiB en la cabecera de cada disco y usamos esas particiones de 1TiB. También tuvimos que invocar argumentos arcanos:
mkfs.ext4 -E lazy_itable_init = 0, lazy_journal_init = 0
—Para evitar que la preasignación de ext4 contamine nuestros resultados.
El uso de estas particiones relativamente pequeñas en lugar de los discos completos fue una necesidad práctica, ya que ext4 necesita arrastrarse por todo el sistema de archivos creado y dispersar los bloques de metadatos preasignados en todas partes. Si hubiéramos utilizado los discos completos, el espacio utilizable en la topología RAID6 de ocho discos habría sido de aproximadamente 65TiB, y habría llevado varias horas formatearlo, con esperas agonizantes similares
cada
topología probada.
Afortunadamente, ZFS no necesita ni quiere preasignar bloques de metadatos, sino que los crea sobre la marcha cuando se vuelven necesarios. Así que alimentamos a ZFS cada disco Ironwolf de 12 TB en su totalidad, y no tuvimos que esperar a través de largos procedimientos de formateo: cada topología, incluso la más grande, estaba lista para usarse uno o dos segundos después de la creación, sin necesidad de argumentos especiales.
Anuncio publicitario
ZFS frente a RAID convencional
Otras lecturas
Bitrot y COW atómicos: dentro de los sistemas de archivos de "próxima generación"
Otras lecturas
ZFS 101: comprensión del almacenamiento y el rendimiento de ZFS
Una matriz RAID convencional es una capa de abstracción simple que se encuentra entre un sistema de archivos y un conjunto de discos. Presenta la matriz completa como un dispositivo de "disco" virtual que, desde la perspectiva del sistema de archivos, es indistinguible de un disco individual real, incluso si es significativamente más grande de lo que podría ser el disco individual más grande.
ZFS es un animal completamente diferente y abarca funciones que normalmente podrían ocupar tres capas separadas en un sistema tradicional tipo Unix. Es un administrador de volumen lógico, un sistema RAID y un sistema de archivos, todo en uno. La fusión de capas tradicionales como esta ha provocado que muchos administradores de alto nivel rechinen los dientes con indignación, pero hay muy buenas razones para ello.
Hay un absoluto
tonelada
de las funciones que ofrece ZFS, y se recomienda encarecidamente a los usuarios que no las conozcan que echen un vistazo a nuestra
cobertura
de sistemas de archivos de próxima generación para una descripción básica, así como nuestro reciente ZFS 101
artículo
para una explicación mucho más completa.
Megabytes vs Mebibytes
Como en el artículo anterior, nuestras unidades de medición del rendimiento aquí son kibibytes (KiB) y mebibytes (MiB). Un kibibyte es 1.024 bytes, un mebibyte es 1.024 kibibytes, y así sucesivamente, en contraste con un kilobyte, que es 1.000 bytes, y un megabyte, que es 1.000 kilobytes.
Los kibibytes y sus hermanos mayores siempre han sido las unidades estándar para el almacenamiento de computadoras. Antes de la década de 1990, los profesionales de la informática simplemente se referían a ellos como K y M, y usaban prefijos métricos inexactos cuando los deletreaban. Pero cada vez que su sistema operativo se refiere a GB, MB o KB, ya sea en términos de espacio libre, velocidad de red o cantidad de RAM, en realidad se refiere a GiB, MiB y KiB.
Desafortunadamente, los proveedores de almacenamiento finalmente aprovecharon la diferencia entre las métricas como una forma de producir unidades de "gigabytes" y luego unidades de "terabytes" de manera más económica, por lo que un SSD de 500 GB en realidad es solo 465 GiB y discos duros de 12 TB como los que tenemos. Las nuevas pruebas de hoy son realmente solo 10.9TiB cada una.
