Так уж исторически сложилось, что мне по наследству достались production-системы, построенные на базе ProxMox VE. Хоть разработчики гордо утверждают, что это "самостоятельный продукт с огромным community", но по факту это просто красивая веб-морда для OpenVZ+KVM с набором удобных утилит.
Как известно, опыт системного администратора растёт прямо пропорционально количеству испорченного оборудования. По мере хождения по граблям выяснилось следующее.
I. Касательно OpenVZ
- OpenVZ можно использовать только для примитивных проектов уровня LAMP. Шаг вправо, шаг влево — kernel panic. А поскольку ядро там одно на всех, то последствия понятны.
- В OpenVZ существует куча ограничений на используемые внутри контейнеров ресурсы. Например, нельзя "из коробки" без серьезных ухищрений примонтировать чужую CIFS или пользовать OpenVPN.
- Реализация NFS в OpenVZ — это вообще из серии "понемногу средь багов нащупал дорогу".
- При малейшем дуновении ветра под OpenVZ отказывается работать Live (online) Migration без объяснения причин.
- В некоторых случаях OpenVZ-flavoured ядро улетает в Kernel Panic просто в момент банальной штатной остановки контейнера.
II. Касательно самого ProxMox 1.x
- Если попытаться выкинуть кривое OpenVZ-ное ядро и пользовать "родное" Debian-овское чисто под KVM, то утилита бэкапа виртуалок vzdump отказывается работать под предлогом того, что не может получить из sysfs список VZ-контейнеров. И неважно, что тебя интересуют только KVM-ные виртуалки. Пофиг. Если хочешь автоматизированных бэкапов — будь добр ставить PVE-шное ядро, без вариантов. Ну или хакать Perl-овые модули компонентов ProxMox-а.
- Забавно реализована миграция виртуалок между хостами. Она может происходить только посредством rsync поверх SSH. Получается что. К примеру, две крутых железки в одном датацентре соединены гигабитным шлангом. А скорость миграции максимум 40 МБайт/с. Почему? А всё упирается в SSH-шифрование, которое никак нельзя отключить и до кучи ещё и не распараллеливается между ядрами процессора.
- Коммуникации между узлами "кластера" строятся на отсылке нодами друг другу команд через SSH. Всё бы ничего, но это делается из-под root-а с авторизацией по RSA keys. Безопасность такая безопасная...
- Именование и зависимости DEB-пакетов выстроены настолько бездарно, что нормальным прямым способом на "чистую" уже готовую Debian-систему это не ставится. Только раком и через одно место. Вместе с тем "автоматический" инсталлятор "для чайников" ничего не спрашивая размечает жесткий диск так, что лучше бы он вообще этого не делал.
III. Касательно ProxMox 2.x
Ну там уж вообще как в анекдоте: "А потом приехал поручик Ржевский, и тут тако-о-о-ой разврат начался". Ребята-разработчики решили забубенить супер-мега кластер из адской помеси Corosync, SQLite3 и FUSE. Софт они взяли из Debian, ядро от RedHat. При этом им пришлось пересобрать часть Debian-пакетов; что-то они выдрали из тестируемой ветки в стабильную, что-то не мудрствуя лукаво стырили из backports. Молодцы, чо. Народ с хабра попробовал попользовать в этом коктейле какие-нибудь кластерные файловые системы типа OCFS и GFS. Не получилось. И я почему-то совсем не удивлён.
Самое же весёлое заключается в том, что вся эта радость ещё и ни хрена не задокументирована. Что... где... как... почему... куда копать... Всем желающим предлагается самостоятельно ковыряться в тонне Perl-овых скриптов чтобы разобраться как оно работает. Вот спасибо, добрые феи. Радость ещё та. Что-то по крупицам удалось выковырять с официального форума. Спешу поделиться.
- Если косячит веб-интерфейс, выдает ошибки 401 и 500, не дает залогиниться. Apache матерится и не стартует. Скорее всего, нужно заново сгенерировать приватные ключи и сертификаты.
pvecm updatecerts
Если что, там есть ещё ключик "--force" для совсем тяжелых случаев. После этого требуется рестартовать службы pvedaemon и apache2.
- Если нужно откатиться к "дефолтной" конфигурации. Например, развалить неудачно построенный кластер (штатным способом сделать этого нельзя).
Остановить службу cman Остановить службу pve-cluster pmxcfs -l rm /etc/cluster/cluster.conf rm -rf /var/lib/pve-cluster/* rm /var/lib/cluster/* rm /var/lib/corosync/* rm -rf /etc/pve/* Снова остановить службу pve-cluster, убедиться что процесс pmxcfs сдох. Запустить pve-cluster Запустить cman
Далее смотри пункт 1. Шаманство ещё то, блин. И да, разумеется конфиги всех виртуалок перед этими манипуляциями нужно обязательно забэкапить. Как вариант, можно грохнуть не весь /etc/pve, а только папку nodes и всё что внутри. Но тут как повезёт. Может, и прокатит.
- Разумеется, у вас в настройках ssh должны быть включены
PermitRootLogin yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys
Сам смотрю на это безобразие и плАчу горькими слезами. А что делать? Только FireWall-ом закрывать.
- Перед построением кластера следует обязательно проверить содержимое /etc/hostname и /etc/hosts. Именно на их основании утилиты принимают решение о том, на каком интерфейсе поднимать соответствующие службы. И если машина multihomed и ты случайно инициировал кластер не на том интерфейсе, то потом начинается тако-о-о-ой геморрой чтобы всё раздерибанить, а потом собрать заново... Смотри пункт 2.
- Иногда там начинает кривить fencing, и тогда самый простой способ вылечить — перезагрузка. Смешно, факт.
Короче говоря, ProxMox хоть и бесплатен, но безобразен. И чем дальше, тем чудесатее и чудесатее. На первое время и для решения простеньких задач оно вполне пойдет. Для начинающего сисадмина, делающего свои первые шаги в виртуализации, тоже годное решение. Но для серьезного production — увольте.
Теперь вот сижу и мучительно размышляю, куда бы с энтого ProxMox-а свалить. Как всегда, хочется чтобы система была простой в обращении, умела автоматизированные backup-ы, Live Migration, High Availability и имела красивую веб-морду. Изучаю список совместимых с KVM фронтендов в количестве 30 штук. Он повергает меня в уныние.
источник: http://klink0v.livejournal.com/27626.html
ссылка на материал: http://thin.kiev.ua/categoryblog/733-proxmox-2.html
{jcomments on}
|