☰

Desempenho lento de NFS e GFS2

tag-icon • tag-icon web-server storage nfs gfs2
Desempenho lento de NFS e GFS2

Recentemente, projetei e configurei um cluster de 4 nós para um webapp que lida muito com arquivos. O cluster foi dividido em 2 funções principais, servidor web e armazenamento. Cada função é replicada para um segundo servidor usando drbd no modo ativo/passivo. O servidor web faz uma montagem NFS do diretório de dados do servidor de armazenamento e este último também possui um servidor web rodando para servir arquivos aos clientes do navegador.

Nos servidores de armazenamento criei um GFS2 FS para armazenar os dados que estão conectados ao drbd. Escolhi o GFS2 principalmente pelo desempenho anunciado e também pelo tamanho do volume que deve ser bem alto.

Desde que entramos em produção tenho enfrentado dois problemas que considero profundamente interligados. Em primeiro lugar, a montagem NFS nos servidores web fica suspensa por cerca de um minuto e depois retoma as operações normais. Ao analisar os logs, descobri que o NFS para de responder por um tempo e gera as seguintes linhas de log:

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

Nesse caso, o travamento durou 16 segundos, mas às vezes leva 1 ou 2 minutos para retomar as operações normais.

Meu primeiro palpite foi que isso estava acontecendo devido à carga pesada da montagem do NFS e que, ao aumentar RPCNFSDCOUNTpara um valor mais alto, isso se tornaria estável. Aumentei várias vezes e aparentemente, depois de um tempo, os logs começaram a aparecer menos vezes. O valor agora está ativado 32.

Depois de investigar mais a fundo o problema, me deparei com um problema diferente, apesar das mensagens NFS ainda aparecerem nos logs. Às vezes, o GFS2 FS simplesmente trava, o que faz com que tanto o NFS quanto o servidor web de armazenamento sirvam arquivos. Ambos ficam travados por um tempo e depois retomam as operações normais. Isso não deixa rastros no lado do cliente (também não deixa NFS ... not respondingmensagens) e, no lado do armazenamento, o sistema de log parece estar vazio, mesmo que esteja rsyslogdem execução.

Os nós se conectam por meio de uma conexão não dedicada de 10 Gbps, mas não acho que isso seja um problema porque o travamento do GFS2 foi confirmado, mas se conectando diretamente ao servidor de armazenamento ativo.

Estou tentando resolver isso há algum tempo e tentei diferentes opções de configuração do NFS, antes de descobrir que o GFS2 FS também está travado.

A montagem NFS é exportada como tal:

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

E o cliente NFS é montado com:

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

Após alguns testes, essas foram as configurações que renderam mais performance ao cluster.

Estou desesperado para encontrar uma solução para isso, pois o cluster já está em modo de produção e preciso consertar isso para que isso não aconteça no futuro e não sei ao certo o que e como devo fazer o benchmarking . O que posso dizer é que isso está acontecendo devido a cargas pesadas, pois testei o cluster anteriormente e esses problemas não estavam acontecendo.

Por favor, diga-me se você precisa que eu forneça detalhes de configuração do cluster e quais você deseja que eu poste.

Como último recurso, posso migrar os arquivos para um FS diferente, mas preciso de algumas dicas sólidas sobre se isso resolverá o problema, já que o tamanho do volume é extremamente grande neste momento.

Os servidores estão hospedados por uma empresa terceirizada e não tenho acesso físico a eles.

Atenciosamente.

EDITAR 1: Os servidores são servidores físicos e suas especificações são:

  • Servidores da Web:

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

  • Armazenar:

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

Inicialmente havia uma configuração de VRack entre os servidores, mas atualizamos um dos servidores de armazenamento para ter mais RAM e ele não estava dentro do VRack. Eles se conectam por meio de uma conexão compartilhada de 10 Gbps entre eles. Observe que é a mesma conexão usada para acesso público. Eles usam um único IP (usando IP Failover) para se conectar entre eles e permitir um failover normal.

O NFS está, portanto, em uma conexão pública e não em qualquer rede privada (era antes da atualização, onde o problema ainda existia).

O firewall foi configurado e testado exaustivamente, mas desativei-o por um tempo para ver se o problema ainda ocorria, e ocorreu. Pelo que sei, o provedor de hospedagem não está bloqueando ou limitando a conexão entre os servidores e o domínio público (pelo menos sob um determinado limite de consumo de largura de banda que ainda não foi atingido).

Espero que isso ajude a descobrir o problema.

EDITAR 2:

Versões 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

Configuração do DRBD em servidores de armazenamento:

#/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;
    }
}

Configuração NFS em servidores de armazenamento:

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

(pode haver algum conflito no uso da mesma porta para LOCKD_UDPPORTe LOCKD_TCPPORT?)

Configuração 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

Ambiente de rede de armazenamento:

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

Os endereços IP são atribuídos estaticamente com as configurações de rede fornecidas:

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

e

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

Arquivo Hosts para permitir um failover NFS elegante em conjunto com a opção NFS fsid=25definida em ambos os servidores de armazenamento:

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

Como você pode ver, os erros de pacotes caíram para 0. Também executei o ping por um longo tempo sem nenhuma perda de pacotes. O tamanho do MTU é o normal 1500. Como não há VLan até o momento, este é o MTU usado para comunicação entre servidores.

O ambiente de rede dos servidores web é semelhante.

Uma coisa que esqueci de mencionar é que os servidores de armazenamento lidam com aproximadamente 200 GB de novos arquivos todos os dias através da conexão NFS, o que é um ponto chave para eu pensar que isso é algum tipo de problema de carga pesada com NFS ou GFS2.

Se você precisar de mais detalhes de configuração, por favor me diga.

EDITAR 3:

Hoje cedo tivemos uma grande falha no sistema de arquivos no servidor de armazenamento. Não consegui obter os detalhes da falha imediatamente porque o servidor parou de responder. Após a reinicialização, percebi que o sistema de arquivos estava extremamente lento e não consegui servir um único arquivo por meio de NFS ou httpd, talvez devido ao aquecimento do cache ou algo assim. Mesmo assim, tenho monitorado o servidor de perto e apareceu o seguinte erro no dmesg. A origem do problema é claramente o GFS, que está esperando por um locke acaba morrendo de fome depois de um tempo.

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:

Eu instalei o munin e tenho alguns dados novos sendo lançados. Hoje houve outro travamento e Munin me mostrou o seguinte: o tamanho da tabela de inodes chega a 80k pouco antes do travamento e depois cai repentinamente para 10k. Tal como acontece com a memória, os dados em cache também caem repentinamente de 7 GB para 500 MB. A média de carga também aumenta durante o travamento e o uso do drbddispositivo também aumenta para valores em torno de 90%.

Comparando com um travamento anterior, esses dois indicadores se comportam de forma idêntica. Isso pode ser devido ao mau gerenciamento de arquivos no lado do aplicativo que não libera manipuladores de arquivos ou talvez a problemas de gerenciamento de memória provenientes do GFS2 ou NFS (o que duvido)?

Obrigado por qualquer feedback possível.

EDITAR 5:

Uso da tabela Inode de Munin:

Uso de memória de Munin:

Responder1

Só posso fornecer algumas dicas gerais.

Primeiro, eu colocaria algumas métricas de benchmark simples em funcionamento. Pelo menos você saberá se as mudanças que está fazendo são para melhor.

  • Munin
  • Cactos

  • Nagios

    são algumas boas escolhas.

Esses nós são servidores virtuais ou físicos, quais são suas especificações.

Que tipo de conexão de rede existe entre cada nó

A configuração do NFS está na rede privada do seu provedor de hospedagem.

Você não está limitando pacotes/portas com firewalls. Seu provedor de hospedagem está fazendo isso?

Responder2

Acho que você tem dois problemas. Em primeiro lugar, um gargalo que causa o problema e, mais importante, um tratamento inadequado de falhas pelo GFS. O GFS realmente deveria estar desacelerando a transferência até que funcione, mas não posso ajudar com isso.

Você diz que o cluster lida com aproximadamente 200 GB de novos arquivos no NFS. Quantos dados estão sendo lidos do cluster?

Eu sempre ficaria nervoso em ter uma conexão de rede para o front-end e o back-end, pois permite que o front-end interrompa "diretamente" o back-end (sobrecarregando a conexão de dados).

Se você instalar o iperf em cada uma das caixas, poderá testar o rendimento da rede disponível em qualquer ponto. Essa pode ser uma maneira rápida de identificar se você tem um gargalo na rede.

Quão pesadamente a rede é utilizada? Qual é a velocidade dos discos no servidor de armazenamento e qual configuração de ataque você está usando? Que rendimento você obtém com isso? Supondo que ele esteja rodando *nix e você tenha um momento tranquilo para testar, você pode usar hdparm

$ hdpard -tT /dev/<device>

Se você encontrar uma utilização intensa da rede, sugiro colocar o GFS em uma conexão de rede secundária e dedicada.

Dependendo de como você invadiu os 12 discos, você pode ter vários graus de desempenho e este pode ser o segundo gargalo. Também dependeria se você está usando ataque de hardware ou ataque de software.

A grande quantidade de memória que você tem na caixa pode ser de pouca utilidade se os dados solicitados estiverem espalhados por mais do que a memória total, o que parece ser. Além disso, a memória só pode ajudar nas leituras e principalmente se muitas leituras forem para o mesmo arquivo (caso contrário, ele seria expulso do cache)

Ao executar top/htop, observe iowait. Um valor alto aqui é um excelente indicador de que a CPU está apenas girando os polegares esperando por algo (rede, disco, etc.)

Na minha opinião, é menos provável que o NFS seja o culpado. Temos uma experiência bastante extensa com NFS e embora ele possa ser ajustado/otimizado - eletendepara funcionar de forma bastante confiável.

Eu estaria inclinado a estabilizar o componente GFS e então ver se os problemas com o NFS desaparecem.

Finalmente, o OCFS2 pode ser uma opção a considerar como substituto do GFS. Enquanto fazia algumas pesquisas sobre sistemas de arquivos distribuídos, fiz uma pesquisa razoável e não consigo me lembrar dos motivos pelos quais escolhi experimentar o OCFS2 - mas tentei. Talvez tenha algo a ver com o uso do OCFS2 pela Oracle para seus back-ends de banco de dados, o que implicaria em requisitos de estabilidade bastante elevados.

Munin é seu amigo. Mas muito mais importante é top/htop. vmstat também pode fornecer alguns números importantes

$ vmstat 1

e você receberá uma atualização a cada segundo sobre exatamente o que o sistema está gastando seu tempo fazendo.

Boa sorte!

Responder3

O primeiro proxy HA fronta os servidores web com Varnish ou Nginx.

Então, para o sistema de arquivos da web: Por que não usar MooseFS em vez de NFS, GFS2, é tolerante a falhas e rápido para leituras. O que você perde do NFS, GFS2 são bloqueios locais, você precisa disso para sua aplicação? Caso contrário, eu mudaria para o MooseFS e pularia os problemas do NFS, GFS2. Você precisará usar o Ucarp para HA os servidores de metadados MFS.

No MFS, defina a meta de replicação como 3

# mfssetgoal 3 /pasta

//Cristão

Responder4

Com base nos seus gráficos munin, o sistema está descartando caches, isso equivale a executar um dos seguintes:

  1. echo 2 > /proc/sys/vm/drop_caches
    1. dentries e inodes gratuitos
  2. echo 3 > /proc/sys/vm/drop_caches
    1. pagecache, dentires e inodes gratuitos

A questão é por que existe talvez uma tarefa cron persistente?

Além de 01h00 -> 12h00, eles parecem estar em intervalos regulares.

Também valeria a pena verificar cerca de meio caminho através de um pico se a execução de um dos comandos acima recriar o seu problema, no entantosemprecertifique-se de rodar à syncdireita antes de fazê-lo.

A falha straceem seu processo drbd (supondo novamente que este seja o culpado) por volta do momento de uma limpeza esperada e até a referida limpeza pode lançar alguma luz.

informação relacionada