+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Драйверы сети Proxmox все довольно нестабильны., Proxmox Виртуальная Среда

felipe

Guest

29.11.2013 13:15:00

Мы перешли с обычного libvirt kvm на Proxmox... Раньше у нас была отлично работающая настройка. Ни разу не было проблем. А теперь одно бедствие сменяется другим... Все началось с проблем с IDE-драйверами Windows, а теперь все наши Windows-компьютеры с rtl8139 потеряли сеть... Поменяли на e1000... Отключение IPv6 приводит к зависанию машины... Некоторые Windows-клиенты теперь вдруг зависают вообще без причины... Работать с таким в продакшен-кластере — просто катастрофа.

quickstarter

Guest

04.01.2014 03:30:00

Я использую точно такую же версию, как и ты, и сталкиваюсь с похожими проблемами. В моём случае вся сеть стала нестабильной после добавления сервера proxmox. Роутер, который раньше работал стабильно, теперь падает три раза в неделю, а на сервере proxmox случаются произвольные замедления в сети. Я сделал следующее, чтобы proxmox стал работать чуть более стабильно: ethtool -K eth0 rx off. Сервер проработал без сбоев неделю, в отличие от ранее — всего один день. После сбоя в логах ничего нет. Я настроил 12 серверов на openvz, мне нравится proxmox, и сейчас пытаюсь понять, в чём дело. Не уверен, связана ли проблема с сетью, или у меня просто плохая память, плохой сетевой кабель или другой неисправный железо. Если найду решение — обязательно поделюсь. Моё оборудование — SGI rackable 3-5 летней давности с 24 ГБ оперативки и двумя четырёхъядерными процессорами AMD.

spirit

Guest

04.01.2014 10:02:00

Привет, насчёт Windows и rtl8139 — это подтверждённая ошибка, исправленная в git QEMU http://git.qemu.org/?p=qemu.git;a=commit;h=00b7ade807b5ce6779ddd86ce29c5521ec5c529a (так что это должно быть исправлено в следующем релизе Proxmox с QEMU 1.7). Что касается e1000, честно говоря, не знаю, у меня с ним никогда проблем не было.

quickstarter Guest	#4 0 05.01.2014 07:43:00 Оказалось, что моя проблема была из-за плохой оперативной памяти. После того, как эту память убрали, с сетью больше не было никаких проблем.

blackpaw Guest	#5 0 05.01.2014 07:55:00 Вот это интересно. Отправлено с моего MT27i через Tapatalk

jdayrhino

Guest

12.03.2014 17:19:00

Кто-нибудь решил эту проблему? У меня такая же ситуация, но только с Windows. CentOS и Ubuntu работают отлично. Похоже, что сетевые драйверы просто засыпают. Если подключиться к консоли и запинговать другую машину, сетевая карта начинает работать, и я тоже могу запинговать эту виртуальную машину. Если оставить её без действий на 30 секунд, а потом попробовать снова запинговать, получаю «Request timed out». Потом можно снова зайти в консоль, запинговать, и сеть снова оживает. Очень странно: если залогиниться в консоль и настроить постоянный пинг, сеть будет работать бесконечно, а как только пинг останавливаешь и ждёшь пару секунд, сетевая карта виртуальной машины перестаёт отвечать.

felipe Guest	#7 0 12.03.2014 17:29:00 Как уже было сказано, в rtl8139 есть ошибка, которая должна быть исправлена с обновлением до Proxmox 3.2 (qemu 1.7), но я больше не использую карты rtl8139. Просто поменяйте их на e1000 — работает отлично.

jdayrhino

Guest

12.03.2014 19:43:00

Спасибо за быстрый ответ. Я немного поэкспериментировал и, похоже, проблема связана с бондингом. Я настроил оба сетевых интерфейса в бонд с использованием balance-rr (мой коммутатор не поддерживает 802.3ad), и это, кажется, работает не очень хорошо. Потом я переключил на balance-alb, и теперь всё вроде работает отлично.

e100

Guest

13.03.2014 04:00:00

Когда происходит сбой, и нет никаких логов с объяснением причины, обычно это связано с kernel panic. По моему опыту, kernel panic почти всегда вызваны неисправным оборудованием, чаще всего плохой оперативной памятью. Даже ECC-память может выйти из строя и вызвать kernel panic. Но я не раз видел, как именно ECC-память предотвращала ошибки.

e100 Guest	#10 0 13.03.2014 04:32:00 Вижу, что ты изменил bonding и решил эту проблему, просто хотел оставить комментарий, который может помочь будущим читателям. То, что ты описал, — классический симптом проблемы на уровне 2 в семислойной модели (http://en.m.wikipedia.org/wiki/OSI_model). Дублирование MAC или IP-адреса, неправильно настроенные VLAN, мосты, транки, bond, коммутаторы и так далее. Коммутаторы и серверы отслеживают, где находится конкретный MAC и какой MAC используется для определённого IP-адреса. Из-за неправильной настройки MAC не удаётся корректно определить, и сеть перестаёт работать для устройств с этим MAC. Когда используется проблемный MAC, например, при отправке пингов с этого MAC, системы «вспоминают», где его искать, и сеть снова начинает работать. Большинство коммутаторов, с которыми я работал, хранят данные о MAC всего 30 секунд, вот почему проблема с недоступностью возникает примерно через 30 секунд активности. Я знаю это и видел много раз, но иногда всё равно чешу голову в недоумении, когда такие проблемы всплывают. Очень легко упустить основы, когда отвлекаешься на крики тысячи пользователей, которые жалуются, что не могут пять минут посмотреть свежие лолкоты.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры