Proxmox VE - радость сисадмина

Всё началось с того, что имеющийся на работе сервер всё больше вызывал смутное ощущение оверкилла.

Два четырёхядерника и восемь гигабайт памяти и RAID 10 на терабайт с небольшим не казались чем-то сверхестественным, но явно были недогружены крутящимся на нём сервером AD (w2k3 R2 x64), который обслуживал ~50 пользователей и, собственно, всё.

Поэтому чем дальше, тем больше вызревала мысль установить на этой радости виртуальную машину и гонять под ней разное. Тем более потребность в этом была.

Не так давно, в силу разных обстоятельств, упоминавшийся w2k3 приказал долго и бестолково жить, а раз так - выходные были посвящены установке на запасную машину Proxmox VE и свежей реинкарнации того же самого w2k3 в ней.

Теперь отвлечёмся от хроники текущих событий и посмотрим - а что, собственно, представляет собой упомянутая выше Proxmox VE?

Для начала определимся - очень упрощённо говоря, виртуальные машины можно разделить на два типа: первые крутятся на рабочих станциях внутри основной ОС и используются для тестирования, например. Вторые ставятся на голое железо и все ОС крутятся только и исключительно внутри них. К ним можно отнести и VMWare ESX (ESXi), и Xen (в т.ч. Xen Server), и oVirt, и пресловутый Proxmox VE.

«Почему же именно Proxmox?», спросит меня читатель. Вопрос этот напрашивается сам собой, а потому постараюсь ответить кратко, но ёмко. Поскольку денег на такое решение мне никто не выделит, я выбирал среди бесплатных решений. Наиболее интересными на мой вкус показались Proxmox и oVirt. Но второй для моих задач - явно избыточен, потому был выбран первый вариант. Итак, посмотрим на него попристальнее.

Технологически, Proxmox VE представляет собой самый обыкновенный Debian Lenny, на котором поднята инфраструктура для управления KVM и OpenVZ. Управляется всё это через вполне приятный web-интерфейс снаружи и libvirt внутри («а внутре у его - неонка!»). Отдельно упомяну, что для корректной работы web-интерфейса (вернее - для реализованного в нём VNC-клиента) требуется JRE.

Есть кластеризация, которая позволяет, например, переносить живые виртуальные машины между физическими хостами. А вот load balansing эта кластеризация, насколько мне известно, делать не позволяет. Впрочем, оно мне не нужно, так что не могу сказать, что я сильно огорчён.

Есть штатные средства бэкапа, которые позволяют бэкапить любую из виртуальных машин (или все скопом) в любой каталог. То, что в этот каталог можно примонтировать что угодно - подразумевается, однако средствами web-интерфейса сделать это невозможно.

Для каждой виртуальной машины имеется индикатор загрузки ЦП и ОЗУ, однако график по этим величинам за определённый (или неопределённый) период отсутствует, что всерьёз огорчает. Это, пожалуй, единственная функциональность, которой мне всерьёз не хватает.

А теперь вернёмся к тому с чего я начал. После установки сервера AD прошло две недели. За это время я успел оценить как удобства, так и недостатки такого решения.

Основным недостатком, на мой взгляд, является работа через VNC. Со временем привыкаешь, но всё же, всё же... Впрочем, никто не мешает настроить в Windows RDP и использовать уже его. На мой взгляд это гораздо удобнее. Про отсутствие средств мониторинга я уже упоминал. Прямо скажем, SNMP или хотя бы график за определённый период был бы, мягко говоря, нелишним.

В настоящее время я планирую установить в виртуальной машине ещё несколько серверов - например Debian + SAMS, взамен стоявшего пиратского UserGate, Openfiler, для орагизации файлообменника для пользователей домена, Zimbra для корпоративной почты и не менее корпоративного IM.

В общем, планов громадьё и цикл про эту ВМ будет продолжен.
Stay tuned, как говорится. :)