Aquí está mi configuración: dos cajas CentOS 5.2 en VMWare ESXi 4.0. La IP del primer cuadro es 192.168.22.52 en eth0 y 192.168.99.1 en eth1. El segundo cuadro ejecuta PostgreSQL 8.3 con ip 192.168.99.2 en eth0. Aquí hay iptables paracaja1, para el cuadro 2, consulte el comentario a continuación.
Configuré el reenvío del puerto 5432 en box1 y puedo conectarme a PostgreSQL en box2 a través de pgAdminIII o psql desde una computadora portátil Vista (192.168.22.1, no hay otros cuadros en esta subred, tiene su propio conmutador y está físicamente aislado). La base de datos a la que me estoy conectando tiene dos esquemas, uno es "más pequeño" (básicamente solo una tabla), otro es más grande (unas 30 tablas, 100 funciones, etc.). Así que puedo trabajar con el esquema más pequeño (examinar el tabla, etc.), pero cuando intento expandir el esquema más grande, pgAdminIII se congela durante aproximadamente 20 minutos.
El registro de PostgreSQL muestra que hay una consulta que lleva demasiado tiempo:
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 box1 como box2 son clones de las cajas de desarrollo, y la estructura de red original era diferente: se podía acceder directamente a box2 sin reenvío de puertos y no hubo ningún problema para acceder a las bases de datos.
Ahora, si ejecuto la consulta anterior a través de psql en box2 o en la máquina 'original', o desde box1 conectándome a box2, se ejecuta inmediatamente.
Durante la ejecución de la consulta, tcpdump en box2 dice periódicamente:
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
Aparte de eso, no veo mucho tráfico. MTU en todas las interfaces ethN es 1500. ping -l 1472 -f 192.168.99.1 desde la computadora portátil se realiza sin problemas.
Sospecho que me falta algo sobre iptables o la configuración de red y agradecería su consejo.
Respuesta1
Algunas cosas para probar:
Comience verificando que su red se esté comportando bien. Suponiendo que tiene conmutadores administrados, observe las estadísticas de la interfaz para detectar discrepancias de velocidad/dúplex o una MTU no coincidente. Considere verificar/reemplazar el cableado si hay errores (por ejemplo: intentar ejecutar GigE sobre Cat5 en lugar de Cat5e probablemente le causará problemas).
Realice algunas pruebas para demostrar que puede realizar transferencias a velocidad de cable entre las dos máquinas y hacia la máquina externa; Las transferencias netcat, ftp o http son un buen comienzo aquí (scp puede limitar la CPU y, por lo tanto, puede no ser la mejor prueba).
Pruebe la misma consulta localmente en el servidor Postgres. Si se completa en un plazo adecuado, sabrá que no es la base de datos. Si no se completa o tarda "demasiado tiempo", entonces tiene una consulta incorrecta u otro problema de base de datos que depurar. Asegúrese de considerar el lado de E/S de almacenamiento; puede que estés saturando lo que tus discos son capaces de proporcionar. Consulte los gráficos de rendimiento de VMware para confirmar/negar.
Suponiendo que funcione, desactive el firewall y ejecute la misma consulta en el servidor postgres desde "box1". Si eso funciona, la conectividad VM->VM probablemente esté bien.
Suponiendo que funcione, vuelva a activar el firewall y vuelva a realizar la prueba. Si eso funciona, entonces su problema probablemente sea externo a ese host, dejando que el conmutador o el host externo se depure.
Buena suerte.
Respuesta2
Tienes un problema de MTU, pero no estoy seguro de por qué. Estoy tratando de entender su topología virtual aquí.
Entonces, ¿su computadora portátil con Windows Vista está conectada a la red "local" o a la red de Internet?
Supongo que su computadora portátil con Windows Vista está conectada a Internet y que está accediendo a la dirección IP externa de la "caja 1" para usar el reenvío de puerto en el puerto 5432 para llegar a la "caja 2". Si ese es el caso, ¿qué obtienes a cambio cuando intentas:
ping -l 1472 -f <cuadro 1 dirección IP>
Editar: Está bien, muy bien. Si lo desea, ejecute un "ifconfig" tanto en la "caja 1" como en la "caja 2" y examine el valor de MTU en cada interfaz Ethernet. Todos deberían ser 1500. (Solo estoy tratando de entender por qué el "cuadro 1" le dijo al "cuadro 2" que no podía fragmentar un datagrama de 556 bytes destinado a su computadora portátil...)
Editar: Zow. Vale... eso es una locura.
Si no es mucho pedir, ¿podría publicar el contenido (o enlaces a ellos) de sus configuraciones de iptables en la pregunta? (Estoy empezando a quedarme perplejo. Lo que estás describiendo es algo que he hecho con frecuencia, pero no estoy seguro de cómo se está descomponiendo).
Editar: Vuelvo contigo ahora. Bueno. Me estoy quedando perplejo con esto ahora. No parece que la configuración de iptables deba causar ningún problema. Veo que estás reenviando UDP 5432 al "cuadro 2". No es necesario reenviar eso: Postgres solo usa TCP. Aunque eso no hará daño a nada.
Durante su espera de 20 minutos, ¿vio tráfico entre la computadora portátil Vista y la "caja 2"? ¿Puedes reproducir esa condición cada vez que te conectas?
No es que haga una gran diferencia, pero en la cadena ADELANTE en el "cuadro 1", normalmente establecería la regla que ACEPTA paquetes con RELACIONADO, ESTABLECIDO configurado como la primera regla en la cadena (para cortocircuitar el procesamiento). Sin embargo, no creo que esto tenga un impacto significativo en el rendimiento para usted.
Odio no saber la respuesta a un problema. Esto me mantendrá despierto por la noche.
Respuesta3
¿Es concebible que una de estas máquinas esté intentando utilizar IPv6 de forma inapropiada? Es decir, ¿se ha asegurado de que IPv6 esté desactivado en todos los lugares donde no se debe usar y, si se usa, esté configurado correctamente?