Aqui está minha configuração: duas caixas CentOS 5.2 no VMWare ESXi 4.0. O ip da primeira caixa é 192.168.22.52 na eth0 e 192.168.99.1 na eth1. A segunda caixa executa PostgreSQL 8.3 com ip 192.168.99.2 em eth0. Aqui estão iptables paracaixa1, para box2 veja o comentário abaixo.
Configurei o encaminhamento da porta 5432 no box1 e consigo me conectar ao PostgreSQL no box2 via pgAdminIII ou psql do notebook Vista (192.168.22.1, não há outras caixas nesta sub-rede, ela possui seu próprio switch e está fisicamente isolada). O banco de dados ao qual estou me conectando tem dois esquemas, um é 'menor' (basicamente apenas uma tabela), outro é maior (cerca de 30 tabelas, 100 funções, etc.). Portanto, posso trabalhar com o esquema menor (navegue no tabela e assim por diante), mas quando tento expandir o esquema maior - o pgAdminIII congela por cerca de 20 minutos.
O log do PostgreSQL mostra que há uma consulta que demora muito:
2009-06-04 21:04:46 EEST LOG: 00000: duration: 493578.874 ms statement:
SELECT pr.oid, pr.xmin, pr.*, format_type(TYP.oid, NULL) AS typname,
typns.nspname AS typnsp, lanname, proargnames, proconfig,
pg_get_userbyid(proowner) as funcowner, description
FROM pg_proc pr
JOIN pg_type typ ON typ.oid=prorettype
JOIN pg_namespace typns ON typns.oid=typ.typnamespace
JOIN pg_language lng ON lng.oid=prolang
LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
WHERE proisagg = FALSE AND pronamespace = 2200::oid
AND typname <> 'trigger'
ORDER BY proname
Tanto o box1 quanto o box2 são clones das caixas de desenvolvimento, e a estrutura de rede original era diferente - o box2 era acessível diretamente sem encaminhamento de porta e não havia nenhum problema para acessar os bancos de dados.
Agora, se eu executar a consulta acima via psql na box2 ou na máquina 'original', ou da box1 conectando-se à box2, ela será executada imediatamente.
Durante a execução da consulta, o tcpdump no box2 diz periodicamente:
12:45:39.770609 IP 192.168.99.2.postgres > 192.168.22.1.49484: . 8760:10220(1460) ack 1 win 54
12:45:39.968496 IP 192.168.22.1.49484 > 192.168.99.2.postgres: . ack 10220 win 16425
12:45:39.968541 IP 192.168.99.2.postgres > 192.168.22.1.49484: . 10220:11680(1460) ack 1 win 54
12:45:39.968574 IP 192.168.99.2.postgres > 192.168.22.1.49484: . 11680:13140(1460) ack 1 win 54
12:45:39.969250 IP 192.168.22.1.49484 > 192.168.99.2.postgres: . ack 13140 win 16425
12:45:39.969275 IP 192.168.99.2.postgres > 192.168.22.1.49484: . 13140:17520(4380) ack 1 win 54
12:45:39.969408 IP 192.168.22.52 > 192.168.99.2: ICMP 192.168.22.1 unreachable - need to frag (mtu 1500), length 556
Fora isso, não vejo muito tráfego. O MTU em todas as interfaces ethN é 1500. O ping -l 1472 -f 192.168.99.1 do notebook funciona sem problemas.
Suspeito que estou faltando alguma coisa sobre iptables ou configuração de rede e agradeceria seu conselho.
Responder1
Algumas coisas para tentar:
Comece verificando se sua rede está se comportando bem. Supondo que você tenha gerenciado switches, observe as estatísticas da interface para incompatibilidade de velocidade/duplex ou MTU incompatível. Considere verificar/substituir o cabeamento se algo estiver apresentando erros (por exemplo: tentar executar GigE sobre Cat5 em vez de Cat5e provavelmente causará sofrimento).
Execute alguns testes para provar que você pode obter transferências wire-speed entre as duas máquinas e para a máquina externa; As transferências netcat, ftp ou http são um bom começo aqui (o scp pode ficar vinculado à CPU e, portanto, pode não ser o melhor teste).
Teste a mesma consulta localmente no servidor Postgres. Se for concluído em um prazo apropriado, você sabe que não é o banco de dados. Se não for concluído ou demorar "muito", você terá uma consulta incorreta ou outro problema de banco de dados para depurar. Certifique-se de considerar o lado de E/S de armazenamento; você pode estar saturando o que seus discos são capazes de fornecer. Verifique os gráficos de desempenho do VMware para confirmar/negar.
Supondo que funcione, desative o firewall e execute a mesma consulta no servidor postgres da "caixa1". Se isso funcionar, a conectividade VM-> VM provavelmente estará correta.
Supondo que funcione, reative o firewall e teste novamente. Se isso funcionar, então o seu problema provavelmente é externo a esse host, deixando o switch ou o host externo para depurar.
Boa sorte.
Responder2
Você está tendo um problema de MTU, mas não sei por quê. Estou tentando entender sua topologia virtual aqui.
Então, seu notebook Windows Vista está conectado à rede "local" ou à rede Internet?
Presumo que seu notebook Windows Vista esteja conectado à Internet e que você esteja acessando o endereço IP externo da "caixa 1" para usar o encaminhamento de porta na porta 5432 para chegar à "caixa 2". Se for esse o caso, o que você ganha quando tenta:
ping -l 1472 -f <endereço IP da caixa 1>
Editar: Ok - muito bom. Se desejar, execute um "ifconfig" na "caixa 1" e na "caixa 2" e examine o valor MTU em cada interface Ethernet. Eles deveriam ser todos 1500. (Estou apenas tentando entender por que a "caixa 1" disse à "caixa 2" que não poderia fragmentar um datagrama de 556 bytes vinculado ao seu notebook ...)
Editar: Zow. Ok - isso é selvagem.
Se não for pedir muito, você poderia postar o conteúdo (ou links para ele) das configurações do seu iptables na pergunta? (Estou começando a ficar perplexo aqui. O que você está descrevendo é algo que tenho feito com frequência, mas não tenho certeza de como está falhando.)
Editar: De volta com você agora. OK. Estou ficando perplexo com isso agora. A configuração do iptables não parece estar causando problemas. Vejo que você está encaminhando o UDP 5432 para a "caixa 2". Você não precisa encaminhar isso - o Postgres usa apenas TCP. Isso não vai doer nada, no entanto.
Durante sua espera de 20 minutos, você viu tráfego circulando entre o notebook Vista e a "caixa 2"? Você consegue reproduzir essa condição toda vez que se conecta?
Não que isso faça uma grande diferença, mas na cadeia FORWARD na "caixa 1", eu normalmente faria a regra de que ACEITA pacotes com RELATED,ESTABLISHED definido como a primeira regra na cadeia (para processamento de curto-circuito). Não acho que isso teria algum impacto significativo no desempenho para você.
Odeio não saber a resposta para um problema. Isso vai me manter acordado à noite.
Responder3
É concebível que uma dessas máquinas esteja tentando usar IPv6 de forma inadequada? Ou seja, você certificou-se de que o IPv6 está desativado em todos os lugares onde não deveria ser usado e, se for usado, configurado corretamente?