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

Программный слой, находящийся между виртуальными разделами и аппаратурой сервера (vPar monitor), после загрузки виртуального раздела практически не вмешивается в его работу. ОС обращается к vPar-монитору только при вызовах встроенного ПО (firmware), администрировании разделов и перезагрузке ОС. Поэтому vPar-монитор оказывает ничтожное влияние на производительность. Таким образом, по производительности виртуальные разделы почти не отличаются от аппаратных. По тем же причинам масштабируемость виртуальных разделов выше, чем у Integrity VM, кроме того, здесь не ограничивается число процессоров в одном разделе (у Integrity VM – восемь процессоров). В отличие от Integrity VM, виртуальные разделы прекрасно подходят для эксплуатации и тестирования крупных систем с большим числом процессоров.

Степень гранулирования ресурсов, выделяемых виртуальному разделу, гораздо выше, чем в случае аппаратных разделов. Здесь минимальной единицей является не целая ячейка, а один процессор (для многоядерных процессоров – ядро), 64 Мбайт памяти и один адаптер ввода-вывода.

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

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

Однако виртуальные разделы не могут сосуществовать с виртуальными машинами (Integrity VM) в одном аппаратном разделе или – при их отстутствии – на одном физическом сервере.

Виртуальные разделы идеально подходят, когда на сервере соседствуют продуктивная и тестовая среды. В этом случае тестовая среда или среда разработки может выступать «донором» ресурсов для продуктивной среды в моменты ее максимальной загруженности.

Возможны случаи, когда одним разделом сервера является тестовая среда или среда разработки, а вторым – резервный узел отказоустойчивого кластера, поддерживающего продуктивную систему. Большую часть времени продуктивная система функционирует на основном узле, и мощности резервного узла могут быть переданы в тестовый раздел. Таким образом удается избежать главного недостатка кластерной архитектуры: ресурсы резервного узла не простаивают! Если же происходит плановая или неплановая миграция продуктивной системы на резервный узел кластера, то ему передается необходимая часть ресурсов тестового раздела.

Преимущества

• Среди всех вариантов разбиения на разделы, кроме nPar, этот способ обеспечивает самую высокую производительность и масштабируемость за счет низких накладных расходов.

• Более высокая по сравнению с nPar степень гранулирования аппаратных ресурсов: один процессор (ядро), 64 Мбайт памяти и один адаптер ввода-вывода.

• Уже в HP-UX 11.23 поддерживается динамическое перемещение процессоров. В этой же версии ОС в аппаратных разделах динамически перемещать ресурсы невозможно.

• При динамическом добавлении памяти в раздел можно явно задать, какая часть этой памяти будет использоваться операционной системой в качестве CLM, а какая – в качестве ILM (с учетом общего объема CLM и ILM, сконфигурированного в системе или аппаратном разделе). Для аппаратных разделов вся динамически добавляемая память является локальной (CLM).

Ограничения

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

• Поддерживается только операционная система HP-UX.

Основная область применения HP Integrity VM (рис. 2) – небольшие, но важные приложения, требующие изоляции ОС, но в среднем не требующие больших ресурсов (один процессор или меньше). Тем не менее серверы для эксплуатации этих приложений конфигурируются так, чтобы выдерживать пиковую нагрузку. В пиковые моменты такие системы могут загрузить и несколько процессоров, поэтому они устанавливаются, как правило, на небольших двух– или четырехпроцессорных серверах. В этом случае среднее использование ресурсов получается небольшим. Размещение подобных приложений на виртуальных машинах позволяет удовлетворить их требования во время пиков загрузки и возвращать ресурсы, когда активность снижается. Необходимые ресурсы предоставляются «по требованию» для реагирования на кратковременные всплески.

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

Такое решение одновременно и обеспечивает изоляцию систем, и существенно повышает степень использования ресурсов (т. е. экономит деньги).

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

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

Помимо виртуализации процессоров и интерфейсов ввода-вывода Integrity VM обеспечивает виртуализацию физической памяти – каждой виртуальной машине выделяется часть физической памяти сервера. Начиная с версии 4.0 возможно динамическое перемещение памяти между виртуальными машинами, т. е. увеличение или уменьшение объема памяти виртуальной машины без ее перезагрузки. Однако если память раздела в процессе работы станет фрагментированной, то освободить ее удастся не всегда, или это может происходить очень медленно. Кроме того, сказанное выше относительно динамического перемещения памяти между аппаратными разделами справедливо и для виртуальных машин.

В Integrity VM 4.1 появилась возможность миграции всей виртуальной машины вместе с гостевой ОС на другой сервер без остановки работающих приложений – Online VM Migration (рис. 3). На финальном этапе миграции система «замораживается» на несколько секунд, в течение которых на новый сервер копируются метаданные, страницы памяти, успевшие измениться за время переноса, и завершаются текущие операции с дисками. Затем система продолжает свою работу уже на новом сервере. Все, что при этом чувствует пользователь, – это кратковременное (не более 10 с) «зависание» своего приложения. Такая чрезвычайно ценная возможность полезна не только для балансировки нагрузки, но и при выполнении любых административных процедур, требующих остановки или перезагрузки системы.