Agrandar
/
OpenZFS admite muchas topologías de disco complejas, pero la "pila en espiral sobre un escritorio" todavía no es una de ellas.
Jim Salter
comentarios del lector
102
con la participación de 48 carteles, incluido el autor de la historia
Comparte esta historia
Compartir en Facebook
Compartir en Twitter
Compartir en Reddit
El desarrollador fundador de OpenZFS, Matthew Ahrens, abrió un PR para una de las funciones más buscadas en la historia de ZFS, la expansión RAIDz, la semana pasada. La nueva función permite a un usuario de ZFS ampliar el tamaño de un solo vdev RAIDz. Por ejemplo, puede utilizar la nueva función para convertir un RAIDz1 de tres discos en un RAIDz1 de cuatro, cinco o seis.
Otras lecturas
ZFS 101: comprensión del almacenamiento y el rendimiento de ZFS
OpenZFS es un sistema de archivos complejo, y las cosas necesariamente se van a complicar un poco al explicar cómo funciona la función. Por lo tanto, si es un novato en ZFS, es posible que desee consultar nuestro completo ZFS 101
Introducción
.
Ampliación del almacenamiento en ZFS
Además de ser un sistema de archivos, ZFS es una matriz de almacenamiento y un administrador de volumen, lo que significa que puede alimentarlo con una gran cantidad de dispositivos de disco, no solo con uno. El corazón de un sistema de almacenamiento ZFS es el
zpool
: Este es el nivel más fundamental de almacenamiento ZFS. los
zpool
a su vez contiene
vdevs
, y
vdevs
contienen discos reales dentro de ellos. Las escrituras se dividen en unidades llamadas
registros
o
bloques
, que luego se distribuyen semi-uniformemente entre los
vdevs
.
Un almacenamiento
vdev
puede ser uno de cinco tipos: un solo disco, espejo,
RAIDz1
,
RAIDz2
, o
RAIDz3
. Puedes agregar mas
vdevs
a un
zpool
, y tu puedes
adjuntar
más discos en un solo o espejo
vdev
. Pero administrar el almacenamiento de esta manera requiere un poco de planificación y presupuesto, algo que los aficionados y los aficionados al hogar no suelen entusiasmar demasiado.
Convencional
REDADA
, que no comparte el concepto de "grupo" con ZFS, generalmente ofrece la capacidad de expandir y / o remodelar una matriz en su lugar. Por ejemplo, puede agregar un solo disco a un disco de seis
RAID6
matriz, convirtiéndola así en una matriz de siete discos
RAID6
formación. Someterse a una remodelación en vivo puede ser bastante doloroso, especialmente en arreglos casi completos; Es muy posible que una tarea de este tipo requiera una semana o más, con el rendimiento de la matriz limitado a un cuarto o menos de lo normal todo el tiempo.
Históricamente, ZFS ha evitado este tipo de expansión. ZFS se desarrolló originalmente para uso empresarial, y la remodelación de arreglos en vivo generalmente no es una novedad en el mundo empresarial. Reducir el rendimiento de su almacenamiento a niveles inutilizables durante días y días generalmente cuesta más en nómina y gastos generales que comprar un conjunto de hardware completamente nuevo. La expansión en vivo también es potencialmente muy peligrosa, ya que implica leer y reescribir todos los datos y coloca la matriz en una condición temporal y mucho menos probada de "la mitad de esto, la mitad de eso" hasta que se complete.
Para usuarios con muchos discos, el nuevo
RAIDz
Es poco probable que la expansión cambie materialmente la forma en que usan ZFS. Seguirá siendo más fácil y práctico de gestionar.
vdevs
como unidades completas en lugar de tratar de hacer tonterías dentro de ellas. Pero los aficionados, los aficionados al hogar y los pequeños usuarios que ejecutan ZFS con un único
vdev
probablemente sacará mucho provecho de la nueva función.
¿Como funciona?
Agrandar
/
En esta diapositiva, vemos un RAIDz1 de cuatro discos (izquierda) expandido a un RAIDz1 de cinco discos (derecha). ¡Tenga en cuenta que los datos todavía se escriben en bandas de cuatro anchos!
Matthew Ahrens
Desde una perspectiva práctica, el nuevo
vdev
La función de expansión simplemente agrega nuevas capacidades a un comando existente, a saber,
zpool adjuntar
, que normalmente se usa para agregar un disco a un solo disco
vdev
(convirtiéndolo en un
espejo vdev
) o agregue un disco adicional a un
espejo
(por ejemplo, girar un disco de dos
espejo
en un disco de tres
espejo
).
Anuncio publicitario
Con el nuevo código, podrá
adjuntar
nuevos discos a un existente
RAIDz
vdev también. Hacerlo expande el ancho de vdev pero no cambia el
vdev
escriba, para que pueda convertir un disco de seis
RAIDz2
vdev en un disco de siete
RAIDz2
vdev, pero tu
hipocresía
conviértelo en un disco de siete
RAIDz3
.
Al emitir su
zpool adjuntar
comando, comienza la expansión. Durante la expansión, cada
cuadra
o
registro
se lee desde el
vdev
expandiéndose y luego reescrito. Los sectores de lo reescrito
cuadra
se distribuyen entre todos los discos del
vdev
, incluidos los nuevos discos, pero el ancho de la banda en sí no cambia. Entonces un
RAIDz2 vdev
expandido de seis discos a diez seguirá estando lleno de bandas de seis de ancho después de que se complete la expansión.
Entonces, aunque el usuario verá el espacio adicional disponible por los nuevos discos, la eficiencia de almacenamiento de los datos expandidos no habrá mejorado debido a los nuevos discos. En el ejemplo anterior, pasamos de un disco de seis
RAIDz2
con una eficiencia de almacenamiento nominal del 67 por ciento (cuatro de cada seis sectores son datos) en un disco de diez
RAIDz2
. Datos
recién
escrito en el RAIDz2 de diez discos tiene una eficiencia de almacenamiento nominal del 80 por ciento (ocho de cada diez sectores son datos), pero los datos expandidos antiguos todavía se escriben en bandas de seis anchos, por lo que todavía tiene la antigua eficiencia de almacenamiento del 67 por ciento.
Vale la pena señalar que este no es un estado inesperado o extraño en el que se encuentre un vdev:
RAIDz
ya utiliza un ancho de banda variable y dinámico para tener en cuenta
bloques
o
registros
demasiado pequeño para distribuir todos los discos en un solo
vdev
.
Por ejemplo, si escribe un solo bloque de metadatos, los datos que contienen el nombre de un archivo, los permisos y la ubicación en el disco, cabe dentro de un solo
sector
en disco. Si escribe ese bloq
ue de metadatos en un ancho de diezRAIDz2
, no escribe una franja completa de diez de ancho; en su lugar, escribe una
cuadra
solo tres discos de ancho; un solo dato
sector
más dos paridad
sectores
. Entonces, el "tamaño insuficiente"
bloques
en un recién ampliado
RAIDz
vdev no es algo con lo que ZFS se confunda. Son solo un día más en la oficina.
¿Hay algún impacto duradero en el rendimiento?
Como comentamos anteriormente, una nueva
RAIDz vdev
no se parecerá a uno diseñado de esa manera desde el "nacimiento", al menos no al principio. Aunque hay más discos en la mezcla, la estructura interna de los datos no cambia.
Agregar uno o más discos nuevos al
vdev
significa que debería ser capaz de un rendimiento algo mayor. Aunque el legado
bloques
no abarque todo el ancho del
vdev
, los discos agregados significan más ejes para distribuir el trabajo. Sin embargo, esto probablemente no suponga un aumento de velocidad asombroso: seis franjas de ancho en un disco de siete
vdev
significa que todavía no puedes leer ni escribir dos
bloques
simultáneamente, por lo que es probable que las mejoras de velocidad sean menores.
El impacto neto en el rendimiento puede ser difícil de predecir. Si se expande desde un disco de seis
RAIDz2
a un disco de siete
RAIDz2
, por ejemplo, su configuración original de seis discos no necesitaba ningún relleno. Un 128 KB
cuadra
se puede cortar uniformemente en cuatro piezas de datos de 32 KB, con dos piezas de paridad de 32 KB. El mismo récord dividido entre
Siete
los discos requieren relleno porque 128 KB / cinco piezas de datos no llegan a un número par de sectores.
Anuncio publicitario
Del mismo modo, en algunos casos, especialmente con una pequeña
tamaño de registro
o
volblocksize
conjunto: la carga de trabajo por disco individual puede ser significativamente menos desafiante en el diseño más antiguo y más estrecho que en el más nuevo y más ancho. Un 128 KB
cuadra
dividido en piezas de 32 KB para un ancho de seis
RAIDz2
se puede leer o escribir de manera más eficiente
por disco
de uno dividido en piezas de 16 KB para un ancho de diez
RAIDz2
, por ejemplo, por lo que es un poco complicado si más discos pero piezas más pequeñas proporcionarán más rendimiento que menos discos pero las piezas más grandes lo hicieron.
Lo único de lo que puede estar seguro es que la configuración recién expandida normalmente debería funcionar tan bien como la versión original no expandida, y que una vez que la mayoría de los datos se (re) escriben en el nuevo ancho, la versión expandida
vdev
no funcionará de manera diferente, ni será menos confiable, que uno que fue diseñado de esa manera desde el principio.
¿Por qué no remodelar registros / bloques durante la expansión?
Puede parecer extraño que el proceso de expansión inicial no reescriba todos los
bloques
al nuevo ancho mientras se está ejecutando; después de todo, está leyendo y reescribiendo los datos de todos modos, ¿verdad? Le preguntamos a Ahrens por qué se dejó el ancho original como estaba, y la respuesta se reduce a "es más fácil y seguro de esa manera".
Un factor clave a reconocer es que técnicamente, la expansión
no es
Moviente
bloques
; se está moviendo
sectores
. De la forma en que está escrito, el código de expansión no necesita saber dónde está la lógica de ZFS.
cuadra
Los límites son: la rutina de expansión no tiene idea de si un individuo
sector
es la paridad o los datos, y mucho menos qué
cuadra
pertenece a.
La expansión podría atravesar todos los
cuadra
punteros para localizar
cuadra
fronteras, y
luego
sabría cual
sector
pertenece a lo que
cuadra
y cómo remodelar el
cuadra
, pero según Ahrens, hacer las cosas de esa manera sería extremadamente invasivo para el formato en disco de ZFS. La expansión necesitaría actualizarse continuamente
mapas espaciales
sobre
metaslabs
para tener en cuenta los cambios en el tamaño en disco de cada
cuadra
—Y si el
cuadra
es parte de un
conjunto de datos
preferible a
zvol
, actualice también la contabilidad por conjunto de datos y por espacio de archivo.
Si realmente le pica los dientes saber que tiene rayas de cuatro de ancho en un vdev de cinco de ancho recién hecho, puede leer y reescribir sus datos usted mismo después de que se complete la expansión. La forma más sencilla de hacer esto es usar
instantánea de zfs
,
enviar zfs
, y
recibir zfs
para replicar todo
conjuntos de datos
y
zvols
. Si no le preocupan las propiedades de ZFS, una simple
mv
la operación hará el truco.
Sin embargo, en la mayoría de los casos recomendamos simplemente relajarse y dejar que ZFS haga lo suyo. Tu tamaño insuficiente
bloques
de datos más antiguos no están realmente dañando nada, y como naturalmente borra y / o altera los datos durante la vida del
vdev
, la mayoría de ellos se reescribirán de forma natural según sea necesario, sin la necesidad de la intervención del administrador o largos períodos de alta carga de almacenamiento debido a la lectura obsesiva y la reescritura de todo a la vez.
¿Cuándo llegará la expansión de RAIDz a producción?
El nuevo código de Ahrens aún no forma parte de ninguna versión de OpenZFS, y mucho menos se ha agregado a los repositorios de nadie más. Le preguntamos a Ahrens cuándo podríamos esperar ver el código en producción y, desafortunadamente, será un tiempo.
Es demasiado tarde para que la expansión de RAIDz se incluya en la próxima versión de OpenZFS 2.1, que se espera muy pronto (la versión 7 de la versión 2.1 candidata ya está disponible). Debería incluirse en la próxima versión principal de OpenZFS; es demasiado pronto para fechas concretas, pero los lanzamientos importantes suelen producirse una vez al año.
En términos generales, esperamos que la expansión de RAIDz llegue a la producción en Ubuntu y FreeBSD alrededor de agosto de 2022, pero eso es solo una suposición. Es muy posible que TrueNAS lo ponga en producción antes de eso, ya que ixSystems tiende a extraer las funciones de ZFS del maestro antes de que alcancen oficialmente el estado de lanzamiento.
Matt Ahrens presentó la expansión RAIDz en la FreeBSD Developer Summit; su charla comienza en 1 hora y 41 minutos en este video.