выбрать тип виртуализации

Слова для поиска: virtualization

Нужно выбрать тип виртуализации чтобы потом не пришлось решать проблемы связанные с переездом / миграцией. Переустанавливать систему, заново конфигурировать и т.п.

Коммерческие решения для виртуализации хороши в корпоративной среде и особенно при недостатке квалификации у обслуживающего персонала. Однако для систем массового хостинга они получаются неоправданно дороги и заметных технических преимуществ не имеют.

Потому здесь речь в основном об открытых и свободных платформах виртуализации - KVM, OpenVZ и XEN.

Каждый тип виртуализации хорош по своему, но имеет и свои недостатки.

Я попытаюсь выделить свойства значимые для пользователя сервера чтобы Вы могли сделать верный выбор.

OpenVZ свободно распространяется на условиях лицензии GNU GPL v.2. и является базовой платформой для Virtuozzo — коммерческого продукта Parallels.

OpenVZ — это реализация технологии виртуализации на уровне операционной системы, которая базируется на ядре Linux. OpenVZ позволяет на одном физическом сервере запускать множество изолированных копий операционной системы, называемых Виртуальные Частные Серверы (Virtual Private Servers, VPS) или Виртуальные Среды (Virtual Environments, VE).

Главная особенность - одно общее ядро для всех контейнеров. Это определяет основные свойства, накладывает некоторые ограничения и обеспечивает особые возможности.

Низкая стоимость. Представьте себе такую аналогию - ваш автомобиль (сервер здесь как аналог автомобиля) едет без груза (мало клиентов) со скоростью ограниченной транспортным потоком (клиент читает страницы вашего сайта последовательно и не быстро). Поэтому большую часть времени большинству автомобилей (виртуальных серверов) нужна небольшая мощность и грузоподъемность. Система виртуализации OpenVZ способна динамически распределять ресурсы процессора и памяти между всеми виртуальными серверами и каждый сервер использует ровно столько ресурсов, сколько ему необходимо. Незанятые ресурсы остаются свободными. Потому хостинговые компании могут размещать на одном физическом сервере под OpenVZ больше виртуальных серверов чем под любой другой системой виртуализации. Хотя можно подумать, что в этом случае продается то чего нет, но это профанация ибо свободные не занятые ресурсы в системе OpenVZ всегда есть. Если же реальные ресурсы на сервере исчерпаны, то производительность падает настолько резко, что не заметить нельзя. Например если заканчивается память, то скорость работы своппамяти определяемая скоростью диска и это очень заметно. OpenVZ выгодна хостинговой компании и это оборачивается выгодой для клиентов ибо стоимость таких VPS самая низкая.

Высокая производительность. А теперь снова вернемся к аналогии описанной выше. На ваш автомобиль загрузили 40 тонн груза и освободилось шоссе (на ваш сервер пришло много клиентов и резко возросло количество запросов). Ваш автомобиль получил мощность целой колонны грузовиков (openvz выделил вам все ядра CPU, всю гарантированную память (oomguardpages) и еще немного (privvmpages) для разгона) и помчался со скоростью ограниченной правилами движения (суммарной скоростью всех внешних каналов связи). Таким образом вы получили заметно больше чем оплатили. И это выгодно

Узкое место технологии OpenVZ - относительно медленная работа с диском. Эта проблема в принципе работы этой системы. В качестве хранилища данных в OpenVZ используется общая файловая система - террабайты данных. Ядро системы выделяет каждому контейнеру лимит на долю этого пространства и контролирует каждый запрос к файловой системе - не выходит ли он за пределы заданной квоты. Процесс проверки не так уж быстр. Все контейнеры порождают огромное количество запросов на запись и чтение которые генерируют значительную дополнительную нагрузку на ядро за счет этих проверок.

Вторая проблема связанная с файловой системой - общий дисковый кэш. Контейнеры с наиболее активным дисковым вводом/выводом вытесняют из дискового кэша данные других контейнеров.

Общая виртуальная память - swap. OpenVZ дает возможность использовать swap виртуальным серверам, но на уровне хост-машины. В связи с этим есть проблема - swap в OpenVZ не срабатывает как демпфер нагрузки. Например в случае прихода слишком большого количества клиентов запустится слишком много демонов apache и память закончится. OpenVZ просто убивает самый прожорливый процесс. Если это apache, то ничего страшного, а если mysqld, то ваш сайт перестанет работать. На практике не помню такого, но теоретически подобное возможно.

Прочие недостатки связаны с общим ядром и необходимостью изоляции каждого контейнера от «соседей».

У владельца гостевой системы ограничены возможности по использованию параметров ядра. Он не может использовать многие модули и функции ядра, не может сменить версию ядра.

У вас не будут работать NFS и IPSec. Например использование OpenVPN может вызвать крах системы - kernel panic. Если на уровне ядра случается серьезный сбой, то это крушит все гостевые системы.

Менее значительный недостаток - в гостевой системе может использоваться только Linux и только те версии которые предусмотрены администратором.

Xen — кросс-платформенный гипервизор, разработанный в компьютерной лаборатории Кембриджского университета. Свободно распространяется на условиях лицензии GPL и является базой для комерческой системы Citrix XenServer.

Использование паравиртуализации. Паравиртуализация — адаптация ядра гостевой операционной системы или использование специальных драйверов для возможности скоординированной работы с устройствами (диск, сеть) ядра Dom0 и гостя. Это резко снижает потери на виртуализацию. Виртуальная машина, если использует режим паравиртуализации, обладает производительностью, сравнимой с реальной машиной.

Использование любого типа ОС - Linux, Windows, FreeBSD и т.п.

Высокая изоляция контейнера от «соседей». Каждый гость использует свое ядро, свою файловую систему и т.п. Гости не делят память и диск. У каждого свое персональное ядро ОС. Совместно используются только процессоры. Но для каждого гостя может быть назначен приоритет для CPU или, в случае необходимости, закреплено отдельное персональное ядро процессора.

Персональный swap у каждого виртуального сервера. Например в случае прихода слишком большого количества клиентов запускается слишком много демонов apache и память заканчивается. Ядро системы внутри контейнера задействует виртуальную память, а так как она работает намного медленнее, то скорость работы системы замедлится, количество обрабатываемых запросов за единицу времени упадет и лишние копии демона будут выгружены по причине невостребованности. Память освободится. Таким образом за счет замедления работы в режиме активного использования swap система будет демпфировать нагрузку и не потеряет ни одного процесса.

Возможность миграции запущенной виртуальной машины между физическими машинами позволяет в случае обслуживания узла или перегрузки незаметно перемещать машину на другой узел.

Более высокая стоимость - главный недостаток. Это понятно. Не хочешь делиться, плати за то, что тебе не всегда нужно. Плотность размещения виртуальных машин под XEN будет существенно ниже чем на OpenVZ. Потому стоимость такого сервера оказывается близкой к стоимости физического сервера.

Генетические проблемы. XEN получил в наследство некоторый набор технических и лицензионных проблем. Техническая проблема заключается в том, что XEN является двухэтажной конструкцией - ядро xen выполняется в среде микроядра ОС Nemesis. То есть по сути Dom0 в XEN является привилегированным гостем который может управлять другими гостями. Это неизбежно увеличивает размеры потоков команд для функционирования гостевых систем, сдерживает производительность подсистем ввода/вывода и усложняет управление и контроль.

Лицензионная проблема в том, что хотя Nemesis распространяется на условиях The Nemesis Free License, система не является открытой технологией. Правообладатель сохраняет контроль над системой. И там замешаны интересы Microsoft. Это образует своеобразный капкан. Вероятно это было одной из причин для отказа Red Hat от участия в развитии XEN и переноса усилий на альтернативную технологию - KVM.

KVM (или Kernel-based Virtual Machine) — это программное решение, обеспечивающее виртуализацию в среде Linux. Распространяется на основе открытых и свободных лицензий и активно поддерживается и развивается усилиями сообщества свободных разработчиков и лидеров отрасли - HP, Intel, Red Hat, IBM.

Простота. KVM обладает всеми преимуществами XEN, но в добавок здесь есть простота. Простая загрузка модуля KVM превращает ядро Linux в гипервизор. Модуль ядра экспортирует устройство, называемое /dev/kvm, которое делает возможным гостевой режим ядра (вдобавок к обычным режимам ядра и пользователей). Каждое псевдоустройство /dev/kvm имеет свое собственное адресное пространство, отдельное от адресного пространства ядра или любых других работающих VM. Каждый виртуальный сервер представлен как отдельный процесс связанный с устройством /dev/kvm. Количество программного кода kvm минимально и, как следствие, потенциально меньше ошибок. Планировщики ядра в условиях большого количества VPS работают более плавно чем в XEN. Система работает быстрее. Контейнеры более отзывчивы на действия пользователя.

Рекордная производительность подсистем ввода/вывода. Актуальные версии имеют самые высокие показатели при одновременной высокой активности большого количества гостевых систем.

Потенциал развития. Производительность системы от версии к версии постоянно растет. А KVM - относительно очень молодой проект. Появляются новые технологии. Вероятно скоро можно будет задействовать механизмы дедупликации данных на уровне файловой системы BtrFS и дедупликацию оперативной памяти - KSM. Пока эти проекты недостаточно зрелые для широкого применения, но время идет. Дедупликация позволяет использовать один физический элемент для размещения блока данных в случае если существуют одинаковые блоки. А в случае работы множества почти одинаковых виртуальных серверов таких блоков может быть очень много. Это может увеличить плотность размещения виртуальных машин и снизить их стоимость.

Молодость. Эта технология быстро развивается и неизбежно содержит еще множество реальных и потенциальных проблем. Программные средства для управления KVM по возможностям пока уступают XEN.

Основная рекомендация - выбрать тип виртуализации в соответствии с текущим состоянием вашего проекта, этапом жизненного цикла, ближайшими и дальними перспективами с точки зрения средней и пиковой нагрузки на сервер.

Если мы обсуждаем вебсервер, то почти невозможно эти параметры привязать к количеству ваших пользователей или количеству одновременных подключений. Очень много зависит от конкретной программной реализации. Должны учитываться только данные локального мониторинга (загрузка процессора, load average, память, трафик, количество подключений, утилизация диска) и внешнего мониторинга доступности сервера.

У вас нет резких пиков нагрузки, количество клиентов относительно ровное то оптимальным решением обходиться недорогой виртуализацией OpenVZ и добавлять ресурсы по мере необходимости.

Когда Вы уже на максимальном тарифном плане и нагрузка заметно нарастает, то можно думать о миграции на физический выделенный сервер. Хотя это потребует существенных затрат, но при очевидном росте это экономически вполне оправданно. Следует заметить, что нередко финансовые вложения в программную оптимизацию дают больший эффект.

• Вы хотите использовать Windows или FreeBSD.
• Повышенные требования к доступности сервера в часы пик.
• Нагрузка резко меняется, не поддается прогнозам.
• У вашего сервера высокий трафик и большая нагрузка на диск.

Объективно оценить сложно. Разница в технических параметрах невелика.

Вероятно здесь важно оценить перспективы.

Мои личные предпочтения - KVM. Больше позитивных ожиданий.

Тестирование производилось путем одновременного запуска тестов apache benchmark на статическом и динамическом контенте c умеренной дисковой нагрузкой (rsync –bwlimit=5000) в цикле.

Оценивалось падение количества обрабатываемых запросов с ростом количества активных виртуальных серверов.

• OpenVZ
• Руководство пользователя Xen
• KVM
• KVM-XGU.RU
• KVM Вики
• Официальный сайт Qumranet — разработчиков KVM
• Узнайте об архитектуре и преимуществах KVM М. Тим Джонс, инженер-консультант, Emulex
• Почему KVM будет королем

—- Актуальность: 2011/08/29 16:58