Em uma atualização recente (do Openstack Diablo no Ubuntu Lucid para o Openstack Essex no Ubuntu Precise), descobrimos que os pacotes DNS eram freqüentemente (quase sempre) descartados na interface da ponte (br100). Para nossos hosts de nó de computação, esse é um Mellanox MT26428 usando o módulo de driver mlx4_en.
Encontramos duas soluções alternativas para isso:
Use um kernel antigo e lúcido (por exemplo, 2.6.32-41-generic). Isto causa outros problemas, em particular a falta de cgroups e a versão antiga dos módulos kvm e kvm_amd (nós suspeitamos que a versão do módulo kvm é a fonte de um bug que estamos vendo onde ocasionalmente uma VM usará 100% da CPU). Nós corremos com isso nos últimos meses, mas não podemos ficar aqui para sempre.
Com os novos kernels do Ubuntu Precise (3.2.x), descobrimos que se usarmos sysctl para desabilitar o netfilter na bridge (veja as configurações sysctl abaixo), o DNS começou a funcionar perfeitamente novamente. Nós pensamos que esta era a solução para o nosso problema até percebermos que desligar o netfilter na interface da bridge significa, é claro, que a regra DNAT redireciona as requisições de VM para o servidor nova-api-metadata (ie redirecionar pacotes destinados a 169.254. 169.254: 80 para computar-node-IP: 8775) será completamente ignorado.
Resumindo: com os kernels 3.x, podemos ter uma rede confiável e um serviço de metadados quebrado ou podemos ter uma rede quebrada e um serviço de metadados que funcionaria bem se houvesse VMs para atender. Ainda não encontramos uma maneira de ter os dois.
Alguém viu este problema ou algo assim antes? tem uma correção? ou um ponteiro na direção certa?
Nossa suspeita é de que é específico para o driver Mellanox, mas não temos certeza disso (já testamos várias versões diferentes do driver mlx4_en, começando com a versão embutida nos kernels 3.2.x. até o driver 1.5.8.3 mais recente no site da mellanox. O driver mlx4_en no kernel 3.5.x do Quantal não funciona de todo)
BTW, nossos nós computacionais têm placas-mãe supermicro H8DGT com NIC mellanox integrada:
02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0)
não estamos usando as outras duas NICs no sistema, apenas a Mellanox e a placa IPMI estão conectadas.
Configurações de sysctl do Bridge netfilter:
net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-ip6tables = 0
Desde que descobrimos essa solução sysctl de bridge-nf, encontramos algumas páginas na rede recomendando exatamente isso (incluindo as mais recentes do Openstack solução de problemas de rede e um relatório de erros da barra de lançamento ligada a esta postagem no blog que tem uma ótima descrição do problema e a solução) .... é mais fácil encontrar coisas quando você sabe o que procurar :), mas não encontramos nada sobre o problema DNAT que causa.
Atualização 2012-09-12:
Algo que eu deveria ter mencionado anteriormente - isso acontece até em máquinas que não têm nenhum pacote openstack ou mesmo libvirt instalado. O mesmo hardware, o mesmo tudo, mas com pouco mais do que o sistema básico do Ubuntu 12.04 instalado.
No kernel 2.6.32-41-generic, a ponte funciona como esperado.
No kernel 3.2.0-29-genérico, usando a interface ethernet, funciona perfeitamente. Usar uma ponte nesse mesmo NIC falha a menos que net.bridge.bridge-nf-call-iptables = 0
Portanto, parece bastante claro que o problema está no driver mellanox, no código de ponte do kernel atualizado, no código do netfilter. ou alguma interação entre eles.
Curiosamente, tenho outras máquinas (sem um cartão mellanox) com uma interface de ponte que não apresentam esse problema. com NICs que variam de cartões r8169 baratos a cartões G6 broadcom tg3 de melhor qualidade em alguns servidores Sun Fire X2200 M2 e placas intel gb em placas-mãe supermicro. Como nossos nós de computação openstack, todos eles usam as interfaces de ponte como sua principal (ou às vezes apenas) interface com um endereço IP - eles são configurados dessa maneira para que possamos executar VMs usando libvirt & kvm com endereços IP reais em vez de NAT.
Então, isso indica que o problema é específico para o driver mellanox, embora o post do blog mencionado acima tenha um problema semelhante com algumas placas de rede broadcom que usaram o driver bnx2.