☰

Rendimiento lento de NFS y GFS2

tag-icon • tag-icon web-server storage nfs gfs2
Rendimiento lento de NFS y GFS2

Recientemente, diseñé y configuré un clúster de 4 nodos para una aplicación web que maneja muchos archivos. El clúster se ha dividido en dos funciones principales: servidor web y almacenamiento. Cada función se replica en un segundo servidor usando drbd en modo activo/pasivo. El servidor web realiza un montaje NFS del directorio de datos del servidor de almacenamiento y este último también tiene un servidor web ejecutándose para servir archivos a los clientes del navegador.

En los servidores de almacenamiento, creé un GFS2 FS para contener los datos que están conectados a drbd. Elegí GFS2 principalmente por el rendimiento anunciado y también por el tamaño del volumen, que tiene que ser bastante alto.

Desde que entramos en producción me he enfrentado a dos problemas que creo que están profundamente conectados. En primer lugar, el montaje NFS en los servidores web sigue colgado durante aproximadamente un minuto y luego reanuda las operaciones normales. Al analizar los registros, descubrí que NFS deja de responder por un tiempo y genera las siguientes líneas de registro:

Oct 15 18:15:42 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:44 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:46 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:51 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:58 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK

En este caso, el bloqueo duró 16 segundos pero a veces se necesitan 1 o 2 minutos para reanudar las operaciones normales.

Mi primera suposición fue que esto sucedía debido a la gran carga del montaje NFS y que al aumentar RPCNFSDCOUNTa un valor más alto, esto se estabilizaría. Lo aumenté varias veces y aparentemente, después de un tiempo, los registros comenzaron a aparecer menos veces. El valor ahora está activado 32.

Después de investigar más a fondo el problema, encontré un bloqueo diferente, a pesar de que los mensajes de NFS todavía aparecen en los registros. A veces, el GFS2 FS simplemente se cuelga, lo que hace que tanto el NFS como el servidor web de almacenamiento sirvan archivos. Ambos permanecen colgados por un tiempo y luego reanudan sus operaciones normales. Esto se bloquea y no deja rastro en el lado del cliente (tampoco deja NFS ... not respondingmensajes) y, en el lado del almacenamiento, el sistema de registro parece estar vacío, aunque se rsyslogdesté ejecutando.

Los nodos se conectan a través de una conexión no dedicada de 10 Gbps, pero no creo que esto sea un problema porque el bloqueo de GFS2 está confirmado pero se conecta directamente al servidor de almacenamiento activo.

He estado tratando de resolver esto por un tiempo y probé diferentes opciones de configuración de NFS, antes de descubrir que GFS2 FS también se bloquea.

El montaje NFS se exporta como tal:

/srv/data/ <ip_address>(rw,async,no_root_squash,no_all_squash,fsid=25)

Y el cliente NFS se monta con:

mount -o "async,hard,intr,wsize=8192,rsize=8192" active.storage.vlan:/srv/data /srv/data

Después de algunas pruebas, estas fueron las configuraciones que más rendimiento le dieron al cluster.

Estoy desesperado por encontrar una solución para esto, ya que el clúster ya está en modo de producción y necesito arreglarlo para que esto no se cuelgue en el futuro y no sé con seguridad qué y cómo debería realizar la evaluación comparativa. . Lo que puedo decir es que esto sucede debido a cargas pesadas, ya que probé el clúster anteriormente y este problema no ocurría en absoluto.

Dígame si necesita que le proporcione detalles de configuración del clúster y cuál desea que publique.

Como último recurso, puedo migrar los archivos a un FS diferente, pero necesito algunos consejos sólidos sobre si esto resolverá estos problemas ya que el tamaño del volumen es extremadamente grande en este momento.

Los servidores están alojados en una empresa de terceros y no tengo acceso físico a ellos.

Atentamente.

EDITAR 1: Los servidores son servidores físicos y sus especificaciones son:

  • Servidores web:

    • Intel Bi Xeon E5606 2x4 2,13GHz
    • 24GB DDR3
    • SSD Intel 320 2 x 120 GB Raid 1

  • Almacenamiento:

    • Intel i5 3550 3,3GHz
    • 16 GB DDR3
    • 12 SATA de 2TB

Inicialmente había una configuración de VRack entre los servidores, pero actualizamos uno de los servidores de almacenamiento para que tuviera más RAM y no estaba dentro del VRack. Se conectan a través de una conexión compartida de 10 Gbps entre ellos. Tenga en cuenta que es la misma conexión que se utiliza para el acceso público. Usan una única IP (usando IP Failover) para conectarse entre ellos y permitir una conmutación por error elegante.

Por lo tanto, NFS se realiza a través de una conexión pública y no en ninguna red privada (era antes de la actualización, donde el problema aún existía).

El firewall fue configurado y probado exhaustivamente, pero lo desactivé por un tiempo para ver si el problema persistía, y así fue. Hasta donde yo sé, el proveedor de alojamiento no está bloqueando ni limitando la conexión entre los servidores y el dominio público (al menos por debajo de un umbral de consumo de ancho de banda determinado que aún no se ha alcanzado).

Espero que esto ayude a resolver el problema.

EDITAR 2:

Versiones de software relevantes:

CentOS 2.6.32-279.9.1.el6.x86_64  
nfs-utils-1.2.3-26.el6.x86_64  
nfs-utils-lib-1.1.5-4.el6.x86_64  
gfs2-utils-3.0.12.1-32.el6_3.1.x86_64  
kmod-drbd84-8.4.2-1.el6_3.elrepo.x86_64  
drbd84-utils-8.4.2-1.el6.elrepo.x86_64

Configuración de DRBD en servidores de almacenamiento:

#/etc/drbd.d/storage.res
resource storage {
    protocol C;

    on <server1 fqdn> {
            device /dev/drbd0;
            disk /dev/vg_storage/LV_replicated;
            address <server1 ip>:7788;
            meta-disk internal;
    }

    on <server2 fqdn> {
            device /dev/drbd0;
            disk /dev/vg_storage/LV_replicated;
            address <server2 ip>:7788;
            meta-disk internal;
    }
}

Configuración NFS en servidores de almacenamiento:

#/etc/sysconfig/nfs
RPCNFSDCOUNT=32
STATD_PORT=10002
STATD_OUTGOING_PORT=10003
MOUNTD_PORT=10004
RQUOTAD_PORT=10005
LOCKD_UDPPORT=30001
LOCKD_TCPPORT=30001

(¿puede haber algún conflicto al usar el mismo puerto para ambos LOCKD_UDPPORTy LOCKD_TCPPORT?)

Configuración GFS2:

# gfs2_tool gettune <mountpoint>
incore_log_blocks = 1024
log_flush_secs = 60
quota_warn_period = 10
quota_quantum = 60
max_readahead = 262144
complain_secs = 10
statfs_slow = 0
quota_simul_sync = 64
statfs_quantum = 30
quota_scale = 1.0000   (1, 1)
new_files_jdata = 0

Entorno de red de almacenamiento:

eth0      Link encap:Ethernet  HWaddr <mac address>
          inet addr:<ip address>  Bcast:<bcast address>  Mask:<ip mask>
          inet6 addr: <ip address> Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:957025127 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1473338731 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2630984979622 (2.3 TiB)  TX bytes:1648430431523 (1.4 TiB)

eth0:0    Link encap:Ethernet  HWaddr <mac address>  
          inet addr:<ip failover address>  Bcast:<bcast address>  Mask:<ip mask>
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Las direcciones IP se asignan estáticamente con las configuraciones de red dadas:

DEVICE="eth0"
BOOTPROTO="static"
HWADDR=<mac address>
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=<ip address>
NETMASK=<net mask>

y

DEVICE="eth0:0"
BOOTPROTO="static"
HWADDR=<mac address>
IPADDR=<ip failover>
NETMASK=<net mask>
ONBOOT="yes"
BROADCAST=<bcast address>

Archivo de hosts para permitir una conmutación por error NFS elegante junto con la opción NFS fsid=25configurada en ambos servidores de almacenamiento:

#/etc/hosts
<storage ip failover address> active.storage.vlan
<webserver ip failover address> active.service.vlan

Como puede ver, los errores de paquetes se redujeron a 0. También ejecuté ping durante mucho tiempo sin pérdida de paquetes. El tamaño de MTU es el normal 1500. Como ahora no hay VLan, esta es la MTU utilizada para comunicarse entre servidores.

El entorno de red de los servidores web es similar.

Una cosa que olvidé mencionar es que los servidores de almacenamiento manejan ~200 GB de archivos nuevos cada día a través de la conexión NFS, lo cual es un punto clave para pensar que se trata de algún tipo de problema de carga pesada ya sea con NFS o GFS2.

Si necesita más detalles de configuración, dímelo.

EDITAR 3:

Hoy tuvimos una falla importante en el sistema de archivos en el servidor de almacenamiento. No pude obtener los detalles del fallo de inmediato porque el servidor dejó de responder. Después del reinicio, noté que el sistema de archivos era extremadamente lento y no podía entregar un solo archivo a través de NFS o httpd, tal vez debido al calentamiento de la caché o algo así. Sin embargo, he estado monitoreando de cerca el servidor y apareció el siguiente error en dmesg. La fuente del problema es claramente GFS, que está esperando locky termina muriendo de hambre después de un tiempo.

INFO: task nfsd:3029 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
nfsd          D 0000000000000000     0  3029      2 0x00000080
 ffff8803814f79e0 0000000000000046 0000000000000000 ffffffff8109213f
 ffff880434c5e148 ffff880624508d88 ffff8803814f7960 ffffffffa037253f
 ffff8803815c1098 ffff8803814f7fd8 000000000000fb88 ffff8803815c1098
Call Trace:
 [<ffffffff8109213f>] ? wake_up_bit+0x2f/0x40
 [<ffffffffa037253f>] ? gfs2_holder_wake+0x1f/0x30 [gfs2]
 [<ffffffff814ff42e>] __mutex_lock_slowpath+0x13e/0x180
 [<ffffffff814ff2cb>] mutex_lock+0x2b/0x50
 [<ffffffffa0379f21>] gfs2_log_reserve+0x51/0x190 [gfs2]
 [<ffffffffa0390da2>] gfs2_trans_begin+0x112/0x1d0 [gfs2]
 [<ffffffffa0369b05>] ? gfs2_dir_check+0x35/0xe0 [gfs2]
 [<ffffffffa0377943>] gfs2_createi+0x1a3/0xaa0 [gfs2]
 [<ffffffff8121aab1>] ? avc_has_perm+0x71/0x90
 [<ffffffffa0383d1e>] gfs2_create+0x7e/0x1a0 [gfs2]
 [<ffffffffa037783f>] ? gfs2_createi+0x9f/0xaa0 [gfs2]
 [<ffffffff81188cf4>] vfs_create+0xb4/0xe0
 [<ffffffffa04217d6>] nfsd_create_v3+0x366/0x4c0 [nfsd]
 [<ffffffffa0429703>] nfsd3_proc_create+0x123/0x1b0 [nfsd]
 [<ffffffffa041a43e>] nfsd_dispatch+0xfe/0x240 [nfsd]
 [<ffffffffa025a5d4>] svc_process_common+0x344/0x640 [sunrpc]
 [<ffffffff810602a0>] ? default_wake_function+0x0/0x20
 [<ffffffffa025ac10>] svc_process+0x110/0x160 [sunrpc]
 [<ffffffffa041ab62>] nfsd+0xc2/0x160 [nfsd]
 [<ffffffffa041aaa0>] ? nfsd+0x0/0x160 [nfsd]
 [<ffffffff81091de6>] kthread+0x96/0xa0
 [<ffffffff8100c14a>] child_rip+0xa/0x20
 [<ffffffff81091d50>] ? kthread+0x0/0xa0
 [<ffffffff8100c140>] ? child_rip+0x0/0x20

EDITAR 4:

Instalé munin y aparecen algunos datos nuevos. Hoy hubo otro bloqueo y Munin me muestra lo siguiente: el tamaño de la tabla de inodos alcanza los 80k justo antes del bloqueo y luego cae repentinamente a 10k. Al igual que con la memoria, los datos almacenados en caché también caen repentinamente de 7 GB a 500 MB. El promedio de carga también aumenta durante el cuelgue y el uso del dispositivo drbdtambién aumenta a valores de alrededor del 90%.

En comparación con una caída anterior, estos dos indicadores se comportan de manera idéntica. ¿Puede esto deberse a una mala administración de archivos en el lado de la aplicación que no libera controladores de archivos, o quizás a problemas de administración de memoria provenientes de GFS2 o NFS (lo cual dudo)?

Gracias por cualquier posible comentario.

EDITAR 5:

Uso de la tabla de inodos de Munin:

Uso de memoria de Munin:

Respuesta1

Sólo puedo dar algunas indicaciones generales.

Primero, pondría en funcionamiento algunas métricas de referencia simples. Al menos así sabrás si los cambios que estás realizando son para mejor.

  • Munín
  • cactus

  • Nagios

    son algunas buenas opciones.

¿Son estos nodos servidores virtuales o físicos? ¿Cuáles son sus especificaciones?

¿Qué tipo de conexión de red hay entre cada nodo?

¿Está configurado NFS en la red privada de su proveedor de hosting?

No estás limitando paquetes/puertos con firewalls. ¿Tu proveedor de hosting está haciendo esto?

Respuesta2

Creo que tienes dos problemas. Un cuello de botella que causa el problema en primer lugar y, lo que es más importante, un mal manejo de fallas por parte de GFS. GFS realmente debería ralentizar la transferencia hasta que funcione, pero no puedo ayudar con eso.

Usted dice que el clúster maneja ~200 GB de archivos nuevos en el NFS. ¿Cuántos datos se leen del clúster?

Siempre me pondría nervioso tener una conexión de red para el frontend y el backend, ya que permite que el frontend rompa "directamente" el backend (sobrecargando la conexión de datos).

Si instala iperf en cada una de las cajas, puede probar el rendimiento de red disponible en cualquier punto dado. Esta puede ser una forma rápida de identificar si tiene un cuello de botella en la red.

¿En qué medida se utiliza la red? ¿Qué tan rápidos son los discos en el servidor de almacenamiento y qué configuración de raid estás usando? ¿Qué rendimiento obtienes con él? Suponiendo que esté ejecutando *nix y tenga un momento de tranquilidad para probar, puede usar hdparm

$ hdpard -tT /dev/<device>

Si encuentra un uso intensivo de la red, le sugeriría que coloque GFS en una conexión de red secundaria y dedicada.

Dependiendo de cómo haya atacado los 12 discos, puede tener distintos grados de rendimiento y este podría ser el segundo cuello de botella. También dependerá de si está utilizando un raid de hardware o un raid de software.

La gran cantidad de memoria que tiene en la caja puede ser de poca utilidad si los datos que se solicitan se distribuyen en más que su memoria total, lo que parece que es así. Además, la memoria solo puede ayudar con las lecturas y, sobre todo, si muchas de las lecturas son para el mismo archivo (de lo contrario, sería expulsado del caché).

Cuando ejecute top/htop, mire iowait. Un valor alto aquí es un excelente indicador de que la CPU simplemente está dando vueltas esperando algo (red, disco, etc.)

En mi opinión, es menos probable que NFS sea el culpable. Tenemos una experiencia bastante amplia con NFS y, si bien se puede ajustar/optimizar,tiendepara funcionar de manera bastante confiable.

Me inclinaría por estabilizar el componente GFS y luego ver si los problemas con NFS desaparecen.

Finalmente, OCFS2 puede ser una opción a considerar como reemplazo de GFS. Mientras investigaba un poco sobre sistemas de archivos distribuidos, investigué bastante y no recuerdo las razones por las que elegí probar OCFS2, pero lo hice. Quizás tuvo algo que ver con que Oracle utilizara OCFS2 para sus backends de bases de datos, lo que implicaría requisitos de estabilidad bastante altos.

Munin es tu amigo. Pero mucho más importante es top/htop. vmstat también puede darle algunos números clave

$ vmstat 1

y recibirá una actualización cada segundo sobre exactamente en qué dedica su tiempo el sistema.

¡Buena suerte!

Respuesta3

El primer proxy HA frente a los servidores web con Varnish o Nginx.

Luego, para el sistema de archivos web: ¿por qué no utilizar MooseFS en lugar de NFS, GFS2, es tolerante a fallos y rápido de lectura? Lo que pierde con NFS, GFS2, son bloqueos locales, ¿los necesita para su aplicación? Si no, cambiaría a MooseFS y me saltaría los problemas de NFS y GFS2. Necesitará utilizar Ucarp para HA los servidores de metadatos MFS.

En MFS, establezca el objetivo de replicación en 3

# mfssetgoal 3 /carpeta

//Cristiano

Respuesta4

Según sus gráficos munin, el sistema está descartando cachés, esto equivale a ejecutar uno de los siguientes:

  1. echo 2 > /proc/sys/vm/drop_caches
    1. dentries e inodos libres
  2. echo 3 > /proc/sys/vm/drop_caches
    1. caché de páginas, dentaduras postizas e inodos gratuitos

La pregunta es ¿por qué? ¿Existe tal vez una tarea cron persistente?

Aparte de las 01:00 -> 12:00, parecen estar en un intervalo regular.

Sin embargo, también valdría la pena verificar aproximadamente la mitad del pico si al ejecutar uno de los comandos anteriores se recrea el problemasiempreasegúrese de girar a la syncderecha antes de hacerlo.

De no ser así, stracesu proceso drbd (asumiendo nuevamente que este es el culpable) alrededor del momento de una purga esperada y hasta dicha purga, puede arrojar algo de luz.

información relacionada