Viernes por la tarde, el proyecto OpenZFS publicado la versión 2.1.0 de nuestro perenne sistema de archivos «es complicado pero vale la pena». La nueva versión es compatible con FreeBSD 12.2-RELEASE y superior, y con los kernels de Linux 3.10-5.13. Esta versión ofrece varias mejoras generales de rendimiento, así como algunas características completamente nuevas, dirigidas principalmente a empresas y otros casos de uso extremadamente avanzados.

Hoy probablemente nos centraremos en la característica más importante agregada por OpenZFS 2.1.0: la topología dRAID vdev. dRAID ha estado en desarrollo activo desde al menos 2015 y alcanzó el estado beta cuando fusionado en OpenZFS master en noviembre de 2020. Desde entonces, se ha probado exhaustivamente en varias grandes tiendas de desarrollo de OpenZFS, lo que significa que la versión actual es «nueva» para el estado de producción, no «nueva» porque no se ha probado.

Comprensión de RAID distribuido (dRAID)

Si alguna vez pensó que la topología ZFS era una complejo sujeto, prepárese para dejarse llevar. RAID distribuido (dRAID) es una topología vdev completamente nueva que encontramos por primera vez durante una presentación en la OpenZFS Dev Summit 2016.

Al crear un vdev dRAID, el administrador especifica una cantidad de datos, paridad y sectores de repuesto dinámico por cinta. Estos números son independientes del número de discos reales en vdev. Lo podemos ver en acción en el siguiente ejemplo, tomado de los conceptos básicos de dRAID Documentación:

root@box:~# zpool create mypool draid2:4d:1s:11c wwn-0 wwn-1 wwn-2 ... wwn-A
root@box:~# zpool status mypool

  pool: mypool
 state: ONLINE
config:

        NAME                  STATE     READ WRITE CKSUM
        tank                  ONLINE       0     0     0
          draid2:4d:11c:1s-0  ONLINE       0     0     0
            wwn-0             ONLINE       0     0     0
            wwn-1             ONLINE       0     0     0
            wwn-2             ONLINE       0     0     0
            wwn-3             ONLINE       0     0     0
            wwn-4             ONLINE       0     0     0
            wwn-5             ONLINE       0     0     0
            wwn-6             ONLINE       0     0     0
            wwn-7             ONLINE       0     0     0
            wwn-8             ONLINE       0     0     0
            wwn-9             ONLINE       0     0     0
            wwn-A             ONLINE       0     0     0
        spares
          draid2-0-0          AVAIL

Topología DRAID

En el ejemplo anterior, tenemos once discos: wwn-0 a través wwn-A. Hemos creado un único vdev dRAID con 2 dispositivos de paridad, 4 dispositivos de datos y 1 repuesto por banda; en un lenguaje condensado, un draid2:4:1.

A pesar de que tenemos once registros en total en el draid2:4:1, solo seis se utilizan en cada banda de datos, y uno en cada físico Vendado. En un mundo de vacíos perfectos, superficies sin fricción y pollos esféricos, el diseño de disco de un draid2:4:1 se vería algo como esto:

Efectivamente, dRAID lleva el concepto de RAID de “paridad diagonal” un paso más allá. La primera topología RAID de paridad no era RAID5, era RAID3, en la que la paridad estaba en una unidad fija, en lugar de distribuirse por toda la matriz.

RAID5 eliminó la unidad de paridad fija y la paridad distribuida en todas las unidades de la matriz, lo que proporcionó operaciones de escritura aleatorias mucho más rápidas que el RAID3 conceptualmente más simple porque no aceleraba cada escritura en un disco de paridad fija.

dRAID toma este concepto, distribuir la paridad entre todos los discos, en lugar de agrupar todo en uno o dos discos fijos, y lo expande a spares. Si un disco falla en un vdev dRAID, la paridad y los sectores de datos que vivían en el disco muerto se copian en los sectores de reserva reservados para cada cinta afectada.

Tomemos el diagrama simplificado anterior y echemos un vistazo a lo que sucede si fallamos una unidad fuera de la matriz. La falla inicial deja agujeros en la mayoría de los conjuntos de datos (en este diagrama simplificado, rasguños):

Pero cuando reponemos, lo hacemos sobre la capacidad de reserva previamente reservada:

Tenga en cuenta que estos diagramas son simplificado. La imagen completa incluye grupos, cortes y filas, que no intentaremos abordar aquí. El diseño lógico también se intercambia aleatoriamente para distribuir las cosas de manera más uniforme en los discos según el desplazamiento. Se anima a los interesados ​​en los detalles más peludos a mirar este detalle. comentario en el código original commit.

También debe tenerse en cuenta que dRAID requiere anchos de banda fijos, no los anchos dinámicos admitidos por los vdevs tradicionales RAIDz1 y RAIDz2. Si usamos discos 4kn, un draid2:4:1 vdev como el que se muestra arriba requerirá 24 KB en el disco para cada bloque de metadatos, mientras que un vdev RAIDz2 tradicional de seis anchos solo necesitaría 12 KB. Esta brecha empeora a medida que aumentan los valores. de d+p obtener un draid2:8:1 ¡Requeriría la friolera de 40 KB para el mismo bloque de metadatos!

Por esta razón, la special La asignación de vdev es muy útil en grupos con dRAID vdevs, cuando un grupo con draid2:8:1 y un tres grande special necesita almacenar un bloque de metadatos de 4 KB, lo hace en solo 12 KB en el special, en lugar de 40 KB en el draid2:8:1.

Rendimiento, tolerancia a fallas y recuperación de DRAID

En su mayor parte, un vdev dRAID funcionará igual que un grupo equivalente de vdev tradicionales, por ejemplo, un draid1:2:0 en nueve discos funcionará casi equivalente a un grupo de tres vdev RAIDz1 de 3 anchos. La tolerancia a fallas también es similar: tiene la garantía de sobrevivir a una sola interrupción con p=1, al igual que con RAIDz1 vdevs.

Tenga en cuenta que dijimos que la tolerancia a fallas es similar, no es identico. Un grupo tradicional RAIDz1 de tres vdev de 3 anchos garantiza solo una falla de disco, pero probablemente sobrevivirá hasta un segundo. Siempre que el segundo disco fallido no forme parte del mismo vdev que el primero, todo está bien.

En nueve discos draid1:2, es casi seguro que una segunda falla en el disco matará el vdev (y el grupo con él), Si esta falla ocurre antes de la recuperación. Dado que no hay grupos fijos para cintas individuales, es muy probable que una segunda falla en la unidad destruya sectores adicionales en cintas ya degradadas, pase lo que pase. cual el disco falla en segundo lugar.

Esta tolerancia a fallas algo reducida se compensa con tiempos de recuperación considerablemente más rápidos. En el gráfico en la parte superior de esta sección, podemos ver que en un grupo de noventa unidades de 16TB, recuperadas en un spare toma aproximadamente treinta horas, independientemente de cómo configuramos vdev dRAID, pero la recuperación de la capacidad de reserva distribuida puede demorar tan solo una hora.

Esto se debe en gran parte a que la recuperación en un repuesto dinámico distribuido distribuye la carga de escritura entre todos los discos supervivientes. Cuando se recupera de un soporte tradicional spare, el repuesto dinámico en sí mismo es el cuello de botella: las lecturas provienen de todos los discos en vdev, pero todas las escrituras deben ser realizadas por el repuesto dinámico. Pero cuando se recupera a una capacidad de reserva distribuida, ambos leen y las cargas de trabajo de escritura se distribuyen entre todos los discos supervivientes.

El recuperador distribuido también puede ser un recuperador secuencial, en lugar de un recuperador de recuperación, lo que significa que ZFS puede simplemente copiar todos los sectores afectados, independientemente de qué blocks estos sectores pertenecen. Por el contrario, los resilientes de reparación deben escanear todo el árbol de bloques, lo que da como resultado una carga de trabajo de lectura aleatoria en lugar de una carga de trabajo de lectura secuencial.

Cuando se agrega un reemplazo físico del disco defectuoso al grupo, esta operación de recuperación voluntad sea ​​curativo, no secuencial, y esto obstaculizará el rendimiento de escritura del disco de reemplazo único, en lugar de todo el vdev. Pero el tiempo para completar esta operación es mucho menos crucial, ya que el vdev no está en un estado degradado para empezar.

Conclusión

Los vdev RAID distribuidos están destinados principalmente a grandes servidores de almacenamiento: OpenZFS draid gran parte del diseño y las pruebas giraron en torno a sistemas de 90 discos. A menor escala, los vdevs tradicionales y spares siguen siendo tan útiles como siempre.

Advertimos especialmente a los nuevos en almacenamiento que tengan cuidado con draid– Es un diseño mucho más complejo que un grupo con vdevs tradicionales. La recuperación rápida es fantástica, pero draid sufre un impacto en los niveles de compresión y algunos escenarios de rendimiento debido a sus bandas de longitud necesariamente fijas.

Si bien las unidades convencionales continúan creciendo sin un aumento significativo en el rendimiento, draid y su rápida recuperación puede ser deseable incluso en sistemas más pequeños, pero llevará algún tiempo determinar exactamente dónde comienza el punto óptimo. Mientras tanto, recuerde que RAID no es una copia de seguridad, y eso incluye draid!