Вот моя установка: две коробки CentOS 5.2 на VMWare ESXi 4.0. Первый IP-адрес коробки - 192.168.22.52 на eth0 и 192.168.99.1 на eth1. Второй ящик запускает PostgreSQL 8.3 с ip 192.168.99.2 на eth0. Вот iptables для box1, относительно box2 см. комментарий ниже.
Я настроил переадресацию порта 5432 на box1 и могу подключиться к PostgreSQL на box2 через pgAdminIII или psql из ноутбука Vista (192.168.22.1, других ящиков в этой подсети нет, он имеет собственный переключатель и физически изолирован). База данных, к которой я подключаюсь, имеет две схемы: одна «меньше» (в основном одна таблица), другая больше (около 30 таблиц, 100 функций и т. Д.). Таким образом, я могу работать с меньшей схемой (просмотрите table и так далее), но когда я пытаюсь расширить более крупную схему, pgAdminIII зависает на 20 минут или около того.
Журнал PostgreSQL показывает, что запрос занимает слишком много времени:
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
И box1, и box2 являются клонами модулей разработки, и исходная структура сети была другой - box2 был доступен напрямую без переадресации портов, и никаких проблем с доступом к базам данных не возникало.
Теперь, если я запускаю вышеуказанный запрос через psql на box2 или «исходном» компьютере или из box1, подключающегося к box2, он выполняется немедленно.
Во время выполнения запроса tcpdump на box2 периодически сообщает:
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
В остальном я не вижу большого трафика. MTU на всех интерфейсах ethN - 1500. ping -l 1472 -f 192.168.99.1 с ноутбука проходит без проблем.
Я подозреваю, что мне что-то не хватает об iptables или настройке сети, и был бы признателен за ваш совет.
Некоторые вещи, которые стоит попробовать:
Начните с проверки того, что ваша сеть работает нормально. Предполагая, что вы управляли коммутаторами, посмотрите статистику интерфейса на предмет несовпадения скорости / дуплекса или несоответствия MTU. Подумайте о проверке / замене кабелей, если что-то работает с ошибками (например: попытка запустить GigE через Cat5 вместо Cat5e, скорее всего, приведет к огорчению).
Выполните несколько тестов, чтобы убедиться, что вы можете передавать данные со скоростью провода между двумя машинами и на внешнюю машину; Передача по netcat, ftp или http - хорошее начало (scp может быть привязан к ЦП и, следовательно, может быть не лучшим тестом).
Протестируйте тот же запрос локально на сервере Postgres. Если он завершится в подходящие сроки, вы знаете, что это не база данных. Если он не завершается или занимает «слишком много времени», значит, у вас плохой запрос или другая проблема с базой данных для отладки. Обязательно учитывайте аспекты ввода-вывода хранилища; вы можете насыщать то, что способны предоставить ваши диски. Проверьте графики производительности VMware, чтобы подтвердить / опровергнуть.
Предполагая, что это работает, отключите брандмауэр и выполните тот же запрос к серверу postgres из "box1". Если это сработает, скорее всего, подключение ВМ-> ВМ в порядке.
Предполагая, что это работает, снова включите брандмауэр и проверьте его снова. Если это сработает, то ваша проблема, скорее всего, является внешней по отношению к этому хосту, поэтому коммутатор или внешний хост остается для отладки.
Удачи.
Возможно ли, что одна из этих машин пытается ненадлежащим образом использовать IPv6? То есть удостоверились ли вы, что IPv6 отключен везде, где его нельзя использовать, и, если он вообще используется, правильно настроен?
У вас проблема с MTU, но я не уверен, почему. Я пытаюсь осмыслить вашу виртуальную топологию.
Итак, ваш ноутбук с Windows Vista подключен к «локальной» сети или к Интернету?
Я предполагаю, что ваш ноутбук с Windows Vista подключен к Интернету и вы обращаетесь к внешнему IP-адресу «коробки 1», чтобы использовать переадресацию порта на порту 5432 для перехода к «ящику 2». Если это так, что вы получите в ответ, если попытаетесь:
ping -l 1472 -f <IP-адрес коробки 1>
Изменить: Хорошо - очень хорошо. Если хотите, запустите «ifconfig» как в «поле 1», так и в «поле 2» и проверьте значение MTU на каждом интерфейсе Ethernet. Все они должны быть 1500. (Я просто пытаюсь понять, почему «ящик 1» сообщил «ящику 2», что он не может фрагментировать 556-байтовую датаграмму, привязанную к вашей записной книжке ...)
Изменить: Zow. Ладно - это дико.
Если нечего спрашивать, не могли бы вы опубликовать содержимое (или ссылки на него) ваших конфигураций iptables в вопросе? (Я начинаю теряться здесь. То, что вы описываете, я делал часто, но не знаю, как это ломается.)
Изменить: Вернемся к вам сейчас. Ладно. Я сейчас озадачен этим. Конфигурация iptables не выглядит так, как будто она должна вызывать какие-либо проблемы. Я вижу, что вы перенаправляете UDP 5432 в «ящик 2». Вам не нужно пересылать это - Postgres использует только TCP. Хотя это никому не повредит.
Во время 20-минутного ожидания вы видели, как трафик перемещается между ноутбуком Vista и «ящиком 2»? Можете ли вы воспроизводить это состояние каждый раз при подключении?
Не то чтобы это имеет большое значение, но в цепочке FORWARD в «коробке 1» я обычно делаю правило, согласно которому ACCEPT пакеты со значением RELATED, ESTABLISHED установлено как первое правило в цепочке (для обработки короткого замыкания). Я не думаю, что это окажет на вас какое-либо значительное влияние на производительность.
Ненавижу незнание ответа на проблему. Это не даст мне уснуть по ночам.