В недавнем обновлении (с Openstack Diablo в Ubuntu Lucid на Openstack Essex в Ubuntu Precise) мы обнаружили, что DNS-пакеты часто (почти всегда) сбрасывались через интерфейс моста (br100). Для наших хостов вычислительных узлов это Mellanox MT26428, использующий модуль драйвера mlx4_en.
Мы нашли два обходных пути для этого:
Используйте старое ясное ядро (например, 2.6.32-41-generic). Это вызывает другие проблемы, в частности отсутствие cgroups и старую версию модулей kvm и kvm_amd (мы подозреваем, что версия модуля kvm является источником наблюдаемой ошибки, когда иногда виртуальная машина будет использовать 100% ЦП). Мы занимаемся этим последние несколько месяцев, но не можем оставаться здесь навсегда.
С новыми ядрами Ubuntu Precise (3.2.x) мы обнаружили, что если мы используем sysctl для отключения netfilter на мосту (см. Настройки sysctl ниже), DNS снова начал работать отлично. Мы думали, что это решение нашей проблемы, пока не осознали, что отключение netfilter на интерфейсе моста, конечно, будет означать, что правило DNAT перенаправляет запросы виртуальных машин для сервера nova-api-metadata (то есть перенаправляет пакеты, предназначенные для 169.254. 169.254: 80 на IP-адрес вычислительного узла: 8775) будет полностью пропущен.
Короче говоря: с ядрами 3.x у нас может быть надежная сеть и сломанная служба метаданных, или у нас может быть сломанная сеть и служба метаданных, которая будет нормально работать, если бы были какие-либо виртуальные машины для обслуживания. Мы еще не нашли способ получить и то, и другое.
Кто-нибудь видел эту проблему или что-то подобное раньше? есть исправление? или указатель в правильном направлении?
Мы подозреваем, что он специфичен для драйвера Mellanox, но мы не уверены в этом (мы пробовали несколько разных версий драйвера mlx4_en, начиная с версии, встроенной в ядра 3.2.x, вплоть до последний драйвер 1.5.8.3 с веб-сайта mellanox. Драйвер mlx4_en в ядре 3.5.x от Quantal вообще не работает)
Кстати, на наших вычислительных узлах установлены материнские платы supermicro H8DGT со встроенной сетевой картой mellanox:
02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0)
мы не используем две другие сетевые карты в системе, подключены только Mellanox и карта IPMI.
Параметры sysctl моста netfilter:
net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-ip6tables = 0
С тех пор, как мы обнаружили этот обходной путь sysctl bridge-nf, мы нашли несколько страниц в сети, рекомендующих именно это (включая последнюю версию Openstack устранение неполадок сети страница и отчет об ошибке на панели запуска что связано с этим Сообщение блога там есть отличное описание проблемы и решения) .... легче найти что-то, когда вы знаете, что искать :), но мы не нашли ничего по проблеме DNAT, которую она вызывает.
Обновление 2012-09-12:
То, что я должен был упомянуть ранее - это происходит даже на машинах, на которых не установлены пакеты openstack или даже libvirt. То же оборудование, все то же самое, но не намного больше, чем базовая система Ubuntu 12.04.
В ядре 2.6.32-41-generic мост работает должным образом.
На ядре 3.2.0-29-generic, используя интерфейс Ethernet, он работает отлично. Использование моста на том же сетевом адаптере не работает, если только net.bridge.bridge-nf-call-iptables = 0
Итак, кажется довольно очевидным, что проблема либо в драйвере mellanox, либо в обновленном коде моста ядра, либо в коде netfilter. или какое-то взаимодействие между ними.
Интересно, что у меня есть другие машины (без карты mellanox) с мостовым интерфейсом, которые не демонстрируют этой проблемы. с сетевыми адаптерами от дешевых карт r8169 до более качественных карт Broadcom tg3 Gbit в некоторых серверах Sun Fire X2200 M2 и карт Intel GB в материнских платах supermicro. Как и наши вычислительные узлы openstack, все они используют интерфейсы моста в качестве основного (или иногда единственного) интерфейса с IP-адресом - они настроены таким образом, чтобы мы могли запускать виртуальные машины с использованием libvirt и kvm с реальными IP-адресами, а не с NAT.
Таким образом, это указывает на то, что проблема специфична для драйвера mellanox, хотя в сообщении в блоге, о котором я упоминал выше, была аналогичная проблема с некоторыми сетевыми адаптерами Broadcom, которые использовали драйвер bnx2.