OpenStack, мостовое соединение, netfilter и dnat
В недавнем обновлении (от 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% CPU). Мы работали с этим последние несколько месяцев, но не можем оставаться здесь вечно.
С более новыми ядрами Ubuntu Precise (3.2.x) мы обнаружили, что если мы используем sysctl для отключения netfilter на мосте (см. Настройки sysctl ниже), то DNS снова заработал идеально. Мы думали, что это решение нашей проблемы, пока не осознали, что отключение сетевого фильтра на интерфейсе моста, разумеется, будет означать, что правило 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.
Настройки моста netfilter sysctl:
net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-ip6tables = 0
С момента обнаружения этого обходного пути для bridge-nf sysctl мы нашли несколько страниц в сети, которые рекомендуют именно это (включая последнюю страницу устранения неполадок в сети 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 и заканчивая более качественными широковещательными картами tg3 Gbit на некоторых серверах Sun Fire X2200 M2 и картами Intel gb на материнских платах supermicro. Как и наши вычислительные узлы openstack, все они используют мостовые интерфейсы в качестве основного (или иногда единственного) интерфейса с IP-адресом - они настроены таким образом, что мы можем запускать виртуальные машины, используя libvirt & kvm с реальными IP-адресами, а не NAT.
Таким образом, это указывает на то, что проблема связана с драйвером mellanox, хотя в упомянутом выше посте блога была похожая проблема с некоторыми сетевыми платами, которые использовали драйвер bnx2.