Tengo el mismo problema que la mayoría de las personas: cómo crear una solución de almacenamiento personal confiable con el hecho de que:

1. Los discos duros fallan con alarmante regularidad. La pérdida de archivos es inaceptable.
2. Compraré un nuevo HDD de vez en cuando. Inevitablemente, el mejor precio / GB es un tamaño diferente que la última compra de HDD.

3. 2 significa que con el tiempo tengo una colección heterogénea de discos. Quiero usarlos todos, y los discos fallidos generalmente serán reemplazados por discos más grandes.

4. La integridad y la fiabilidad de los datos son más importantes para mí que la velocidad.

Entonces, después de golpearme la cabeza contra este problema durante unos días (y en la parte posterior de mi cabeza durante años), propongo la siguiente solución. Describiré una solución que he probado basada en ZFS nativo de Linux que está disponible en un PPA de Ubuntu , pero LVM, MD y btrfs se pueden usar para lograr lo mismo. Para esto usaré RAID1 (ZFS mirror vdevs).

1. Dado su conjunto de unidades, agrúpelas en dos conjuntos de discos, de modo que la capacidad de cada conjunto sea lo más cercana posible al otro.
2. Particione los discos más grandes de modo que haya una partición exactamente del mismo tamaño que uno de los discos más pequeños, en el otro grupo.
3. Cree vdevs espejo de manera que cada disco tenga su espejo en otro disco.

Por ejemplo, considere un conjunto de discos de una nueva unidad de 2 TB, una unidad anterior de 750 GB, 2 unidades anteriores de 400 GB y una unidad anterior de 500 GB. La partición en espejo óptima tiene 2 TB de espacio utilizable y se describe en el siguiente diagrama donde ':' separa las particiones y '|' separa discos:

+------------------------------------------------------------------+
| 2TB (sda1)        : (sda2)       : (sda3)       : (sda4)         |
+------------------------------------------------------------------+--+
| 750 GB (sdb)      | 400 GB (sdc) | 400 GB (sdd) | 500 GB (sde1)  :XX|
+---------------------------------------------------------------------+

Crea tu zpool como

zpool create archive mirror /dev/sda1 /dev/sdb mirror /dev/sda2 /dev/sdc mirror /dev/sda3 /dev/sdd mirror /dev/sda4 /dev/sde1

Esto crea 4 vdevs espejados. Si alguno de los discos falla, se puede reemplazar (con un disco de cualquier tamaño) y particionar para recrear las particiones que faltan. Es importante que los vdevs de ZFS se puedan agregar a un grupo pero no se eliminen . Entonces, si es posible, cuando uno compra una nueva unidad, desea reorganizar los vdevs existentes. Digamos que la próxima compra fue una unidad de 3 TB. Su configuración óptima es de 3.5 TB utilizables, como se describe en el siguiente diagrama. Esto es ahora 5 pares de vdev. Esto se puede lograr mediante una partición adecuada y fallando sucesivamente y reparticionando las unidades.

+--------------------------------------------------------------+-------------+
| 3 TB (sdf1)       : (sdf2)      : (sdf3)      : (sdf4)       | 500GB (sde) |
+--------------------------------------------------------------+-------------+-+
| 2TB (sda1)        | 400GB (sdb) | 400GB (sdc) | 750GB (sdd1) : (sdd2)      :X| 
+------------------------------------------------------------------------------+

Mantener este emparejamiento de unidades duplicadas también se puede hacer con LVM o con MD RAID, la idea es asegurarse de que cada unidad siempre tenga una unidad espejo o parición. Debido a que todo está reflejado, somos libres de fallar las unidades y reorganizar las particiones cuando se agregan o eliminan unidades. Usando LVM o MD, sería posible eliminar unidades y reducir la matriz, si se desea, a expensas de herramientas de recuperación menos sofisticadas en ZFS en comparación con BTRFS.

¿Algún comentario sobre este procedimiento? Un buen script podría manejar la asignación sin pérdidas y la reorganización de las unidades. ¿Algún comentario sobre LVM vs. MD vs. ZFS? ¿Algún comentario sobre el rendimiento de la matriz extrañamente particionada resultante? ¿La disposición de datos en múltiples particiones en el mismo disco causará una búsqueda excesiva de cabeza y falla temprana?

Desarrolladores de BTRFS: todos quieren esto y LVM o MD no son técnicamente necesarios (y en mi opinión, subóptimos). Facilitar el mantenimiento de una matriz heterogénea redundante sería una característica excelente para btrfs. Es un truco en LVM / MD / ZFS tal como está. Minimizar resliver / resincronización es enormemente deseable.

Sí, esto es obviamente un Drobo de un hombre pobre. Uno no debería necesitar hardware dedicado para eso ...

He probado esto con ZFS y el rendimiento de escritura es aproximadamente la mitad de lo que debería ser, porque ZFS distribuye lecturas y escrituras en todos los vdevs (por lo tanto, divide la E / S en varios lugares en el mismo disco). Por lo tanto, la velocidad está limitada por la velocidad del disco con la mayoría de las particiones. La velocidad de lectura parece ser igual al ancho de banda del disco. Tenga en cuenta que un par de particiones ZFS en dos discos tiene aproximadamente el doble de la velocidad de lectura de cualquier disco individual, ya que puede leer en paralelo desde los discos.

El uso de matrices MD LINEAR o LVM para crear las dos mitades da como resultado el doble del rendimiento de escritura en comparación con la propuesta ZFS anterior, pero tiene la desventaja de que LVM y MD no tienen idea de dónde se almacenan los datos. En el caso de una falla o actualización del disco, un lado de la matriz debe ser completamente destruido y resynced / reslivered, seguido por el otro lado. (por ejemplo, la resincronización / resliver tiene que copiar 2 * (tamaño de la matriz))

Por lo tanto, parece que la solución óptima es crear un único vdev espejo ZFS en dos dispositivos LVM o MD LINEAR que combinen los discos en "mitades" del mismo tamaño. Esto tiene aproximadamente el doble del ancho de banda de lectura de cualquier disco, y el ancho de banda de escritura es igual a los anchos de banda del disco individual.

Usar BTRFS raid1 en lugar de ZFS también funciona, pero tiene la mitad del ancho de banda de lectura porque ZFS distribuye sus lecturas para duplicar el ancho de banda, mientras que parece que BTRFS no lo hace (según mis pruebas). BTRFS tiene la ventaja de que las particiones pueden reducirse, mientras que no pueden con ZFS (por lo tanto, si después de una falla tiene mucho espacio vacío, con BTRFS es posible reconstruir una matriz redundante más pequeña reduciendo el sistema de archivos y luego reorganizando los discos).

Esto es tedioso de hacer a mano pero fácil con algunos buenos scripts.