Desempenho ruim do OpenVPN NFS

4

Eu tenho servidores de aplicativos do EC2 por trás de um balanceador de carga elástico. Todos os servidores de aplicativos têm acesso a um servidor de armazenamento compartilhado, principalmente para arquivos de cache centralizados, registro, etc. O servidor de armazenamento compartilhado implementa o NFS sobre o OpenVPN para fazer seu trabalho. Todos os servidores estão na mesma zona de disponibilidade e conversam entre si pela rede interna. No entanto, a solução de armazenamento compartilhado está levando a uma CPU e latência anormalmente altas que normalmente não existem se o armazenamento for 100% local. Ligeiras diminuições de desempenho com esta configuração são esperadas, mas neste caso a CPU subiu & a saída diminuiu em 2-3x

Então, essa é uma pergunta de 2 partes:

  1. O que posso fazer para entender melhor o que é o culpado? Eu sei que é a combinação do OpenVPN & NFS, mas posso identificar os arquivos específicos que estão sendo lidos & escrito para o mais? Ou posso dizer facilmente onde está o gargalo?

  2. Alguém tem conselho baseado puramente nas informações acima? Existe uma maneira melhor de compartilhar arquivos entre servidores em um ambiente baseado em nuvem? (Por favor, não responda com "use S3", pois isso não é um bom ajuste para requisitos de arquivos instantâneos / temporários)

Obrigado!

    
por John 23.05.2011 / 21:45

2 respostas

5

Certifique-se de que seu link-MTU para o túnel openvpn esteja configurado com precisão para que você não obtenha fragmentação duas vezes (uma no host de 8192 bytes para 1500 bytes e uma vez no openvpn de 1500 bytes para 1400 bytes ou qualquer outro). openvpn manipula a configuração da interface mtu muito mal (ativamente impede tentativas de configurar o mtu corretamente).

Verifique a latência de diferentes tamanhos de pacotes que passam e circulam pelo túnel. Plote e procure problemas.

Configure um NFS de teste fora do túnel e faça algumas medições de desempenho para isolar se o problema é ou não openvpn.

Experimente diferentes versões do NFS, TCP e UDP.

Tente ativar o armazenamento em cache agressivo e a E / S assíncrona.

O seguinte é um discurso sobre o "impedimento ativo" do openvpn WRT MTU (adicionado por "request")

Sim. Definir tun-mtu faz com que o openvpn gere WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1413). Eu não uso --mssfix ou --fragment .

Além disso, definir uma MTU estática na configuração é estúpido e propenso a erros, ela precisa ser dinâmica. Então, você usa "mtu-disc yes", certo? Bem, é claro, exceto que o valor que ele passa para o script de inicialização é off-by-14 (embora eu esteja usando o suporte a TAP para IPv6, o que pode confundi-lo misteriosamente). Então, eu preciso de /sbin/ifconfig $1 mtu $(($2-14)) up para obter o valor adequado (propriamente dito, um valor que fará com que os pacotes de túnel não sejam fragmentados ou descartados porque são muito grandes).

Eu tenho dificuldade em imaginar uma circunstância em que configurar a interface MTU com o valor correto não é uma boa ideia, pelo menos se você não tiver um conjunto de fragmentos (e você nunca deve ter um conjunto de fragmentos; você). Ele também deve alterar dinamicamente a interface MTU se, posteriormente, receber erros de fragmentos necessários devido a alterações na rede após a inicialização.

MSS é totalmente a camada de rede errada para fazer este trabalho. Se você tiver a interface MTU configurada corretamente, o Path-MTU discovery, o MSS e tudo simplesmente funcionarão. Se você não fizer isso, algumas coisas podem meio que funcionar, outras não, e quais coisas funcionam dependendo se o pacote real é enviado pelo host openvpn ou algum outro host. Ah, e não me fale sobre o que pode falhar se o MTU for assimétrico (não totalmente incomum).

Acho que o OpenVPN foi escrito por pessoas sem muita experiência com a rede e com o sysadmin e suas escolhas ruins ficaram codificadas na configuração e nas estruturas de dados / API. Eles realmente não fizeram um trabalho muito bom com configuração e integração de rede flexível e sã (este é apenas um dos vários exemplos). O triste é que é centenas de vezes melhor do que as outras soluções que me fazem um suporte ao OpenVPN. A Cisco VPN é uma ferrugem, por exemplo.

    
por 24.05.2011 / 20:46
0

Também há minhas dicas aqui: NFS sobre OpenVPN: principais impulsionadores de desempenho

e a versão completa está aqui: link

    
por 07.06.2015 / 11:06

Tags