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

Hoy, nos centraremos en la característica más importante que agrega 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 emitir en OpenZFS master en noviembre de 2020. Desde entonces, se ha probado exhaustivamente en varias tiendas de desarrollo de OpenZFS, lo que significa que el lanzamiento de hoy es «nuevo» para el estado de producción, no «nuevo» como no probado.

Descripción general de RAID distribuido (dRAID)

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

Al crear un vdev dRAID, el administrador especifica una cantidad de sectores de datos, paridad y puntos de acceso por banda. Estos números son independientes del número de discos reales en vdev. Podemos ver esto 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 de wwn-A. Creamos un único vdev dRAID con 2 dispositivos de paridad, 4 dispositivos de datos y 1 dispositivo de repuesto por pista; en jerga condensada, uno draid2:4:1.

Aunque tenemos once discos en total en el draid2:4:1, solo seis se utilizan en cada rango de datos, y uno en cada físico raya. En un mundo de vacíos perfectos, superficies sin fricción y pollos esféricos, la disposición del disco de un draid2:4:1 sería algo como esto:

Efectivamente, dRAID está llevando el concepto RAID de «paridad diagonal» un paso más allá. La primera topología RAID de paridad no era RAID5, era RAID3, donde la paridad estaba en una unidad fija en lugar de estar dividida en toda la matriz.

RAID5 eliminó la unidad de paridad fija y distribuyó la paridad en todos los discos de la matriz, lo que ofreció operaciones de escritura aleatoria significativamente más rápidas que el RAID3 conceptualmente más simple, ya que no saturaba cada escritura en un disco de paridad fija.

dRAID toma este concepto, distribuir la paridad en todos los discos en lugar de agrupar todo en uno o dos discos fijos, y lo extiende a spares. Si un disco falla en un dRAID vdev, los sectores de paridad y datos que solían vivir en el disco muerto se copian en los sectores de repuesto para cada fracción afectada.

Tomemos el diagrama simplificado anterior y examinemos qué sucede si fallamos en un disco fuera de la matriz. El defecto inicial deja huecos en la mayoría de los grupos de datos (en este diagrama simplificado, bandas):

Pero cuando recuperamos, lo hacemos en la capacidad de reserva reservada previamente:

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

También es importante tener 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 discrepancia empeora cuanto mayores son los valores de d+p consíguete un draid2:8:1 ¡Requeriría 40 KB increíbles 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 uno de tres anchos special necesita almacenar un bloque de metadatos de 4 KB, lo hace en solo 12 KB en el special, en lugar de 40 KiB en el draid2:8:1.

DRAID rendimiento, tolerancia a fallos y recuperación

En su mayor parte, un vdev dRAID funcionará de manera similar a un grupo equivalente de vdev tradicionales, por ejemplo, un draid1:2:0 en nueve discos funcionará casi tanto como un grupo de tres vdevs RAIDz1 de 3 anchos. La tolerancia a fallas también es similar: se le garantiza que sobrevivirá a una sola falla con p=1, tal como lo hace con RAIDz1 vdevs.

Tenga en cuenta que dijimos que la tolerancia a fallas es similar, no es identico. Un grupo tradicional de tres vdev RAIDz1 de 3 anchos solo está garantizado para sobrevivir a una falla de un solo disco, pero probablemente sobrevivirá un segundo, siempre que el segundo disco que falle no sea parte del mismo vdev que el primero, está bien.

en un disco de nueve draid1:2, una segunda falla en el disco casi seguramente matará a vdev (y al grupo junto con él), Y si esta falla ocurre antes de la recuperación. Dado que no hay grupos fijos para distribuciones individuales, una segunda falla en el disco probablemente borrará sectores adicionales en distribuciones ya degradadas, pase lo que pase. qué el disco falla en segundo lugar.

Esta tolerancia a fallas algo disminuida se compensa con tiempos de recuperación drásticamente más rápidos. En el gráfico en la parte superior de esta sección, podemos ver que en un grupo de noventa discos de 16TB, se recuperan en un tradicional, fijo spare toma alrededor de treinta horas sin importar cómo configuremos dRAID vdev, pero la recuperación en la capacidad de reserva distribuida solo puede tomar una hora.

Esto se debe principalmente a que la recuperación en un repuesto distribuido divide la carga de escritura en todos los discos supervivientes. Cuando se recupera en un spare, el disco de repuesto en sí mismo es el cuello de botella: las lecturas provienen de todos los discos en vdev, pero las escrituras deben ser completadas por el repuesto. Pero cuando se recupera a la capacidad de reserva distribuida, ambos leen y Las cargas de trabajo de grabación se dividen en 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, pase lo que pase. blocks estos sectores pertenecen. Los recuperadores de reparación, por otro lado, 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 para el disco fallado al grupo, esta operación de recuperación voluntad ser reparable, no secuencial, y esto provocará un cuello de botella en 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 vdev no está en un estado degradado para empezar.

Conclusiones

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

Recomendamos especialmente a los principiantes en almacenamiento que tengan cuidado con draid—Es un diseño significativamente más complejo que un grupo con vdevs tradicionales. La recuperación rápida es fantástica, pero draid sufre un impacto tanto en los niveles de compresión como en algunos escenarios de rendimiento debido a sus rangos de longitud necesariamente fijos.

A medida que los discos convencionales continúan creciendo sin aumentos significativos de rendimiento, draid y su rápida recuperación puede ser deseable incluso en sistemas más pequeños, pero llevará algún tiempo averiguar exactamente dónde comienza el punto óptimo. Mientras tanto, recuerde que RAID no es una copia de seguridad, y eso incluye draid!