Евгений Чайкин aka StraNNick
2009-09-02
Всё началось с того, что имеющийся на работе сервер всё больше вызывал смутное ощущение оверкилла.
Два четырёхядерника и восемь гигабайт памяти и 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 balancing эта кластеризация, насколько мне известно, делать не позволяет. Впрочем, оно мне не нужно, так что не могу сказать, что я сильно огорчён.
Есть штатные средства бэкапа, которые позволяют бэкапить любую из виртуальных машин (или все скопом) в любой каталог. То, что в этот каталог можно примонтировать что угодно — подразумевается, однако средствами web-интерфейса сделать это невозможно.
Для каждой виртуальной машины имеется индикатор загрузки ЦП и ОЗУ, однако график по этим величинам за определённый (или неопределённый) период отсутствует, что всерьёз огорчает. Это, пожалуй, единственная функциональность, которой мне всерьёз не хватает.
А теперь вернёмся к тому с чего я начал. После установки сервера AD прошло две недели. За это время я успел оценить как удобства, так и недостатки такого решения.
Основным недостатком, на мой взгляд, является работа через VNC. Со временем привыкаешь, но всё же, всё же... Впрочем, никто не мешает настроить в Windows RDP и использовать уже его. На мой взгляд это гораздо удобнее. Про отсутствие средств мониторинга я уже упоминал. Прямо скажем, SNMP или хотя бы график за определённый период был бы, мягко говоря, нелишним.
В настоящее время я планирую установить в виртуальной машине ещё несколько серверов — например Debian + SAMS, взамен стоявшего пиратского UserGate, Openfiler, для организации файлообменника для пользователей домена, Zimbra для корпоративной почты и не менее корпоративного IM.
В общем, планов громадьё и цикл про эту ВМ будет продолжен. Stay tuned, как говорится.
P.S. Да, если кто-то заинтересовался — крайне рекомендую почитать ещё вот это.
Там человек, куда лучше меня разбирающийся в виртуализации, пишет об oVirt.