После одиннадцати месяцев разработки представлен (http://blog.xen.org/index.php/2011/03/25/xen-4-1-releases/) релиз свободного гипервизора Xen 4.1 (http://www.xen.org/products/xen_source.html). По сравнению с прошлым выпуском в Xen 4.1 внесено 1906 коммитов, в подготовке которых приняло участие 102 разработчика и 25 организаций. Кроме того, около 400 коммитов связанных с поддержкой Xen, было принято в состав основной ветки Linux-ядра. Ожидается, что интеграция оставшихся бэкенд-драйверов, необходимых для обеспечения работы Xen Dom0 из коробки, будет завершена в Linux-ядре 2.6.39.
Из ключевых улучшений (http://wiki.xen.org/xenwiki/Xen4.1) Xen 4.1 можно отметить:- Переработана архитектура и расширены возможности инструментария XL, заменяющего собой XM/XEND. XL базируется на использовании библиотеки libxenlight (http://blog.xen.org/index.php/2011/03/25/index.php/2009/11/0.../), предоставляющей простой и надежный управляющий API. Функционально XL эквивалентен...
URL: http://blog.xen.org/index.php/2011/03/25/xen-4-1-releases/
Новость: http://www.opennet.me/opennews/art.shtml?num=30034
Есть ли опыт использования у кого-то Xen в коммерческих целях? На сколько это надежно/стабильно? Можно ли начинать промышленное использование?
вообще-то только он реально в коммерческих целях и используется - и редхэтом (в котором хотят на kvm перейти), и ораклом (в котором остались на xen и переходить пока не думают), и в SLES/OES, и в Citrix XenServer.
реальная альтернатива сейчас это только вмваре.
вообще-то RH уже давно перешли на KVM. "пытаются" было где-то 3 года назад
не давно, а только с вышедшей недавно 6 версии.
> не давно, а только с вышедшей недавно 6 версии.KVM официально в RHEL с версии 5.4
фраза "перешла" - это когда xen'а не стало в списке поддерживаемых.
> фраза "перешла" - это когда xen'а не стало в списке поддерживаемых.а я думал разговор идет о использовании в коммерческих целях, в продакшен. потому что куча народа использует KVM именно так, с RHEL5.4 и выше.
ну, куча народу использует и xen на том же рэдхэте.
перешла - это перешла. окончательно и безповоротно.
> ну, куча народу использует и xen на том же рэдхэте.
> перешла - это перешла. окончательно и безповоротно.ну, внутренние гипервизоры все на KVMת так что да - перешла
речь шла о коммерческом использовании.
так что окончательно и бесповоротно (что не факт, тк в 39 ведре уже и ксен будет изкаропки. так что могут бэкпортировать, если сочтут что так теряют клиентов) перешла только с шестёрки.
Основное решение виртуализации от редхат, RHEV, вышло больше, чем "несколько месяцев" назад - до 6-ки точно - и оно построено полностью на базе KVM, xen там поддерживается только с точки зрения инструментов миграции с него :)
Если не считать разводил, которые вместо vds дают openvz/jail, то практически все vds'ы у современных хостеров работают на xen либо vmware. Причём у ксена там доля очень неслабая.
Hetzner, к примеру, даёт KVM.
Amazon Web Services на нем построены.
Использую как ксен, так и квм для виртуализации линукса и венды. Хост-система -- дебиан (сквиз, ленни). Вендовые виртуалки (w2k3) -- терминальные сервера 1С (v7.7, v8.1), линуксовые -- в основном дебиан, ленни и сквиз, для тестовых целей крутится пара виртуалок под центосью. Отказался от КсенСервер (Цитрикс) в пользу КВМ. Ксен оставил только там, где процессоры не поддерживают аппаратную виртуализацию. Решающей причиной перевода на квм с ксен-сервер была впечатляющая производительность КВМ и отсутствие заморочек с лицензиями и прочей сранью со стороны ксен-сервера. Проблем нет. Аптайм вендовых виртуалок -- месяцами :) Про линукс вообще молчу, они годами работают. Из недостатков свободного ксен-квм -- только отсутствие развитого вменяемого фронтэнда, хотя бы по типу ксен-центр для КсенСервера. Хотя сама либвирт достаточно развита, чтобы управлять удаленно, все-таки хочется полноценную веб-морду. Начал недавно играться karesansui, но до ума еще не довел. Городить огород с решениями типа oVirt не хочется.
Ну, скажем так, мелкие проблемы есть. К примеру, слёты ф/с и ошибки в них в случае остановки дочки с w2k3 не через механизмы этой самой дочки, а через xm. С kvm-ом таких проблем нет. Правда, kvm с virtio сливает по скорости работы с дисками неофициальным pv-драйверам для венды, с сетью такая же ситуация. Но, опять же, kvm работает более предсказуемо.
Если честно, ничего из описанного Вами не наблюдалось. Ставил PV драйверы для венды, но, по моим замерам, они ощутимо сливали драйверам виртио... В КВМ, опять же, для остановки виртуалок используются стандартные механизмы системы (просто нужно настроить некоторые политики), а не служба, устанавливаемая PV драйверами. Повторюсь -- мне важна была система, которая не уступала бы по производительности ксен-сервер с их драйверами. С КВМ это у меня получилось.
А, вы про КсенСервер. Я же про Ксен просто. КсенСервер не использовал.
> Ну, скажем так, мелкие проблемы есть. К примеру, слёты ф/с и ошибки
> в них в случае остановки дочки с w2k3 не через механизмы
> этой самой дочки, а через xm. С kvm-ом таких проблем нет.
> Правда, kvm с virtio сливает по скорости работы с дисками неофициальным
> pv-драйверам для венды, с сетью такая же ситуация. Но, опять же,
> kvm работает более предсказуемо.Да, у меня виртуалки на LVM. Может, это вносит свою лепту...
Используешь cache=none ?
нет, дефолт -- writethrough
> Да, у меня виртуалки на LVM. Может, это вносит свою лепту...У меня они на софтовом раиде, поверх него drbd, а там уже lvm lv под виртуалки. Но я предполагаю к лету на всех обслуживаемых узлах перейти на kvm.
В Xen Cloud Platform версии 1.0, которая три недели тому вышла, уже поддерживается цитрусовый ХенЦентер. Не полностью, в некоторых диалогах вылетает, но на 99% уже работает.
А Proxmox не прбовалали? http://pve.proxmox.com
Имхо, очень неплохая управлялка kvm + openvz в виде bare-metall инсталлера (based on Debian x64)
У Хеn ограничен список поддерживаемых ОС: Fedora, RH, SuSe(все), Windows.
> У Хеn ограничен список поддерживаемых ОС: Fedora, RH, SuSe(все), Windows.Вы, как и многие тут, путаете Xen и XenServer. У Xen таких ограничений нет.
Более 2 лет на Xen 3.2.1 работают 3 сервера в продакшене. Использовал до этого использовал OpenVZ, но по возможностям, производительности и универсальности мне понравился именно Xen.
про сроки выхода XCP на сабже не слышно?
Главная ссылка к новости (http://blog.xen.org/index.php/2011/03/25...)
OpenNews: Анонсирован выход Xen Cloud Platform 1.0
OpenNews: Рассматривается возможность возвращения поддержки Xen Dom0 в Fedora Linux
XCP до сих пор основан на Xen 3.x, когда перейдут на Xen 4.x пока не известно.
XCP 1.0 на Xen 3.4.2
http://www.xen.org/download/xcp/index.html
а интресуют хотя бы планы с сабжем на борту
К сожалению, этого не знаю. Использую голый Xen.
вот и я к_сожалению_не_знаю.
а хотелось бы прояснить, может кто в курсе. решение то интересное.
если вам нужно 30 виртуалок на разных тазиках то лучше использовать XEN, а если надо >30 виртуалок + кластерные фичи + у вас есть СХД блейды etc то альтернативы esx vmware просто нет
> если вам нужно 30 виртуалок на разных тазиках то лучше использовать XEN,
> а если надо >30 виртуалок + кластерные фичи + у вас
> есть СХД блейды etc то альтернативы esx vmware просто нетчто за чушь? что умеет вмварь чего не могут открытые решения? кроме, конечно, выписывания огромных счетов клиентам
Может уважаемый сэр покажет открытое решение (а впрочем, и любое другое не-vmware закрытое подойдет), где fibre channel умеет делать trunk из нескольких физических каналов? Пример: ставим на железо Linux (или Windows, тот же результат), получаем скорость чтения/записи Х (работает только один физический канал, остальные - резерв); ставим под ним vmware, скорость становится почти 4*Х (работают паралельно все 4 физических канала, которые есть).WWell,
если вы про вариант распределение нагрузки round robbin, то 4 параллельно работающих fc канала в esxi дают не суммирование скорости каналов, а переключение на следующий fc канал через каждые 1000 iops ( настройка по умолчанию ). так что скорость останется такой же, как и скорость одиночного fc канала.
Линуксовый малтипас в режиме актив-актив чем вам не подходит?
1. Подключаешь по FC диски ( http://www.cyberciti.biz/faq/howto-linux-see-new-fiber-chann.../ )
2. Делаешь RAID
3. PROFIT
>открытое решение (а впрочем, и любое другое не-vmware закрытое подойдет), где fibre channel умеет делать trunk из нескольких физических каналовmdadm или lvm дядя в помощь в случае FC, ну или стандартный 802.1ad в случае FCoE.
Внутри VmWare дядя тот же linux, те же механизмы, те же протоколы, те же драйвера, может что названия только другие, да значки™ стоят®, и агрегация там точно такая же.
>mdadm или lvm дядя в помощь в случае FCКакой mdadm, какой lvm, вы с дуба упали? Это делается через dm-multipath.
Не надо путать multipath с рейдом, это совершенно разные вещи.
Ну, во-первых, канал не будет 4Х. А, во-вторых, вам правильно указали на dm-multipath.
> если вам нужно 30 виртуалок на разных тазиках то лучше использовать XEN,
> а если надо >30 виртуалок + кластерные фичи + у вас
> есть СХД блейды etc то альтернативы esx vmware просто нетА пацаны из амазона не знают советов "эксперта", и поэтому крутят на ксене самое большое облако в мире.
>> если вам нужно 30 виртуалок на разных тазиках то лучше использовать XEN,
>> а если надо >30 виртуалок + кластерные фичи + у вас
>> есть СХД блейды etc то альтернативы esx vmware просто нет
> А пацаны из амазона не знают советов "эксперта", и поэтому крутят на
> ксене самое большое облако в мире.ага. и еще куча провайдеров помимо амазона. причем на KVM все больше и больше
посмотрите ganeti
сложный прдукт но того стоит,
например винда под ксеном работает лучше и быстрее.. (virtio надо тюненговать для нагруженных систем, а xen отдает все из коробки тем более паравиртуалные драва под винду лучше себя ведут)кластер ганети обеспечивает все что дает вмварь + куча разных интересных фиичь есть одно но... ввсяким любителям окошечного управления лучше не соваться... прдукт для тру админов имхо
> если вам нужно 30 виртуалок на разных тазиках то лучше использовать XEN,
> а если надо >30 виртуалок + кластерные фичи + у вас
> есть СХД блейды etc то альтернативы esx vmware просто нет
Парни мне лень спорить на этот счет
вы лучше сами заюзайте esx в продакшен и сравните сами. ESX очень и очень юзабельно, самые вкусные фичи лично для меня это vmotion, Fault Tolerant в аналогах реализованы они не так приятсвенно как в vmware.
> Парни мне лень спорить на этот счет
> вы лучше сами заюзайте esx в продакшен и сравните сами. ESX очень
> и очень юзабельно, самые вкусные фичи лично для меня это vmotion,
> Fault Tolerant в аналогах реализованы они не так приятсвенно как в
> vmware.такой умный, и такой ленивый, ну надо же? я пользовал ESX и проблем более чем хватало.
живая миграция есть во всех современных системах.
FT - маркетинговая чушь, с такими ограничениями, что все равно ничего серьезного под этим не запустишь. кроме того, с теми же ограничениями, ее делали под xen в свое время, но бросили эти глупости, когда увидели что в продакшен эту фигню не запустить.
>вы лучше сами заюзайте esx в продакшен и сравните самиЗаюзать в продакшене значит купить, ну не на одной же виртуалке гонять. А смысла покупать нет, так как тема тобой не раскрыта, удобства они индивидуальны, а реальных преимуществ в плане функциональности и масшатабируемости нет.
Ну и как всегда "эксперта" можно определить по маркетинговым словечкам vmotion™ вместо миграции.
"FT - маркетинговая чушь" ну не будьте вы таким упертым - шире на мир смотреть надо :)
понятно что на высоконагруженной vm использовать ft не выгодно, а зачастую и невозможно, но для vm с небольшой нагрузкой и очень критичной к простою FT очень эффективна и проста.
вы пишите у вас были нерешимые проблемы с esx от которых, как я понял, вы счастливо избавились в "открытых" решениях - можно более поподробнее эти моменты осветить?
> "FT - маркетинговая чушь" ну не будьте вы таким упертым - шире
> на мир смотреть надо :)и это я слышу от апологета вмвари, которые не только изо всех сил стараются запереть клиентов на своих решениях, чтоб они никогда не увидели ничего другого, но и запрещают публиковать бенчмарки и проблемы, под страхом решения лицензии, которая кстати стоит бешеных денег
> понятно что на высоконагруженной vm использовать ft не выгодно, а зачастую и
> невозможно, но для vm с небольшой нагрузкой и очень критичной к
> простою FT очень эффективна и проста.ВМ как таковая никому не нужна. важен сервис который там бежит. и во первых сервис можно держать в кластере, а во вторых, достаточно важный сервис обычно и так защищен, и ФТ оказывается не нужен.
> вы пишите у вас были нерешимые проблемы с esx от которых, как
> я понял, вы счастливо избавились в "открытых" решениях - можно более
> поподробнее эти моменты осветить?вы сначала осветите вашу позицию на тему "не хочу спорить"
потом поясните как же вы все равно спорите, после этого - через "не хочу" получается?
а потом покажите где я упоминал "нерешимые" проблемы? просто их было много, ничуть не меньше чем с альтернативными решениями, хотя казалось бы что за такие деньги, все должно быть идеально, не?
не надо ярлыки навешивать, я использовал и Hyper-V, сейчас использую XEN и vmware и если вы прочтете мой первый пост то увидите там мое собственное мнение сформированное на основе личного опыта и кстати свое мнение я никому не навязываю
to Dim я вас спросил какие у вас были серъезные проблемы? а вы поступаете чисто по еврейски отвечаете вопросом на вопрос.
to haha - попробую объяснить свой выбор
при мощностях современных серверов мне уже глубоко пофигу показания бенчмарков и прочие прес-релизы заказных пиписькомеров а ля "мы круче" кто бы их не публиковал. Для меня выбор любой системы стал определяться в первую очередь простотой эксплуатации уровнем надежности и временем реакции техподержки, а также уровнем квалификации обслуживающего ее персонала (чем проще - тем меньше можно платить инженеграм саппорта) - ну что доходчиво объяснил?
> не надо ярлыки навешивать, я использовал и Hyper-V, сейчас использую XEN и
> vmware и если вы прочтете мой первый пост то увидите там
> мое собственное мнение сформированное на основе личного опыта и кстати свое
> мнение я никому не навязываюпо категоричности поста этого не скажешь.
> to Dim я вас спросил какие у вас были серъезные проблемы? а
> вы поступаете чисто по еврейски отвечаете вопросом на вопрос.даже не буду на эту чушь реагировать.
> to haha - попробую объяснить свой выбор
> при мощностях современных серверов мне уже глубоко пофигу показания бенчмарков и прочие
> прес-релизы заказных пиписькомеров а ля "мы круче" кто бы их не
> публиковал. Для меня выбор любой системы стал определяться в первую очередь
> простотой эксплуатации уровнем надежности и временем реакции техподержки, а также уровнем
> квалификации обслуживающего ее персонала (чем проще - тем меньше можно платить
> инженеграм саппорта) - ну что доходчиво объяснил?
Э, как бы вам сказать. Дело в том, что "простота эксплуатации" это миф. Тем более в системах с таким горизонтом, как кластерные или облачные. Поэтому на уровне квалификации сэкономить за счёт некой "простоты эксплуатации" не выйдет. Это мой взгляд. На первые места, на практике, выходит адекватность и качество документирования сформированной системы и наличие в достаточном количестве методик обслуживания и, конечно же, наличие сообщества. Поэтому лучше вкладываться именно в квалификацию персонала, но не просто так, а ставя перед этим персоналом понятные и достижимые цели.
>при мощностях современных серверов мне уже глубоко пофигу показания бенчмарков и прочие прес-релизы заказных пиписькомеров а ля "мы круче" кто бы их не публиковал.Несколькими постами выше было всё наоборот.
>Для меня выбор любой системы стал определяться в первую очередь простотой эксплуатации уровнем надежности и временем реакции техподержки.
И шо вы хотите этим сказать? Что поддержку на Xen или KVM купить нельзя? Так это чушь, можно купить с любым SLA. Что уровень надежности меньше? Так опять ведь чушь. Что эксплуатация проще, так нет же — это продукты одной категории сложности.
>а также уровнем квалификации обслуживающего ее персонала (чем проще - тем меньше можно платить инженеграм саппорта)
Во-первых нет никакой корреляции между простотой программного обеспечения и квалификацией персонала а уж тем более заработной платой этого персонала. Это разные вещи.
Во-вторых любая "простая" технология при масштабирование внезапно становится очень сложной, с кучей критических ньюансов, которые не видны на малом масштабе.В-третьих, абсолютно не понятно на каких основаниях виртуализацию можно отнести к простым технологиям.
> - ну что доходчиво объяснил?
Это было не объяснение это было какое-то оправдание.