Лекция 10: Динамические LPAR (DLPAR) и виртуализация (VIO)

Освобождение ресурсов DLPAR и CUoD

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

HACMP сначала освобождает ресурсы DLPAR или CUoD, которые были получены в последнюю очередь. Это означает, что ресурсы CUoD не всегда освобождаются раньше ресурсов DLPAR.

Свободный пул ограничен только одним фреймом. Другими словами, в кластерах, сконфигурированных на основе двух фреймов, HACMP не запрашивает из второго фрейма ресурсы для узла LPAR, расположенного в первом фрейме.

Кроме того, если LPAR-1 освобождает приложение, помещающее некоторые ресурсы DLPAR в свободный пул, LPAR-2, использующий ресурсы CUoD, не предпринимает попыток освободить ресурсы CUoD и получить свободные ресурсы DLPAR.

Остановка узлов LPAR

При принудительном отключении диспетчера кластера (Cluster Manager) на узле LPAR с последующим завершением работы LPAR (вне HACMP) происходит освобождение ресурсов процессора и памяти (без участия HACMP), которые становятся доступными для других групп ресурсов, запущенных на других LPAR. HACMP не следит за ресурсами процессора и памяти, выделенными для LPAR, и не сохраняет их для использования при реинтеграции узла LPAR в кластер.

Если LPAR не был остановлен после принудительного отключения диспетчера кластера на узле, ресурсы процессора и памяти остаются выделенными для LPAR и используются при реинтеграции LPAR в кластер.

Динамическое изменение ресурсов DLPAR и CUoD

Можно выполнить изменение требований к ресурсам DLPAR и CUoD для серверов приложений без остановки служб кластера. После внесения изменений необходимо выполнить синхронизацию кластера.

Новая конфигурация не отображается до возникновения следующего события, вызывающего освобождение приложения (а значит, и группы ресурсов) и его перехват другим узлом. Другими словами, изменение в требованиях к ресурсам процессора, памяти или обоих компонентов не вызывает перерасчета ресурсов DLPAR. HACMP не останавливает и не перезапускает серверы приложений только для того, чтобы внести изменения в систему обеспечения приложения ресурсами (application provisioning).

Если какое-либо другое изменение динамической реконфигурации (т. е. rg_move) вызывает освобождение и перехват групп ресурсов, новые требования к ресурсам для DLPAR и CUoD используются в конце события динамической реконфигурации.

Примеры использования ресурсов DLPAR и CUoD

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

Конфигурация представляет собой фрейм на восемь процессоров с кластером из двух узлов (каждый из которых представляет собой LPAR). Пул CUoD содержит два процессора, доступные посредством активизации CUoD. Узлы (разделы) имеют характеристики, представленные в табл. 10.1 и 10.2.

Определено три сервера приложений, каждый из которых относится к отдельной группе ресурсов.

Параметры стартовой конфигурации:
Longhorn имеет 3 выделенных процессора;
Hurricane имеет 1 выделенный процессор;
свободный пул содержит 4 выделенных процессора.
Серверы приложений запускаются в следующем порядке:
Longhorn запускает App2. Не происходит выделения 
процессоров для выполнения требования наличия трех
процессоров (3 процессора представляют сумму 
минимального количества процессоров для LPAR первого узла, 
равного единице, и желательного количества процессоров 
для App2, равного двум). Longhorn останавливает App2.
Освобождается 2 процессора; остается 1 процессор, 
что соответствует минимальному требованию. 
(Так как отсутствуют другие запущенные серверы приложений, 
единственное требование – наличие минимального количества 
процессоров для LPAR Longhorn, равного единице).

В этом примере мы начинаем с тех же параметров
конфигурации, которые представлены в первом примере.
Серверы приложений запускаются следующим образом:
Longhorn запускает App1; процессоры не выделяются, 
так как требование наличия двух процессоров выполняется. 
Longhorn запускает App3; выделяется 3 процессора для 
выполнения требования наличия шести процессоров. 
Теперь свободный пул содержит 1 процессор.
Longhorn пытается запустить App2. После того как Longhorn 
подхватит App1 и App3, общее количество процессоров, 
требуемое узлу Longhorn для выполнения этих требований, 
равно шести (сумма минимума для LPAR Longhorn, равного единице,
желательного количества для App1, равного единице, и 
желательного количества для App3, равного четырем).
Так как минимальное количество процессоров для App2 равно двум, 
то для получения App2 узлу Longhorn требуется выделить 2 
дополнительных процессора, однако в свободном пуле остался 
только 1 процессор, что не позволяет выполнить минимальное 
требование для App2, составляющее 2 процессора. 
Группа ресурсов с App2 не подхватывается локально, 
так как свободный пул содержит только 1 процессор,
и использование CUoD не разрешено. Если другие участвующие 
узлы отсутствуют, группа ресурсов переходит в состояние ERROR.
Если бы узел Hurricane был членом группы ресурсов App2 и 
был активным в кластере, то произошел бы вызов rg_move 
для переноса группы ресурсов на узел Hurricane.

Стартовая конфигурация имеет следующие параметры:
Longhorn имеет 3 выделенных процессора;
Hurricane имеет 1 выделенный процессор;
свободный пул содержит 4 выделенных процессора.
Серверы приложений запускаются в следующем порядке:
Longhorn запускает App3; выделяется 2 процессора, 
чтобы выполнить условие наличия пяти процессоров;
Longhorn запускает App2; выделяется 2 процессора, 
чтобы выполнить условие наличия семи процессоров. 
В свободном пуле процессоры отсутствуют;
Longhorn запускает App1, из CUoD выделяется 1 процессор, 
чтобы выполнить условие наличия восьми процессоров;
Longhorn останавливает App3, освобождается 4 процессора, 
1 из которых помещается обратно в пул CUoD.

В этом примере при получении группы ресурсов 
происходит сбой в связи с тем, что минимальные 
требуемые ресурсы недоступны при достижении максимума в LPAR.
Конфигурация имеет следующие параметры:
Longhorn имеет 1 процессор;
Hurricane имеет 1 процессор;
свободный пул содержит 6 процессоров.
Серверы приложений запускаются в следующем порядке:
Hurricane запускает App3; выделяется 4 процессора 
для выполнения требования наличия пяти процессоров. 
В свободном пуле остается 2 процессора;
Hurricane пытается запустить App2, однако 
App2 переходит в состояние ERROR, так как максимальное 
количество процессоров для Hurricane – 5 и Hurricane
не может получить больше процессоров.

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

Сервер приложения App1 имеет параметры, представленные в табл. 10.4:

Стартовая конфигурация представлена ниже.

• Longhorn имеет 4 выделенных процессора;
• Свободный пул содержит 4 процессора;

Сервер приложения App1 запускается локально на узле Longhorn. В процессе получения проверяется минимум для LPAR, который прибавляется к минимуму сервера приложений, что в сумме дает 5. Эта сумма превышает максимум для LPAR, вследствие чего группа ресурсов переходит в состояние ERROR.

Хотя технически LPAR может иметь достаточно ресурсов для содержания приложения, сочетание параметров вызывает отказ. Вообще говоря, минимум и максимум у вас не будут одинаковы.

Такой ситуации можно было избежать одним из трех способов:

• измените минимум для LPAR на 3 или меньшее значение;
• измените максимум для LPAR на значение больше четырех;
• измените минимальное количество процессоров для App1 на 0.