Comments 25
Зависающий nfs решили переходом на proxmox backup server, очень довольны.
lock контейнеров у нас возникал как правило только из-за глючного nfs
Когда потребности перерастают один, ответственный за все, железный сервер,
У меня как раз Proxmox'ы трудятся в сценарии, когда "за всё ответствен один железный сервер" :) Ну точнее, не один, а три в разных местах, но в кластер они не объединены, т.к. между этими местами network latency оставляет желать сильно лучшего.
Когда виртуалок уже ближе к десятку, но при этом гибкое масштабирование не нужно, обнаруживается, что и выгоднее, и на порядок удобнее в плане управляемости арендовать выделенный железный сервер и развернуть на нём Proxmox.
У меня каждый из Proxmox'ов ещё и Proxmox Backup Server, и по ночам они все дружно бекапятся друг на друга, обеспечивая 2 независимых резервных копии для каждой VM, чего для моих потребностей (простой в целом допустим, простой ночью - даже не критичен) хватает.
однако если udp-пакеты перестают нормально ходить
а ещё насколько я помню прохмох часто посылает толстенные UDP пакеты от каждой ноды к каждой соседней для проверки "а не изменился ли mtu", не очень понимаю зачем это надо, но это приводит к довольно печальным последствиям если кол-во нод доходит до 30ти, а интерлинк всего гиг да ещё и не на самом лучшем свиче..
UPD: мне было лень рассписывать свою историю, поэтому нашёл похожую
По поводу кластеризации Proxmox.
Начиная с 6 версии был обновлен стек corosync и снято ограничение на 32 ноды в кластере. Сейчас количество нод теоритически неограничено и упирается в производительность кластерной сети. Те "толстые UDP пакеты", о которых вы пишите - это pmxcfs, которая монтируется в /etc/pve, содержит в себе конфиги proxmox и общая для всех нод кластера. Они периодически генерируют трафик, синхронизируя между собой содержимое этой директории. И чем больше нод, тем больше такого трафика генерируется.
В самом proxmox тестировали максимально 36 нод в кластере и при этом у них вышло 2,5 Гб/с трафика на синхронизацию. Это только на нужды кластеризации, а если у вас ещё оверлейные сети между гостевыми системами - то вам нужна ещё более производительная сеть.
Но, думается мне, 100 Гб/с InfiniBand хватит обеспечить нормальную работу кластеру из 100 нод с оверлейными сетями и хранилками через iscsi.
Хорошо укопались товарищи… у нас пока траффика лишнего, к счастью, не наблюдается в больших количествах.
Но на заметку взять точно стоит.
Да, всем хорош этот Проксмокс, но вот решение строить кластер на коросинке — это боль. Этот кластер из 29 нод так иногда и разваливается. Правда теперь только из-за зависающих сетевых карт в момент подключения ранее перезагруженной ноды. Т.е. вот надо железку перезагрузить, переношу с неё виртуалки, говорю ей ребут. И всё хорошо, пока она не загрузится и не начнёт пытаться заехать в кластер. В этот момент может на одном или нескольких серваках в кластере словить глюк броадкомовская сетевуха. Если сетевуха словила этот глюк, то трафик через неё больше не ходит, в логах ядра постоянные ошибки с попытками обресетить карту, а свитч рапортует о постоянно моргающем линке. При этом, повисшую сетевуху восстановить можно только перезагрузкой либо выгрузкой-загрузкой модуля ядра. Но т.к. на этих серверах все 4 сетевых одинаковые, то это для прод. нагрузки равноценно перезагрузке.
И да, иногда эта сетевуха виснет совсем жёстко, тогда любое обращение к настройкам сети вешает приложение. Т.е. виснут намертво утилиты ip, iptables, невозможно подключиться по ssh и т.д. Поведение сильно напоминает hard lock на сетевой шаре.
Не видим в "мане по починке proxmox" команду "corosync-cfgtool [-s]" -> закрываем статью.
О чём статья-то? Как порестартить сервисы и "почините свою сетоньку"?
Кажется, вы впали в рекурсию на нечеткой логике, иначе бы ваш комментарий под статьей не появился бы.
Ну а раз сказали А — говорите и Б: то есть, поделитесь свои опытом. Недаром на хабре комментарии почти всегда интереснее и полезнее самой статьи.
Для рекурсии нужен цикл хоть какой-то.
А в общем-то всё, поделился. "corosync-cfgtool - A tool for displaying and configuring active parameters within corosync."
Если исключить проблемы со стораджами (уникальные для каждого стораджа и никак не связанные с самим проксмоксом - например, если используете Ceph, будьте добры уметь чинить его), то corosync - первое, что нужно дебажить, если проксмокс "сломался" (а не его сломали). Corosync ломается даже чаще, чем отдельные сервисы на отдельных хостах. Ну а чтобы дебажить его - нужно знать про corosync-cfgtool.
Тот же (упомянутый в статье, кстати) pmxfs как раз хранится в corosync.
Ну, излагать не опробованное на практике это как писать картину бури в открытом море с прудика за окном. А у нас пока что особо страшных проблем с коросинком не возникало, он всплывал только в разборе полетов а не являлся источником проблемы.
Кроме коросинка весь udp-траффик летел псу под хвост: remote logging, push metrics, wireguard… но на коросинке это сказывалось особенно… эффектно.
Вообще, статья появилась в ответ на просьбу другого хабраузера рассказать поподробнее о своем опыте )
Почти 7 лет продуктовой работы 5 нод и iscsi хранилки. Локи на машинах бывало подвисали и один раз упал zfs рутовый, который восстановил за 10 мин и собственно всё, больше ничего не было.
Другие среды виртуализации/кластеризации тоже столько проблем имеют? Или там ещё хуже?
Хуже. Но прокс по моему мнению пока лучший инструмент "система виртуализации".
Это сводка всего что случалось за два с лишним года эксплуатации на проде ) Разумеется, сами инциденты не происходят на постоянной основе — они, скорее, исключение.
С другими дела на проде иметь не довелось, ну а на вирталках или под кроватью все работает с полпинка и замечательно.
По поводу отсутствия кворума — лечится expected (нужное кол-во хостов).
Если уводишь но обслуживание определённое кол-во хостов или падал свич этой половины — сразу помогает. Потом на остальных рестартим corosync и pmxcfs. Иногда ещё pve-proxy.
Где же информация про fencing была пару лет назад. Сколько крови выпил перегружающийся без видимых причин proxmox с пустыми логами, без ответов - только вопрос трёхлетней давности без ответа на форуме и методом тыка - какая-то завязка на системное время. Неужели в системный лог тяжело было событие кинуть?
С 2012 года испытал много средств виртуализации. В конторе не меньше 150 серверов были. , 25 в офисах. 125 - магазины.
Везде стояла ESXi 6-6.5.
Работала как часы.
За 8 летипару раз наблюдал розовый экран смерти и то некоторые были изза железа.
Proxmox изучал когда появилась. Хорошая интересная, но видно была сырой и вылетала.
Сначала ставлю ESXi на домашнем сервакн на своих 20 виртуалках.
Так вот ESXi 7.0 имеет неприятную особенность. Вебморда работает, но с тачками ничего не сделать. Приходится сканить сеть. Зазолить на каждую и выключать. Потом рестартить весь сервер.
ControlCenter 7.0 жрет дтск как не в себя и орет что диски заполнены.иувеличение решает проблему на еару дней.
Вернулся на 6.7 U2
Все работает как часы. Старая добрая 6.7 Лучшая.
Отредактировал файл VMX. И выставил версию 14. Таким образом виртуалкам можно снизить версию, если вы ее апгрейдили.
Вы же конечно тестируете новую версию Proxmox? В течении долгого времени и конечно же сможете откатиться на более низкую версию?
Сервера на ESXi 6.7 U2 реально работают годами.
Много лет используем Proxmox VE и хвала ИТ богам не сталкивались с описанными в статье проблемами. По первости шаловливые ручки что-то не так делали, но в целом доволен, что много лет назад выбрали PVE как систему виртуализации. После ввода в строй Proxmox Backup Server всё стало ещё надёжней в плане сохранности виртуальных машин. PVE + PBS = шикарная вещь!
Спасибо за статью.
Интересующимся https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/
Как падает и поднимается Proxmox