Наконец-то вышел Proxmox VE 2.0 final release

    30 марта 2012 года вышел финальный релиз Proxmox VE 2.0. Первая публичная бета вышла 30 сентября 2011 — ровно 6 месяцев шла заточка напильником. RC1 был опубликован 16 февраля 2012.



    Proxmox VE (wiki) — система виртуализации с открытым исходным кодом на базе гипервизоров KVM и OpenVZ, основанная на Debian GNU/Linux.

    Версия 2.0 довольно радикально отличается от первой ветки.

    Начать можно с того, что изменилась лицензия продукта и добавилась возможность покупки платной поддержки. GPL v2 сменил AGPL v3.

    Одной из отличительных черт Proxmox VE является простота установки и дружелюбие интерфейса. В версии 2 интерфейс полностью переработан. В новой версии он базируется на ExtJs 4. Некоторые утверждают, что он стал более запутанным и сложным. В любом случае очевидно, что его внешний вид стал намного приятнее. Разработчики подчеркивают высокую скорость работы (полный AJAX) и удобство пользования новым интерфейсом за счет хорошего поиска.

    В новой версии также появились возможности для создания отказоустойчивого кластера. Кластер основан на corosync. Используется собственная файловая система для хранения и синхронизации конфигурационных файлов Proxmox Cluster file system (pmxcfs), поддерживается multi-master и централизованное логирование. В новой версии возможен автоматический старт виртуальных машин на новой ноде при отказе старой.

    Наконец-то освежена версия Debian, на основе которой работает VE. Теперь это Squeeze. Ядро обновлено до 2.6.32.

    В версии 2.0 добавлен RESTful HTTP API. Так же появилась возможность Backup/Restore через веб-интерфейс, в том числе по расписанию. Напомню, что любые действия в системе можно сделать из без GUI, используя стандартные утилиты командной строки OpenVZ, KVM и собственные утилиты Proxmox. Однако, разработчики делают ставку на простоту. Следовательно основным инструментом админа в данном случае считается GUI. И они его реально пилят напильником по-максимуму.



    В новой версии добавлена интеграция с TurnKey (сервис готовых шаблонов для OpenVZ) и возможность скачки шаблонов из собственного комплекта. Теперь поддерживается несколько хранилищ для контейнеров OpenVZ и нет необходимости привязываться к /var/lib/vz (мелочь, а очень приятно в некоторых ситуациях). Добавлена поддержка VSwap.

    Смотрите также: полный список изменений, видео-уроки, раздел скачки ISO, мануал по обновлению с 1.9.

    Добавлю, что в основе Proxmox лежит виртуализация на базе контейнеров Linux OpenVZ. KVM-гипервизор используется в первую очередь для остальных операционных систем. OpenVZ (как и другие контейнерные системы) работают по принципу общего ядра между гостями и хостом. Это накладывает значительные ограничения на гостевые машины (тоже самое ядро, что и на хосте). Поэтому в некоторых ситуациях даже Linux запускают в KVM, а не OpenVZ. Сама Proxmox VE представлет одинаково удобный GUI для работы с обеими платформами.

    Использование Proxmox наиболее актуально для тех пользователей, которые не хотят или не могут лезть в дебри OpenVZ и KVM. Система позиционируется как готовая к использованию. И реально так и есть. Отлично подойдет для начинающих.

    Из бесплатных аналогов на рынке Open Source можно отметить Citrix XenServer. Он использует совершенно другую схему виртуализации — паравиртуализацию. В этом случае на каждую гостевую машину будет работать свое xen-совместимое ядро, что значительно ослабляет зависимость требований к гостю от хоста. Для виртуализации систем, отличных от Linux, также используется Xen-HVM (базируется на QEMU). У XenServer дефолтовый клиент работает только под Windows, однако есть сторонние реализации, в том числе и web-based.

    Выбор в пользу той или иной платформы зависит от ряда факторов. У каждой из них есть свои преимущества и недостатки. Но в любом случае обе платформы являются серьезными игроками на рынке Open Source-виртуализации.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 76
    • 0
      В XenServer, а так же в бесплатном варианте Xen Cloud Platform, для HVM тоже использкется Xen. Насчет пропатченного ядра тоже не совсем верно — в совремнных дистрибутивах ядра «из коробки» прекрасно себя чувствуют в PV-режиме.
      • 0
        Подправил. Кстати, по скорости и надежности в общем случае что будет быстрее: Xen-HVM или KVM?
        • 0
          К сожалению, под руками нет данных. Не буду гадать.
          Тут уже скорее религиозный вопрос. Чисто
          субъективно, Xen-HVM выглядит симпатичнее.
          Я пробовал в себя в лаборатории RHEV3, Ubuntu
          11.10 и Fedora 16 даже не смогли загрузиться в KVM,
          хотя прекрасно живут в XCP. А последние пару
          месяцевя я уже перешел на Ubuntu 12.04 в PV-mode.
          Полет нормальный
          • 0
            Зачем HVM, если практически всё уже давно умеет работать в PV?
            • +1
              С pv режимом в цитриксе вечно какие то проблемы. То виртуалка залипнет так, что помогает только полный ребут хостовой ноды. То сетевое хранилище без видимых причин отваливается. Конвертация hvm в pv та еще песня… Ну и виндовая панель управления совсем не доставляет.
        • +3
          > Ядро обновлено до 2.6.32
          Ядро 2.6.32 используется давно и оставлено в новой версии потому-что, как говорят разработчики, «очень надёжное».

          > Разработчики подчеркивают высокую скорость работы (полный AJAX)
          На счёт высокой скорости я бы поспорил, старый интерфейс быстрее. Но новый функциональнее и удобнее.

          > Использование Proxmox наиболее актуально для тех пользователей, которые не хотят или не могут лезть в дебри OpenVZ и KVM. Система позиционируется как готовая к использованию. И реально так и есть. Отлично подойдет для начинающих.
          Proxmox VE не позиционирует себя как «для тех, кто хочет попроще» или «для начинающих». Сегодня Proxmox VE становится реальной альтернативой VMware.

          > Добавлю, что в основе Proxmox лежит виртуализация на базе контейнеров Linux OpenVZ.
          Разработчики не ставят приоритеты именно на OpenVZ. Для версий 1.x существовали ядра и вовсе без поддержки OpenVZ, а только с KVM.
          • 0
            А случайно не известно когда они его до 2.6.35+ дотянут?
            • 0
              У них было ядро 2.6.35 опционально в 1.x, но сейчас используется 2.6.32, при чём не Debian-овское, а от RedHat.
          • –1
            В новой версии также появились возможности для создания отказоустойчивого кластера.
            Кластер был и в первой ветке, не было multi-master.
            • 0
              HA в первой ветке не было.
              • 0
                HA = High Availability
                • –3
                  Было-было.
                  • +2
                    pve.proxmox.com/wiki/Roadmap#Proxmox_VE_2.0

                    High Availability Cluster support for KVM guests and OpenVZ containers
                        resource agents for KVM and OpenVZ
                        GUI for managing KVM and OpenVZ HA settings
                    
                    • –3
                      А теперь почитай про 1.8, теоретик ты мой. Кластер был, но по другой технологии, с ограничениями.
                      • +1
                        Возможность создать кластер была уже в первых версиях Proxmox (мы его используем начиная с версии 1.3), но High Availability не было до версии 2.0.
                        • +1
                          HA не было, была «мгновенная» миграция, но для этого надо было общий NAS.
              • 0
                На mdadm оно так и не научилось ставиться?
                • 0
                  Думаю что не научится. Можно сделать вручную, но не рекомендуется.
                  • +2
                    Ставьте дебиан, делайте любой конфиг, накатывайте поверх проксмокс и вуаля.
                    • 0
                      Разработчики четко против такого. Если не ошибаюсь, были моменты в работе LVM со снапшотами поверх md.

                      Да и по-чести, если Вы делаете надежный сервер виртуализации, зачем его собирать на совсем уже бросовом железе? Если же хочется дешево и сердито, не парьтесь по зеркало.
                      • 0
                        Всё нормально, у меня оно на аппаратном рейде с BBU стояло. Но в силу своей бесплатности Proxmox занимает нишу «малого и среднего бизнеса», где на VmWare денег никогда не выделят, а с ручной настройкой Xen/KVM, допустим, кому-то возиться не хочется.
                        • +1
                          Так и у меня стоит на нормальных серверах :) И отлично работает, разумеется.

                          Я про то, что ставить сервер виртуализации поверх софтового рейда против рекомендаций разработчиков — верный путь к дальнейшим жалобам «опять разрабы что-то недокрутили». Не стоит риск завалить много машин (VM-ок) и сервер стоимости железного рейда, но до многих такая простая истина доходит только «кровью».
                    • 0
                      Разделяемые хранилища типа DAS, SAN не научились еще использовать?
                      • 0
                        Что вы имеете ввиду? По каким протоколам?
                        • 0
                          FC, SAS.
                          • 0
                            FC и SAS заявлены давно как поддерживаемые.
                            • 0
                              pve.proxmox.com/wiki/Storage_Model
                              Как LVM что-ли?
                              • +1
                                FC и SAS поддерживаются на уровне ядра и имеют мало отношения к Proxmox-у как таковому. LVM широко используется в Proxmox, что позволяет делать snapshot-бэкапы, а так же обеспечивать конкурентный доступ в случае с внешним хранилищем или DRBD.
                        • +1
                          HA требует разделяемого хранилища. И использовать их научились довольно давно.
                          • 0
                            Я не нашел как адекватно использовать dell powervalue md3200 (на борту два контроллера с 4мя SAS портами на каждом) в качестве разделяемого хранилища.
                            Да и про использование SAN-хранилищ я как-то информации не нашел.
                            • 0
                              А о том, что без SAN не будет работать HA нашли? Есть в Wiki. Вообще надо их списком рассылки и форумом пользоваться — там очень много информации и живой разработчик отвечает на все вопросы.
                              • 0
                                Спасибо за информацию.
                                Если денег на VMWare не выйдет выбить — придется поискать.
                                Вообще я там чуть выше писал про Storage Model, эта информация уже устарела?
                                • 0
                                  Надо конкретную модель хранилища поискать на форуме. Я думаю, что разработчики не считают NAS SAN'ом — они всё таки не глупые.
                                • 0
                                  Кажется я понял в чем проблема.

                                  " No need for expensive fiber channel (FC) infrastructure or the complexity of configuration of an extra storage network for iSCSI. In order get shared LVM storage you just need the optional shared LUN key.
                                  The IMS and Proxmox VE storage model are very flexible so you can configure the disks to meet your requirement. Just a basic recommendation: Use only certified disks and only redundant raid levels, best performance with Raid10."

                                  Разработчики считают, что SAN это iSCSI, а я, что SAN это FC.
                                  Соотвественно, чтоб прицепить СХД по оптике, мне придется сделать это через анус (не вижу смысла в LVM, при наличии нормального хранилища).
                                  • 0
                                    Про LVM ответил выше. Что касается SAN — они говорят, что можно использовать iSCSI и с экономить (и многие так и делают, с Proxmox iSCSI работает очень быстро в отличии от VMware), но выбор за вами.
                                    • 0
                                      А можно по подробнее, какие есть проблемы у vSphere при работе с СХД по iSCSI?
                                    • 0
                                      Кстати, SAN это не FC согласно определению: en.wikipedia.org/wiki/Storage_area_network. FC, наверное, ближе к SAS.
                                      • 0
                                        Приехали.
                                        FC (FCP), iSCSI, AoE — это все SAN.
                                        По-крайней мере в этом уверены HP, Dell, EMC, Hitachi, Sun
                                    • 0
                                      Собственно, разделение хранилища (в 1.х) у них было сделано именно через LVM. Что касается нормального хранилища — их форум в помощь, отвечают быстро и разумно.

                                      За 2.х, правда, не скажу (пока только тестирую), но, уж раз мы говорим об opensource, никто не мешает попробовать, написать в их же wiki статью, и тем расширить знания сообщества.
                                    • 0
                                      Можно использовать DRBD вместо SAN, хотя SAN рекомендуется.
                                      • 0
                                        Можно, но страшновато. Ещё одна точка отказа, причём малопредсказуемая.
                                        • 0
                                          Точка отказа? Мне кажется наоборот, это ведь зеркало по сети. Представьте если SAN откажет. DRBD это тоже самое, что два SAN-а в HA-кластере.
                                          • +1
                                            Представьте, если DRBD откажет. Где концы искать? А он отказывает, и надо либо своими силами его поддерживать, либо латную поддержку принимать, а она стоит как SAN.
                                            • 0
                                              Что делать если откажет SAN?
                                              • 0
                                                Чаще всего в стоимость сана входит поддержка с помощью и заменами на пару лет.
                                                • 0
                                                  Я не совсем вас понимаю.

                                                  Есть два сервера, между ними DRBD. Допустим сгорел сервер (блок питания или что там ещё), т.к. сервер на поддержке, его чинят. Тем временем DRBD работает на оставшемся сервере.

                                                  Тоже самое с саном (правда SAN всего один, поэтому пока SAN чинят работа стоит).

                                                  Если что-то происходит на урофне файловой системы, то тут поддержка не поможет, только бэкапы могут спасти.
                                                  • 0
                                                    Что-то случилось, drbd не поднимается, устройство не создаётся. Куда бежать? С SAN — понятно.
                                                    • 0
                                                      Вопрос из разряда «система не грузится, куда бежать». Производитель поддерживает железо, за данные вы отвечаете сами, будь то SAN или Сервер.
                                                      • 0
                                                        Не совсем: за SAN и относящийся к нему софтотвечает вендор. За линукс, или вмвару, предположим, тоже. Ну, или сам я курсы продвинутые закончил, и к ремонту готов.
                                                        Включая тот же kvm и lvm.

                                                        А drbd?
                                                        • 0
                                                          За софт отвечает, а за данные нет.
                                                • 0
                                                  Для понимания, что такое _простенький_ SAN.
                                                  Это два БП и два супервизора минимум + если архитектор не ****** то это два коммутатора и multipathing т.е. это полное дублирование.
                                                  • 0
                                                    Если откажет SAN, то у вас доле быть backup. Если точка отказа очень кретична, можно делать снэпшоты самой карзины на iscsi (можно поднять на nas, или взять linux и поднять самому). Если корзина выходит из строя по гарантии, то ее производитель меняет давольно шустро. Ну или как вариант две корзинки в зеркале =) Но как по мне это перебор уже.

                                                    Я сечас пробую glusterfs в виде nfs. Если все будет хорошо, то можно будет как временное решение, ели умерла корзинка.
                                                    • 0
                                                      Тоже самое и c DRBD, но плюс к этому в случае отказа одного из серверов 2-й можно использовать в одиночку до тех пор пока не будет восстановлен 1-й.
                                                      • 0
                                                        DRBD я сам люблю, но есть но!

                                                        1) производительность
                                                        2) кол-во подключемых машин.

                                                        Нам нужна производительность и маштабируемость + быстрые (очень быстрые насколько это возможно) резервные копии.

                                                        у на сейчас 11 машин из proxmox, к сожелению сделать это с drbd нельзя.
                                                        • 0
                                                          > 1) производительность
                                                          С этим у нас проблем не было, но мы и не web-хостинг и не дата-центр.

                                                          > 2) кол-во подключаемых машин.
                                                          Разумеется DRBD в режиме мастер мастер может быть установлено только на два хоста. Каждой задаче своё решение и наоборот. Нам больше двух хостов в кластере не нужно.
                                                          • 0
                                                            мы то е начинали с drdb, но быстро выросли. Просто san это отличное решение, етественно надо понимать для чего оно вам нужно и как с этим работать.

                                                            Если вернутся к бэкапам, то у san с этим проблем нет.
                                                            • 0
                                                              У нас тоже нет проблем с бэкапом. У нас три кластера по два хоста в разных сетях. Если мы будем к каждому прикручивать SAN, то это будут неоправданные расходы в нашем случае.
                                                              • 0
                                                                у на сделанно switch l3 — который делит сети
                                                                все машины на 1 класторе.
                                                                по сути 1 SAN на все машины.

                                                                каждый получает кусок того, что ему положенно.

                                                                Хотя я сам буду тестировать связку glusterfs (будет цеплятся как nfs), что бы попробовать снизить затраты.
                                                                • 0
                                                                  У нас так нельзя, сети должны быть физически разделены.
                                                                  • 0
                                                                    Ну опять же вам виднее и у каждого заказчика свои причуды.
                                        • +1
                                          Все у proxmox нормально с SAN. Если linux видет ваш FC контроллер, то все будет работать с proxmox через lvm. Мы так с ранних бет и используем в продакшене.
                                    • 0
                                      Что вы имеете ввиду? По каким протоколам?
                                      • 0
                                        HA требует еще и fencing — управляемый коммутатор питания или сети, насколько я понял. Т.е. Просто на нодах HA не построить, а жаль. Не понятно — ведь разделяемое хранилище является узким местом по надежности. Ну что может случиться с нодой ну сгорит блок питания… Та их там несколько как правило. Встанет кулер на проце… Маловероятно на том железе. Чаще всего сбои связаны с дисками. И этот узел у нас один. Да raid — но несколько нод каждая с raid ИМХО надежней.
                                        • 0
                                          Построить можно и без ничего, только считается, что смысла в этом нет, т.к. надёжность такого комплекса будет крайне низкой.
                                          • 0
                                            Почему только надежность? Нужно обеспечить зеркало дисков на каждой ноде — тут проблема скорее в производительности.
                                            • 0
                                              Зеркало не снижает производительность, а вариант RAID 1+0 ещё и увеличивает её.
                                              • 0
                                                Я имел ввиду репликацию.
                                          • 0
                                            Если у нас серверы, набитые виртуалками, то давайте так посчитаем надёжность запуска всех виртуалок:
                                            Представьте, что вероятность сбоя сервера либо системы хранения одинаковая. Тогда вероятность сбоя отказоустойчивого кластера равна вероятности сбоя системы хранения ну и плюс вероятность одновременного сбоя нескольких серверов (больше избыточности), которой пренебрежём. А вероятность сбоя кластера без системы хранения равна сумме вероятностей сбоев одиночного сервера. 10 одиночных серверов получается в 10 раз менее надёжны, чем 10 серверов плюс система хранения. Конечно, если мы считаем, что кластер работает если все виртуалки на нём работают. Если можно какое-то количество виртуалок потерять на большое время — то конечно одиночные сервера лучше. Если сервер с бэкапами не вылетит, конечно — а сами подумайте, tuk надёжность выше чем надёжность системы хранения?
                                            • 0
                                              Не понятно почему вы складываете вероятности выхода из строя серверов без общей системы хранения, если сервера в HA кластере находятся врежиме горячего резерва и только один является активным. (в самом простом случае)Выход из строя резервного узла вообще к ничему не приводит — он просто увеличивает вероятность сбоя.
                                              • 0
                                                рассматривать систему из двух узлов нет смысла — там всё по другому, а в системе из N узлов примерно как я написал и получается. Да и горячий резерв — это либо один сервер на 10 активных, что не сильно портит расчёты, либо вообще все сервера активные.
                                              • 0
                                                Извините, но я ничего не понял.
                                                Если считать надёжность сервера и надёжность SAN одинаковыми (нормальный рейд, два БП и т.д.), то два сервера в зеркале надёжнее чем один SAN, т.к. при выходе одного из серверов за короткое время все виртуальные машины запускается на втором, т.к. диск (DRBD) у них общий с одними и теме же данными. А первый сервер тем временем восстанавливается.
                                                • 0
                                                  Насчёт надёжности системы из двух узлов вообще надо рассуждать отдельно. Например как вы определяете вышел ли один из узлов из строя, чтобы переключиться на третий, как определяется надёжность самого DRBD, что делать при ошибках синхронизации и так далее. В случае с SAN всё более определённо.
                                              • 0
                                                fencing у них сделан средствами RedHat, все что можно настроить в RedHat для HA, можно настроить и для proxmox. Например использовать ILO HP для HA proxmox.

                                                И еще дополнение, для всего этого надо 3 машины :)

                                                По поводу корзины, есть разные методы как сделать ее резервной.
                                                Мы использует корзины HP Storage P2000 в зеркале + бэкапы всегда готовы включится по iscsi через nfs + запись на ленту.
                                                • 0
                                                  fencing прекрасно работает на любой IPMI карте. То есть DRAC/iLO/RSA/IMM/… в каждый из серверов и все.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.