Las mejores opciones de sistema de archivos para NFS que almacenan imágenes de disco de VMware

Actualmente utilizamos una SAN iSCSI como almacenamiento para varios servidores VMware ESXi. Estoy investigando el uso de un objetivo NFS en un servidor Linux para máquinas virtuales adicionales. También estoy abierto a la idea de usar un sistema operativo alternativo (como OpenSolaris) si proporcionará ventajas significativas.

¿Qué sistema de archivos basado en Linux favorece archivos contiguos muy grandes (como las imágenes de disco de VMware)? Alternativamente, ¿cómo han encontrado ZFS en OpenSolaris para este tipo de carga de trabajo?

(Esta pregunta se hizo originalmente en SuperUser ; no dude en migrar las respuestas aquí si sabe cómo hacerlo).

Realmente recomiendo que eche un vistazo a ZFS, pero para obtener un rendimiento decente, necesitará elegir un dispositivo dedicado como un Registro de Intenciones ZFS (ZIL). Básicamente, este es un dispositivo pequeño (unos pocos GB) que puede escribir extremadamente rápido (20-100K IOPS) que le permite a ZFS confirmar de inmediato que las escrituras se han sincronizado al almacenamiento, pero espere hasta 30 segundos para enviar las escrituras a los discos duros en tu piscina En caso de bloqueo / interrupción, cualquier transacción no confirmada en el ZIL se reproduce en el montaje. Como resultado, además de un UPS, es posible que desee una unidad con una fuente de alimentación interna / supercondensador para que cualquier E / S pendiente llegue al almacenamiento permanente en caso de pérdida de energía. Si opta por un dispositivo ZIL dedicado, las escrituras pueden tener una alta latencia y provocar todo tipo de problemas. Suponiendo que no estés interesado en Sun '

• DDRDrive X1 - 4GB DDR2 + 4GB SLC Flash en una tarjeta PCIe x1 diseñada explícitamente para uso ZIL. Las escrituras van a la RAM; en caso de pérdida de energía, sincroniza RAM a NAND en <60 segundos alimentado por un supercondensador. (50k-300k IOPS; $ 2000 Directo, $ 1500 por .edu)
• Intel X25-E 32GB SSD de 2.5 pulgadas (SLC, pero no super cap, 3300 escribir IOPS); [$ 390 en Amazon] [11]
• OCZ Vertex 2 Pro 40GB SSD de 2.5 pulgadas (supercap, pero MLC, 20k-50k escribir IOPS); $ 435 @ Amazon .

Una vez que tenga la configuración de OpenSolaris / Nexenta + ZFS, hay bastantes maneras de mover bloques entre su OpenSolaris y ESX boxen; lo que es adecuado para usted depende en gran medida de su infraestructura existente (conmutadores L3, tarjetas de fibra) y sus prioridades (redundancia, latencia, velocidad, costo). Pero como no necesita licencias especializadas para desbloquear la funcionalidad iSCSI / FC / NFS, puede evaluar cualquier cosa para la que tenga hardware y elegir su favorito:

• Objetivos iSCSI (sobrecarga de la CPU; sin compatibilidad con TOE en OpenSolaris)
• Objetivos de canal de fibra (las tarjetas de fibra no son baratas)
• NFS (VMWare + NFS puede ser meticuloso, limitado a 32 montajes)

Si no puede gastar $ 500 para la evaluación, pruebe con y sin ZIL desactivado para ver si el ZIL es un cuello de botella. (Probablemente lo sea). No hagas esto en producción . No te metas con la deduplicación de ZFS todavía, a menos que también tengas mucha memoria RAM y un SSD para L2ARC. Definitivamente es bueno una vez que lo configuras, pero definitivamente intentas hacer un ajuste de NFS antes de jugar con dedup. Una vez que consiga saturar los enlaces de 1-2 Gb, hay oportunidades de crecimiento en 8 gb FC, 10 gigE e infiniband, pero cada uno requiere una inversión significativa incluso para la evaluación.

No haría exactamente esto. En mi experiencia, Linux (específicamente CentOS 3/4/5) es una elección generalmente pobre para un servidor NFS. He tenido varios y descubrí que bajo carga, la latencia y el rendimiento tienden a disminuir por razones que nunca podríamos entender.

En nuestros casos, estábamos comparando el rendimiento de Linux de forma consecutiva con Solaris (en Ultra-SPARC) y NetApp; los cuales arrojaron resultados en términos de rendimiento de manzanas a manzanas y en términos nebulosos de "ingenieros que no se quejan tanto por la latencia cuando el servidor estaba bajo carga". Hubo múltiples intentos de sintonizar el servidor NFS de Linux; los sistemas NetApps y Solaris se ejecutaron tal cual están listos para usar. Y dado que los sistemas Solaris y NetApp involucrados eran más antiguos, se podría argumentar que los servidores Linux tenían todas las ventajas y aún no eran convincentes.

Si tiene el tiempo, valdría la pena experimentar para configurar el mismo hardware con OpenSolaris (ahora que Solaris es efectivamente demasiado costoso de usar), Linux y quizás una o dos variantes BSD, y competir con ellos. Si puede obtener algunas métricas de rendimiento (por ejemplo, el recuento de E / S de disco en una máquina virtual alojada fuera de la tienda) podría ser un artículo blanco o un artículo de Internet interesante. (Si tienes el tiempo.)

Con respecto a NFS en general, la gente de NetApp me dijo varias veces que sus puntos de referencia mostraban que NFS solo tenía un costo de 5 a 10% en rendimiento para máquinas virtuales, y si su aplicación era lo suficientemente sensible como para que esto fuera un problema, no debería estar virtualizando En primer lugar.

Pero debo confesar que después de todo ese tiempo y lágrimas, nuestras tiendas VM de producción no local son alimentadas por iSCSI, principalmente de NetApp.

Estamos utilizando OpenSolaris 2009/06 con una configuración RAID 10 ZFS para proporcionar NFS a nuestro servidor VMWare ESXi. Funciona bastante bien para nuestras necesidades hasta ahora. Estamos utilizando unidades de tipo Raid SATA (unidades Seagate ES.2 de 1 TB). Sin embargo, todavía tenemos que hacer algunos ajustes.

Soy un gran admirador de los almacenes de datos NFS para VMware, NetApp tiene una excelente implementación.

TR-3808 compara la escala de los almacenes de datos compartidos conectados de NetApp FC, iSCSI y NFS, que es una lectura excelente.

Es posible que desee considerar el error de más de 3 años con ZFS ARC que aún persiste antes de saltar demasiado profundo con ZFS ...

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017

(¡Este es desagradable, ya que también se saldrá de los límites de VM de un hipervisor!)