Soy un usuario de un clúster que utiliza NFS para nuestras necesidades de almacenamiento de datos. Recientemente, he estado ejecutando una canalización que tiene una E/S muy alta durante algunas operaciones.
El programa que creemos que está causando el problema se llama Bowtie, un alineador en tuberías bioinformáticas. En definitiva tenemos secuencias alfabéticas en archivos fragmentados de 1 millón de líneas por archivo que se comparan con otro archivo que contiene el diccionario completo. (Esta es una simplificación excesiva del algoritmo)
Este diccionario se asigna en memoria durante el procedimiento. Tengo derechos de envío de colas para tres nodos del clúster.
Nodos: Nodo1 Nodo2 Nodo3 Nodo4 Nodo5 Nodo6 Nodo7
Mi derecho: Nodo1 Nodo2 Nodo3
Número de procesadores disponibles para mí: 128 procesadores o 128 ranuras de cola en ejecución.
Para ejecutarse en el clúster, el archivo principal se divide en fragmentos de 1 millón de líneas cada uno y luego todos los trabajos se inician utilizando SGE.
El Diccionario en este punto se carga en la memoria de cada nodo, es decir, Nodo1, 2 y 3.
Para cada trabajo activo en la ranura de la cola, tengo abiertos los siguientes controladores de archivos
1 archivo de trabajo que contiene el código a ejecutar 1 archivo de código que contiene el código de salida del proceso 1 archivo STDOUT generado por SGE 1 archivo STDERR generado por SGE 1 fragmento de archivo 1 archivo de salida
Lo que significa que durante este proceso tengo 768+3 controladores de archivos abiertos en el almacenamiento de datos remoto, aunque los primeros cuatro archivos son constantes para cada script en proceso.
Siempre que esto sucede, el servidor NFS en el almacenamiento de datos falla y todo nuestro clúster deja de funcionar porque el almacenamiento deja de responder.
Nuestro personal de TI ha sugerido que esto puede deberse a una alta E/S durante este proceso y posiblemente NFS solo estuvo destinado a clústeres pequeños, no a grandes escalas.
Por lo tanto, hemos trabajado para encontrar una solución en la que planeamos ejecutar este proceso en uno de los Nodos. Pero entonces se anula el objetivo de tener un clúster a nuestra disposición porque estaríamos escribiendo en el disco del Nodo y no en el almacenamiento de datos compartido entre todos los clústeres.
No creo que NFS se haya creado para clústeres de pequeña escala y que nunca se haya implementado con éxito en soluciones de gran escala empresarial. ¿Puede existir otra razón por la cual NFS interrumpe repentinamente la conexión de red?
Estoy seguro de que el proceso en cuestión es la causa de la congelación del clúster, pero no estoy convencido de que la velocidad de lectura/escritura que exige sea la causa del error. ¿Alguno de ustedes ha experimentado un problema de este tipo anteriormente? ¿Es una migración completa del protocolo la única solución que tenemos?
Respuesta1
Algunas sugerencias aprendidas a lo largo de los años.
- Minimice la carga en el servidor NFS:
configurar las opciones de exportación NFS:async,insecure,no_subtree_check
establecer opciones de montaje NFSsoft,noatime,nodiratime,nolock,vers=3
también configurado: noatime,nodiratimeen montajes de datos/tmp/scratch. Asegúrese de que el cifrado NFS esté desactivado para reducir la carga. Detenga el proceso de bloqueo de NFS.
Intente habilitar las tramas JUMBO para la red en todos los hosts (si el equipo de red las admite): configure MTU en 9k aproximadamente.
Asegúrese de que se utilice el almacenamiento raid10 (evite raid5/6 a TODO costo) para IO de escritura aleatoria. ¿Algún SSD?
Maximice la cantidad de identificadores de FS abiertos (el valor predeterminado es 2K en algunos sistemas), configúrelo en 1M aproximadamente.
¿Alguna posibilidad de copiar la base de datos de mapeo con datos de entrada al almacenamiento del nodo temporal local y luego combinar/ordenar los archivos sam resultantes como un paso separado?
Aumente el tamaño del fragmento procesado (para que se procese durante al menos 30 minutos o más).
Si es posibledividir los trabajos en el nivel más alto posible(intente mapear/clasificar 10 genomas/muestras separadas en 10 nodos diferentes en paralelo, en lugar de intentar mapear cada genoma en serie usando 10 hosts). Intente establecer puntos de control una vez que todos los procesos hayan finalizado.
Modifique la fuente de un programa para que lea datos en fragmentos más grandes, como 1 M en lugar de 4k.
Tenga en cuenta la disputa de interconexión CPU/RAM (especialmente en sistemas AMD de 4 a 8 sockets), a veces ejecutar de 12 a 24 subprocesos en una caja de 48 núcleos es mucho más rápido que 48 subprocesos. Pruebe diferentes niveles de utilización. Asegúrese de que NUMA esté encendido y configurado para sistemas con múltiples CPU. Vuelva a compilar con NUMA habilitado.
PD: Gestionar un clúster eficiente es similar a planificar/administrar una obra de construcción con más de 1.000 trabajadores...