Comments 40
К сожалению статья ничего не описывает использование Xen Cloud Platform в условия предприятия, скорее похоже на словарь терминов.
Ну, это же ещё начало цикла статей. Посмотрим, что будет дальше.
Я только начал. Я не люблю американский подход (когда сначала «как сделать», а потом объяснение как это получилось), мне ближе европейский подход (сначала объяснить как это получится, а потом показать как это делается). Терминология нужна, потому что дальше на ней будет основываться всё остальное.
> когда содержимое виртуальных машин и виртуализатор управляется одной и той же организацией
Таки «содержимое виртуальных машин и виртуальная инфраструктура»?
Таки «содержимое виртуальных машин и виртуальная инфраструктура»?
> XCP — единственная бесплатная и свободная
Может калибр не тот, но все же еще есть Proxmox VE
Может калибр не тот, но все же еще есть Proxmox VE
Скедулер наверное хочет быть планировщиком в этой стране, но это мелочи.
На самом деле стиль повествования похож на доисторическую манеру ведения лекций для студентов младших курсов о чём-нибудь очень для них далёком: там тоже начинали с терминов — «Вы запишите сначала термины, а то непонятно будет». ИМХО термины должны появляться по мере необходимости, а то и заменяться словами «механизм», «структура» и прочими, до тех пор, пока не будет необходимости дать термин.
Ждем то самое «ту би континьюд». ;-)
На самом деле стиль повествования похож на доисторическую манеру ведения лекций для студентов младших курсов о чём-нибудь очень для них далёком: там тоже начинали с терминов — «Вы запишите сначала термины, а то непонятно будет». ИМХО термины должны появляться по мере необходимости, а то и заменяться словами «механизм», «структура» и прочими, до тех пор, пока не будет необходимости дать термин.
Ждем то самое «ту би континьюд». ;-)
>>Хосты (в случае, если их больше одного) должны быть строго одинаковыми — одинаковый степпинг процессора, материнская плата и т.д.
Это никаким образом не обходится?
Это никаким образом не обходится?
В клауде ещё не пробовал а в XenServer можно убедить машины с разными CPU войти в пул. Миграция тогда часто становится возможна лишь в одну сторону. У меня например машина запушщенная на Pentium D дуалкоре мигрирует на Core2Duo, а вот наоборот умирает, т.к. набор фич и инструкций у процессоров разный
Обходится. Можно сказать «принять машину в пул силком», но у этого могут быть сильно печальные последствия, если у процессоров будет разная интерпретация данных (например, список доступных инструкций). Больнее всего это стукнет во время миграции.
А нигде нет хотя бы по процессорам допустимых направлений переходов?
да и по материнкам-чипсетам не мешало бы.
Дабы понимать с какого железа на какое все же можно перейти и в каком направлении.
да и по материнкам-чипсетам не мешало бы.
Дабы понимать с какого железа на какое все же можно перейти и в каком направлении.
Причины по CPU мне прекрасно известны, хотя отсутствие ограниченного фичер-сета для такого применения огорчает.
Меня больше интересует требования к материнской плате и прочим комплектующим, кроме само собой разумеющегося что «так будет лучше ибо одинаково», есть ли действительно каки-либо ограничения в самом ксене.
Вопрос не праздный, камрады собираются две стойки блейдов виртуализировать (Win* экосистема, я есстесно в качестве нативного предлагаю Hyper-V, они хотят Xen (правда аргументировать выше «нравится» и «просто» не могут)), соответственно хотелось бы узнать заранее pro/cons.
Меня больше интересует требования к материнской плате и прочим комплектующим, кроме само собой разумеющегося что «так будет лучше ибо одинаково», есть ли действительно каки-либо ограничения в самом ксене.
Вопрос не праздный, камрады собираются две стойки блейдов виртуализировать (Win* экосистема, я есстесно в качестве нативного предлагаю Hyper-V, они хотят Xen (правда аргументировать выше «нравится» и «просто» не могут)), соответственно хотелось бы узнать заранее pro/cons.
Наверное, про материнки никто и не скажет толком… С большой вероятностью это связано с особенностями северного моста каждой из них. Хотя, попытаться можно, наверное.
Основная идея запрета на различия платформ: лучше не экспериментировать.
Я hyper-v настолько не знаю, чтобы говорить о его серьёзном сравнении с зеном. Однако, HVM хуже PV для зена. Если голые винды без намёков на линуксы, ставить hyper-v и грызть мозг майкрософту. Совмещать opensource подход и надменную проприентарщину будет просто психологически тяжело.
Основная идея запрета на различия платформ: лучше не экспериментировать.
Я hyper-v настолько не знаю, чтобы говорить о его серьёзном сравнении с зеном. Однако, HVM хуже PV для зена. Если голые винды без намёков на линуксы, ставить hyper-v и грызть мозг майкрософту. Совмещать opensource подход и надменную проприентарщину будет просто психологически тяжело.
Разве HVM медленeе PV? Я думаю, что все наоборот. У нас не нужны облока, поэтому выбрали KVM и по синтетическим тестам он пошустрее
UFO just landed and posted this here
Не так. В HVM привелегированные инструкции перехватываются гипервизором с помощью механизма исключений (то, что VT/pacifica предоставляет), а в PV ядро НИКОГДА не выполняет привилегированных инструкций, делая вместо них гипервызовы. HVM может так же делать гипервызовы, но они обычно делаются только драйверами, а ядро свои операции выполняет силком — это приводит к некоторому пенальти в работе (и это свойство всех «принудительных» виртуализаторов, хоть VMWare, хоть Hyper-V).
странно, на одной и той же машине KVM работает лучше, чем Xen HVM/PV.
Что означает «лучше» и на каком ядре?
Ядро 2.6.18 CentOS. В Xen начинались жуткие тормоза при 12-13 виртуальных машинах под нагрузкой, kvm держал до 15-16.
Какой нагрузкой? Процессор? Диск? Память? Сеть? Жуткие тормоза начинались в какой области и у кого? Какие скедулеры использовались?
freshmeat.net/projects/dbench/
виртуалки не откликались ни по сети(легкий вебсервер местного написания с отображением статики), ни по ssh
Все по дефолту, т.к. планировалось еще запускать FreeBSD и возможно Windows.
виртуалки не откликались ни по сети(легкий вебсервер местного написания с отображением статики), ни по ssh
Все по дефолту, т.к. планировалось еще запускать FreeBSD и возможно Windows.
А как оно работает с IB? Ну там всякие RDMA-over-IB, MPI и тому подобное?
RDMA и т.д. будут работать только для dom0. В XCP в принципе не поддерживается прокидывание железа в домены (для возможности лёгкой миграции между хостами). Единственная поблажка, которую я знаю, это netfront2, позволяющий использовать tcp offloading для domU с карточками, которые в курсе наличия нескольких виртуальных устройств (откровенно, я эту часть плохо читал, там как-то хитро сделано, что сетевуха поддерживает несколько независимых потоков, которые раздаются гостевым системам).
… Хотя, возможно, я часть, связанную с blktap2 ещё просто не расковырял, там могут быть интересные фичи.
… Хотя, возможно, я часть, связанную с blktap2 ещё просто не расковырял, там могут быть интересные фичи.
А как ISCSI SR экспортирует блочное устройство?
Для каждого диска виртуальной машины свое устройство или
одно блочное устройство на всех и какая то специальная файловая система?
Догадываюсь что ответ где то в райное PBD…
PS. Ваша статья для меня выглядит как многообещающее начало. Спасибо.
Для каждого диска виртуальной машины свое устройство или
одно блочное устройство на всех и какая то специальная файловая система?
Догадываюсь что ответ где то в райное PBD…
PS. Ваша статья для меня выглядит как многообещающее начало. Спасибо.
SR не экспортирует устройство. PBD создаёт локальное блочное устройство для хоста. SR — это всего лишь список PBD на разных хостах.
Локальное же блочное устройство делается обычным iscsi-initiator.
Локальное же блочное устройство делается обычным iscsi-initiator.
Ага.
Так вот это локальное блочное устройство,
через него хост имеет доступ к всем VDI из своего пула?
Так вот это локальное блочное устройство,
через него хост имеет доступ к всем VDI из своего пула?
Не совсем так. Локальное блочное устройство с точки зрения XCP называется PBD. Оно входит в SR. VDI расположен на SR. Если хост решает, что VBD виртуальной машины ссылается на указанный VDI, а VDI расположен на указанном SR, то он использует свой PBD для получения доступа к VDI.
Самих SR может быть много, так же как и PBD.
Самих SR может быть много, так же как и PBD.
Sign up to leave a comment.
Xen Cloud Platform в условиях предприятия [1]