В KVM ничего такого не было до появления механизма распределения ресурсов ядра . Как обычно в Linux, доступ к этим функциям был реализован посредством специальной файловой системы cgroup, в которой при помощи обычных системных вызовов write() можно было добавить процесс в группу, назначить ему его вес в попугаях, указать ядро, на котором он будет работать, указать пропускную способность диска, которую этот процесс может использовать, или, опять же, назначить ему вес.
Основной проблемой в реализации услуги в самом начале представлялось лимитирование ресурсов для виртуальных машин. В Xen эта проблема была решена при помощи внутреннего шедулера, распределяющего ресурсы между виртуальными машинами и что самое прекрасное, была реализована возможность лимитировать и дисковые операции в том числе.
Иногда к libvirtd по непонятной причине невозможно подключиться он перестаёт реагировать на внешние события.
Невозможность изменять часть конфигурации виртуальной машины на лету, хотя QMP ( ) это вполне позволяет.
Абсолютно невменяемые сообщения об ошибках.
Разумеется, решение не идеально. Из минусов libvirt следует назвать:
libvirt это система, которая хранит настройки виртуальных машин, управляет ими, ведёт по ним статистику, следит за тем, чтобы при старте у виртуальной машины поднимался интерфейс, подключает устройства к машине в общем, выполняет кучу полезной работы и еще немножко сверх того.
Для управления виртуальными машинами оказалось чрезвычайно удобно использовать libvirt и продукты, использующие ее API: virsh, virt-manager, virt-install, пр.
Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.
Также во внимание принимался факт наличия огромного количества разработчиков, хостеров, комерческих решений именно на базе Xen тем интереснее было провести в жизнь решение именно на базе KVM.
Замечу, что лично я не очень хорошо знаю Xen, его архитектуру и уж тем более мелкие особенности в основном я знакомился с ним в качестве гостя. Нет повода сказать, что Xen чем-то плох (потому, что он ещё не полностью вошёл в ядро, или у него что-то не так с производительностью, или еще по какой-то причине). Ничего определённого нельзя сказать и в плане производительности: в каких-то тестах KVM на 10-20 процентов опережает Xen по всем показателям, а где-то выигрывает Xen. Фактически, на текущий момент они практически сравнялись по функционалу, производительности, надёжности. И в принципе, не за горами тот день, когда Xen также войдёт в ядро. Уже вошёл в состав ядра
При выборе технологии виртуализации рассматривались два варианта Xen и KVM.
В планах имеется публикация репозитория с пакетами.
Мы же, повторюсь, решили использовать Debian Squeeze с набором пакетов из Sid/Experimental и некоторыми пакетами, бэкпортированными и собранными с нашими патчами.
Если вы планируете самостоятельно развернуть инфраструктуру, используя аналогичные технологии, я бы посоветовал взять именно RHEL: благодаря хорошей документации и хорошо написаным прикладным программам это будет если не на порядок, то уж точно раза в два проще, а благодаря развитой системе сертификации без особого труда можно будет найти некоторое количество специалистов, на должном уровне знакомых в данной ОС.
Почему ? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед Red Hat Enterprise Linux у него нет, но было принято решение работать со знакомой системой.
В этой вступительной статье я расскажу вкратце обо всех программных средствах, использованных в процессе разработки услуги. Более подробно о них будет рассказано в следующих статьях.
Как и , начинаю серию статей о том, как мы делали услугу аренды выделенных серверов на базе .
Работа с виртуальными машинами KVM. Введение
Работа с виртуальными машинами KVM. Введение / Хабрахабр
Комментариев нет:
Отправить комментарий