Xen Cloud Platform в условиях предприятия [1]

[OlegSL]

К сожалению статья ничего не описывает использование Xen Cloud Platform в условия предприятия, скорее похоже на словарь терминов.

[RussianNeuroMancer]

Ну, это же ещё начало цикла статей. Посмотрим, что будет дальше.

[amarao]

Я только начал. Я не люблю американский подход (когда сначала «как сделать», а потом объяснение как это получилось), мне ближе европейский подход (сначала объяснить как это получится, а потом показать как это делается). Терминология нужна, потому что дальше на ней будет основываться всё остальное.

[OlegSL]

Надеюсь, что вы напишите цикл статей до логического конца. Тут часто бывает, что начнут, а продолжения нету или оно затягивается. Если это так, очень буду ждать завершения. Самому интересна данная тема.

[RussianNeuroMancer]

> когда содержимое виртуальных машин и виртуализатор управляется одной и той же организацией
Таки «содержимое виртуальных машин и виртуальная инфраструктура»?

[amarao]

Можно и так сказать. Сейчас поправлю.

[painEffect]

> XCP — единственная бесплатная и свободная

Может калибр не тот, но все же еще есть Proxmox VE

[past]

+1

[akme]

proxmox будет в разы интереснее когда они API доделают =)

[keir]

Скедулер наверное хочет быть планировщиком в этой стране, но это мелочи.
На самом деле стиль повествования похож на доисторическую манеру ведения лекций для студентов младших курсов о чём-нибудь очень для них далёком: там тоже начинали с терминов — «Вы запишите сначала термины, а то непонятно будет». ИМХО термины должны появляться по мере необходимости, а то и заменяться словами «механизм», «структура» и прочими, до тех пор, пока не будет необходимости дать термин.
Ждем то самое «ту би континьюд». ;-)

[amarao]

Я всё это ещё много раз объясню, но не зря на сайте xen'а в API нарисован кружочек со стрелками. Они все друг на друга завязаны, невозможно найти того, с кого можно начинать выстраивать цепочку терминов.

Где-то в районе понедельника запощу вторую часть.

[keir]

Супер.

[amc]

>>Хосты (в случае, если их больше одного) должны быть строго одинаковыми — одинаковый степпинг процессора, материнская плата и т.д.
Это никаким образом не обходится?

[TDz]

В клауде ещё не пробовал а в XenServer можно убедить машины с разными CPU войти в пул. Миграция тогда часто становится возможна лишь в одну сторону. У меня например машина запушщенная на Pentium D дуалкоре мигрирует на Core2Duo, а вот наоборот умирает, т.к. набор фич и инструкций у процессоров разный

[amarao]

Обходится. Можно сказать «принять машину в пул силком», но у этого могут быть сильно печальные последствия, если у процессоров будет разная интерпретация данных (например, список доступных инструкций). Больнее всего это стукнет во время миграции.

[postdig]

А нигде нет хотя бы по процессорам допустимых направлений переходов?
да и по материнкам-чипсетам не мешало бы.

Дабы понимать с какого железа на какое все же можно перейти и в каком направлении.

[amarao]

Офицальный ответ — «никаких переходов». Хосты должны быть одинаковыми. Неофицально — то, куда мигрируете машину, должно целиком и полностью уметь всё, что умеет то, откуда мигрируете. Как их сопоставлять и выяснять — я не знаю.

[amc]

Причины по CPU мне прекрасно известны, хотя отсутствие ограниченного фичер-сета для такого применения огорчает.
Меня больше интересует требования к материнской плате и прочим комплектующим, кроме само собой разумеющегося что «так будет лучше ибо одинаково», есть ли действительно каки-либо ограничения в самом ксене.
Вопрос не праздный, камрады собираются две стойки блейдов виртуализировать (Win* экосистема, я есстесно в качестве нативного предлагаю Hyper-V, они хотят Xen (правда аргументировать выше «нравится» и «просто» не могут)), соответственно хотелось бы узнать заранее pro/cons.

[amarao]

Наверное, про материнки никто и не скажет толком… С большой вероятностью это связано с особенностями северного моста каждой из них. Хотя, попытаться можно, наверное.

Основная идея запрета на различия платформ: лучше не экспериментировать.

Я hyper-v настолько не знаю, чтобы говорить о его серьёзном сравнении с зеном. Однако, HVM хуже PV для зена. Если голые винды без намёков на линуксы, ставить hyper-v и грызть мозг майкрософту. Совмещать opensource подход и надменную проприентарщину будет просто психологически тяжело.

[phasma]

Разве HVM медленeе PV? Я думаю, что все наоборот. У нас не нужны облока, поэтому выбрали KVM и по синтетическим тестам он пошустрее

[amarao]

Не так. В HVM привелегированные инструкции перехватываются гипервизором с помощью механизма исключений (то, что VT/pacifica предоставляет), а в PV ядро НИКОГДА не выполняет привилегированных инструкций, делая вместо них гипервызовы. HVM может так же делать гипервызовы, но они обычно делаются только драйверами, а ядро свои операции выполняет силком — это приводит к некоторому пенальти в работе (и это свойство всех «принудительных» виртуализаторов, хоть VMWare, хоть Hyper-V).

[phasma]

странно, на одной и той же машине KVM работает лучше, чем Xen HVM/PV.

[amarao]

Что означает «лучше» и на каком ядре?

[phasma]

Ядро 2.6.18 CentOS. В Xen начинались жуткие тормоза при 12-13 виртуальных машинах под нагрузкой, kvm держал до 15-16.

[amarao]

Какой нагрузкой? Процессор? Диск? Память? Сеть? Жуткие тормоза начинались в какой области и у кого? Какие скедулеры использовались?

[phasma]

freshmeat.net/projects/dbench/
виртуалки не откликались ни по сети(легкий вебсервер местного написания с отображением статики), ни по ssh
Все по дефолту, т.к. планировалось еще запускать FreeBSD и возможно Windows.

[phasma]

да и в принципе лучше сразу оговориться, что паравиртуализация меня мало интересовала из-за указанных выше FreeBSD и Windows. Т.к. оборудование под виртуализацию не освободилось, хотелось бы выбрать окончательно ПО.

[amarao]

FreeBSD прекрасно умеет работать в PV-режиме. Насчёт остального, нужно смотреть на guest tools (я откровенно хреново знаю HVM'ную часть, и точно знаю, что с ней геморроя из-за сопротивляющегося гостя куда больше).

[phasma]

буду ждать продолжения статей, надеюсь про разницу HVM и PV выйдет поскорее.

[amarao]

PV или HVM?

[divanikus]

А как оно работает с IB? Ну там всякие RDMA-over-IB, MPI и тому подобное?

[amarao]

RDMA и т.д. будут работать только для dom0. В XCP в принципе не поддерживается прокидывание железа в домены (для возможности лёгкой миграции между хостами). Единственная поблажка, которую я знаю, это netfront2, позволяющий использовать tcp offloading для domU с карточками, которые в курсе наличия нескольких виртуальных устройств (откровенно, я эту часть плохо читал, там как-то хитро сделано, что сетевуха поддерживает несколько независимых потоков, которые раздаются гостевым системам).

… Хотя, возможно, я часть, связанную с blktap2 ещё просто не расковырял, там могут быть интересные фичи.

[divanikus]

Я просто тогда слабо представляю как можно будет в виртуалку завернуть тот же GPFS без ощутимой потери производительности…

[amarao]

Откровенно, мы говорим за пределами моей квалификации. Я не работал с IB, так что сказать, что делают в этом случае в зене, не могу. Пока нагуглилось «SmartIO» (судя по всему, это как раз для работы с IB), но есть ли его поддержка в ядрах в XCP, и в каком оно статусе, я не знаю.

[dmitriko]

А как ISCSI SR экспортирует блочное устройство?

Для каждого диска виртуальной машины свое устройство или
одно блочное устройство на всех и какая то специальная файловая система?

Догадываюсь что ответ где то в райное PBD…

PS. Ваша статья для меня выглядит как многообещающее начало. Спасибо.

[amarao]

SR не экспортирует устройство. PBD создаёт локальное блочное устройство для хоста. SR — это всего лишь список PBD на разных хостах.

Локальное же блочное устройство делается обычным iscsi-initiator.

[dmitriko]

Ага.

Так вот это локальное блочное устройство,
через него хост имеет доступ к всем VDI из своего пула?

[amarao]

Не совсем так. Локальное блочное устройство с точки зрения XCP называется PBD. Оно входит в SR. VDI расположен на SR. Если хост решает, что VBD виртуальной машины ссылается на указанный VDI, а VDI расположен на указанном SR, то он использует свой PBD для получения доступа к VDI.

Самих SR может быть много, так же как и PBD.

[dmitriko]

спасибо