October 15th, 2013

404

kvm strategy

Или, если точнее, продолжение известного спора Танненбаума с Линусом.

Как я говорил ранее, Xen - фактически является пуристской реализацией того, о чём говорил Танненбаум. Микроядро, которое передаёт между сервисами сообщения (events в контексте зена), управляет сервисами (доменами), памятью, распределением процессорного времени, прерываниями, и, как выяснилось, ещё и временем. Сама инфраструктура зена продолжает развиваться (по крайней мере в планах) на построение stub domains, и всё большее число всяких "baremetall" окамлов/эрлангов и т.д., позволяющих запустить единственное приложение на домен, начинают окончательно размывать концепцию гипервизора и делать из него просто микроядро, управляющее процессами.

Альтернативной стратегией, причём не по формальным критериям, а по идеологическим, является Hyper-V и KVM. Поскольку ничего хорошего про MS мы говорить не будем, то остановимся на KVM.

Идеология KVM строится на том, что "гость" - это всего лишь ещё один рядовой процесс. С некоторыми тонкими нюансами и ассистингом со стороны ядерного модуля для hvm. Но важно, что он не несёт в себе ничего специального для самого линукса. Процесс и процесс. Для которого предоставляется весь спектр насыщенных функций монолитного ядра.

При том, что я сейчас (ещё не разобрался до конца с вопросом, но в процессе изучения) нахожусь при мнении, что блочные и сетевые устройства KVM примерно в 2 раза тормознее xen'овых (я про самый нижний уровень, то есть ещё до бриджа и всяких qcow2/vhd), мне кажется, что второй подход, при всей своей идейной нечистоте, или лучше даже сказать, безыдейности, несёт в себе важную вещь: visualization is not a big deal. Для того, чтобы начать пользоваться виртуализацией в зене надо посвятить ему всё и вся. Целиком компьютер. Зен главный, dom0 - равный среди равных. Идейно всё хорошо, на практике "выживание утопающих дело рук самих утопающих". То есть зену пофигу на проблемы доменов, они должны сами выкручиваться в сложившейся ситуации как хотят. Так что зен - это всегда dedicated computer. Вы не можете иметь зен в режиме "иногда поиграться с виртуалочками". Отношения по памяти между зеном и dom0 очень сложные и там трудно ожидать свободного трансфера неограниченных объёмов памяти между dom0 и xen'ом. В силу того, что балунинг всё ещё сосёт и сосать будет (проблемы гостей гиперивзор не ...волнуют), то "отъел от dom0 95% памяти для виртуалок" будет несбыточной мечтой, сопровождающейся всякими хаками класса dom0_mem при загрузке.

Это же ощущается и в разработке. Xen - он сам по себе. И разработка линукса под зен - "задача второго порядка", то есть менее приоритетная, чем разработка самого гипервизора.

У KVM'а же ситуация обратная. Разработка гипервизора вторична по сравнению с операционной системой. Более того, даже разработка операционной системы вторична по отношению юзерспейсу - Линус про это много раз ругался, когда кто-то посягал на API breakage. И именно в этом месте находится их главное отличие.

Xen - типичный computer science, в котором идея/теория работает сама на себя. Она важнее, чем её прикладные проявления. Если прикладная задача научилась использовать нашу штуку - ну просто супер. Если нет - ну и что, идея-то всё равно хорошая.

KVM - сугубо прикладной комплект технологий, нацеленный на решение проблемы. И если красоту алгоритмического решения придётся сильно исказить ради удобства userspace, то так оно и будет. Если у алгоритма не нашлось практического применения - и нафига нам такой "полезный" алгоритм? (точнее, даже не так, нет смысла писать алгоритм, который не решает конкретную задачу).

Я даю KVM'у большой кредит доверия тут, особенно с поправкой на моё скромное знание KVM. Но я более чем насмотрелся на последствия зенового подхода - когда rock solid hypervisor куда важнее, чем кривой скрипт управления блочным устройством, портящим данные во время глюков ядра в одном из доменов. Хотя с потребительской точки зрения "насрать на rock solid hypervisor, где мои данные?" куда более животрепещущий вопрос - но ведь гипервизор важнее.
404

разница в IO/CPU xen/kvm

Я только что осознал, что моя предыдущая позиция "kvm жрёт очень много CPU на io", мягко говоря, ошибочная. Речь про virtio, разумеется, всякие qemushnie emulatsii мы пропускаем как несерьёзные.

Так вот, как я смотрел на CPU? Ну, примерно как в зене. Брал высокую нагрузку (сеть или IO) в чистом виде (то есть подальше от остального стека), смотрел сколько CPU жрут крупные процессы в системе. В случае с xen'ом это было просто: netback, blkback/tapdisk на каждый интерфейс/диск, и сколько он жрёт, столько это стоит dom0 по процу.

Но ведь в зене CPU гостей намертво исключено из всяких top'ов внутри dom0. А в kvm - нет. Так что видеть, "ой, в dom0 начали жрать 300% CPU на 50к IOPS" - это не то же самое, что в зене. Потому что CPU гостя в этом списке так же будет.

Так что часть тестов сейчас придётся переделывать.