Доступен (https://www.proxmox.com/en/news/press-releases/proxmox-ve-4-4) релиз Proxmox Virtual Environment 4.4 (http://www.proxmox.com), специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таких продуктов, как VMware vSphere, Microsoft Hyper-V и Citrix XenServer. Размер установочного iso-образа (http://www.proxmox.com/downloads/) 521 Мб.Proxmox VE предоставляет средства для развёртывания полностью готовой системы виртуальных серверов промышленного уровня с управлением через web-интерфейс, рассчитанный на управление сотнями или даже тысячами виртуальных машин. Дистрибутив имеет встроенные инструменты для организации резервного копирования виртуальных окружений и доступную из коробки поддержку кластеризации, включая возможность миграции виртуальных окружений с одного узла на другой без остановки работы. Среди особенностей web-интерфейса : поддержка безопасной VNC-консоли; управление доступом ко всем доступным объектам (VM, хранилище, узлы и т.п.) на основе ролей; поддержка различных механизмов аутентификации (MS ADS, LDAP, Linux PAM, Proxmox VE authentication).
В новом выпуске (http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.4):
- В графическом интерфейсе представлены экраны для настройки кластера и файловой системы Ceph, улучшены средства управления дисками. Переработан интерфейс для отказоустойчивых конфигураций: объединены вкладки "resource" и "HA status", в новый сводный экран наблюдения за состоянием кластера добавлена возможность редактирования и добавления ресурсов, реализован новый редактор групп высокой доступности с поддержкой установки приоритетов через web-интерфейс;
- Добавлена поддержка управления созданием непривилегированных LXС контейнеров через web-интерфейс. Добавлена функция миграции при перезапуске, позволяющая переместить контейнер на другой хост в процессе проведения плановых работ или при переносе сервера. Обновлены версии пакетов Debian, Ubuntu, CentOS, Fedora, Arch и Alpine в репозитории шаблонов контейнеров. Возможность установки лимитов на число ядер CPU для распределения производительности между контейнерами;- Обновлены ядро Linux (4.4.35), QEMU 2.7.0, LXC 2.0.6;
- В установщик ISO добавлены расширенные настройки ZFS;
- В CLI добавлены средства для развёртывания отдельной сети для миграции контейнеров и виртуальных машин;
- Поддержка DRBD9 теперь осуществляется производителем (Linbit).
URL: https://www.proxmox.com/en/news/press-releases/proxmox-ve-4-4
Новость: http://www.opennet.me/opennews/art.shtml?num=45676
Вдруг кому пригодится:
http://www.altlinux.org/PVE
http://www.altlinux.org/Starterkits/server-pve
http://packages.altlinux.org/ru/p8/srpms/pve-manager
Спасибо, но мне как-то на debian уютней pve юзать.
В таком виде не пригодится.
А сертификация есть?
"А ели Вам нужны шпингалеты ..."
Смена у GNU GPL ПО логотипа с последующем распространением в массы - а разве так можно? Ведь вы же не форк сделали.
Да
Ребята конечно молодцы, но каждый раз, когда я вижу их новый дизайн веб-интерфейса, глаза стремятся вытечь.
по первой ссылке в вику - а зачем "ужу" хранилище данных?
> по первой ссылке в вику - а зачем "ужу" хранилище данных?HA с репликацией и переключением на уровне блочного у.
А сеть все так и настраивается через задницу? В смысле, если нужны VLAN-ы и все такое.
Там идеологически сеть организована неправильно, правда 4.3 и эту я не смотрел.
Например, у меня не удалось сделать для виртуалки .1q транк. Хотя дома ручками я легко это делаю, пробрасывая в виртуалку (шлюз+фаервол) под KVM все свои три ) влана: local, dmz и wifi-guest ))
> Там идеологически сеть организована неправильно, правда 4.3 и эту я не смотрел.
> Например, у меня не удалось сделать для виртуалки .1q транк. Хотя дома
> ручками я легко это делаю, пробрасывая в виртуалку (шлюз+фаервол) под KVM
> все свои три ) влана: local, dmz и wifi-guest ))Вот это не пробовал на ProxMox...
На 4.3 кручу уже месяц тестовый кластер (3 узла), много чего пробовал и запускал - нестабильностей на типовых задачах не обнаружено. НО - это без нагрузки. Исключительно тестовые задачки...(Samba4 as AD, FreeIPA, windows разных версий - все нормально встает и работает).
На ESXi (бесплатном) делал транк внутрь виртуалки, там это элементарно и просто работает.
На Hyper-V тоже не пробовал (задачи такой не было) - и вообще не уверен, что это получится...Microsoft как всегда своим путем идет...Network Virtualization у них вообще зубо-дробилка...через powershell и новые сущности аля GRE туннели )))
PS: Когда VLAN со стороны хоста - проблем нет ни у кого уже давно. Но проброс транка до виртуалки (чтобы уже внутри ее видеть теги и раскладывать по интерфейсам) задачка редкая. Но случается. У меня в последний раз была, когда срочно пришлось один физически подыхающий сервер перетаскивать в виртуалку (а там транк и vlan-ы). Но благо стоял ESXi - поэтому все прошло быстро и безболезненно.
Иногда vlan-ы не могут проходить через простой bridge из-за драйвера сетевой карты с аппаратной поддержкой 802.1q. Или отключать аппаратную обработку или использовать несколько интерфейсов в VM. Ещё можно их заново затегировать :-)Proxmox не пробовал, не знаю как там это настраивается.
>Например, у меня не удалось сделать для виртуалки .1q транк. Хотя дома ручками я легко это делаю, пробрасывая в виртуалку (шлюз+фаервол) под KVM все свои три ) влана: local, dmz и wifi-guest ))Обычный бридж вполне себе пробрасывает все вланы, включая дабл таг, в виртуалку, баз каких либо танцев с бубнами.
> А сеть все так и настраивается через задницу? В смысле, если нужны
> VLAN-ы и все такое.Если править конфиги в CLI это через то самое место - то да:
https://pve.proxmox.com/wiki/VlansPS: кто не хотят править конфиги - покупают/пиратят что-то другое...
> Если править конфиги в CLI это через то самое место - то даЧерез задницу - это когда неконсистентно. Не через задницу - это либо когда все настраивается через GUI/API, либо все настраивается через конфиги. А когда что-то настраивается через конфиги (причем, на каждом хосте руками в якобы "кластере"), а что-то через GUI - это через задницу.
Можно было бы понять, что это какие-то низкоуровневые тонкие настройки, они везде через локальные конфиги настраиваются, но это же - простейшие VLAN-ы, даже без каких-либо еще примочек.
>> Если править конфиги в CLI это через то самое место - то да
> Через задницу - это когда неконсистентно. Не через задницу - это либо
> когда все настраивается через GUI/API, либо все настраивается через конфиги. А
> когда что-то настраивается через конфиги (причем, на каждом хосте руками в
> якобы "кластере"), а что-то через GUI - это через задницу.
> Можно было бы понять, что это какие-то низкоуровневые тонкие настройки, они везде
> через локальные конфиги настраиваются, но это же - простейшие VLAN-ы, даже
> без каких-либо еще примочек.Зато Just for Fun и свободно/бесплатно.
А то, что что-то не допилили - ну так дайте время...ESXi вот с 2001/2002 года пилят...А думается мне бюджет у них на порядок (порядки) скромнее...
> Зато Just for Fun и свободно/бесплатно.Ну, вообще, там пишут про "энтерпрайз-класс фичерзы": https://www.proxmox.com/en/proxmox-ve
Раз энтерпрайз, то отмазки типа "зато бесплатно, модно, молодежно" - не канают.> А то, что что-то не допилили - ну так дайте время...ESXi вот с 2001/2002 года пилят...
Вообще говоря, если брать ESX, более-менее годный для практических задач (версия 3.5) - то ESX и Proxmox VE достаточно недалеко друг от друга по времени появления. И Proxmox VE, как бы, не с нуля создавался, в отличие от ESX, а как обертка для существующих и отдельно разрабатываемых технологий.
Так что тоже - не канает. Уж "обертку"-то за 9 лет - можно было бы и допилить уже.> А думается мне бюджет у них на порядок (порядки) скромнее...
Так и возможности, мягко говоря, во многом скромнее.
Note: Article is outdated and contain advices which are not recommended
Да все давно отлично. Вы какую щупали, что не понравилось, 2.х? Там да, было трудно.
Последняя версия, которую я более-менее активно использовал - была 3.4.
OpenVZ нету?
В четвёрке же OpenVZ выпилили.
в тройке. в четверке заменили на лхс
была ж новость вродеhttps://forum.proxmox.com/threads/moving-to-lxc-is-a-mistake.../
'''
There is no OpenVZ for ANY kernel later 2.6.32. In fact, OpenVZ development is stopped and a follow up project is started. The new "OpenVZ" is currently called Virtuozzo 7 (the team behind change name and company several times, quite confusing and a bit hard to follow.).Virtuozzo 7 is still under development and obviously not suitable for production and not feature compatible to the old OpenVZ project. more or less all new.
See also their roadmap:
https://openvz.org/RoadmapSo if you want/need stable OpenVZ, you can ONLY use 2.6.32 - available and maintained in Proxmox VE 3.x series.
#6tom, Jan 14, 2016
'''
Используем proxmox как штатную виртуализацию в конторе. Крутятся и корпоративные сервисы и стенды и виртуалки для работы в разных сегментах сети. Всего виртуалок штук 500 - впечатления положительные.
> Используем proxmox как штатную виртуализацию в конторе. Крутятся и корпоративные сервисы
> и стенды и виртуалки для работы в разных сегментах сети. Всего
> виртуалок штук 500 - впечатления положительные.Можно несколько вопросов?
1) Сколько у Вас хостов ?
2) Смотрели ли oVirt ?
3) Есть ли очень нагруженные системы по дисковому I/O и по CPU? Как со стабильностью?
1 8-10хостов, около 50-70 виртуалок
2 Да, там проблем с настройками много, тут из коробки, ну и гайки докручивать в проксмокс легче
3 По разделению ресурсов - нужно допиливать, I\O нагруженных нет, кроме ZFS, который крайне зависит от ОЗУ, CPU - проблем нет, максимум повышение LAИз проблем:
- Невозможно понизить приоиритеты операций, кроме как руками из CLI делать, что крайне неудобно, та же операция миграции диска может повесить систему, притом крайне неожиданно по LA без прочих признаков
- Пару раз за 3 года висла бекапилка, отправляя в накаут весь хост, работает, но на предел и миграции отказываются работать
- При 2х нодах, отказ одной ноды приведет почти к смерти (резко упадет скорость сети и дисковой подсистемы, до выполнения операции в консоли)
- Бывают косяки на ровном месте, рода - перепутались местами сетевые интерфейсы, повис интерфейс и нужно обновить страницу, на ранних версиях терял яzfs пул
- Большой косяк - пр ZFS 1/2 ОЗУ уходит ему, по умолчанию, ну и при таком раскладе у меня 2-ды я терял связь с виртулками без особых видимых причин (видно свапиться стал), в чем причина узнал по косвенным признакам, 10-20 минут простой как никак. Допиливается-но неприятно
- медленно бекапится на 3-й версии (есть еще такие в кластере одном), одна виртуалка без особых причин бекапится 24часа, и это 30 гигов не изменяемых
Всецело 24*7, несколько кластеров по миру все стабильно, но иногда не радует
> Всецело 24*7, несколько кластеров по миру все стабильно, но иногда не радуетВижу более-менее системный подход, в связи с чем не могу не спросить - считалась ли стоимость владения и сравнивалась ли с коммерческими решениями?
Полагаю, прекрасно понятно, что в стоимость закладываются и вынужденные аварийные простои бизнес-систем, крутящихся на этих виртуалках, что в принципе не может быть "бесплатным", только если там не тест/разработка крутится.
Считалась
Но выяснилось вот что:
- Большинство ошибок кроются в кривых руках тех или иных лиц, неправильная структура, разработчики
- Требуется замена оборудования для обеспечения совместимости c Vmware, строгое выделение хранилки, при том не одной
- Время простоев во время перехода очень большое, отдельный большой вопрос с vmware tools, которые под тот же gentoo (не спрашивайте зачем он у нас) будут собираться и допиливаться долго
- VSAN от Vmware стоит порядком денег, в Proxmox Ceph и ZFS+NFS+rsync
- Простой в час в год является допустимым у нас
- uptime кластера доходил до 2 лет, отсюда и с 3-ки пока не уходим
- Ну и стоит понимать, тут задавали вопрос о высоком IO и загрузки проца, так вот такие вещи вообще виртуализировать нельзя! те же базы данных у нас хранятся на отдельных серверах и тут вопрос не в системе виртуализации
> - Большинство ошибок кроются в кривых руках тех или иных лиц, неправильная структура, разработчикиДа, но это зачастую - данность, с которой приходится жить и, соответственно, подстраивать под это инфраструктуру. Как оправдание это - увы - почти никогда не работает.
> - Требуется замена оборудования для обеспечения совместимости c Vmware, строгое выделение хранилки, при том не одной
Насчет "замены оборудования", честно говоря, не понял что имеется в виду. Про HCL, что ли, речь?
Насчет "строгого выделения хранилки" - тоже не совсем понял.> - Время простоев во время перехода очень большое, отдельный большой вопрос с
> vmware tools, которые под тот же gentoo (не спрашивайте зачем он
> у нас) будут собираться и допиливаться долгоТак речь не о переходе. Если закладывать переход - то это к любой системе некислый плюс к цене пририсует, даже к бесплатной.
> - VSAN от Vmware стоит порядком денег, в Proxmox Ceph и ZFS+NFS+rsync
Так ведь мы о стоимости владения говорим, а это параметр комплексный. Допустим, сэкономили вы на лицензиях VSAN, но жор памяти ZFS "съел" достаточно памяти, что цена этой самой памяти стала сопоставима со стоимостью VSAN.
> - Ну и стоит понимать, тут задавали вопрос о высоком IO и загрузки проца, так вот такие вещи вообще виртуализировать нельзя!
Это почему?
> те же базы данных у нас хранятся на отдельных серверах и тут вопрос не в системе виртуализации
А в чем вопрос?
1 Ну статистику она и портит более чем минимальные простои от косяков проксмокса
2 HCL - да про него, хранилка - это построение SAN для Vmware
3 Стоимость владения намного ниже для нас чем Vmware, опять же Vmware не чистый, к нему еще нужно бекапы докупать и т.д.
4 ZFS после настроек съел 8-12GB, цена VSAN - лямы
5-6 Потому что в пиках возникают проблемы у всех соседей в том или ином виде, ограничивать и корпеть над каждым ограничением глупо, та же сеть, диски и т.д. Потом при виртуализации нужно соблюдать архитектуру процессоров, чтобы сохранить миграцию, в этом случае весь кластер работает на архитектуре минимального севрера. Потом диагностика узких мест при БД будет проблематична и не всегда очевидна.
Ну и скажу совсем непопулярную мысль
Сервера Intel и Supermicro не уступают в надежности Hp, Dell, IBM, а в цене по совокупности в разы дешевле
Хранилки не в счет, там отдельная тема
Ага. Тестировали примерно три-четыре года назад Proxmox, ESXi и KVM.
В итоге, пришли к такому же выводу, как из-за косяков в сабже, так и по причине более жёсткого HCL для VMware. Удобно, да и по плюшкам запас есть, есть куда двигаться.
> 2 HCL - да про него, хранилка - это построение SAN для VmwareSAN по-разному можно строить. Можно FC, а можно и iSCSI на карточках с аппаратным инкапсюлированием.
> 3 Стоимость владения намного ниже для нас чем Vmware
Ну так я потому и спрашивал расчет. Просто интересно было - как считали.
> опять же Vmware не чистый, к нему еще нужно бекапы докупать и т.д.
Если бэкапы делать таким же образом, как на Proxmox - такие "бэкапы" можно сделать и на PS-скриптах в вари, без проблем. Плюс, варь, вроде бы, бесплатный аплаенс для бэкапов раздает. Хотя, он достаточно убогенький и лишь для не слишком большого количества VM годится.
> 4 ZFS после настроек съел 8-12GB, цена VSAN - лямы
Ну VSAN, вроде как, $2500 стоит на проц. Не лямы. Хотя, конечно, и дороже. Но VSAN немного для другого предназначен - для гиперконвергентных платформ.
Опять же, считать отдельно VSAN - смысла нет, в рамках какого-то общего пакеты лицензий - он дешевле.
Ну и так, на всякий случай - по GPL-ценам никто и ничего не покупает. ;-)> 5-6 Потому что в пиках возникают проблемы у всех соседей в том или ином виде, ограничивать и корпеть над каждым ограничением глупо
Не совсем понял, почему глупо-то? Правильно настроенные политики и приоритеты - и полет будет нормальный.
Сваливать все в одну кучу и надеяться, что все как-то само собой разрулится - конечно же, не получится. Но и все далеко не так страшно, как вы описываете.> в этом случае весь кластер работает на архитектуре минимального севрера.
Если у вас сервера настолько сильно расходятся по поколениям, то имеет смысл разбить кластер на несколько, например.
> Потом диагностика узких мест при БД будет проблематична и не всегда очевидна.
При правильно организованной среде я себе с трудом представляю такие проблемы. Только если с CPU, что тоже будет происходить лишь при неверно настроенном распределении ресурсов.
> Сервера Intel и Supermicro не уступают в надежности Hp, Dell, IBM,
Все зависит от задач. Для некоторых задач просто невозможно использовать самосборы в силу банальной неподдержки их производителем софта. Не лицензировано - и все тут. Ну и для многих компаний наличие определенного уровня поддержки - является требованием регуляторов. Для самосборов такой поддержки просто не бывает в принципе.
А вот веб-компании, насколько я знаю, самосборы используют достаточно широко. В силу низкой стоимости и возможности навтыкать их настолько много, что падение каждого из них не будет являться проблемой.
Ещё бы оно не падало при свопе.
что за сториджа используете?
ceph
nfs
zfs
The best!
Программисты пишут Проксмокс безелаберно, на хабре давно была статья, что lxc хреново работает в Проксмоксе и недавно была статья с тестами, что zfs реализована в Проксмоксе через ж.
Ага, нажимаем кнопку выключение, не ставя на госте acpid, гость больше команд принимать не может, т.к. выключение "залипло".
> zfs реализована в Проксмоксе через ж.Через твою ж?
> Программисты пишут Проксмокс безелаберно, на хабре давно была статья, что lxc хреново
> работает в Проксмоксе и недавно была статья с тестами, что zfs
> реализована в Проксмоксе через ж.LXC и без него работает плохо.
Крутится на проксмоксе уже 2-й год виртуальный сервер под шаред хостинг, 200 хостов примерно. В этом году еще понадобился файерберд сервер - и все это удовольствие бесплатно. Хороший подход. Не могу иметь претензий, лишь бы лавочку не закрыли