OpenVZ Forum


Home » International » Russian » Временное повисание HN при останоке VE.
icon3.gif  Временное повисание HN при останоке VE. [message #40338] Wed, 11 August 2010 18:04 Go to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: *static.corbina.ru
HN: 2хL5520, 12 ГБ, CentOS 5.5 x86_64.
VE: CentOS 5.5 x86.
ovzkernel: 2.6.18-194.8.1.el5.028stab070.2xen
vzctl: vzctl-3.0.24.1-1

VE создан по шаблону basic. В VE запущен стандартный набор служб: sshd, xinetd, sendmail, crond, saslauthd.
Никаких виртуалок Xen не запущено.
Сеть HN построена на бридже, но без медвежьей помощи Xen-а. IP HN назначен на br0.

Суть происшествия.
Экспериментировал с veth. Часто останавливал и запускал VE в течении дня. Подметил, что со временем остановка контейнера происходит все медленнее. Понемногу, но медленнее.
Во время одной остановки контейнера HN повисла: ssh-сессия разорвалась по таймауту, пинги не проходили.
Т.к. машина удаленная и контролировать ее в живую не было возможности, а человек для ребута был временно недоступен, то просто запустил непрерывный пинг с интервалом 1 секунда. Примерно через 6 минут пинг появился.
Зашел на HN. uptime показал, что ребута не было. dmesg никаких ядерных ошибок не сообщил:
Quote:
CT: 190: started
device veth190.0 entered promiscuous mode
br0: port 3(veth190.0) entering learning state
br0: port 3(veth190.0) entering learning state
veth190.0: no IPv6 routers present
br0: topology change detected, propagating
br0: port 3(veth190.0) entering forwarding state
br0: port 3(veth190.0) entering disabled state
device veth190.0 left promiscuous mode
br0: port 3(veth190.0) entering disabled state
CT: 190: stopped


Если бы не "со временем остановка контейнера происходит все медленнее", то грешил бы на сбой бриджа. А так подозреваю какую-то проблему в ovz-ядре.

Кто-нибудь может что-то сказать по сути происшествия или развеять мои подозрения?


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Re: Временное повисание HN при останоке VE. [message #40353 is a reply to message #40338] Fri, 13 August 2010 16:50 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
From: *sw.ru
Здравствуйте,

ваше описание пока не позволяет отделить мух от котлет, то есть
сказать - действительно ли HN зависает или это проблема сети.
Не хотите попробовать эксперимент: одноврменно с постоянным пингом
запустить tcpdump на удаленной машине и на вашей HN так, чтобы были видны временные отметки (часы должны быть более или менее синхронны), тогда мы будем знать когда пакет пришел на ноду и когда ушел. Одновременно с tcpdump можно запустить какое-нибудь приложение, не связанное с сетью так, чтобы по его выводу можно было понять, зависает ли сама HN, когда наблюдаются проблемы с сетью.

P.S. Нет ли у вас каких нибудь start/stop скриптов, которые могли бы вызвать такое поведение.
P.P.S. Самое невероятное - не меняется ли у вас MAC адрес на br0 при старте/стопе VE?
Re: Временное повисание HN при останоке VE. [message #40361 is a reply to message #40353] Fri, 13 August 2010 17:47 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: *static.corbina.ru
Я понимаю неоднозначность фактов. Правда, мне несколько не верится, что удаление виртуального интерфейса из бриджа могло вызвать его сбой - ситуация то вполне штатная.

Эксперимент интересный. Только думаю, что под выходные не стоит его устраивать. Попробую пока на более близкой машине, но там немного другое окружение (процессор P4 и 32-битная ОС).

Для данной VE никаких дополнительных скриптов не было. Одно расхождение с базовой настройкой - vznet.conf с указанием внешнего скрипта /usr/sbin/vznetaddbr, но он ведь вызывается только после запуска VE.

О возможной смене MAC адреса я как-то не подумал. С загрузки HN и до сих пор для br0 указан MAC от добавленного в бридж eth0.

...
Рискнул и запустил эту VE (с остановкой пока повременю). Действительно MAC br0 сменился на MAC veth190.0.

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.001851ba0d46       no              veth190.0
                                                        eth0

# ip link show
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:25:90:00:f1:fc brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 00:18:51:ba:0d:46 brd ff:ff:ff:ff:ff:ff
51: veth190.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 00:18:51:ba:0d:46 brd ff:ff:ff:ff:ff:ff


...

В конфиге 190.conf указано:
NETIF="ifname=eth0,bridge=br0,host_ifname=veth190.0"


Скрипт /usr/sbin/vznetaddbr фактически выполнил только:
ip link set dev veth190.0 up
brctl addif br0 veth190.0


В общем, пока только не понятно, как избежать смены MAC адреса. Назве что модифицировать скрипт, чтобы он сохранял адрес до addif и устанавливал его после. Но это явно не нормально. Sad


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

[Updated on: Fri, 13 August 2010 18:31]

Report message to a moderator

Re: Временное повисание HN при останоке VE. [message #40374 is a reply to message #40361] Sun, 15 August 2010 14:36 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
From: *masterlink.ru
Он не должен меняться на MAC veth.
Если это так - это баг.
Re: Временное повисание HN при останоке VE. [message #40376 is a reply to message #40374] Sun, 15 August 2010 17:51 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: *static.corbina.ru
Видимо - баг...
Пытался повторить на виртуалках под VMware с 32-битным ядром, но эффекта не обнаружено.
На проблемной машине проверил - эффект смены MAC повторяется (машину не перегружал, но полагаю, что после ребута баг может исчезнуть). Пока выхожу из положения так: меняю MAC руками на правильный и только затем останавливаю VE.

Кстати, еще есть странность с ядром 2.6.18-194.8.1.el5.028stab070.2xen (32 бита) на процессоре без поддержки виртуализации: известная проблема glibc не решается через nosegneg, когда как откатившись на штатное ядро CentOS 2.6.18-194.11.1.el5xen проблема исчезла.


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Re: Временное повисание HN при останоке VE. [message #40385 is a reply to message #40376] Mon, 16 August 2010 08:17 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
From: *masterlink.ru
МАС на бридже ставится как минимальный из MAC адресов входящих в него интерфейсов, но в случае OpenVZ должна существовать подпорка, которая предотвращает появление MACа c veth. Насколько я знаю, такая подпорка существовала, но, возможно, в новом ядре каким-то образом поменяли логику. Предлагаю вам забить баг и дождаться мнения разработчиков.
Re: Временное повисание HN при останоке VE. [message #40386 is a reply to message #40385] Mon, 16 August 2010 08:51 Go to previous message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: 82.204.178*
Или задать в конфиге MAC для veth более высокий. Так и сделаю.
Без опасения можно использовать "локальные" MAC-адреса, в которых в первом байте два младших бита равны 10.

Слышал, что для OVZ ветка RHEL 2.6.18 в недалеком будущем отойдет в ряд не поддерживаемых. Т.ч. наверно напрягать разработчиков смысла нет.


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

[Updated on: Mon, 16 August 2010 09:06]

Report message to a moderator

Previous Topic: IPTables ctstate в VE
Next Topic: Помогите распределить ресурсы
Goto Forum:
  


Current Time: Tue Oct 23 18:22:41 GMT 2018