Лекция 11: Расширение возможностей группы ресурсов

Ограничения на сочетание зависимостей

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

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

Вывод зависимостей группы ресурсов

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

#clrgdependency -?
usage: clrgdependency -t <ANTICOLLOCATION> 
  -u -hp <high priority RG list> -ip
<intermediate priority RG list> 
  -lp <low priority RG list>
usage: clrgdependency -t <PARENT_CHILD | 
  NODECOLLOCATION | SITECOLLOCATION |
ANTICOLLOCATION > -sl
#clrgdependency -t PARENT_CHILD -sl
#Parent Child
DB2_1Rg Child_1Rg
DB2_2Rg Child_2Rg

Во время создания этой публикации не существовало страницы электронного руководства для команды clrgdependency.

Альтернативный вариант состоит в том, чтобы просмотреть разделы (stanzas) ODM-классов HACMPrg_loc_dependency и HACMPrgdependency с помощью команды odmget:

#odmget HACMPrgdependency
HACMPrgdependency:
id = 0
group_parent = "DB2_1Rg"
group_child = "Child_1Rg"
dependency_type = "PARENT_CHILD"
dep_type = 0

Сценарий тестирования зависимостей групп ресурсов

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

Мы решили использовать кластер из трех узлов, включающий несколько экземпляров баз данных DB2, где дочерние группы ресурсов содержат приложения WebSphere. Мы сделали третий узел дежурным узлом, содержащим приложение Tivoli для создания резервных копий, и группу ресурсов, содержащую тестируемое приложение. Используемая конфигурация представлена на рис. 11.5:

Рис. 11.5. Сценарий тестирования зависимости группы ресурсов

Мы реализовали шесть различных зависимостей, включая: зависимость "родительский объект/дочерний объект" (2 набора), зависимость подключения на одном узле (2 набора) и зависимость подключения на разных узлах (2 набора). Эти зависимости также описаны в табл. 11.4. Мы реализовали конфигурацию, в которой родительская группа ресурсов всегда подключается на одном узле с соответствующей дочерней группой ресурсов, но родительские группы ресурсов и группа ресурсов Tivoli всегда подключаются на разных узлах, что позволяет распределить нагрузку. Мы включили зависимость расположения на разных узлах для дочерних групп ресурсов и группы ресурсов Testbed_Rg, чтобы в случае перемещения рабочих ресурсов на дежурный узел python группа ресурсов с низким приоритетом, содержащая тестовое приложение, была отключена.

В табл. 11.5 описываются различные атрибуты групп ресурсов и политики запуска/перемещения при сбое/возврата после восстановления, используемые в наших группах ресурсов. Если вы незнакомы с сокращениями, указываемыми для каждой политики группы ресурсов, просмотрите в этом руководстве раздел, посвященный терминам. Также мы включили участвующие узлы, сервисные IP-метки и серверы приложений, используемые в каждой группе ресурсов.

Операции и результаты сценария тестирования

При тестировании мы пытались воссоздать отказы и операции групп ресурсов, имеющие место в рабочей среде. Мы обнаружили, что методами, фактически применяющими политики зависимостей, являются завершение работы узла или постепенная остановка с передачей ресурсов (graceful stop with takeover). Так как в нашей среде на всех узлах были расположены группы ресурсов с высоким приоритетом, выполнение операций перемещения групп ресурсов не разрешалось; это будет рассмотрено ниже при описании результатов тестирования.

Наше тестирование содержало следующие действия:

1. Мы выполнили постепенную остановку HACMP с передачей ресурсов на узел viper. После остановки служб кластера с передачей ресурсов группы ресурсов были успешно перемещены на дежурный узел python. Была применена политика размещения на разных узлах для дочерних групп ресурсов и группы ресурсов Testbed_Rg, и тестовая группа ресурсов была переведена в состояние OFFLINE. Группа ресурсов Tivoli_Rg была оставлена в состоянии ONLINE, так как был установлен средний приоритет. Выходные данные команды clRGinfo содержали следующее:

   #/usr/es/sbin/cluster/utilities/clRGinfo
   DB2_2Rg OFFLINE viper
   ONLINE python
   OFFLINE cobra
   Child_2Rg OFFLINE viper
   ONLINE python
   OFFLINE cobra
   Testbed_Rg OFFLINE due to lack of node python
   ERROR cobra
   OFFLINE viper
   Tivoli_Rg ONLINE python
   OFFLINE cobra
   OFFLINE viper
2. Мы попытались снова подключить группу ресурсов Testbed_Rg. В этом состоянии мы попытались подключить тестовую группу ресурсов через меню HACMP. Мы обнаружили, что не было доступных узлов для подключения группы ресурсов. Затем мы попытались выбрать опцию Restore_Node_Priority_Order, чтобы подключить группу ресурсов; эта команда выполнилась без ошибок, однако, как и ожидалось, не было самого действия.
3. Мы выполнили реинтеграцию узла viper в кластер. Мы интегрировали узел обратно в кластер, и группа ресурсов Testbed_Rg была снова подключена на нем.
   Примечание. Это произошло потому, что группа ресурсов Testbed_Rg имела низкий приоритет и не была расположена на каком-либо узле.
4. Мы попытались переместить группу ресурсов DB2_2Rg с узла python обратно на первоначальный узел viper. Хотя группа ресурсов находилась в состоянии после перемещения при сбое, мы попытались переместить первоначальные ресурсы узла viper обратно на домашний узел через меню HACMP. Эта операция не показывала, что этот узел доступен для выполнения перемещения. Единственный способ, который позволил нам переместить группу ресурсов обратно на узел viper, состоял в постепенном отключении узла python с передачей ресурсов.
5. Мы выполнили реинтеграцию узла python в кластер.

Мы обратили внимание на задержку при реинтеграции этого узла обратно в кластер, однако в целом выполнение операции прошло успешно, и группа ресурсов Testbed_Rg возвратилась на узел python. Во время задержки в файлы hacmp.out и clstrmgr.debug ничего не было записано. Группа ресурсов Tivoli_Rg осталась подключенной на узле viper, и мы решили оставить ее на этом узле.

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

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