OpenZFS 2.1 ha sido lanzado: hablemos de sus nuevos dispositivos dRAID vdevs

Viernes por la tarde, proyecto OpenZFS eximir la versión 2.1.0 es nuestro sistema de archivos favorito “es complicado, pero vale la pena”. La nueva versión es compatible con FreeBSD 12.2-RELEASE y posteriores 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, principalmente para empresas y otros casos de uso muy avanzados.

Hoy, sin duda nos centraremos en la característica más importante que agrega OpenZFS 2.1.0: la óptica dRAID vdev. dRAID ha estado en desarrollo activo desde al menos 2015 y alcanzó la versión beta cuando incorporado Para el maestro de OpenZFS en noviembre de 2020. Desde entonces, se ha probado exhaustivamente en varios puntos importantes de desarrollo de OpenZFS, lo que significa que el lanzamiento de hoy es “nuevo” en el modo de producción, no “nuevo” como no se probó.

Demostración de RAID distribuido (dRAID)

Si ya pensaba que la topología ZFS era una complejo tema, prepárate para volar tu mente. RAID distribuido (dRAID) es una topología vdev completamente nueva que conocimos por primera vez en la OpenZFS Dev Summit 2016.

Al crear un vdev DRAID, el administrador define un conjunto de datos, paridad y sectores de repuesto por pista. Estos números son independientes del número de discos vdev reales. Podemos ver esto en acción en el siguiente ejemplo, que se ha eliminado 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 mediante wwn-A. Hemos creado un dispositivo DRAID vdev con 2 dispositivos de paridad, 4 dispositivos de datos y 1 dispositivo de repuesto para cada pista, en una prohibición profesional condensada, draid2:4:1.

Aunque tenemos 11 registros en total draid2:4:1, solo seis se utilizan en cada fila de datos, y uno en cada físico raya. En un mundo de vacíos perfectos, superficies sin fricción y un pollo esférico un draid2:4:1 se vería así:

En la práctica, 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, donde la paridad se fijaba en lugar de dividirse en una matriz.

RAID5 finalizó la unidad de paridad fija y en su lugar compartió la paridad en todos los discos de la matriz, lo que proporcionó operaciones de escritura aleatoria significativamente más rápidas que el RAID3 conceptualmente más simple porque no causó un cuello de botella para cada escritura en el disco de paridad fija.

dRAID toma este concepto, dividiendo la paridad entre todos los discos en lugar de acumular en uno o dos discos duros, y lo extiende spares. Si el disco falla en dRAID vdev, la paridad y los sectores de datos que residían en el disco muerto se copian en las áreas de repuesto reservadas para cada pista herida.

Tomemos el diagrama simplificado anterior y examinemos qué sucede si fallamos desde el disco fuera de la tabla. La falla original deja lagunas en la mayoría de los grupos de datos (franjas en este diagrama simplificado):

Pero cuando volvemos a disolver, lo hacemos para la capacidad de reserva reservada previamente:

Tenga en cuenta que estos diagramas son predigerido. La imagen completa contiene grupos, cortes y filas que no estamos tratando de obtener aquí. El diseño lógico también se ha permutado ocasionalmente para distribuir las cosas de manera más uniforme según la transición. Se anima a los interesados ​​en los detalles más peludos a mirar esto en detalle. comentario en el código original para confirmar.

También vale la pena señalar que dRAID requiere anchos de pista fijos, no los anchos dinámicos admitidos por los vdevs tradicionales RAIDz1 y RAIDz2. Si usamos placas de 4kn, un draid2:4:1 Un vdev como el anterior requiere 24 kb de espacio en el disco duro para cada bloque de metadatos, mientras que un vdev RAIDz2 tradicional de seis anchos solo necesita 12 kb. Esta discrepancia empeora cuanto mayores son los valores d+p obtener draid2:8:1 ¡Requeriría la friolera de 40 kb para el mismo bloque de metadatos!

Por esta razón special assignivdev es muy útil en grupos con DRAID vdevs – cuando el pool draid2:8:1 y tres de ancho special necesita almacenar un bloque de metadatos de 4 KB, solo lo hace en 12 KB special, En lugar de 40 kb draid2:8:1.

Rendimiento, tolerancia a fallas y recuperación de DRAID

En su mayor parte, dRAID vdev funciona de la misma manera que el grupo correspondiente de vdev tradicionales, por ejemplo draid1:2:0 los nueve discos funcionan casi por igual en el grupo de tres discos RAIDz1 de 3 anchos. La tolerancia a fallas también es similar: puede garantizar que sobrevivirá con una falla p=1, al igual que con RAIDz1 vdevs.

Tenga en cuenta que dijimos que la tolerancia a fallas es similar, no es idéntico. El grupo tradicional de tres grupos de RAIDz1 vdevs de 3 anchos solo está garantizado para sobrevivir a una falla de un solo disco, pero probablemente tomará un segundo, siempre que el segundo disco fallado no sea parte del mismo dispositivo vdev que el primero, todo es bien.

Con nueve discos draid1:2, es casi seguro que otra falla en el disco matará a vdev (y al grupo que lo acompaña), Si ese fallo ocurre antes de volver a pegar. Dado que no hay grupos fijos para pistas individuales, es probable que otra falla del disco derribe más sectores en pistas ya rotas. Qué el disco falla en segundo lugar.

Esta tolerancia a fallas algo reducida se compensa con tiempos de recuperación significativamente más rápidos. En el diagrama en la parte superior de esta sección, podemos ver que en un grupo de noventa discos de 16 TB, se fusionan en un tradicional, fijo spare toma alrededor de treinta horas sin importar cómo configuremos dRAID vdev, pero la redistribución a la capacidad de respaldo distribuida puede demorar hasta una hora.

Esto se debe en gran parte al hecho de que reiniciar en una partición distribuida distribuye la carga de escritura entre todos los discos restantes. Al soldar a la tradicional spare, el disco de repuesto en sí es un cuello de botella: las cifras provienen de todos los discos vdev, pero todo debe escribirse en las piezas de repuesto. Pero cuando se descentraliza a la capacidad no utilizada descentralizada, ambos leen y las cargas de escritura se comparten entre todos los discos restantes.

Un recuperador compartido también puede ser un recuperador secuencial y no un recuperador de recuperación, lo que significa que ZFS puede simplemente copiar todos los sectores afectados sin importar qué blocks estos sectores están incluidos. Los aglutinantes curativos, por otro lado, tienen que escanear todo el árbol de bloques, lo que da como resultado un número aleatorio de cargas de trabajo en lugar de un trabajo de lectura secuencial.

Cuando se agrega al grupo la compensación física por un disco defectuoso, ese redirector funciona voluntad no se cura, no es secuencial, y se produce un cuello de botella en las capacidades de escritura de un solo disco de reemplazo, en lugar de todo el vdevin. Pero el tiempo para realizar esta operación es mucho menos importante porque vdev no se encuentra al comienzo del estado degradado.

Conclusiones

Los vdev RAID distribuidos son principalmente para grandes servidores de almacenamiento – OpenZFS draid el diseño y las pruebas giraban en gran medida en torno a sistemas de 90 anchos. A menor escala, los vdevs tradicionales y spares siguen siendo tan útiles como siempre.

En particular, advertimos a los principiantes sobre la precaución. draid—Es un diseño mucho más complejo que una piscina con equipos vdevs tradicionales. La reconstitución rápida es excelente, pero draid se golpea tanto en los niveles de compresión como en algunos escenarios de rendimiento, necesariamente debido a sus franjas de longitud fija.

A medida que los tableros convencionales continúan creciendo sin un aumento significativo en el rendimiento, draid y su rápida reconfiguración puede resultar deseable incluso en sistemas más pequeños, pero llevará algún tiempo averiguar exactamente dónde comienza el punto óptimo. Mientras tanto, tenga en cuenta que RAID no es una copia de seguridad, e incluye draid!