После более чем года разработки увидел свет (http://blog.xen.org/index.php/2012/11/27/xcp-1-6-releases/) релиз Xen Cloud Platform 1.6 (http://xen.org/download/xcp/) (XCP (http://www.xen.org/products/cloudxen.html)), развиваемой силами сообщества разработчиков Xen платформы для развертывания и управления работой облачной инфраструктуры. XCP можно использовать как автономное решение для развертывания сервиса аренды виртуальных серверов, приватных cloud-окружений и инфраструктур промышленной виртуализации, так и как базис для наращивания функциональности и создания новых программных решений, построенных поверх кодовой базы XCP.
Консолидация серверов предприятия и их размещение без привязки к физическому оборудованию в инфраструктуре виртуализации позволяет повысить гибкость, увеличить безопасность и понизить затраты, за счет более рационального расходования ресурсов (аппаратное обеспечение не простаивает и нагружается равномерно, новые серверы докупаются по мере необходимости, каждый сервис не пересекается в ОС с другими сервисами и запускается в отдельном окружении). Поддержка стандартных API в платформе XCP дает возможность в случае непредвиденных проблем, например, при нехватке мощности оборудования в пиковые моменты, перенести часть «облака» во внешние системы, такие как Amazon EC2, Rackspace Cloud Servers или GoGrid. Технология XenMotion позволяет организовать работу высоконадежных конфигураций, за счет горячего резервного копирования виртуальных машин и совместного использования разделяемых ресурсов.Платформа XCP является свободным (GPLv2) ответвлением от продукта Citrix XenServer (http://www.opennet.me/opennews/art.shtml?num=35008). Разработчики гарантируют, что XCP всегда будет доступен под свободной лицензией и все части проекта будут открыты. Загрузочный пакет XCP оформлен в виде готового iso-образа (http://xen.org/download/xcp/index_1.6.0.html#install) (400 Мб), основанного на CentOS и адаптированного для быстрого развертывания хост-системы (Dom0). В комплект входят все необходимые драйверы и модули для поддержки популярных cloud-инфраструктур. Для дистрибутивов Debian и Ubuntu предоставлена (http://wiki.xen.org/xenwiki/XAPI_on_debian) возможность установки штатного инструментария XenAPI из специального репозитория, что позволяет на базе Debian и Ubuntu создать вариант сервера виртуализации, полностью функционально эквивалентный стандартному дистрибутиву XCP.
Ключевые улучшения, добавленные в Xen Cloud Platform (XCP) 1.6:- Поддержка технологии Storage XenMotion (http://wiki.xen.org/wiki/Storage_XenMotion), позволяющей переносить работающие виртуальные окружения с одного сервера на другой без необходимости использования общего хранилища. При использовании Storage XenMotion при выполнении live-миграции производится перенос непосредственного содержимого связанных с окружением виртуальных дисков. При этом миграция возможна не только в рамках одного пула ресурсов, но и между разными пулами. Перенос виртуальных дисков производится без остановки работы окружения - вначале создаётся снапшот, который копируется в фоне, при этом наблюдаемая после создания снапшота дисковая активность параллельно синхронизируется на новый хост в режиме зеркалирования. Кроме live-миграции Storage XenMotion также открывает новые возможности для резервного копирования и позволяет избавиться от простоя инфраструктуры при необходимости обновления оборудования хранилищ;
- Возможность Live-миграции VDI-образов (Virtual Disk Image), позволяющая перемещать между серверами VDI-образы работающих окружений без остановки их работы. Например, можно перемещать окружения с локального хранилища на более быстрые и надёжные массивы хранения данных, перемещать образы из тестовых систем в рабочие окружения, распределять образы по другим серверам при нехватке места, выполнять обновления дисковой подсистемы без остановки работы размещаемых виртуальных машин;
- Поддержка протокола Link Aggregation Control Protocol (LACP), который может использоваться для организации работы отказоустойчивых систем и балансировки нагрузки. Возможность объединения до 4 сетевых карт в один виртуальный высокопроизводительный сетевой интерфейс с интеллектуальной балансировкой нагрузки;
- Организация разграничения трафика виртуальных машин через привязку к MAC-адресам, без использования VLAN-ов. В настройках виртуальной машины можно ограничить для заданного MAC-адреса отправку и приём пакетов только для указанных IP-адресов;
- Увеличена масштабируемость виртуальной сети на основе VLAN-ов, устранены ранее присутствующие ограничения, тормозящие развёртывание инфраструктур с большим числом используемых VLAN-ов. В XCP 1.6 указанные проблемы устранены и системы с сотнями VLAN-ов могут быть запущены в пуле XCP очень быстро;
- Поддержка IPv6 для госетвых систем;
- Механизм экстренного восстановления работы сети, позволяющий быстро восстановить работоспособность сетевой подсистемы хоста, вернув её в изначально рабочее состояние;
- Поддержка работы в роли гостевых систем новых версий дистрибутивов: Ubuntu 12.04; CentOS 5.7, 1.5, 6.1, 6.2; Red Hat Enterprise Linux 5.7, 6.1, 6.2; Oracle Enterprise Linux 5.7, 6.1, 6.2;
- Упрощён механизм настройки виртуальных CPU для управляющего домена dom0;
- Виртуальный коммутатор Open vSwitch, используемый для организации сетевого взаимодействия между виртуальными машинами, обновлён до версии 1.4.2;
- Поддержка до четырёх GPU на хост для проброса в гостевое окружение;
- Добавлены дополнения для обеспечения переносимости со сторонними инструментариями: асинхронный биндинг XenAPI для языка Си, расширения Workload Balancing (WLB);
- Поддержка мониторинга работы гипервизора (vhostmd), позволяющая запускать продукты SAP внутри XCP VM.
Общие особенности платформы XCP:- Единый управляющий интерфейс XAPI, написанный на языке OCaml и являющийся надстройкой над XenAPI, позволяет конфигурировать, распределять ресурсы и контролировать работу отдельных хостов и групп. Используя XAPI, сторонние производители получают возможность написания собственных модулей управления, например, уже реализовано несколько свободных и коммерческих GUI-интерфейсов для управления XCP.
В частности, доступен (http://wiki.xensource.com/xenwiki/XCP_Projects) широкий спектр дополнительных GUI-оболочек, таких как Citrix XenCenter (http://wiki.xen.org/xenwiki/XCP_Docs?highlight=%28XenCe...), Xen Orchestra (http://xen-orchestra.com/), Xen Cloud Control System (XCCS (http://www.xencloudcontrol.com/)), OpenXenManager (http://wiki.xensource.com/xenwiki/OpenXenManager), Xen Web Manager (http://sourceforge.net/projects/xenwebmanager/) и Zentific (http://wiki.zentific.com/index.php/Main_Page).
- Использование виртуального коммутатора Open vSwitch для организации сетевого взаимодействия между виртуальными машинами;
- Готовый к промышленной эксплуатации полнофункциональный управляющий инструментарий на базе Xen API;- Поддержка автоматического восстановления после сбоев;
- Поддержка горячего копирования снапшотов без остановки работы запущенных окружений (Live snapshot), контрольные точки (checkpoint) и прозрачная миграция окружений с одного сервера на другой;
- Возможность автоматической миграции окружений при нехватке ресурсов или для их балансировки; автоматическое конфигурирование; автоматическое восстановление работы окружений на других хостах в случае сбоя сервера;
- Гибкие инструменты управления хранилищами, сетевыми настройками и питанием (power management);
- Отслеживание событий: оценка прогресса выполнения операций и поддержка уведомлений;
- Шифрование потоков информации с использованием SSL;
- Средства для массового обновления систем и установки патчей;
- Мониторинг производительности и уведомление о проблемах в реальном режиме времени;
- Поддержка бесшовной интеграции с последним релизом cloud-платформы Openstack (http://www.opennet.r...URL: http://blog.xen.org/index.php/2012/11/27/xcp-1-6-releases/
Новость: http://www.opennet.me/opennews/art.shtml?num=35437
Господа, поделитесь плюсами и минусами от пользования XCP в продакшне.
Интересует именно практический опыт.
Благодарю.
Плюсы: работает. Надежно и устойчиво. Умеет запускать линуксовых гостей на серверах со старыми камнями, не имеющими аппаратной поддержки виртуализации.Минусы: при объединении машин в кластер весьма требователен к конфигурации. Проще говоря, все серверы, входящие в кластер, должны быть идентичными (на практике чуть-чуть смухлевать можно, но гарантий устойчивой работы - никаких). Не имеет ни одной вменяемой морды управления, кроме виндовой Citrix XenCenter.
Из-за последних двух минусов переехали на kvm и, в целом, весьма довольны.
> Плюсы: работает. Надежно и устойчиво. Умеет запускать линуксовых гостей на серверах со
> старыми камнями, не имеющими аппаратной поддержки виртуализации.
> Минусы: при объединении машин в кластер весьма требователен к конфигурации. Проще говоря,
> все серверы, входящие в кластер, должны быть идентичными (на практике чуть-чуть
> смухлевать можно, но гарантий устойчивой работы - никаких). Не имеет ни
> одной вменяемой морды управления, кроме виндовой Citrix XenCenter.
> Из-за последних двух минусов переехали на kvm и, в целом, весьма довольны.Премного благодарен за Ваш ответ. У меня сейчас хозяйство из примерно 5-ти нод в кластере под управлением Proxmox VE 2.2 с порядка 30-тью виртуалками (как правило - убунту сервер) и несколькими сугубо Hight Availability виртуалками, под которые отдано по 2 сервера.
Работает это всё на КVM.
Столкнулся с неведомой проблемой - делая ночные бекапы раз в неделю (чаще нету смысла) гипервизор наглухо виснет, причём - проверялось на абсолютно другом, даже не идентичном железе, но одинаковой архитектуры (x86_64, coreI7) процессора. Гугление толком ни к чему не привело, потому и думаю о возможной миграции на что-то другое. Не исключена кривизна моих рук, правда заводилось всё штатно, без напильника и кусачек.
А ситриксовый ксенсервер - это тот же ХЦП, только в профиль, насколько я понял?
> А ситриксовый ксенсервер - это тот же ХЦП, только в профиль, насколько
> я понял?Абсолютно верно.
Опишите проблему с бэкапами подробнее.
>> А ситриксовый ксенсервер - это тот же ХЦП, только в профиль, насколько
>> я понял?
> Абсолютно верно.
> Опишите проблему с бэкапами подробнее.Всё просто - запланированный бекап в воскресенье в 4:00. Каждая виртуалка (100,101,102, ...) саспендится по очереди, делается полный бекап (у меня их почему-то по 5 штук на виртуалку) виртуалки, после чего она резюмится и работает дальше, а гипервизор переходит к следующей. После того, как гипервизор бекапнул первую виртуалку - его клинит на второй, после чего высыпается в кернел паник и висит пока я не прихожу и ребучу его руками. Вторая виртуалка, разумеется, висит в состоянии "Locked. Backup" и мне приходится её руками разлочивать и запускать. И неважно какой сервер идёт вторым - ситуация одна и та же. Никакого сжатия не применяется. Такие вот пироги. Если делаю руками бекап каждой виртуалки отдельно - всё нормально.
>[оверквотинг удален]
> ...) саспендится по очереди, делается полный бекап (у меня их почему-то
> по 5 штук на виртуалку) виртуалки, после чего она резюмится и
> работает дальше, а гипервизор переходит к следующей. После того, как гипервизор
> бекапнул первую виртуалку - его клинит на второй, после чего высыпается
> в кернел паник и висит пока я не прихожу и ребучу
> его руками. Вторая виртуалка, разумеется, висит в состоянии "Locked. Backup" и
> мне приходится её руками разлочивать и запускать. И неважно какой сервер
> идёт вторым - ситуация одна и та же. Никакого сжатия не
> применяется. Такие вот пироги. Если делаю руками бекап каждой виртуалки отдельно
> - всё нормально.Саспенд -> бэкап -> запуск - из этого делаю вывод, что машины у вас в виртуальных образах, а не в LVM-разделах, верно? А где виртуальные диски, на отдельном сетевом ресурсе?
>[оверквотинг удален]
>> работает дальше, а гипервизор переходит к следующей. После того, как гипервизор
>> бекапнул первую виртуалку - его клинит на второй, после чего высыпается
>> в кернел паник и висит пока я не прихожу и ребучу
>> его руками. Вторая виртуалка, разумеется, висит в состоянии "Locked. Backup" и
>> мне приходится её руками разлочивать и запускать. И неважно какой сервер
>> идёт вторым - ситуация одна и та же. Никакого сжатия не
>> применяется. Такие вот пироги. Если делаю руками бекап каждой виртуалки отдельно
>> - всё нормально.
> Саспенд -> бэкап -> запуск - из этого делаю вывод, что машины
> у вас в виртуальных образах, а не в LVM-разделах, верно?Так точно. Виртуалка селится на выбранной мною ноде и живёт там до смерти :).
> А где виртуальные диски, на отдельном сетевом ресурсе?
Виртуальные диски на нодах. Бекап на гипервизоре, на отдельном физическом диске.
Если нужно её мигрировать ну другую ноду - я это делаю руками путём переноса виртуального диска на другой сервер, но это до сих пор ни разу не приходилось делать. Все 5 нод абсолютно идентичны по аппаратной начинке.
> Так точно. Виртуалка селится на выбранной мною ноде и живёт там до
> смерти :).Возможно, LVM-раздел был бы лучшим выбором. Впрочем, в данном случае, скорее всего, дело не в этом.
Если у вас последняя версия ядра, я бы порекомендовал вам попробовать откатиться на одну-две версии. Но только не забывайте все бэкапить по максимуму перед экспериментами.
Уважаемые коллеги, имеющие опыт работы с Proxmox 2.2 подскажите пожалуйста, у вас web интерфейс работает нормально? Я сейчас в процессе выбора гипервизора и управлялки к нему. На тестовом сервере поднял Proxmox 2.2 появилась проблема, через несколько дней в web интерфейсе управления перестают работать все грфики отображения загруженности (CPU,mem,net...). И в левой панеле все виртуальные сервера отображаются как выключенные (мониторы с чёрным экраном). Но при этом все виртуальные сервера работают нормально. Может кто подсажет с чем это связанно и/или как это исправить?
Обратитесь к их форуму. Такая проблема наблюдалась после релиза, быстро поправили. Сам я на 2.2 еще не переходил.
Была такая проблема, после последних апдейтов вроде ушла, не забывайте вовремя обновляться :)
> Плюсы: работает.а есть возможность сделать Fault Tolerance (миграцию вместе с образом памяти в случае падения)?
>> Плюсы: работает.
> а есть возможность сделать Fault Tolerance (миграцию вместе с образом памяти в
> случае падения)?Да, но я уже не помню, где искать нормальную информацию по развертыванию HA кластера с использованием выделенного NAS. Вот посмотрите, здесь про drbd написано, по логике можно догадаться, как сделать нормально, через NAS:
http://wiki.xen.org/wiki/XCP_HowTo,_Index_of#High_Availability
>>> Плюсы: работает.
>> а есть возможность сделать Fault Tolerance (миграцию вместе с образом памяти в
>> случае падения)?
> Да, но я уже не помню, где искать нормальную информацию по развертыванию
> HA кластера с использованием выделенного NAS. Вот посмотрите, здесь про drbd
> написано, по логике можно догадаться, как сделать нормально, через NAS:
> http://wiki.xen.org/wiki/XCP_HowTo,_Index_of#High_Availabilityда меня и через DRBD вполне устроит. я не уверен, что смогу nas в разные дц разнести.
посмотрите в сторону remus.
Из минусов - при использовании drdb падает производительность дисковой на 30-50%
спасибо, я в гугле тоже про remus нашел.
мне спрашивал у тех, кто точно знает, что конкретно эта сборка XEN и версия содержит все необходимое.
С пол-года пробовали эксплуатировать XCP 1.5 beta в варианте с 2-я нодами и shared storage на drbd (тоже 2 ноды), с подключением по lvm over iSCSI (один из вариантов, который умеет XCP). Выявили примерно такие проблемы:* при изменении размера диска vm надо ручками ресайзить файловую систему
* низкая скорость i/o (запись) в гостевой системе (~13 Мб/с по сравнению с ~50 Мб/с на голом iSCSI, сеть 1 Гбит)
* multipath в варианте с drbd реализуется ручками (т.е. если iSCSI-портал не анонсирует два адреса)
* при удалении vm VDI (образ диска vm) не удаляется
* сложность и запутанность управления с помощью xe cli
* не удалось сделать автозапуск виртуальных машин при загрузке нод (например после power failure)
* встроенный high-availability отказывался включаться, кажется с сообщением что он ещё не имплементирован, или может запрашивал пакет расширений
> * при изменении размера диска vm надо ручками ресайзить файловую системуА как иначе?
> * multipath в варианте с drbd реализуется ручками (т.е. если iSCSI-портал не анонсирует два адреса)
С drbd вообще сложно, практически в любой популярной платформе виртуализации.
> * сложность и запутанность управления с помощью xe cli
Это да, с uuid'ами там просто ад.
> * не удалось сделать автозапуск виртуальных машин при загрузке нод (например после power failure)
Эту возможность в 1.5 выпилили из управления через GUI, включалось через консоль.
> * встроенный high-availability отказывался включаться, кажется с сообщением что он ещё не имплементирован, или может запрашивал пакет расширений
А это, если мне память не изменяет, конфликт между Citrix XenCenter (судя по описанию, вы использовали именно его) и версией XCP 1.5 . У них в вики было описание действий, необходимых для того, чтобы полностью подружить XenCenter и XCP.
>> * при изменении размера диска vm надо ручками ресайзить файловую систему
> А как иначе?Гм, ну да, иначе только в openvz.
>> * не удалось сделать автозапуск виртуальных машин при загрузке нод (например после power failure)
> Эту возможность в 1.5 выпилили из управления через GUI, включалось через консоль.Я пробовал включить так:
- глобально: xe pool-param-set uuid=xxx other-config:auto_poweron=true
- per-vm: xe vm-param-set other-config:auto_poweron=true uuid=xxxНи то ни другое не сработало.
>> * встроенный high-availability отказывался включаться, кажется с сообщением что он ещё не имплементирован, или может запрашивал пакет расширений
> А это, если мне память не изменяет, конфликт между Citrix XenCenter (судя
> по описанию, вы использовали именно его) и версией XCP 1.5 .
> У них в вики было описание действий, необходимых для того, чтобы
> полностью подружить XenCenter и XCP.Нет, никакого xencenter, пробовал включить через cli, как описано мануале по xen server. Интересно, смотрю в мануал по XCP (Xen Cloud Platform Administrator's Guide Release 0.1 ) - и не вижу там секции "high availability".
RedHat и Убунту (тоже вроди) перешли на KVM.
Видать не зря. Какая выгода от нового Ксена?
> RedHat и Убунту (тоже вроди) перешли на KVM.
> Видать не зря. Какая выгода от нового Ксена?http://theinvisiblethings.blogspot.ru/2012/09/how-is-qubes-o...
We think Xen is unique because it combines an elegant architecture (type I, baremetal, hypervisor) with a number of practical features, such as power management, support for Intel VT-d and driver domains, support for both para-virtualizaed, and fully-virtualized VMs, and many more, not found in e.g. academic microkernels/hypervisor projects, that otherwise seem attractive from the architecture point of view.
Много интересного про Xen vs KVM можно найти в http://qubes-os.org/files/doc/arch-spec-0.3.pdfXen hypervisor is very small comparing to Linux kernel (KVM), which makes it substantially easier to audit for security problems. Xen allows to move most of the “world-facing” code out of Dom0, including the I/O emulator, networking code and many drivers, leaving very slim interface between other VMs and Dom0. Xenʼs support for driver domain is crucial in Qubes OS architecture. KVM relies on the Linux kernel to provide isolation, e.g. for the I/O emulator process, which we believe is not as secure as Xenʼs isolation based on virtualization enforced by thin hypervisor. KVM also doesnʼt support
driver domains.
> Xen hypervisor is very small comparing to Linux kernel (KVM), which makes
> it substantially easier to audit for security problems. Xen allows to
> move most of the “world-facing” code out of Dom0, including the
> I/O emulator, networking code and many drivers, leaving very slim interface
> between other VMs and Dom0. Xenʼs support for driver domain is
> crucial in Qubes OS architecture. KVM relies on the Linux kernel
> to provide isolation, e.g. for the I/O emulator process, which we
> believe is not as secure as Xenʼs isolation based on virtualization
> enforced by thin hypervisor. KVM also doesnʼt support
> driver domains.С точки зрения безопасности в теории вроде все верно, но на практике уязвимости, позволяющие выполнить код из гостя в основной системе, в xen'e пока что встречались чаще.
> С точки зрения безопасности в теории вроде все верно, но на практике уязвимости, позволяющие выполнить код из гостя в основной системе, в xen'e пока что встречались чаще.предоставьте ссылку(и) на источник ваших данных, пожалуйста
> предоставьте ссылку(и) на источник ваших данных, пожалуйстаНовости на опеннете хотя-бы :). Как ни странно, дырок в xen находилось, невзирая на его казалось бы скромный размер.
они изначально kvm продвигали
У Xen установка паравиртуальных драйверов изменяет реестр Windows и метод работы с жестким диском. Соответственно если вдруг понадобится загрузиться как с IDE то возникнут проблемы в виде выпадания в синий экран. Попробуйте например без танцев с бубном обновить Windows 2003 Standard на Enterprise. В KVM-же просто меняется тип диска с virtio на ide и загружается как IDE.
Вы просто не умеете его готовить.
hint: "ioemu:hda" vs "hda"
Вы виртуализацию от паравиртуализации различаите?
А есть что то подобное но с возможностью использовать разные сервера и отсутствием централизованной файловой системы.
Основная проблема во втором вопросе, сколько не находил описания связок везде применяется или общее хранилище или DRBD(на сколько я понял нормально работает только в связке двух физических серверов).
> А есть что то подобное но с возможностью использовать разные сервера и
> отсутствием централизованной файловой системы.
> Основная проблема во втором вопросе, сколько не находил описания связок везде применяется
> или общее хранилище или DRBD(на сколько я понял нормально работает только
> в связке двух физических серверов).Использовать Ceph RBD. В kvm есть поддержка. В xen не знаю.
В RHEL 6.3 (и его клонах) появилась возможность в Cluster LVM использовать нормальные рейды, а не только LVM mirror. Можно на основе него сделать.
в свежем проксмоксе это добавляется. посмотрите его список изменений.
> А есть что то подобное но с возможностью использовать разные сервера и
> отсутствием централизованной файловой системы.
> Основная проблема во втором вопросе, сколько не находил описания связок везде применяется
> или общее хранилище или DRBD(на сколько я понял нормально работает только
> в связке двух физических серверов).Я не совсем понял, что именно нужно вам реализовать. Просто гипервизор, без fault tolerance? Так можно использовать локальное хранилище.
В общем пока уперся в проблему отстутсвия распределенного хранилища. DRDB связывает только два сервера. Хочу поставить пять машин и чтобы виртуальные машины мигрировали между ними свободно, но чтобы это реализовать требуется выделенное общее хранилище. И чтобы в эту систему можно было добавлять(убирать) физические сервера малой кровью. "Проект" некоммерческий, в большей степени учебный, поэтому машины под севера идут совершенно разношерстные.
> В общем пока уперся в проблему отстутсвия распределенного хранилища. DRDB связывает только
> два сервера. Хочу поставить пять машин и чтобы виртуальные машины мигрировали
> между ними свободно, но чтобы это реализовать требуется выделенное общее хранилище.
> И чтобы в эту систему можно было добавлять(убирать) физические сервера малой
> кровью. "Проект" некоммерческий, в большей степени учебный, поэтому машины под севера
> идут совершенно разношерстные.для KVM есть шикарнейшее решение -- sheepdog.
насколько оно заводимо под xen -- к сожалению не знаю.
> А есть что то подобное но с возможностью использовать разные сервера и
> отсутствием централизованной файловой системы.Proxmox'овцы тестируют ceph и sheepdog, но и та и другая в продакшн ещё не вышла (например, на форуме один тестер написал что после 200-т миграций виртуалка накрылась). Так что реально только DRBD. (glusterfs некоторые используют, но больше ругают).
Спасибо ответившим, я думал, что просто плохо искал... Оказывается искал нормально, ничего стабильного к сожалению нет.
Может кто подскажет вменяемый и работоспособный веб-менеджмент под libvirt для kvm?
На основном сайте конечно много информации, но хотелось бы услышать отзывы
> Может кто подскажет вменяемый и работоспособный веб-менеджмент под libvirt для kvm?
> На основном сайте конечно много информации, но хотелось бы услышать отзывыOpenNebula