ZFS y SAN: ¿mejores prácticas?

La mayoría de las discusiones sobre ZFS sugieren que el RAID de hardware se apague y que ZFS debería hablar directamente con los discos y administrar el RAID en el host (en lugar del controlador RAID).

Esto tiene sentido en una computadora con 2-16 o incluso más discos locales, pero ¿qué pasa en un entorno con una SAN grande?

Por ejemplo, la empresa para la que trabajo tiene lo que yo consideraría una SAN de tamaño modesto con 2 racks completos de discos, que es algo así como 400 husos. He visto estantes SAN que son mucho más densos que los nuestros, y despliegues SAN mucho más grandes que los nuestros.

¿Las personas exponen 100 discos directamente a grandes servidores ZFS? 300 discos? 3000 discos? ¿Las herramientas de administración de SAN facilitan la administración automatizada de este tipo de cosas?

FWIW Tengo experiencia con hasta 92 discos en un único grupo de ZFS y hasta ahora funciona bien.

Pero si realmente está hablando de varios cientos de discos, consideraría dividirlos en un pequeño número de grupos disjuntos (pero aún grandes). No quiero saber cuánto tiempo, por ejemplo, un se zpool scrubejecuta en un grupo de 3000 discos (pero desea restregarlo regularmente). Además, la salida de comandos como zpool statussería difícil de manejar con una cantidad tan grande de discos. Entonces, ¿por qué poner todos los huevos en una sola canasta?

(Nota al margen sobre la deducción : tenga en cuenta que aunque la deducción puede controlarse a nivel de conjunto de datos, encontrará duplicados a nivel de grupo. Es decir, probablemente obtendrá peores resultados de deducción si está particionando como se sugiere. Por otro lado, necesita mucha más memoria para contener los hash de deduplicación de un único grupo gigante que podría no encajar en ARC + L2ARC si el grupo es demasiado grande. Por lo tanto, si está utilizando dedup, la cantidad de memoria disponible es probablemente un buen indicador del tamaño práctico máximo del grupo .)

Dejamos que nuestras SAN administren el RAID. ¿Por qué gastar dinero en toda esa NVRAM respaldada por batería y esos procesadores dedicados y luego descargar el trabajo en el servidor, cuyas CPU quiero hacer algo más que sumas de verificación RAID?

Aquí hay un sitio web que puede consultar para considerar el tamaño y la configuración de los grupos para la probabilidad de pérdida de datos.
https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protection

¡Es una pregunta antigua pero hoy es relevante como lo fue hace 7 años!

Para responder a la primera parte de la pregunta, no estoy al tanto de lo que llamaríamos una "SAN" que expondría los discos en bruto a un servidor que podría ejecutar ZFS. Una SAN por definición solo presenta almacenamiento en bloque (LUN) o tal vez con algo como un Filer / FS presenta un NFS o CIFS. Hay algunas "SAN" que realmente ejecutan ZFS internamente, pero esto se abstrae en gran medida: los discos nunca están expuestos a un servidor, en cambio, el componente "Filer" de la SAN presenta sistemas de archivos de red o bloque a los servidores.

Un dispositivo que presenta los discos sin formato (sobre SAS o menos probable sobre FC) es un DAS. Para ejecutar ZFS, normalmente le diría al controlador RAID que presente los discos como un JBOD.

Sin embargo, ¿debería usar ZFS en un LUN presentado por una SAN? Posiblemente: ZFS frente a, por ejemplo, EXT4, proporciona algunas características adicionales, como scrubs que verifican sumas de verificación o para ejecutar instantáneas. Es probable que un exfoliante no pueda sanar automáticamente de la misma manera que si está haciendo el RAID del disco, pero aún puede alertarlo sobre la corrupción, lo que ayuda a prevenir Bitrot. Las instantáneas que puede crear, por ejemplo, en un servidor de archivos SAMBA de Linux son muy superiores a lo que puede hacer con EXT, incluso pueden exponerse en Windows como "Versiones anteriores".

Si no proporciona datos redundantes de ZFS para trabajar (por ejemplo, espejos, RAID-Z), pierde muchos de los beneficios de usarlos. El número de discos involucrados no cambiará ese hecho. Sin embargo, si eso importa realmente depende de su entorno. Debe determinar qué funciones de almacenamiento necesita (un análisis potencialmente laborioso) y luego buscar la solución menos costosa (que pueda pagar) que satisfaga sus necesidades. Eso puede significar usar ZFS en todas partes junto con dispositivos de almacenamiento especializados de Oracle (algunas personas hacen eso y tienen muchos discos expuestos a ZFS sin problemas, y usan herramientas de Oracle para administrar), puede significar usar solo productos SAN empresariales, o puede significar usar algunos híbridos (en cuyo caso probablemente tendrá que desarrollar algunas herramientas y procesos por su cuenta para administrar el entorno). Don'