Журнал PC Magazine/RE №08/2009

Обзор технологий виртуализации в HP-UX

Александр Букреев – руководитель группы сопровождения бизнес-систем, отдел внедрения и сопровождения центров обработки данных компании «Ай-Теко» (www.i-teco.ru). Автор выражает признательность Екатерине Иванниковой (руководитель группы производительности бизнес-систем, «Ай-Теко») за ценные замечания и уточнения как по теоретическим, так и практическим аспектам данной темы.

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

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

Очевидно, что эти проблемы нужно решать путем консолидации: прикладные системы, располагающиеся на разных физических серверах, объединить на одном более мощном сервере. Чтобы такое решение работало, необходимо обеспечить аппаратную или программную изоляцию систем друг от друга, что позволит избежать конфликтов между ними, а также снизит вероятность того, что какой-либо программный или аппаратный сбой выведет из строя сразу несколько систем. Для этого в операционной системе HP-UX существует набор технологий виртуализации с разбиением физического сервера на разделы:

• аппаратные (nPartitions, nPar);

• виртуальные (Virtual Partitions, vPar);

• виртуальные машины (Integrity Virtual Machines);

• безопасные разделы ресурсов (Secure Resource Partitions, SRP).

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

Однако консолидация вычислительных ресурсов и изоляция разделов сами по себе не решают проблему неравномерных нагрузок и недостаточного использования ресурсов. Требуется еще при необходимости перемещать ресурсы из одного раздела в другой, причем делать это желательно без перезагрузки ОС, перезапуска СУБД и остановки прикладных систем. Перечисленные технологии в разной степени предоставляют такую возможность.

Аппаратные разделы (nPar) электрически изолированы друг от друга и выглядят и действуют подобно отдельной системе. Каждый раздел имеет свое оборудование и свою операционную систему. Благодаря этому обеспечивается изоляция сбоев – как аппаратных, так и в ПО. Это означает, что отказ аппаратуры или сбой ПО в одном аппаратном разделе не может повлиять на работу другого раздела.

Еще одним полезным свойством аппаратных разделов является то, что обеспечивается одновременная работа процессоров PA-RISC в одном аппаратном разделе и процессоров Itanium в другом на любой системе с наборами микросхем sx1000 и sx2000.

Аппаратные разделы могут быть созданы только на серверах, основанных на ячейках (cell-based). К таким серверам относятся следующие модели: Superdome, rp7400, rp7410, rp7420, rp7440, rp8400, rp8420, rp8440, rx7620, rx7640, rx8620, rx8640.

В версиях HP-UX 11.11 и 11.23 перемещение ячеек из одного аппаратного раздела в другой невозможно без остановки соответствующих разделов. Начиная с версии HP-UX 11.31 Update 1 поддерживается активация и деактивация ячеек аппаратного раздела в онлайновом режиме, т. е. без перезагрузки раздела и остановки работающих в нем приложений.

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

Сервер может иметь ячейки, первоначально не принадлежащие ни одному разделу (unassigned cells). По мере необходимости их можно добавлять в нужный раздел при возникновении проблемы с производительностью.

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

Во-первых, освободить можно лишь часть памяти, которая в данный момент не занята работающими приложениями, например, не является частью Oracle SGA.

Во-вторых, большинство приложений могут воспользоваться динамически добавленной памятью только с определенными оговорками. Скажем, сегмент разделяемой памяти, выделенный ОС под Oracle SGA, не может быть увеличен динамически (в большинстве случаев это и не требуется), но пользовательские сессии Oracle, созданные после динамического добавления памяти, смогут ее использовать. Таким образом, число одновременно работающих сессий в системе может быть увеличено.

Динамические аппаратные разделы работают не на всех серверах cell-based, а лишь на моделях Superdome, rp7420, rp7440, rp8420, rp8440, rx7620, rx7640, rx8620, rx8640.

Память, принадлежащая плавающим ячейкам аппаратных разделов, может быть только типа CLM (Cell Local Memory). Многие современные ОС используют на серверах cell-based технологию NUMA (non-uniform memory access) – оптимизированный доступ к памяти, когда выделяемая память физически находится внутри ячейки, на ЦП которой работает процесс, запросивший память. Обращение процессора к локальной памяти своей ячейки происходит быстрее, чем к памяти других ячеек, среднее время доступа к памяти сокращается, и благодаря этому увеличивается производительность. Таким образом, в системах, реализующих технологию NUMA, память может подразделяться на CLM и ILM (Interleaved Memory). Доступ к ILM-памяти однороден и не зависит от местоположения процессора, осуществляющего его.

Технология NUMA должна поддерживаться не только ОС, но и приложением. Многие приложения и СУБД последних версий декларируют такую совместимость, однако на практике все выглядит не так гладко, поскольку технология еще не достигла зрелости. Например, включение режима поддержки NUMA в Oracle может приводить к сбоям в работе системы и даже к «зависаниям» самой СУБД (см., в частности, Metalink Note 759565.1). Использование NUMA в MS SQL Server также не всегда приводит к желаемому результату.

Хотя теоретически работа с CLM более эффективна, на практике это бывает не так: здесь многое зависит и от того, как конкретное приложение использует память, и от того, насколько точно отлажена конфигурация CLM в каждом отдельном случае. Если все данные процесса так или иначе оказались в соседней ячейке, то среднее время доступа окажется даже больше, чем если бы эти данные лежали в ILM-памяти и были равномерно распределены по ячейкам. В таком случае мы, повторяя одну и ту же нагрузку (например, в процессе тестирования ПО), можем получать разное время исполнения.

Можно спорить о том, насколько эффективно использование CLM и NUMA на сегодняшнем этапе развития этих технологий, но бесспорно другое – необходимо иметь возможность выбора варианта конфигурации памяти. К тому же большинство прикладных задач могут получить выигрыш от комбинирования этих видов памяти (за исключением ОС Windows, где HP рекомендует для достижения максимальной производительности использовать только CLM). Динамические ячейки аппаратных разделов, в отличие от перемещаемой памяти виртуальных разделов (vPar), таких возможностей не предоставляют, вся память динамических ячеек – локальная (CLM).

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

• Основное преимущество аппаратных разделов – изоляция отказов оборудования: гарантируется, что никакой отказ аппаратуры в одном разделе не может повлиять на другой раздел. Это следствие электрической изоляции разделов внутри одной системы. Поскольку степень изоляции виртуальных разделов слабее, чем у аппаратных, то зачастую аппаратным разделам отдается предпочтение в случаях, когда на сервере работают несколько бизнес-критичных продуктивных систем.

• Аппаратные разделы Integrity-серверов, помимо HP-UX, обеспечивают также работу операционных систем Windows, Linux и OpenVMS. Для сравнения: виртуальные разделы (vPar) рассчитаны только на HP-UX.

Ограничения

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

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

• Память перемещаемых ячеек может быть только типа CLM.

Виртуальные разделы (vPar) – это те, изоляция между которыми реализована программно средствами операционной системы HP-UX, в отличие от аппаратных разделов, изолированных на аппаратном уровне.

Каждый раздел функционирует точно так, как если бы он был отдельной системой, видит он только выделенную ему часть оборудования и аппаратных ресурсов физического сервера (рис. 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 с) «зависание» своего приложения. Такая чрезвычайно ценная возможность полезна не только для балансировки нагрузки, но и при выполнении любых административных процедур, требующих остановки или перезагрузки системы.

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

• Обеспечивается более высокий уровень гранулирования при распределении ресурсов, чем в случае аппаратных и виртуальных разделов: между виртуальными машинами можно разделять отдельные физические процессоры и платы ввода-вывода. Доля ресурсов, выделяемых виртуальной машине, задается в процентах. Минимальная доля выделяемых ресурсов – 5 % физического процессора (для многоядерных процессоров – ядра).

• В качестве гостевой операционной системы может выступать не только HP-UX, но и Windows 2003, Linux Red Hat, Linux SUSE, причем виртуальные машины с различными ОС можно совмещать на одном физическом сервере.

• Возможность миграции виртуальной машины на другой сервер без остановки работающих приложений (Online VM Migration).

• Работают на любых системах Integrity, а не только на cell-based.

Ограничения

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

• Версии VM, работающие на HP-UX 11.23 (3.0, 3.5), используют не более четырех виртуальных процессоров на каждой виртуальной машине, а последние версии, функционирующие на HP-UX 11.31 (4.0, 4.1) – не более восьми.

• До версии 3.5 Integrity VM не рекомендовалось использовать для систем с интенсивным потоком ввода-вывода. В версии Integrity VM 3.5 появился усовершенствованный механизм виртуального дискового и сетевого ввода-вывода – Accelerated Virtual I/O (AVIO), который позволяет примерно в полтора раза увеличить производительность ввода-вывода и вдвое уменьшить процессорную нагрузку, создаваемую виртуальным вводом-выводом. В версиях 4.0 и 4.1 этот механизм был усовершенствован. Тем не менее необходимо с большой осторожностью подходить к внедрению VM там, где важна высокая пропускная способность ввода-вывода, и учитывать некоторые ограничения AVIO.

• Online VM Migration работает только при условии, что гостевая ОС – HP-UX. Число виртуальных процессоров в одной виртуальной машине не может превышать количество физических процессоров.

• Не работают на системах с архитектурой PA-RISC.

Безопасные разделы ресурсов (SRP) поддерживаются программно внутри одной копии операционной системы HP-UX. При создании раздела ему выделяется определенная часть процессорных ресурсов, оперативной памяти сервера и пропускной способности ввода-вывода для группы дисковых томов.

Процессорные ресурсы можно выделять либо используя наборы процессоров (PSET), либо средствами Fair Share Scheduler (FSS), который представляет собой планировщик 2-го уровня над стандартным планировщиком ОС. При использовании PSET процессоры (ядра) выделяются разделу целиком. При применении FSS распределение процессорных ресурсов между разделами задается в процентах, и в соответствии с этим распределением процессорное время выделяется каждому разделу квантами по 10 мс.

Каждому разделу может быть выделена часть физической памяти сервера, хотя делать это не обязательно. Память между разделами распределяется средствами технологии Memory Resource Groups (MRG). При этом каждый раздел «видит» и может использовать только свою часть общей памяти сервера. Это обеспечивает более высокий уровень изоляции между разделами. Однако по умолчанию неиспользуемая память разделяется между разделами, и один раздел может временно использовать свободную память другого.

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

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

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

• Благодаря консолидации уменьшается количество экземпляров ОС.

• Единая операционная среда дает больше возможностей для разделения ресурсов: можно совместно использовать процессоры, платы ввода-вывода, память, файловые системы.

• Работают на любых системах, где запускается HP-UX, а не только на cell-based (как nPar и vPar) или Integrity-серверах (как Integrity VM).

Ограничения

• Меньший уровень изоляции, чем у всех остальных типов разделов, так как разделы ресурсов существуют внутри одной копии операционной системы.

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

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

Это решение было специально разработано для того, чтобы облегчить процесс модернизации системы. Активирование процессоров происходит моментально и не требует остановки системы. Активирование целиком ячеек (процессоров и памяти) на ходу можно провести только в версии HP-UX 11.31, в предыдущих версиях необходима перезагрузка, но время простоя при этом несопоставимо с временем, которое затрачивается на закупку, поставку и установку дополнительного оборудования. С финансовой же точки зрения несмотря на то, что заказчик в конце концов выплачивает всю стоимость iCAP-ресурса, он может даже выиграть, так как со временем цена соответствующей единицы оборудования падает. Таким образом, Instant Capacity позволяет существенно снизить риски при планировании мощностей под развивающиеся системы с постоянно растущей нагрузкой – в системе присутствуют запасные неактивные мощности, которые могут быть задействованы в нужный момент.

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

Решение, называемое Global Instant Capacity (GiCAP), позволяет аналогичным образом перемещать ресурсы между физическими серверами. Если продуктивный сервер загружен, на него можно переместить часть лицензий слабозагруженного сервера.

Возможна ситуация, когда нам негде временно деактивировать ресурсы, – пик нагрузки на одном сервере или аппаратном разделе не совпадает по времени со спадом нагрузки на других серверах (разделах). В таких случаях можно применить Temporary Instant Capacity (TiCAP). Лицензия TiCAP дает право активировать любое число iCAP-процессоров на суммарное время, равное 30 дням работы одного процессора. Лицензия TiCAP действует подобно телефонной карте на определенное количество минут. Пока процессор работает, использованное им процессорное время вычитается из общего «счета» квантами по 30 мин. Можно активировать не один, а сразу несколько процессоров – тогда время TiCAP-лицензии будет расходоваться быстрее. Когда все 30 суток процессорного времени будут израсходованы, баланс станет отрицательным, но процессоры остановятся только после перезагрузки сервера. Если затем приобрести постоянные лицензии, отрицательный баланс будет аннулирован. При покупке еще одной TiCAP-лицензии отрицательный баланс будет вычтен из нее.

В заключение остается отметить, что в операционной системе HP-UX имеются инструменты, позволяющие автоматизировать процессы распределения и динамического перемещения ресурсов между разделами, – это Workload Manager (WLM) и Global Workload Manager (gWLM). Эти средства позволяют автоматизировать действия администратора, связанные с управлением и распределением вычислительных ресурсов, такие как:

• постоянный мониторинг нагрузок;

• принятие решения о добавлении ресурсов определенному приложению;

• поиск резервных или не занятых в данный момент ресурсов;

• освобождение неиспользуемых ресурсов;

• добавление ресурсов тому приложению, которое в них нуждается.

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

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

WLM интегрирован со всеми описанными решениями разбиения на разделы, кроме Integrity VM. Он позволяет перемещать ресурсы между аппаратными (nPar), программными (vPar) разделами, безопасными разделами ресурсов (SRP), а также временно активировать Instant Capacity по лицензии TiCAP.

gWLM – это более новый и современный продукт по сравнению с WLM. С другой стороны, WLM проще в конфигурировании и сопровождении. WLM конфигурируется для одной системы или одного раздела, у gWLM есть центральный сервер управления (CMS). В этом и состоит основное различие между этими решениями. WLM не поддерживает Integrity VM и работает только на HP-UX, поэтому для управления виртуальными машинами нужно применять gWLM. Если число поддерживаемых систем и нагрузок невелико, все они управляются HP-UX и при этом не требуется поддержка Integrity VM, тогда WLM может быть более предпочтительным, так как он проще в использовании. В то же время gWLM имеет ряд серьезных преимуществ перед WLM, поэтому централизованное управление ресурсами при большом числе систем и сложном распределении нагрузок без применения этой технологии невозможно.

Интеграция nPar, vPar, Integrity VM, а также WLM/gWLM с технологией кластеризации HP Serviceguard позволяет системе автоматически реагировать не только на рост или падение нагрузки, но и на аппаратные и программные сбои в работе вычислительной среды. Благодаря интеграции с WLM кластерный пакет Serviceguard может быть перемещен на другой узел не только при сбое какого-то компонента системы, но и при достижении определенного порога нагрузки, превышение которого приведет к падению производительности.

Как мы увидели, технологии компании HP предоставляют широкий спектр возможностей виртуализации, перераспределения ресурсов, автоматического управления ресурсами. Каждая из описанных технологий может применяться индивидуально. В то же время они тесно интегрированы между собой и вместе составляют так называемую виртуальную серверную среду (HP Virtual Server Environment – VSE). VSE (http://docs.hp.com/en/vse.html) позволяет создать гибкую и хорошо управляемую информационную инфраструктуру и добиться высокой степени эффективности использования вычислительных ресурсов, производительности и доступности сервисов при снижении стоимости владения.

Начать применять эти технологии несложно – чаще всего для этого достаточно набрать несколько команд (и выполнить пару перезагрузок), и продукт начинает работать!

Вместе с тем, чтобы добиться максимального эффекта от использования VSE, требуется определенная проектная работа. Необходимо провести тщательное планирование и аудит, позволяющий получить исчерпывающее представление о вычислительной среде предприятия, ресурсах, распределении нагрузок, требованиях по доступности и отказоустойчивости сервисов. Нельзя забывать о том, что внедрение технологий VSE – задача комплексная и не ограничивается приобретением лицензий. Здесь, как всегда в нашем деле, хорошая подготовка и аккуратность – залог успеха!