В настоящее время для виртуализации серверов применяются три основных подхода: физическое разделение, логическое разделение с использованием гипервизора, а также изоляция приложений с помощью средств операционной системы. Эти технологии различаются по степени дробления (granularity) при выделении ресурсов отдельным приложениям и по мере изолированности отдельных экземпляров (см. Рисунок 1). Так, физическое разделение на данный момент обеспечивает максимальное разграничение элементов на одном сервере. К примеру, при делении на три физических раздела сервер способен изолировать даже одну аппаратную ошибку от другой. Это сказывается на степени дробления, поскольку физическое разделение осуществимо лишь на основе процессора. Что же касается виртуализации приложений с помощью средств операционной системы, то в этом случае достигается наименьшая степень изолированности между приложениями, но наибольшая гибкость при распределении ресурсов с минимальными дополнительными затратами (Overhead).

Какая технология наиболее пригодна для конкретной задачи? Если приложение имеет критическую важность для деятельности предприятия, то по-прежнему рекомендуется прибегать к физическому разделению. Так, на одном сервере старшего класса можно параллельно использовать производственную систему и систему контроля качества. Если на производственной системе потребуется установить, к примеру, новый адаптер шины (Host Bus Adapter), его можно сначала протестировать в разделе обеспечения качества. В случае успешного прохождения тестов этот адаптер можно перевести в производственный раздел, даже не прерывая эксплуатации систем.

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

В настоящее время наиболее часто применяется следующая технология виртуализации: деление сервера на несколько логических разделов с помощью гипервизора. В каждом разделе можно установить собственную операционную систему. В основе метода лежит применение слоя абстрагирования, обычно называемого виртуальной машиной. Имеющееся аппаратное обеспечение абстрагируется в такой степени, что каждая операционная система видит «свой» сервер. Гипервизор позволяет виртуальным машинам осуществлять более тонкое распределение ресурсов по сравнению с физическим разделением, однако степень изолированности между отдельными инстанциями оказывается ниже. Аппаратный сбой способен привести к полному отказу всех экземпляров, в то время как в случае с физическим разделением пострадает лишь тот, в чьем разделе возникла ошибка. По этой причине для виртуализации с созданием логических разделов необходимо выбирать очень надежные серверы. Кроме того, важно учитывать, что операционные системы тоже потребляют ресурсы, а гипервизор может еще и отрицательно повлиять на выполнение операций ввода/вывода очень требовательными приложениями. В связи с этим имеет смысл заранее провести анализ и определить, действительно ли для каждого приложения требуется свой экземпляр операционной системы.

С ГИПЕРВИЗОРОМ И БЕЗ НЕГО

При наличии должной поддержки со стороны операционной системы приложения все равно можно виртуализировать с соответствующей экономией ресурсов, даже если операционная система на сервере работает без гипервизора. В этом случае под управлением операционной системы функционирует несколько «контейнеров». Внутри такого контейнера приложение может работать без ограничений, но выйти за его пределы не в состоянии. Преимущество очевидно: на сервере выполняется лишь одна операционная система, и только она потребляет ресурсы. Накладные расходы на организацию контейнеров составляют около 1% — независимо от их количества.

Недостаток такого подхода заключается в том, что все приложения должны быть совместимы с одной и той же операционной системой. Хотя в настоящее время уже появились разработки, позволяющие запускать в разных контейнерах приложения, предназначенные для разных версий одной операционной системы. Так, в Sun Solaris 10 можно создать контейнер для приложений, сертифицированных только для Solaris 8. Кроме того, поддерживаемые среды включают Solaris 9 или Linux.

Тесты производительности, где приводился бы анализ работы одного и того же приложения во всех трех сценариях, встречаются редко. Результаты тестирования в виртуальных средах вполне могут оказаться лучше результатов, полученных в случае использования физического аппаратного обеспечения. Однако это касается лишь таких приложений, которые не масштабируются на современных многопроцессорных и многоядерных серверах и поэтому не могут самостоятельно использовать предоставляемые ресурсы в полном объеме. Тогда применение нескольких виртуализированных экземпляров, на которых установлены такие приложения, дает гораздо более высокую суммарную производительность, чем выполнение одного экземпляра на реальном оборудовании с чрезвычайно малой загрузкой.

ТЕСТИРОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ

Рисунок 2. Центр управления Sun xVM Ops Center управляет физическими и виртуальными серверами через единый интерфейс.Тест производительности SAP-SD 2 Tier хорошо подходит для такого сравнения, потому что, во-первых, SAP-SD может масштабироваться на современном аппаратном обеспечении с многоядерными процессорами и без помощи виртуализации, а во-вторых, результаты тестирования на идентичном аппаратном обеспечении имеются для обеих вышеописанных технологий виртуализации (с использованием гипервизоров и контейнеров).

Производительность технологии физического разделения аналогична достигаемой при эксплуатации приложений без виртуализации, поэтому в этом сравнении мы не будем ее рассматривать. Результаты представлены в Таблице 1. Видно, что повышение производительности приложений при виртуализации достигает 36% за счет более экономного расходования ресурсов.

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

ОПРЕДЕЛЕНИЕ ЦЕЛЕЙ

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

Рольф Керстен — руководитель отдела маркетинга компании Sun Microsystems.

© ITP Verlag
Рисунок 1. Обзор традиционных технологий виртуализации.

Таблица 1. Результаты тестирования в Two-tier SAP Sales and Distribution (SD) Standard SAP SD Benchmark на основе SAP Enhancement Package 4 для приложения SAP ERP 6.0 (Unicode) от 26.08.2009: Sun Fire X4270 (2 процессора, 8 ядер, 16 потоков) 2800 SAP SD User, Intel Xeon x5570 2×2,93 ГГц, память 48 Гбайт, Oracle 10g, Solaris 10 с одной неглобальной зоной и восемью виртуальными процессорами. Fujitsu Primergy Model RX300 S5 (2 процессора, 8 ядер, 16 потоков), 2056 SAP SD User, 2×2,93 ГГц Intel Xeon x5570, память 96 Гбайт, MaxDB 7.8, SuSE Linux Enterprise Server 10 на VMware ESX Server 4.0, SAP, R/3. Дополнительная информация по ссылке http://www.sap.com/benchmark.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF