LINUX.ORG.RU
решено Форум — Admin  

Странные глюки с сетью в LXC-контейнере с Ubuntu 13.10

 , ,


0

2

Собственно, есть машина с хостовой Ubuntu 12.04 LTS. Под ней штук 8 контейнеров. Gentoo, Ubuntu 12.04 LTS и Ubuntu 12.10 в контейнерах работают отлично, никаких вопросов. Но нужен контейнер с 13.10. И вот тут возник какой-то странный глюк.

Во-первых, в таблицы роутинга не прописывается шлюз по умолчанию. При чём проблема эта, как оказалось, не только у меня одного и не только с последней Ubuntu. В свежем Debian'е также. Сам не понял, в чём дело, на форумах народ занимается чистой магией по ручному прописыванию route default gw при старте системы или подъёме интерфейса. Ладно, я не гордый, тоже так сделал. Сеть с виду как живая. Но!

Контейнер мне нужен не сам по себе, а как web-сайт. На хосте стоит nginx, который проксирует заданный виртхост на внутренний адрес контейнера. И вот тут порылась собака. Почему-то контейнер отдаёт контент (своим nginx) для части запросов с ровно минутной задержкой. Очень похоже на проблемы с разрешением доменных имён или ещё чем-то в таком духе. Однако, DNS внутри контейнера работает как надо. Вообще, с виду всё работает. Но вот эта задержка непонятная... При чём пофиг, nginx внутри или redmine. При обращении снаружи — задержка. Но не на все запросы. С некоторыми всё ок, мгновенно отдаются. Логики никакой не вижу. Внутри контейнера тоже всё мгновенно отдаётся. С другими версиями ОС в контейнерах, как писал, тоже всё ок.

Видел пару жалоб на такое поведение 13.10 (или вообще, что после апгрейда на неё в контейнере всё ломается), но без разрешения. Советуют тупо даунгрейдиться.

Что ещё интересно: на машине с хостовой Gentoo, гостевая Ubuntu 13.10 в контейнере, вроде, работает тоже без проблем.

Есть мысли, в какую сторону покопать? Даунгрейд, конечно, вариант, но не интересный. Хочется именно 13.10. Ведь, блин, можно же как-то придумать, наверное, как найти что тормозит конкретно?

★★★★★
← а как в этих ваших новомодных инитах с проверкой перед запуском?
Почтовый сервер не шлет почту. →

lxc какой версии ?

конфиг сети контейнера покажи.

Принципиально есть 2 пути

1) всю сеть (ip & gw) настраивать в lxc, а в контейнере ее не трогать

2) в lxc только создать сетевой интерфейс, а все настройки его делать в контейнере, как на обычной системе.

vel ★★★★★
()
Ответ на: комментарий от getup

tcpdump внутри контейнера не смотрел?

А на что внимание обращать?

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от vel

lxc какой версии ?

1.0.1

конфиг сети контейнера покажи.

Сейчас — так:

auto lo
iface lo inet loopback

iface eth0 inet static
    address 10.0.3.78
    netmask 255.255.255.0
    dns-nameservers 8.8.8.8

А, вообще, по-разному пробовал. И с dhcp, и с явным указанием gateway. Разницы никакой (кроме случаев, когда сеть вообще не стартовала)

Аналогичные конфиги (вообще, пробовал 1 в 1 переносить, кроме IP-адреса) в других контейнерах, с другими версиями Ubuntu — работают.

Принципиально есть 2 пути

Пробовал оба варианта.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

я про config от lxc (lxc.network.*), а не про настройки внктри контейнера.

Во-первых, в таблицы роутинга не прописывается шлюз по умолчанию

где именно? в config lxc или сам контейнер его не может прописать?

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

я про config от lxc

# Network configuration
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0

# ------------------------------
# networking
lxc.network.ipv4 = 10.0.3.78/24
lxc.network.ipv4.gateway = 10.0.3.1
lxc.network.veth.pair = apdev
# ------------------------------

где именно? в config lxc или сам контейнер его не может прописать?

Прикол в том, что в других версиях ОС в контейнере я понятия не имею, как gw прописывается. Он просто есть. Хоть с dhcp, хоть со статической конфигурацией, даже если gateway не указан в lxc-конфиге.

А в 13.10 внутри контейнера route пишет только сеть 10.x.x.x и всё. Шлюза по умолчанию нет ни в каком варианте конфигурации. Как уже писал, похоже, это массовое явление. В форумах и блогах народ тупо прописывает шлюз вручную...

...

Хрень какая-то. Вчера находил штук 5 статей/ответов с похожими темами, а сейчас ни одной найти не могу o_O Запрос, вроде, такой же, как вчера, в духе «lxc ubuntu 13.10 default gateway».

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Шлюза по умолчанию нет ни в каком варианте конфигурации. Как уже писал, похоже, это массовое явление. В форумах и блогах народ тупо прописывает шлюз вручную...

так достаточно сделать интерфейсу down & up и все маршруты связанные с этим интерфейсом сбросятся.

дык зайти на этот контейнер через lxc-console и посмотреть, что там с сетью. IMHO при работе внутри контейнера нужно убирать из стартовых скриптов практически все связанное с определением оборудования.

У тебя сетевой интерфейс veth - заначит проблемы сеть тебе может создавать мост. Если на нем включено stp, то появляются задержки при старте.

Что плохо в lxc - нельзя задать аппаратные адреса для veth - они каждый раз при старте контейнера будут менятся :(

ps *ubuntu живьем видел 1 раз, так что как там сеть конфигурируется - без понятия. Оно случаем не на systemd ?

vel ★★★★★
()
Ответ на: комментарий от vel

дык зайти на этот контейнер через lxc-console и посмотреть, что там с сетью

Я же пишу — сеть работает, всё отлично. Только в route прописан один путь — на локальный гейт. Он и пингуется, как и локальная подсетка. Ротинг же дефолтовый просто отсутствует. Если добавить его — всё начинает работать. Кроме непонятных таймаутов, с которых и началась тема.

У тебя сетевой интерфейс veth - заначит проблемы сеть тебе может создавать мост.

Сеть работает.

Оно случаем не на systemd ?

Слава богу, ещё нет :) Конфигурируется также, как и много лет назад. С такой же конфигурацией работает как на реальном железе (13.10, три машины), так и в контейнерах (12.04 LTS, больше десятка контейнеров). Проблема именно с 13.10 и в контейнере. При чём проблема странная. Часть запросов работает идеально, а вот часть — зависает на минуту. Из того, с чем лезу в контейнер, ssh работает прекрасно, а вот nginx или redmine отдают контент с описанными задержками для части запросов.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

дык так логирование access.log error.log с обеих сторон даст больше информации о причинах задержки

anonymous
()
Ответ на: комментарий от KRoN73

А в логах ядра есть что-нубудь интересное ?

А если tcpdump запустить и подождать ответ с задержкой ? Или запустить nginx в 1 worker и strace на него натравить?

Что за ядро на хосте ?

vel ★★★★★
()
Ответ на: комментарий от vel

А в логах ядра есть что-нубудь интересное ?

Нету. Там, вообще, за прошлую ночь экспериментов ни одной записи.

А если tcpdump запустить и подождать ответ с задержкой ?

Так на что глядеть-то там?

Что за ядро на хосте ?

Linux htz 3.8.0-36-generic #52~precise1-Ubuntu SMP Mon Feb 3 21:54:46 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

А если tcpdump запустить и подождать ответ с задержкой ?

Так на что глядеть-то там?

Понять на какой стади возникает пауза и нет ли в этот момент попытки что-то отрезолвить.

Я пока не совсем понял про задержки. Они возникают при определенных запросах или в какой-то случайный момент[ы] времени ?

Проблема со шлюзом может дать задержку при первых запросах после старта контейнера, да и если на мосте fd не 0, то при старте тоже будут задержки, но потом все должно работать без задержек.

На хосте стоит nginx, который проксирует заданный виртхост на внутренний адрес контейнера

Вопрос - с хоста на контейнер соединение устанавливается сразу, а ответ задерживается или с хоста долго не могут сконнектиться с контейнером? proxy_connect_timeout как раз 60 c.

Если коннект в контейнер приходит с адреса из непосредственно подключенной сети, то отсутствие dgw на работу не будет влиять.

Если таймауты выкрутить на минимум, то будет видно в какой момент наступает пауза.

У меня почему-то сложилось предвзятое отношение к ядрам 3.7-3.9. Там очень много меняли и ломали. Я практически уверен, что если заменить это 3.8 на 3.4.последнее или 3.12.14, то хуже точно не станет. В новых ядрах активно чинили cgroups и разные namespaces.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

Блин! Ларчик просто открывался :D Спасибо за наводящие вопросы, решение нашёл при _внимательном_ изучении логов nginx на хосте. До этого видел там только «connection timeout» и дальше не всматривался.

А сейчас просёк, что отвалившиеся запросы там идут на совсем левый адрес.

Оказалось, что у меня в hosts (а он большой :D) для внутреннего адреса гостевого контейнера две записи. Первая — правильная. При обращении по ssh и первом запросе через nginx, запрос идёт через неё и поэтому с виду всё ок.

При части следующих запросов nginx обращается через второй, некорректный IP. Забавно, я думал, что через /etc/hosts всегда работает только один IP (первый или второй — не вдавался).

Ещё сбивало с толку то, что у меня прописано proxy_read_timeout 10s; А отваливалось через 60 сек. Перепутал с proxy_connect_timeout.

Всем спасибо, всё заработало :)

KRoN73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← а как в этих ваших новомодных инитах с проверкой перед запуском?
Admin
Почтовый сервер не шлет почту. →