Как известно, опыт системного администратора растёт прямо пропорционально количеству испорченного оборудования. По мере хождения по граблям выяснилось следующее.

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-овых скриптов чтобы разобраться как оно работает. Вот спасибо, добрые феи. Радость ещё та. Что-то по крупицам удалось выковырять с официального форума. Спешу поделиться.

1. Если косячит веб-интерфейс, выдает ошибки 401 и 500, не дает залогиниться. Apache матерится и не стартует. Скорее всего, нужно заново сгенерировать приватные ключи и сертификаты.

   pvecm updatecerts

   Если что, там есть ещё ключик "--force" для совсем тяжелых случаев. После этого требуется рестартовать службы pvedaemon и apache2.
2. Если нужно откатиться к "дефолтной" конфигурации. Например, развалить неудачно построенный кластер (штатным способом сделать этого нельзя).

   Остановить службу 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 и всё что внутри. Но тут как повезёт. Может, и прокатит.
3. Разумеется, у вас в настройках ssh должны быть включены

   PermitRootLogin yes
   PubkeyAuthentication yes
   AuthorizedKeysFile      %h/.ssh/authorized_keys

   Сам смотрю на это безобразие и плАчу горькими слезами. А что делать? Только FireWall-ом закрывать.
4. Перед построением кластера следует обязательно проверить содержимое /etc/hostname и /etc/hosts. Именно на их основании утилиты принимают решение о том, на каком интерфейсе поднимать соответствующие службы. И если машина multihomed и ты случайно инициировал кластер не на том интерфейсе, то потом начинается тако-о-о-ой геморрой чтобы всё раздерибанить, а потом собрать заново... Смотри пункт 2.
5. Иногда там начинает кривить 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}