Una cosa que siempre me ha dejado perplejo son las mejores prácticas de almacenamiento. Los sistemas de archivos se jactan de que pueden tener un tamaño de petabytes o exabytes. Sin embargo, no conozco muchos administradores de sistemas que estén dispuestos a dejar que un único volumen crezca en varios terrabytes. Sé que la razón principal detrás de esto es cuánto tiempo llevaría reconstruir la matriz en caso de que falle una unidad. Cuantas más unidades haya en un solo LUN, más tiempo llevará y mayor será el riesgo de perder otra unidad mientras se lleva a cabo la reconstrucción.
Luego están las razones de uso. Los administradores crearán un LUN en función de la cantidad de espacio que creen que se debe asignar al proyecto. Me parece más práctico que el LUN sea un array grande y utilice cuotas. Entiendo que esto no satisfaría todos los requisitos (iSCSI), pero veo muchos sistemas NAS (NFS) administrados de esta manera. También entiendo que los volúmenes subyacentes se pueden aumentar o reducir según sea necesario con bastante facilidad, pero ¿no sería menos "arriesgado" utilizar cuotas en lugar de manipular volúmenes e incluir una posible pérdida de datos en la ecuación?
Puede haber otras razones por las que me falta, así que por favor infórmame. ¿No podemos esperar que los sistemas de archivos lleguen a ser tan grandes? ¿Estamos esperando que el hardware sea más rápido para reducir los tiempos de reconstrucción?
Respuesta1
La separación del husillo es una buena razón para no tener un gran volumen. Si está ejecutando Exchange, SQL Server y otras cosas aleatorias (tal vez invitados ESXi) desde un único dispositivo NFS, seguramente querrá separar el eje. Los datos de intercambio y los longs deben estar en ejes separados entre sí, así como en bases de datos y registros SQL.
Respuesta2
Reconstruir una unidad no depende del sistema de archivos sino de la unidad misma. Si utilizó unidades de 2 TB, necesitará mucho tiempo para reconstruirlas.
La reconstrucción es un problema de raid 5. Por esto ahora los controladores pueden soportar raid 6 o mucho mejor, podrías hacer un raid 10 (si quieres el mejor rendimiento). Exportar un lun es un trabajo para una SAN, exportar un sistema de archivos es un trabajo para un NAS.
Ambos tienen sus pros y sus contras (busque en Google, hay toneladas de documentos al respecto). Crear muchos LUN (o sistemas de archivos) independientes tiene la ventaja de realizar copias de seguridad instantáneas.
Respuesta3
Personalmente, no ejecutaría tráfico empresarial real (Oracle, MSSQL, Production ESX) a través de iSCSI o NFS en absoluto; conozco y confío en FC, tanto para el rendimiento general como durante situaciones de falla. Oh, por supuesto, esto significa que no puedo simplemente crear LUN masivos y subdividirlos y crea bastante complejidad/trabajo, pero la disponibilidad de nuestro sistema y las cifras de experiencia del usuario final han sido mejores y más consistentes de lo que esperábamos.
En cuanto a su respuesta real, bueno, sus publicaciones parecen muy orientadas a NetApp/filer, de ahí mi último párrafo, pero usted mismo ha expuesto las razones. Las interfaces de disco se han quedado significativamente por detrás de la capacidad del disco, lo que significa que los tiempos de reconstrucción pueden ser ridículos, especialmente si desea ver un rendimiento decente durante la reconstrucción de su tráfico existente. Los discos mueren todo el tiempo y la idea de afectar el rendimiento de múltiples plataformas durante una reconstrucción para simplemente hacer la vida más fácil para el administrador sería un método de corta duración. Además, desde una perspectiva puramente de seguridad de la plataforma, es posible que desee particionar sus sistemas y es posible que el enfoque de 'gran LUN' no funcione en ese escenario (según el hardware, por supuesto).
En última instancia, las SAN empresariales son inherentemente críticas para el negocio o la misión, y exigen disponibilidad y coherencia por encima del costo, facilidad de administración o incluso el máximo rendimiento.