 Временное повисание HN при останоке VE. [message #40338] |
Wed, 11 August 2010 18:04  |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
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  |
maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
|
Senior Member |
|
|
Здравствуйте,
ваше описание пока не позволяет отделить мух от котлет, то есть
сказать - действительно ли 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 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Я понимаю неоднозначность фактов. Правда, мне несколько не верится, что удаление виртуального интерфейса из бриджа могло вызвать его сбой - ситуация то вполне штатная.
Эксперимент интересный. Только думаю, что под выходные не стоит его устраивать. Попробую пока на более близкой машине, но там немного другое окружение (процессор 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 и устанавливал его после. Но это явно не нормально. 
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
[Updated on: Fri, 13 August 2010 18:31] Report message to a moderator |
|
|
|
|
|
| Re: Временное повисание HN при останоке VE. [message #40376 is a reply to message #40374] |
Sun, 15 August 2010 17:51 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Видимо - баг...
Пытался повторить на виртуалках под 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 #40386 is a reply to message #40385] |
Mon, 16 August 2010 08:51 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Или задать в конфиге MAC для veth более высокий. Так и сделаю.
Без опасения можно использовать "локальные" MAC-адреса, в которых в первом байте два младших бита равны 10.
Слышал, что для OVZ ветка RHEL 2.6.18 в недалеком будущем отойдет в ряд не поддерживаемых. Т.ч. наверно напрягать разработчиков смысла нет.
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
[Updated on: Mon, 16 August 2010 09:06] Report message to a moderator |
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
