Pull to refresh

Comments 31

Не подскажете, может кто знает, он почему «клауд» в названии имеет? Поддерживается живая миграция виртуалки с одной железяки на другую?
Да, разумеется. Более того, он позволяет обновить версию всего XCP без выключения виртуалок (совершенно головоломный процесс).
А может ли виртуалка «расползаться» по нескольким нодам?
Прозрачно и святым духом? Нет. В остальном есть NUMA, которая это позволяет. Если не знаете, что это такое, вам это не нужно.
В отдалённых планах есть о чём-то таком подумать, но нужно понимать, что в большинстве случаев речь идёт не о «чём-то гигантском», а о честной нарезке на машины существующих мощностей.
SSI дает только не только масштабирование, но и быстрое мигрирование в случае проблемы с железом. Или Xen это уже позволяет сделать?
Сегодня тестировал скорость работы с дисковой на 2 гипервизорах.

Бой был Oracle VM (Xen) vs VMware. Измерял скорость линейной записи (dd) и рандомно чтение-запись (IO benchmark IOzone с ключем — а). На ксене ВМ установлены в паравиртуально, а на ВМваре полность виртуально. Хост одинаковый. BL460c G6 64Gb. Массив EVA8400 по SAN
Тестировал в разное время суток, сумарно по 5 раз каждый тест, т.к. нагрузка на дисковый массив может влиять на результаты. VMware проходила тест с IOzone в среднем на 20% быстрее Oracle VM, а у Oracle VM линейная скорость записи было больше на 10%. Т.к. в 99% случаев чтение-запись рандомно важнее для общем производительности ВМ, то VMware в моих тестах выглядела привлекательно. + У VMware отличный перворманс в ВМ на Windows.
А Xen выигрывает ценой (бесплатностью) и если виртуализировать только Linux в PV.

Честно, я бы даже предпродакшн клауд на Xen не делал. Да уж простят меня Xen'офилы Хабра.
Э… что в бэкэнде-то было? Понятно, что если через loop гонять, то можно и совсем смешно увидеть.
В бэкенде была OCFS2. ОС доменов хранилась в img-файлах.
Вы неправильно поняли что такое «backend». Драйверы диска в Xen'е состоят из двух половинок — front-end (в виртуальной машине) и back-end, который делает всю осмысленную работу (в dom0).

Соответственно, что было в качестве бэкэнда? blktap? blktap2? loop?

Дальше — был ли включен thin allocation? Он особо херов в случае sparsed-файлов на некоторых FS.
Скорее всего, вы небрежно провели тест, и малоосмысленные результаты, принимать решения по которым очень опрометчиво. Разница в random IO у различных систем виртуализации крайне мала и нивелируется тем, что время, которое тратят физические перемещения головок на многие порядки превышает любые возможные задержки на границе между виртуальной и хост-машиными.

Разница, которую получили вы, вызвана разными настройками очереди диска у виртуальных машин, и различием в флагах открытия дискового устройства (direct IO vs file IO с кэшированием).
Ну, реально, если задаться целью криво настроить зен, можно сделать такой бэкэнд, который будет тормозить.

Но в XCP используется blktap (очень шустрая штука), а 1.0 blktap2 (ещё серьёзно не щупал). Собственно, у нас облако работает на XCP, и я могу сказать, что на облаке aptitude update/upgrade (без предварительного кеширования) пролетает раз в 5 быстрее, чем на системном диске того хранилища, которое виртуалку хранит :) То есть к производительности дисков я претензий назвать не могу.
Дело не совсем в том, что при неправильной настройке у xen диск может тормозить, а в том, другие получают преимущество за счет неявного использования памяти хоста.

В виртуализаторах, использующих эмуляцию устройств — vmware, vritualbox, qemu — диск для виртуальной машины на хосте по умолчанию открывается как обычный файл, с включенным дисковым кэшем, расположенным в памяти хостовой ОС. И кэш работает не только для файловых бэкендов, но и для нормальный блочных устройств, типа lvm-разделов или напрямую дисков. В таком случае все запросы из гостя к диску идут через кэш хоста и скорость random IO для такого гостя будет больше, чем для гостя, работающего с диском без хостового кэша.

Если тестируемый диск сделать небольшим, скажем, 1 Гб, у гостя сделать память 64 Мб, а у хоста свободной памяти будет несколько ГБ, то разница между госятми, работающими напрямую с диском, и через кэш хоста, будет уже на порядки.

Но использование кэша на хосте — это, чаще, недостаток, чем премущество, т.к. вместо четкого выделения памяти и разделения ресурсов между гостями, один ресурс — дисковый кэш хоста, становится неконтроллируемый. Можно считать, что выделение памяти для гостевых машин получается не четко N Mb, а N Mb + сколько там можно будет урвать у хоста, конкурируя с другими машинами.
В qemu можно отключить использование кеша хоста.
Можно. Правда, при использовании в качестве диска файловых имиджей, лучше не отключать, т.к. производительность сильно деградирует — гость о файле ничего не знает и пытается оптимизировать порядок запросов, как обычному линейному диску.
Да, мне тоже показалось, что это имеет смысл в случае хранилища на разделе или LVM.
У нас, например, кеширование активно используется. Просто конкуренция честная, кто обедает, тот и танцует. А наша задача сделать так, чтобы всем хватало.
Ну если целенаправленно для чего-то так решили делать, возможно, вам оно нужно. Хотя на стандартных ядрах при больших дисбалансах в дисковой активности гостей, машины с низким использованием IO страдают заметно.

Не понял про «Просто конкуренция честная, кто обедает, тот и танцует.» — вы тарифицируете использование дискового кэша хоста?
Нет, мы тарифицируем IOP'ы и объём прокачанных данных. В результате кеш для них — это исключительно _наш_ кеш, который снижает _нам_ затраты на предоставление этих иопов клиентам. Кроме того, у нас кеш на на хостах (на хостах память, которая продаётся клиентам), а на хранилищах.
А при чем здесь кэш файл-сервера? Человек тестировал на обычной машине с локальным диском и разница в использовании или не использовании под кэш памяти хоста. А кэш на диске, контроллере, или файловом сервере для этого случая на результат не повлияет.
В исходном возмущении вообще не ясно, так как человек не сказал, через какой бэкэнд работали с дисками домены.

А дальше я просто объяснил, как мы решили проблему «чей кеш».
Если скорость random IO выше при более низкой скорости линейной записи, то единственной причиной этого может быть присутсвие дискового кэша вне виртуальной машины в первом случае, и его отсутствие во втором, и это может быть только дисковый кэш хоста. Надеюсь, это не нужно объяснять еще более подробно. Или нужно?

Информация о том, что вы используете кэш на файловых серверах, безусловно, интересна и оригинальна. Правда, я не вижу того, как это связывается с утверждением, что отдавать память хоста под дисковый кэш гостей редко когда приносит пользу.
На истину в последней инстанции я не претендую. Хотелось стравнить именно гипервизоры по производительности, чтобы понять, что реально быстрее без замыленого взгляда. Я хотел как-то померить этого «сферического коня в вакууме» на каких нибуть бенчмарках, чтобы понять, кто реально быстрее.

Что посоветуете?
В этой ситуации мы имеем большую проблему: Xen не обеспечивает блочные устройства. Xen — гипервизор и только. Он управляет процессором, прерываниями, памятью, временем и всё.

Соответственно, именно производительность Xen'а в PV не отличима от производительности хоста без гипервизора (я сам тестировал).

Дальше там идёт userspace, который делает сеть и диски. Есть минимум 4 разных метода сделать сеть и 5 (или больше?) методов сделать диски. Соответственно, под разные задачи используются разные методы.

Дальше ещё интереснее. Всякие технологии snapshot'ов позволяют «сделать» машину (диск) мгновенно, но накладывают пенальти при операциях чтения записи.

Использование thin allocation приводит к снижению производительности при первой записи (особенно в случае vhd-файлов).

И т.д.

Если хотите тестировать производительность, описывайте конфигурацию виртуальной машины и гипервизора.
>>
Соответственно, именно производительность Xen'а в PV не отличима от производительности хоста без гипервизора (я сам тестировал).

Как тестировали? Хочется тоже замерить пенальти, накладываемые на домены гипервизором.
Ну, тестировать в зене можно ровно три вещи:

1) скорость работы железа (с пробросом PCI)
2) скорость работы процессора
3) скорость передачи информации между доменами (IDC) — именно его используют все виртуальные железки.

По пунктам. 1 — не тестировал, но верю, что быстро (ибо нет причин быть медленным).

2 — тестировал простой нагрузкой на процессор. Причём, как в свободном режиме (когда загружается на 100% один домен при максимуме VCPU соответствующем CPU), так и в конкурирующем режиме, соответствующем нескольким загруженным на 100% доменам с полным комплектом VCPU). Разница была столь малой, что иногда погрешность измерения показывала, что под зеном быстрее в пределах десятых долей процента. Берёте любую числодробилку а ля superpi и считаете фиксированную задачу (количество знаков), а время вычисления — результат. В случае конкурирующего доступа суммируется время во всех доменах и делится на количество доменов.

Самое интересное — 3. Напрямую его тестить сложно, придётся писать mad skillz код, так что есть решение проще — 10G. Я взял домен, подключил его к виртуальной сети, соединенённой на 10G и посмотрел на скорость iperf'ом. Я получил около 8Гбит/с, что близко к максимальной скорости работы с 10G на голом хосте. (кстати, я сейчас подумал, что тоже самое можно было бы сделать между двумя виртуалками в pure virtual network — так данные были бы чище).

Вот и всё.
Удобно ли бэкапить виртуальные машины на XCP?
Решаем вопрос о внедрении в продакшен этого хозяйства.
Опыт работы с Citrix Xen Server в этом плане крайне негативный (снапшоты удалются, но место не высвобождается, экспорт VM делается крайне медленно и нагружает диски, и т.д.). Как дела у XCF?
В 1.0 с этим, вроде бы, стало полегче, хотя я в снапшоты глубоко пока не зарывался.
Sign up to leave a comment.

Articles