Поведение отключенной группы ресурсов при запуске состоит в том, чтобы запуститься на первом доступном узле с наивысшим приоритетом, интегрируемом в кластер. Опция времени установления позволяет отсрочить старт группы ресурсов, чтобы в случае интеграции в кластер узла с более высоким приоритетом можно было подключить группу ресурсов на этом узле.
Работа опции времени установления
Конфигурирование времени установления для групп ресурсов
Чтобы настроить время установления для групп ресурсов, нужно выполнить следующие действия:
smit hacmpВывод текущего времени установления
Чтобы вывести текущее значение времени установления в кластере, можно выполнить команду clsettlingtime list.
#/usr/es/sbin/cluster/utilities/clsettlingtime list #SETTLING_TIME 120
Во время активизации групп ресурсов при запуске кластера значение времени установления можно также вывести командой clRGinfo -t (
пример 11.1
).
#/usr/es/sbin/cluster/uti1ities/clRGinfo -t Group Naate Group State Node Delayed Timers settling rgl OFFLINE cobra 120 Seconds OFFLINE python 120 Seconds settling_rg2 OFFLINE viper 120 Seconds OFFt INF python 120 Seconds
Обратите внимание на то, что это значение выводится только во время активизации; выходные данные команды clRGinfo будут пустыми по истечении периода времени установления и после активизации группы ресурсов на соответствующем узле.
Сценарий тестирования времени установления
Чтобы протестировать эту функцию, мы сконфигурировали кластер из трех узлов, использующий две группы ресурсов. При тестировании мы пытались проверить два утверждения:
Мы начинаем выполнение своего теста с того, что задаем параметру времени
установления значение 10 мин. (или 600 с). Две наши группы ресурсов ( Settling1_RG
и Settling2_RG ) были настроены на использование политики запуска Online on First
Available Node (Подключение на первом доступном узле). Мы задаем порядок в списке узлов для каждой группы ресурсов, чтобы перемещение при сбое для узлов kaitlyn
и thrish выполнялось на узел mike. Рис. 11.1 содержит схему нашей конфигурации,
а также последовательность поочередного запуска HACMP на узлах для тестирования
параметра времени установления.
Наше тестирование включало следующие действия:
(рис 11.1) Среда тестирования параметра времени установленияThe Resource Group Settling time value is: 120 secs. The Resource Group(s) affected by the settling time are: settling_rg1 settling_rg2
clRGinfo -t выдавало время установления, равное 600 с.
В файл hacmp.out была записана информация, представленная в
примере 11.2
:kaitlyn. Службы кластера были запущены через 2 мин. после начала периода времени установления. Сразу же после
запуска узла была активизирована группа ресурсов Settling2_RG. Нам не пришлось
ждать оставшиеся 8 мин. для получения и подключения группы ресурсов. Таких результатов мы и ожидали.#more /tmp/clstrmgr.debug Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Using resource attribute IBM.Host.PctTotalTimeldle Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: for nodes 3, 2. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: using values , 0.0000, 0.0000. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: condition is DNP_argest Wed Jul 13 10:40:53 In larges_comparison
Settling1_RG была активизирована на
узле mike. Так как первый узел в списке узлов ( thrish ) не стал доступным в период
времени установления, группа ресурсов была получена следующим узлом в списке
узлов ( mike ). Опять же, таких результатов мы и ожидали.В целом наш тест подтвердил, что опция времени установления работает, как и ожидалось, и что группы ресурсов были распределены требуемым образом между узлами.
Одной из политик запуска, которую можно задать для группы ресурсов в кластере, является политика Online Using Node Distribution (Подключение с применением распределения узлов). При использовании этой политики распределения распространение групп ресурсов происходит таким образом, что во время запуска узел получает только одну группу ресурсов. Это позволяет сбалансировать приложения с интенсивным использованием процессоров на разных узлах.
В HACMP 5.3 поддерживается только политика распределения на основе узлов.
Если при интеграции узла в кластер две или больше групп ресурсов отключены, политика сортирует группы ресурсов в следующем порядке
Если одна или несколько групп ресурсов являются родительскими группами ресурсов, HACMP отдает предпочтение родительской группе ресурсов. Дополнительные сведения по этой теме см. в разделе "Зависимости групп ресурсов".
Чтобы установить этот тип политики распределения, необходимо выполнить следующие действия ( пример 11.3 ):
smit hacmpAdd a Resource Group (extended)
Type or select values in entry fields.
Press Enter AFTER making all desired changes*
[Entry fields]
* Resource Group Maine
* Participating Nodes (Default Node Priority)
Startup Policy Online On Home Node О
Fallover Policy Fallover lo Next PHo>
Fallback Policy Fallback To Higher Pr>
Startup Policy
Hove cursor to desired item and press Enter,
Online On Home Node Only
Online On First Available Node
Online Using Distribution Policy
Online On All Available Nodes
Fl=Help F2=Refresh F3=Cancel
F8=Image F10=Exit Enter=Do
/=Find n=Find Next
В документации говорится, что при использовании групп ресурсов с этой политикой
только одна группа ресурсов на узле будет получена при запуске. В этом сценарии
тестирования мы хотели доказать, что это ограничение не повлияет на
Для выполнения тестирования политики распределения на основе узлов мы сконфигурировали кластер из двух узлов с пятью группами ресурсов:
Это было сделано для того, чтобы увеличить количество групп ресурсов, использующих политику Online Using Node Distribution (Подключение с использованием распределения узлов), которые можно подключить в кластере. Рис. 11.2 содержит схему нашей конфигурации.
(рис 11.2) Сценарий тестирования политики Online Using Node Distribution (Подключение с использованием распределения узлов)После поочередного запуска служб кластера на каждом узле получение было выполнено только для групп ресурсов Distributed_Rg1 и Distributed_Rg2 из групп ресурсов с политикой запуска Online Using Node Distribution (Подключение с использованием распределения узлов). Третья группа ресурсов, Distributed_Rg3, осталась без
узла, в состоянии OFFLINE. Однако ограничение не распространялось на оставшиеся
группы ресурсов, использующие другую политику запуска. Группы ресурсов APP1_Rg
и APP2_Rg были подключены на узлах cobra и viper, соответственно.
Результаты нашего тестирования подтвердили, что использование политики распределения на основе узлов ограничивает получение групп ресурсов этого типа на узле при запуске только одной группой ресурсов. Это не влияет на получение групп ресурсов, использующих другие политики.
Distributed_Rg3 в
состояние ONLINE в этой среде состоит в том, чтобы установить опцию подключения
группы ресурсов при каждом запуске кластера через панели HACMP или командой clRGmove.По умолчанию порядок приоритетов узлов для группы ресурсов соответствует порядку в списке участвующих узлов. Включение динамического приоритета узлов для
групп ресурсов позволяет изменить стандартный механизм перемещения при сбое
в HACMP и определить целевой узел для перемещения группы ресурсов при сбое на
основании следующих предопределенных атрибутов
cl_highest_free_mem - узел с наибольшим процентным показателем свободной
памятиcl_highest_idle_cpu - узел с наименьшим использованием процессораcl_lowest_disk_busy - узел с наименьшим использованием дисковДля обеспечения эффективности DNP необходимо отметить следующее:
На момент создания этой публикации сочетание устройств vpath с политикой cl_lowest_disk_busy не поддерживалось. Поддержка такой конфигурации, возможно,
будет добавлена в версию позднее, в форме обновления.
Для того чтобы установить DNP для группы ресурсов, эта группа ресурсов не должна уже содержать какие-либо ресурсы. Назначение политики динамического приоритета узлов должно происходить при создании группы ресурсов. Для того чтобы группа ресурсов использовала одну из трех политик DNP, необходимо выполнить следующие действия (пример 11.4).
smit hacmpAdd a Resource Group (extended) Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] * Resource Group Name [] * Participating Nodes (Default Node Priority) [] + Startup Policy Online On Home Node 0> + Fall over Policy Fall over To Next Prio> + Fallback Policy Fallback To Higher Pr> +Установите в поле Fallover Policy (Политика перемещения при сбое) значение Dynamic Node Priority (Динамический приоритет узлов).
Change/Show All Resources and Attributes for a Resource Group Type or select values in entry fields. Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name DNP_testl Participating Nodes (Default Node Priority) alexis Jessica Jordan * Dynamic Node Priority Policy [] + Startup Policy Online On Home Node 0> Fallover Policy Fallover Using Dynami> Fallback Policy Fallback To Higher Pr>
Для просмотра текущей политики DNP существующей группы ресурсов в вашей конфигурации можно выполнить следующую команду:
#odmget -q group=APP1_RG HACMPresource | more HACMPresource: group = "APP1_RG" name = "NODE_PRIORITY_POLICY" value = "cl_highest_free_mem" id = 1
Нельзя изменить политику перемещения при сбое на DNP, если какие-либо ресурсы
на данный момент являются частью группы ресурсов. При попытке изменения группы ресурсов через
Начиная с HACMP 5.2 определение динамического приоритета узлов больше не
опрашивает службы управления событиями (Event Management Services, emsvcs).
Вместо этого clstrmgrES каждые 2 мин. опрашивает демон Resource Monitoring and
Control (ctrmc) и ведет таблицу, в которой хранятся показатели текущего объема памяти, загруженности процессора и дискового ввода-вывода для каждого узла.
Мониторы ресурсов, содержащие информацию по каждой политике, следующие:
Каждый из этих мониторов может быть опрошен во время функционирования путем выполнения команд, представленных в примере 11.6
#lsrsrc -Ad IBM.Host | grep TotalPgSpFree TotalPgSpFree = 123076 PctTotalPgSpFree = 93.8995 flsrsrc -Ad IBM.Host I grep PetTotalTimeldle PctTotalTlrtieldle = 99.6649 #1srsrc -Ap IBM.PhysicalVolume resource 1: Name = "vpath7"
Текущую таблицу, которую ведет clstrmgrES, можно вывести путем выполнения команд, представленных в
примере 11.7
.
#l5src -Is clstrmgrES Current state: ST_STABLE sccsid = "@(#)36 1.135.1.37 src/haes/usr/sbin/cluster/hacmprd/main.C, hacmp.pe, 51haes_r530, r5300525a 6/20/05 14:13:01" i_local_nodeid 1, i_1ocal_siteid -1, my_handle Z ml_1dx[l]=0 ml_idx[2] = l ml_idx[3]=2 There are 0 events on the Ibcast queue There are 0 events on the RM Ibcast queue CLversion: 8 local node vrmf is 5300 cluster fix level is "0" The following timer(s) are currently active: Current DNP values DNP Values for Nodeld - 1 NodeName - cobra PgSpFree = 130771 PvPctBusy = 0 PctTotalTimeldle = 99.947917 DNP Values for Nodeld - 2 NodeName - python PgSpFree = 130741 PvPctBusy = 0 PctTotalTimeldle - 99.879167 DNP Values for Nodeld - 3 NodeName - viper PgSpFree = 124489 PvPctBusy = 0 PctTotalTimeldle = 99.941667
Значения в таблице употребляются для определения DNP в случае перемещения
при сбое. Если в процессе опроса текущего состояния демоном clstrmgrES происходит перемещение при сбое, для определения DNP используется значение, имевшее
место, когда кластер последний раз был в стабильном состоянии.
Для тестирования функций динамического приоритета узлов мы установили кластер из
трех узлов с двумя группами ресурсов, использующими различные политики DNP. Первая
группа ресурсов A (APP1_RG) использует значение cl_highest_idle_cpu, тогда как группа
ресурсов B (APP2_RG) применяет значение cl_highest_free_mem для определения узла для
перемещения при сбое. Для каждой группы ресурсов мы выполнили тестирование различных сценариев перемещения при сбое и задокументировали результаты. На рис. 11.3
представлена схема используемой конфигурации.
(рис 11.3) Сценарий тестирования динамического приоритета узловВ нашей среде мы установили для каждой группы ресурсов использование следующих политик запуска/перемещения при сбое/возврате после восстановления:
Startup = Online Using Distribution Policy Fallover = Fallover Using Dynamic Node Priority Fallback = Never Fallback Мы установили следующий порядок узлов для обеих групп ресурсов: cobra viper python
Наша топология содержит сеть Ethernet с применением IP-синонимов. Это означает, что в случае перемещения при сбое на одном узле могли располагаться несколько групп ресурсов. Это может произойти только в том случае, если определение узла с наименьшим использованием процессора и определение узла с наименьшим употреблением памяти указывают на один и тот же узел.
Этапы сценария тестирования DNP
В целях упрощения тестирования мы не использовали реальные рабочие нагрузки приложений для перегрузки процессоров или памяти узла. Вместо этого мы запустили цикл, чтобы загрузить два процессора, и применили команду rmss, чтобы логически сократить количество памяти, видимой в системе, инициируя выполнение операций подкачки.
Ниже приведен перечень действий, которые мы выполнили, чтобы убедиться в применении политик DNP.
cobra. Только первая группа ресурсов
(APP1_RG) была подключена в связи с установленной политикой Online Using Distribution
Policy (Подключение с использованием политики распределения).f/usr/es/sbin/cluster/uti)ities/clRGinfo APP1_RG ONLINE cobra OFFLINE viper OFFLINE python APP2_R6 ONLINE cobra OFFLINE viper OFFLINE pythonЭто позволило освободить узлы (
viper и python ), что дает нам возможность
применять два узла для выполнения перемещения при сбое. Это также позволило
нам протестировать определение показателей неиспользуемой памяти и процессора
на следующем этапе.viper, чтобы уменьшить количество доступной памяти и инициировать операции подкачки, как показано в
примере 11.9
:cobra-#rmss -p Simulated memory size is 8192 Mb. viper-#rmss -p Simulated memory size is 8192 Mb. viper-#rmss -c 2000 Simulated memory size changed to 2000 Mb. viper-#lptest 80 1000000000 > /appl/garbageJ41e.out viper-#lsps -s Total Paging Space Percent Used 512MB 7% viper-#lsrsrc -Ad IBM.Host grep PctTotalPgSpFree PctTotalPgSpFree = 93.8995Сначала мы сократили объем памяти на узле viper до 2 Гб, уменьшив, таким образом, объем доступной памяти. Затем мы использовали команду
lptest, чтобы
сгенерировать запись большого количества символов в файл, что инициирует операции подкачки. Мы осуществляли мониторинг изменений значения TotalPgSpFree в классе IBM.Host. В результате повышенной нагрузки на память узла viper узел
python стал следующим логичным вариантом при определении DNP для группы
ресурсов APP1_RG.ksh #vi cpu_loopl while true do done #./cpu_loopl #./cpu_loop2В результате выполнения двух экземпляров скрипта в фоновом режиме два процессора оказались перегружены. Результаты приведены в примере 11.11 :
#sar -P ALL 5 AIX p630nO2 3 5 000685BF4C00 07/08/05 System configuration: lcpu=4 11:56:46 cpu %usr %sys %wio %idle 11:56:51 0 0 0 0 100 1 100 0 0 0 2 100 0 0 0 3 0 0 0 100 50 0 0 50Мы перегрузили два процессора на узле viper, так как он был следующим узлом в списке узлов группы ресурсов. Таким образом, в результате уменьшение количества неиспользуемых процессоров узел python стал следующим логичным вариантом при определении DNP для группы ресурсов APP2_RG.
| Узлы кластера | Наибольший показатель бездействия процессора | Наибольший показатель свободной памяти |
|---|---|---|
| viper | 93.8995 | 93.8995 |
| python | 93.8995 | 93.8995 |
| Наилучший целевой узел | python | python |
#more /tmp/clstrmgr.debug Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Using resource attribute IBM.Host.PctTotalTimeldle Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: for nodes 3, 2. Wed Jul 13 10:40:53 NodeList: :RmcComputeNodePrion'ty: using values , 0.0000, 0.0000. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: condition is DNPJargest Wed Jul 13 10:40:53 In largest_comparison Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Computed node order 3, 2. Wed Jul 13 10:40:53 For Resource Group APP1_RG, BestNode got node order Wed Jul 13 10:40:53 NodeList::showNodeList: Got the following 2 node IDs: Wed Jul 13 10:40:53 NodeList::showNodeList: 3 2 Wed Jul 13 10:40:53 The best node for group APP1_RG is python. Wed Jul 13 10:40:53 RGPA got viper as highest priority node. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Using resource attribute IBM.Host.TotalPgSpFree Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: for nodes 3, 2. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: using values , 0.0000, 0.0000. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: condition is DNPJargest Wed Jul 13 10:40:53 In largest_comparison Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Computed node order 3, 2. Wed Jul 13 10:40:53 For Resource Group APP2_RG, BestNode got node order Wed Jul 13 10:40:53 NodeList::showNodeList: Got the following 2 node IDs: Wed Jul 13 10:40:53 NodeList::showNodeList: 3 2 Wed Jul 13 10:40:53 The best node for group APP2_RG is python. Wed Jul 13 10:40:53 RGPA got viper as highest priority node.
cobra в кластер.cobra и viper делается таким образом, чтобы при определении
DNP выполнялось распределение двух групп ресурсов на узле python между двумя
разными узлами (
пример 11.13
).viper-#rmss -r Simulated memory size is 8192 Mb. viper-#./cpuloop1 viper- #./cpuloop2 viper-#sar -P ALL 5 AIX p630n02 3 5 00065BF4C00 07/08/05 System configuration: lcpu=4 18:03:20 cpu %usr %sys %wio %idle 18:03:25 0 0 0 0 100 1 100 0 0 0 2 100 0 0 0 3 0 0 0 100 50 0 0 50 viper-A*lsps -s Total Paging Space Percent Used 512MB 1% cobra-#rmss -c 2000 Simulated memory size changed to 2000 Mb. cobra-#lptest 80 1000000000 > /app1/garbage_file.out cobra-#lsps -s Total Paging Space Percent Used 512MB 6 %Мы перегрузили два процессора на узле
viper и инициировали операции подкачки на узле cobra, чтобы политика DNP в каждой группе ресурсов распределила их по
разным узлам.halt -qpython. Это вызвало перемещение группы ресурсов APP1_RG на узел cobra, так как на нем были доступны все процессоры. Группа ресурсов APP2_RG была перемещена на узел viper, так как на нем не выполнялись
операции подкачки и он имел больше свободной памяти. Табл. 11.3 показывает текущие значения clstrmgrES на момент перемещения при сбое.| Узел кластера | Наибольший показатель бездействия процессора | Наибольший показатель свободной памяти |
|---|---|---|
| viper | 93.8995 | 93.8995 |
| python | 93.8995 | 93.8995 |
| Наилучший целевой узел | cobra | viper |
Результаты тестирования сценария DNP
В результате выполнения сценария тестирования мы смогли доказать, что во время перемещения при сбое порядок в списке узлов по умолчанию игнорировался. После реинтеграции отказавшего узла мы изменили нагрузку на память и процессоры на двух бездействующих узлах и выполнили тестирование отказа узла, содержащего группы ресурсов. При определении DNP во второй раз было успешно выполнено распределение групп ресурсов по двум разным дежурным узлам.
В нашей среде мы использовали практичные команды для изменения нагрузки
на процессоры и память систем. Мы считаем, что результаты будут такими же, когда
нагрузка будет вызвана выполняющимся приложением. Во время настройки своей
среды DNP обязательно протестируйте все возможные сценарии перемещения при
сбое и выполните команды lsrscr -Ad и lssrc -ls clstrmgrES, описанные в этом
руководстве, для мониторинга текущей нагрузки на процессоры, память и дисковый
ввод-вывод на узлах кластера.
Понятие расположения, отменяющего приоритет (priority override location), появилось в HACMP 5.1 в качестве замены для прежнего атрибута "
При установке значения
Атрибут
Перемещение группы ресурсов
Обратите внимание на то, что эта операция недоступна для групп ресурсов без одновременного
Чтобы переместить группу ресурсов проделайте следующее:
clRGinfo -p. Образец результата выполнения данной команды представлен в
примере 11.14
.# /usr/es/sbin/cluster/utllitles/clRGInfo -p Cluster Name: migration2 Resource Group Name: C10RG2 Priority Override Information: Primary Instance POL: Node State viper ONLINE cobra OFFLINE Resource Group Name: C10RG1 Priority Override Information: Primary Instance POL: viper Node State cobra OFFLINE viper ONLINE
Если установлен атрибут /usr/es/sbin/
cluster/etc/clpol, который остается на этих узлах до перезагрузки кластера или перемещения группы ресурсов с установленной опцией Restore_Node_Priority_Order.
Файл содержит представление всех расположений, отменяющих приоритет, и его
можно интерпретировать в следующем формате: [RG id] [node id] [
3 2 2 1 // RG 3 on node 2 is OFFLINE persistent 3 1 2 1 // RG 3 on node 1 is OFFLINE persistent 1 1 1 0 // RG 1 on node 1 is ONLINE non-persistent
Данные файла имеют числовой формат и не предназначены для просмотра или изменения конечным пользователем.
clpol вручную НЕ сбрасывает атрибут Подключение или отключение группы ресурсов
Существует несколько дополнительных операций, при которых можно неявным
образом установить расположение, отменяющее приоритет для группы ресурсов.
При подключении или отключении группы ресурсов с использованием следующих
опций меню и выборе целевого узла происходит установка атрибута
Если при подключении группы ресурсов установить опцию Restore_Node_Priority_
Order, группа ресурсов будет подключена на узле, для которого установлен
наивысший приоритет (определяемый на основании списка узлов), и атрибут
При отключении группы ресурсов с использованием метода, приведенного выше,
следует помнить о том, что устанавливается другой тип Restore_Node_Priority_Order.
Сброс расположения, отменяющего приоритет
После установки Restore_Node_Priority_Order. В
примере 11.15
показано, как выглядит эта опция меню.
При выборе этой опции:
При использовании групп ресурсов с политикой запуска Online Using Distribution
Policy (Подключение с использованием политики распределения) опция меню
будет выглядеть по-другому. Вместо опции Restore_Node_Priority_Order для сброса
Move a Resource Group to Another Node / Site Move cursor to desired item and press Enter. Move Resource Groups to Another Node Move Resource Groups to Another Site Select a Destination Node Move cursor to desired item and press Enter. # To choose the highest priority available node for the # resource group, and to remove any Priority Override Location # that is set for the resource group, select # "Restore_Node_Priority_Order" below, Restore_Node_Priority_Order # To choose a specific node, select one below. viper Fl=Help F2=Refresh F3=Cancel F8=Image FlO=Exit Enter=Do F1/Find n=Find Next
атрибута Reset_Any_Priority_Overrides. Для группы
ресурсов данного типа восстановление приоритета узла не должно вызывать действительного перемещения ресурсов, так как в этом случае отсутствует понятие узла с
наивысшим приоритетом.
Рекомендации по использованию атрибута расположения, отменяющего приоритет
При управлении расположением своих групп ресурсов следует быть особенно внимательным к тому, где расположен атрибут
Restore_Node_Priority_Order.Restore_Node_Priority_Order.Restore_Node_Priority_Order, выбирается определенное
имя узла, атрибут Этот параметр позволяет настраивать выполнение возврата после восстановления для группы ресурсов таким образом, чтобы оно происходило в заданное время: ежедневно, еженедельно, ежемесячно, ежегодно или в заданную дату и время. Это полезно для того, чтобы планировать возвраты после восстановления на нерабочее время. схема на рис. 11.5 показывает три различных этапа при использовании таймеров отсроченного возврата после восстановления.
(рис 11.4) Этапы таймеров отсроченного возврата после восстановленияВ случае отказа происходит перемещение группы ресурсов на дежурный узел. Группа ресурсов остается там, пока не наступит время, заданное таймером отсроченного возврата после восстановления. Если в это время на основном узле активны службы кластера, группа ресурсов выполняет перемещение на узел с наивысшим приоритетом. Если узел с более высоким приоритетом в это время будет недоступен, таймер возврата после восстановления будет переустановлен и возврат после восстановления будет отсрочен до следующего повторения этого значения времени.
Принцип работы таймера отсроченного возврата после восстановления
Для эффективной реализации среды, использующей таймеры отсроченного возврата после восстановления, следует учитывать следующие аспекты:
Конфигурирование таймера возврата после восстановления для групп ресурсов
Для конфигурирования этой функции нужно выполнить следующие действия:
Change/Show All Resources and Attributes for a Resource Group Type 6r select values in entry fields. Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name fal1backl_rg Participating Nodes (Default Node Priority) cobra viper python Startup Policy Online On Home Node Only Fallover Policy Fallover To Next Priority** Fallback Policy Fallback To Higher Priori> Fallback Timer Policy (empty is immediate) [] Service IP Labels/Addresses Ap VO Us Au Fi Fi [MOR F1=H F5=R F9=S Fallback Timer Policy (empty is immediate) Move cursor to desired item and press Enter. julyl2 julyltest Fl-Help F2-Refresh F3-Cancel F8=Image F10=Exit Enter=Do /=Find n=Find Next
Вывод таймеров отсроченного возврата после восстановления в группе ресурсов
При работе в среде с запущенным кластером можно проверить наличие существующих политик возврата после восстановления для групп ресурсов путем просмотра
выходных данных команды clshowres, как показано в
примере 11.17
:
#/usr/es/sbin/cluster/uti1ities/clshowres Resource Group Name fallbackl_rg Participating Node Name(s) cobra viper python Startup Policy Online On Home Node Only Fall over Policy Fall over To Next Priority Node In The List Fallback Policy Fallback To Higher Priority Node In The List Delayed Fallback Timer july12
Для вывода значений существующей политики таймера возврата после восстановления можно выбрать
Альтернативный вариант состоит в том, чтобы опросить объектный класс HACMPtimer путем выполнения следующего кода:
#odmget HACMPtimer HACMPtimer: policy_name = "july12" recurrence = "once" year = 105 month = 6 day_of_month = 12 week_day = 0 hour = 17 minutes = 47
Сценарий тестирования таймеров отсроченного возврата после восстановления
Для того чтобы протестировать работу этой функции, мы сконфигурировали кластер из двух узлов с одной группой ресурсов, использующей таймер возврата после восстановления. В целях выполнения своего теста мы применили таймер возврата после восстановления, содержащий определенную дату.
Ниже перечислены атрибуты используемой нами группы ресурсов.
В процессе выполнения верификации/синхронизации нашего кластера мы заметили следующее сообщение в выходных данных clverify:
Resource Group ‘fallback1_rg’ is configured to use ‘july12’ fallback timer policy
После установления политики мы имитировали три этапа, представленные на рис. 11.5.
Ниже перечислены предпринятые нами действия.
cobra viper.viper.No action taken on resource group ‘fallback1_rg’ The Resource Group ‘fallback1_rg’ has been configured to fallback using ‘july12’ Timer Policy.Несмотря на то что в кластер был интегрирован узел с более высоким приоритетом, политика таймера была включена и для группы ресурсов не был выполнен немедленный возврат после восстановления. На этапе 2, представленном на рис. 11.4, как видим, группа ресурсов остается на дежурном узле до тех пор, пока не наступит период возврата после восстановления.
fallback1_rg перемещается обратно на основной узел ( cobra ). Так как основной узел
для группы ресурсов был доступен на момент проверки таймера возврата после восстановления (этап 3 на рис. 11.4), было выполнено немедленное перемещение группы ресурсов на этот узел.Результаты тестирования таймера отсроченного возврата после восстановления
В ходе теста мы доказали, что политика таймера возврата после восстановления была
реализована точно и что группа ресурсов не выполняла возврата на основной узел
до наступления заданного времени. Следует сообщить об одном нашем наблюдении, связанном с методом определения времени после реализации политики возврата после восстановления при переходе на летнее время. При включении перехода
на летнее время на компьютерах определение времени возврата после восстановления было неточным, что отразилось в файле журнала hacmp.out. Мы обнаружили это
при мониторинге применения политики таймера возврата после восстановления.
Ниже представлен пример обнаруженного нами несоответствия.
#date Wed Jul 13 17:18:09 EST 2005 #tail -f /tmp/hacmp.out No action taken on resource group ‘fallback1_rg’ The Resource Group ‘fallback1_rg’ has been configured to fallback on ‘Wed Jul 13 18:25:00 2005’
Кластер сообщил, что возврат после восстановления произойдет в 18:25:00, тогда как мы установили политику таймера возврата после восстановления на 17:25:00, как показано ниже.
#odmget HACMPtimer HACMPtimer: policy_name = "july13" recurrence = "once" year = 105 month = 6 day_of_month = 13 week_day = 0 hour = 17 minutes = 25
Тот же тест с отключенной опцией перехода на летнее время работал без несоответствий определения времени.
Появившееся в HACMP 5.2 понятие зависимости типа "
Такие зависимости могут быть полезны в бизнес-конфигурациях, использующих многоуровневые приложения. Например, в среде, в которой база данных должна быть подключена до сервера приложения, в случае отказа базы данных и ее перемещения на другой узел группа ресурсов, содержащая сервер приложения, также должна быть отключена и перемещена на любой из доступных узлов кластера. При неуспешном перемещении родительской группы ресурсов обе группы ресурсов (родительская и дочерняя) переходят в состояние ERROR и остаются отключенными.
Зависимость расположения, добавленная в HACMP 5.3, дает контроль над типом политики распространения группы ресурсов при ее получении и освобождении. Ниже описываются новые понятия, связанные с зависимостями.
Реализация зависимости дочернего объекта для группы ресурсов повышает гибкость конфигурирования приложений, зависящих друг от друга. Новым сотрудникам, осуществляющим управление кластером или пытающимся понять конфигурацию кластера, всегда следует сообщать об этих зависимостях, так как использование этой функции изменяет режим работы стандартных политик HACMP.
Можно вывести информацию об установленных зависимостях с использованием
команды clrgdependency.
Планирование зависимостей дочерних объектов для групп ресурсов
При подготовке к использованию зависимостей групп ресурсов следует учитывать множество различных аспектов конфигурирования.
Конфигурирование зависимости дочернего объекта для группы ресурсов
Помните о том, что конфигурируемые зависимости:
Ниже перечислены действия по конфигурированию зависимости дочернего объекта для группы ресурсов.
smit hacmpВ HACMP 5.3 были реализованы зависимости расположения для групп ресурсов. Их назначение состоит в том, чтобы контролировать расположение подключения зависимых групп ресурсов. Возможные варианты включают размещение всех зависимых ресурсов на одном узле и их размещение на разных узлах. При использовании сайтов можно применить политику совместного размещения групп ресурсов на одном сайте.
Ниже представлены три политики зависимости расположения.
Возможно совместное использование зависимости дочернего объекта для группы ресурсов и зависимости расположения. При этом можно указать, чтобы набор групп ресурсов всегда подключался на одном узле или чтобы набор групп ресурсов всегда подключался на разных узлах.
Планирование зависимости подключения на одном узле
Для эффективной реализации этой политики нужно помнить следующее:
Конфигурирование зависимости подключения на одном узле
Зависимость расположения на одном узле позволяет установить для набора групп ресурсов получение на одном узле. Конфигурирование этой политики осуществляется следующим образом:
smit hacmpПланирование зависимости подключения на разных узлах
Для эффективной реализации этой политики необходимо помнить о следующих правилах и ограничениях:
Конфигурирование зависимости подключения на разных узлах
Конфигурирование зависимости расположения такого типа осуществляется следующим образом:
smit hacmpПланирование зависимости подключения на одном сайте
При настройке двух или больше групп ресурсов на использование зависимости расположения эти группы ресурсов относятся к набору, связанному с определенной зависимостью. На зависимости сайтов распространяются следующие правила и ограничения:
Конфигурирование зависимости подключения на одном сайте
Для того чтобы настроить группы ресурсы на использование зависимости подключения на одном сайте, необходимо выполнить следующие действия:
smit hacmpСуществуют следующие ограничения конфигураций совмещения зависимостей. Верификация выдаст ошибку, если не следовать следующим инструкциям:
Если при получении уже существующего кластера 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)
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) Сценарий тестирования зависимости группы ресурсовМы реализовали шесть различных зависимостей, включая: зависимость "Tivoli всегда
подключаются на разных узлах, что позволяет распределить нагрузку. Мы включили
зависимость расположения на разных узлах для дочерних групп ресурсов и группы
ресурсов Testbed_Rg, чтобы в случае перемещения рабочих ресурсов на дежурный
узел python группа ресурсов с низким приоритетом, содержащая тестовое приложение, была отключена.
В табл. 11.5 описываются различные атрибуты групп ресурсов и политики запуска/перемещения при сбое/возврата после восстановления, используемые в наших группах ресурсов. Если вы незнакомы с сокращениями, указываемыми для каждой политики группы ресурсов, просмотрите в этом руководстве раздел, посвященный терминам. Также мы включили участвующие узлы, сервисные IP-метки и серверы приложений, используемые в каждой группе ресурсов.
| Группы ресурсов, определенные в кластере | ||||||
|---|---|---|---|---|---|---|
| Политика | DB2_1Rg | Child_1Rg | DB2_2Rg | Child_2Rg | Testbed_Rg | Tivoli_Rg |
| Родительский объект/дочерний объект | Да | Да | ||||
| Подключение на одном узле | Да | Да | ||||
| Родительский объект/дочерний объект | Да | Да | ||||
| Подключение на одном узле | Да | Да | ||||
| Подключение на разных узлах | Высокий | Высокий | Низкий | |||
| Подключение на разных узлах | Высокий | Высокий | Средний | |||
| Группы ресурсов, определенные в кластере | ||||||
|---|---|---|---|---|---|---|
| Атрибуты | DB2_1Rg | Child_1Rg | DB2_2Rg | Child_2Rg | Testbed_Rg | Tivoli_Rg |
| Запуск | OHNO | OHNO | OHNO | OHNO | OHNO | OHNO |
| Перемещение при сбое | FNPNL | FNPNL | FNPNL | FNPNL | FNPNL | FNPNL |
| Возврат после восстановления | NF | NF | NF | NF | NF | NF |
| Участвующие узлы | cobra, python, viper | cobra, python, viper | viper, python, cobra | viper, python, cobra | python, cobra, viper | python, cobra, viper |
| Сервисная IP-метка | app1svc | app2svc | app3svc | app4svc | ||
| Сервер приложения | db2_1 | db2_child1 | db2_2 | db2_child2 | testbed_app | tivoli_app |
Операции и результаты сценария тестирования
При тестировании мы пытались воссоздать
Наше тестирование содержало следующие действия:
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
Testbed_Rg. В этом состоянии мы попытались подключить тестовую группу ресурсов через меню HACMP. Мы
обнаружили, что не было доступных узлов для подключения группы ресурсов. Затем мы попытались выбрать опцию Restore_Node_Priority_Order, чтобы подключить
группу ресурсов; эта команда выполнилась без ошибок, однако, как и ожидалось, не
было самого действия.viper в кластер. Мы интегрировали узел обратно в кластер, и группа ресурсов Testbed_Rg была снова подключена на нем.DB2_2Rg с узла python обратно
на первоначальный узел viper.
Хотя группа ресурсов находилась в состоянии после перемещения при сбое, мы
попытались переместить первоначальные ресурсы узла viper обратно на домашний
узел через меню HACMP. Эта операция не показывала, что этот узел доступен для выполнения перемещения. Единственный способ, который позволил нам переместить
группу ресурсов обратно на узел viper, состоял в постепенном отключении узла python с передачей ресурсов.python в кластер.Мы обратили внимание на задержку при реинтеграции этого узла обратно
в кластер, однако в целом выполнение операции прошло успешно, и группа ресурсов Testbed_Rg возвратилась на узел python. Во время задержки в файлы hacmp.out
и clstrmgr.debug ничего не было записано. Группа ресурсов Tivoli_Rg осталась подключенной на узле viper, и мы решили оставить ее на этом узле.
В целом тестирование зависимостей групп ресурсов прошло успешно. Основным нашим наблюдением было то, что операции перемещения групп ресурсов были недоступны для всех групп ресурсов после реинтеграции узла, для которого прежде было выполнено перемещение при сбое. Это распространялось на группы ресурсов с высоким и низким приоритетом.
Во время тестирования мы не смогли протестировать операции DARE для изменений в политиках зависимостей групп ресурсов из-за отсутствия соответствующих функций. Однако поддержка динамических изменений в политиках зависимостей групп ресурсов будет реализована в последующих обновлениях этой версии.
Поведение отключенной группы ресурсов при запуске состоит в том, чтобы запуститься на первом доступном узле с наивысшим приоритетом, интегрируемом в кластер. Опция времени установления позволяет отсрочить старт группы ресурсов, чтобы в случае интеграции в кластер узла с более высоким приоритетом можно было подключить группу ресурсов на этом узле.
Работа опции времени установления
Конфигурирование времени установления для групп ресурсов
Чтобы настроить время установления для групп ресурсов, нужно выполнить следующие действия:
smit hacmpВывод текущего времени установления
Чтобы вывести текущее значение времени установления в кластере, можно выполнить команду clsettlingtime list.
#/usr/es/sbin/cluster/utilities/clsettlingtime list #SETTLING_TIME 120
Во время активизации групп ресурсов при запуске кластера значение времени установления можно также вывести командой clRGinfo -t (
пример 11.1
).
#/usr/es/sbin/cluster/uti1ities/clRGinfo -t Group Naate Group State Node Delayed Timers settling rgl OFFLINE cobra 120 Seconds OFFLINE python 120 Seconds settling_rg2 OFFLINE viper 120 Seconds OFFt INF python 120 Seconds
Обратите внимание на то, что это значение выводится только во время активизации; выходные данные команды clRGinfo будут пустыми по истечении периода времени установления и после активизации группы ресурсов на соответствующем узле.
Сценарий тестирования времени установления
Чтобы протестировать эту функцию, мы сконфигурировали кластер из трех узлов, использующий две группы ресурсов. При тестировании мы пытались проверить два утверждения:
Мы начинаем выполнение своего теста с того, что задаем параметру времени
установления значение 10 мин. (или 600 с). Две наши группы ресурсов ( Settling1_RG
и Settling2_RG ) были настроены на использование политики запуска Online on First
Available Node (Подключение на первом доступном узле). Мы задаем порядок в списке узлов для каждой группы ресурсов, чтобы перемещение при сбое для узлов kaitlyn
и thrish выполнялось на узел mike. Рис. 11.1 содержит схему нашей конфигурации,
а также последовательность поочередного запуска HACMP на узлах для тестирования
параметра времени установления.
Наше тестирование включало следующие действия:
(рис 11.1) Среда тестирования параметра времени установленияThe Resource Group Settling time value is: 120 secs. The Resource Group(s) affected by the settling time are: settling_rg1 settling_rg2
clRGinfo -t выдавало время установления, равное 600 с.
В файл hacmp.out была записана информация, представленная в
примере 11.2
:kaitlyn. Службы кластера были запущены через 2 мин. после начала периода времени установления. Сразу же после
запуска узла была активизирована группа ресурсов Settling2_RG. Нам не пришлось
ждать оставшиеся 8 мин. для получения и подключения группы ресурсов. Таких результатов мы и ожидали.#more /tmp/clstrmgr.debug Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Using resource attribute IBM.Host.PctTotalTimeldle Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: for nodes 3, 2. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: using values , 0.0000, 0.0000. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: condition is DNP_argest Wed Jul 13 10:40:53 In larges_comparison
Settling1_RG была активизирована на
узле mike. Так как первый узел в списке узлов ( thrish ) не стал доступным в период
времени установления, группа ресурсов была получена следующим узлом в списке
узлов ( mike ). Опять же, таких результатов мы и ожидали.В целом наш тест подтвердил, что опция времени установления работает, как и ожидалось, и что группы ресурсов были распределены требуемым образом между узлами.
Одной из политик запуска, которую можно задать для группы ресурсов в кластере, является политика Online Using Node Distribution (Подключение с применением распределения узлов). При использовании этой политики распределения распространение групп ресурсов происходит таким образом, что во время запуска узел получает только одну группу ресурсов. Это позволяет сбалансировать приложения с интенсивным использованием процессоров на разных узлах.
В HACMP 5.3 поддерживается только политика распределения на основе узлов.
Если при интеграции узла в кластер две или больше групп ресурсов отключены, политика сортирует группы ресурсов в следующем порядке
Если одна или несколько групп ресурсов являются родительскими группами ресурсов, HACMP отдает предпочтение родительской группе ресурсов. Дополнительные сведения по этой теме см. в разделе "Зависимости групп ресурсов".
Чтобы установить этот тип политики распределения, необходимо выполнить следующие действия ( пример 11.3 ):
smit hacmpAdd a Resource Group (extended)
Type or select values in entry fields.
Press Enter AFTER making all desired changes*
[Entry fields]
* Resource Group Maine
* Participating Nodes (Default Node Priority)
Startup Policy Online On Home Node О
Fallover Policy Fallover lo Next PHo>
Fallback Policy Fallback To Higher Pr>
Startup Policy
Hove cursor to desired item and press Enter,
Online On Home Node Only
Online On First Available Node
Online Using Distribution Policy
Online On All Available Nodes
Fl=Help F2=Refresh F3=Cancel
F8=Image F10=Exit Enter=Do
/=Find n=Find Next
В документации говорится, что при использовании групп ресурсов с этой политикой
только одна группа ресурсов на узле будет получена при запуске. В этом сценарии
тестирования мы хотели доказать, что это ограничение не повлияет на
Для выполнения тестирования политики распределения на основе узлов мы сконфигурировали кластер из двух узлов с пятью группами ресурсов:
Это было сделано для того, чтобы увеличить количество групп ресурсов, использующих политику Online Using Node Distribution (Подключение с использованием распределения узлов), которые можно подключить в кластере. Рис. 11.2 содержит схему нашей конфигурации.
(рис 11.2) Сценарий тестирования политики Online Using Node Distribution (Подключение с использованием распределения узлов)После поочередного запуска служб кластера на каждом узле получение было выполнено только для групп ресурсов Distributed_Rg1 и Distributed_Rg2 из групп ресурсов с политикой запуска Online Using Node Distribution (Подключение с использованием распределения узлов). Третья группа ресурсов, Distributed_Rg3, осталась без
узла, в состоянии OFFLINE. Однако ограничение не распространялось на оставшиеся
группы ресурсов, использующие другую политику запуска. Группы ресурсов APP1_Rg
и APP2_Rg были подключены на узлах cobra и viper, соответственно.
Результаты нашего тестирования подтвердили, что использование политики распределения на основе узлов ограничивает получение групп ресурсов этого типа на узле при запуске только одной группой ресурсов. Это не влияет на получение групп ресурсов, использующих другие политики.
Distributed_Rg3 в
состояние ONLINE в этой среде состоит в том, чтобы установить опцию подключения
группы ресурсов при каждом запуске кластера через панели HACMP или командой clRGmove.По умолчанию порядок приоритетов узлов для группы ресурсов соответствует порядку в списке участвующих узлов. Включение динамического приоритета узлов для
групп ресурсов позволяет изменить стандартный механизм перемещения при сбое
в HACMP и определить целевой узел для перемещения группы ресурсов при сбое на
основании следующих предопределенных атрибутов
cl_highest_free_mem - узел с наибольшим процентным показателем свободной
памятиcl_highest_idle_cpu - узел с наименьшим использованием процессораcl_lowest_disk_busy - узел с наименьшим использованием дисковДля обеспечения эффективности DNP необходимо отметить следующее:
На момент создания этой публикации сочетание устройств vpath с политикой cl_lowest_disk_busy не поддерживалось. Поддержка такой конфигурации, возможно,
будет добавлена в версию позднее, в форме обновления.
Для того чтобы установить DNP для группы ресурсов, эта группа ресурсов не должна уже содержать какие-либо ресурсы. Назначение политики динамического приоритета узлов должно происходить при создании группы ресурсов. Для того чтобы группа ресурсов использовала одну из трех политик DNP, необходимо выполнить следующие действия (пример 11.4).
smit hacmpAdd a Resource Group (extended) Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] * Resource Group Name [] * Participating Nodes (Default Node Priority) [] + Startup Policy Online On Home Node 0> + Fall over Policy Fall over To Next Prio> + Fallback Policy Fallback To Higher Pr> +Установите в поле Fallover Policy (Политика перемещения при сбое) значение Dynamic Node Priority (Динамический приоритет узлов).
Change/Show All Resources and Attributes for a Resource Group Type or select values in entry fields. Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name DNP_testl Participating Nodes (Default Node Priority) alexis Jessica Jordan * Dynamic Node Priority Policy [] + Startup Policy Online On Home Node 0> Fallover Policy Fallover Using Dynami> Fallback Policy Fallback To Higher Pr>
Для просмотра текущей политики DNP существующей группы ресурсов в вашей конфигурации можно выполнить следующую команду:
#odmget -q group=APP1_RG HACMPresource | more HACMPresource: group = "APP1_RG" name = "NODE_PRIORITY_POLICY" value = "cl_highest_free_mem" id = 1
Нельзя изменить политику перемещения при сбое на DNP, если какие-либо ресурсы
на данный момент являются частью группы ресурсов. При попытке изменения группы ресурсов через
Начиная с HACMP 5.2 определение динамического приоритета узлов больше не
опрашивает службы управления событиями (Event Management Services, emsvcs).
Вместо этого clstrmgrES каждые 2 мин. опрашивает демон Resource Monitoring and
Control (ctrmc) и ведет таблицу, в которой хранятся показатели текущего объема памяти, загруженности процессора и дискового ввода-вывода для каждого узла.
Мониторы ресурсов, содержащие информацию по каждой политике, следующие:
Каждый из этих мониторов может быть опрошен во время функционирования путем выполнения команд, представленных в примере 11.6
#lsrsrc -Ad IBM.Host | grep TotalPgSpFree TotalPgSpFree = 123076 PctTotalPgSpFree = 93.8995 flsrsrc -Ad IBM.Host I grep PetTotalTimeldle PctTotalTlrtieldle = 99.6649 #1srsrc -Ap IBM.PhysicalVolume resource 1: Name = "vpath7"
Текущую таблицу, которую ведет clstrmgrES, можно вывести путем выполнения команд, представленных в
примере 11.7
.
#l5src -Is clstrmgrES Current state: ST_STABLE sccsid = "@(#)36 1.135.1.37 src/haes/usr/sbin/cluster/hacmprd/main.C, hacmp.pe, 51haes_r530, r5300525a 6/20/05 14:13:01" i_local_nodeid 1, i_1ocal_siteid -1, my_handle Z ml_1dx[l]=0 ml_idx[2] = l ml_idx[3]=2 There are 0 events on the Ibcast queue There are 0 events on the RM Ibcast queue CLversion: 8 local node vrmf is 5300 cluster fix level is "0" The following timer(s) are currently active: Current DNP values DNP Values for Nodeld - 1 NodeName - cobra PgSpFree = 130771 PvPctBusy = 0 PctTotalTimeldle = 99.947917 DNP Values for Nodeld - 2 NodeName - python PgSpFree = 130741 PvPctBusy = 0 PctTotalTimeldle - 99.879167 DNP Values for Nodeld - 3 NodeName - viper PgSpFree = 124489 PvPctBusy = 0 PctTotalTimeldle = 99.941667
Значения в таблице употребляются для определения DNP в случае перемещения
при сбое. Если в процессе опроса текущего состояния демоном clstrmgrES происходит перемещение при сбое, для определения DNP используется значение, имевшее
место, когда кластер последний раз был в стабильном состоянии.
Для тестирования функций динамического приоритета узлов мы установили кластер из
трех узлов с двумя группами ресурсов, использующими различные политики DNP. Первая
группа ресурсов A (APP1_RG) использует значение cl_highest_idle_cpu, тогда как группа
ресурсов B (APP2_RG) применяет значение cl_highest_free_mem для определения узла для
перемещения при сбое. Для каждой группы ресурсов мы выполнили тестирование различных сценариев перемещения при сбое и задокументировали результаты. На рис. 11.3
представлена схема используемой конфигурации.
(рис 11.3) Сценарий тестирования динамического приоритета узловВ нашей среде мы установили для каждой группы ресурсов использование следующих политик запуска/перемещения при сбое/возврате после восстановления:
Startup = Online Using Distribution Policy Fallover = Fallover Using Dynamic Node Priority Fallback = Never Fallback Мы установили следующий порядок узлов для обеих групп ресурсов: cobra viper python
Наша топология содержит сеть Ethernet с применением IP-синонимов. Это означает, что в случае перемещения при сбое на одном узле могли располагаться несколько групп ресурсов. Это может произойти только в том случае, если определение узла с наименьшим использованием процессора и определение узла с наименьшим употреблением памяти указывают на один и тот же узел.
Этапы сценария тестирования DNP
В целях упрощения тестирования мы не использовали реальные рабочие нагрузки приложений для перегрузки процессоров или памяти узла. Вместо этого мы запустили цикл, чтобы загрузить два процессора, и применили команду rmss, чтобы логически сократить количество памяти, видимой в системе, инициируя выполнение операций подкачки.
Ниже приведен перечень действий, которые мы выполнили, чтобы убедиться в применении политик DNP.
cobra. Только первая группа ресурсов
(APP1_RG) была подключена в связи с установленной политикой Online Using Distribution
Policy (Подключение с использованием политики распределения).f/usr/es/sbin/cluster/uti)ities/clRGinfo APP1_RG ONLINE cobra OFFLINE viper OFFLINE python APP2_R6 ONLINE cobra OFFLINE viper OFFLINE pythonЭто позволило освободить узлы (
viper и python ), что дает нам возможность
применять два узла для выполнения перемещения при сбое. Это также позволило
нам протестировать определение показателей неиспользуемой памяти и процессора
на следующем этапе.viper, чтобы уменьшить количество доступной памяти и инициировать операции подкачки, как показано в
примере 11.9
:cobra-#rmss -p Simulated memory size is 8192 Mb. viper-#rmss -p Simulated memory size is 8192 Mb. viper-#rmss -c 2000 Simulated memory size changed to 2000 Mb. viper-#lptest 80 1000000000 > /appl/garbageJ41e.out viper-#lsps -s Total Paging Space Percent Used 512MB 7% viper-#lsrsrc -Ad IBM.Host grep PctTotalPgSpFree PctTotalPgSpFree = 93.8995Сначала мы сократили объем памяти на узле viper до 2 Гб, уменьшив, таким образом, объем доступной памяти. Затем мы использовали команду
lptest, чтобы
сгенерировать запись большого количества символов в файл, что инициирует операции подкачки. Мы осуществляли мониторинг изменений значения TotalPgSpFree в классе IBM.Host. В результате повышенной нагрузки на память узла viper узел
python стал следующим логичным вариантом при определении DNP для группы
ресурсов APP1_RG.ksh #vi cpu_loopl while true do done #./cpu_loopl #./cpu_loop2В результате выполнения двух экземпляров скрипта в фоновом режиме два процессора оказались перегружены. Результаты приведены в примере 11.11 :
#sar -P ALL 5 AIX p630nO2 3 5 000685BF4C00 07/08/05 System configuration: lcpu=4 11:56:46 cpu %usr %sys %wio %idle 11:56:51 0 0 0 0 100 1 100 0 0 0 2 100 0 0 0 3 0 0 0 100 50 0 0 50Мы перегрузили два процессора на узле viper, так как он был следующим узлом в списке узлов группы ресурсов. Таким образом, в результате уменьшение количества неиспользуемых процессоров узел python стал следующим логичным вариантом при определении DNP для группы ресурсов APP2_RG.
| Узлы кластера | Наибольший показатель бездействия процессора | Наибольший показатель свободной памяти |
|---|---|---|
| viper | 93.8995 | 93.8995 |
| python | 93.8995 | 93.8995 |
| Наилучший целевой узел | python | python |
#more /tmp/clstrmgr.debug Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Using resource attribute IBM.Host.PctTotalTimeldle Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: for nodes 3, 2. Wed Jul 13 10:40:53 NodeList: :RmcComputeNodePrion'ty: using values , 0.0000, 0.0000. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: condition is DNPJargest Wed Jul 13 10:40:53 In largest_comparison Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Computed node order 3, 2. Wed Jul 13 10:40:53 For Resource Group APP1_RG, BestNode got node order Wed Jul 13 10:40:53 NodeList::showNodeList: Got the following 2 node IDs: Wed Jul 13 10:40:53 NodeList::showNodeList: 3 2 Wed Jul 13 10:40:53 The best node for group APP1_RG is python. Wed Jul 13 10:40:53 RGPA got viper as highest priority node. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Using resource attribute IBM.Host.TotalPgSpFree Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: for nodes 3, 2. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: using values , 0.0000, 0.0000. Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: condition is DNPJargest Wed Jul 13 10:40:53 In largest_comparison Wed Jul 13 10:40:53 NodeList::RmcComputeNodePriority: Computed node order 3, 2. Wed Jul 13 10:40:53 For Resource Group APP2_RG, BestNode got node order Wed Jul 13 10:40:53 NodeList::showNodeList: Got the following 2 node IDs: Wed Jul 13 10:40:53 NodeList::showNodeList: 3 2 Wed Jul 13 10:40:53 The best node for group APP2_RG is python. Wed Jul 13 10:40:53 RGPA got viper as highest priority node.
cobra в кластер.cobra и viper делается таким образом, чтобы при определении
DNP выполнялось распределение двух групп ресурсов на узле python между двумя
разными узлами (
пример 11.13
).viper-#rmss -r Simulated memory size is 8192 Mb. viper-#./cpuloop1 viper- #./cpuloop2 viper-#sar -P ALL 5 AIX p630n02 3 5 00065BF4C00 07/08/05 System configuration: lcpu=4 18:03:20 cpu %usr %sys %wio %idle 18:03:25 0 0 0 0 100 1 100 0 0 0 2 100 0 0 0 3 0 0 0 100 50 0 0 50 viper-A*lsps -s Total Paging Space Percent Used 512MB 1% cobra-#rmss -c 2000 Simulated memory size changed to 2000 Mb. cobra-#lptest 80 1000000000 > /app1/garbage_file.out cobra-#lsps -s Total Paging Space Percent Used 512MB 6 %Мы перегрузили два процессора на узле
viper и инициировали операции подкачки на узле cobra, чтобы политика DNP в каждой группе ресурсов распределила их по
разным узлам.halt -qpython. Это вызвало перемещение группы ресурсов APP1_RG на узел cobra, так как на нем были доступны все процессоры. Группа ресурсов APP2_RG была перемещена на узел viper, так как на нем не выполнялись
операции подкачки и он имел больше свободной памяти. Табл. 11.3 показывает текущие значения clstrmgrES на момент перемещения при сбое.| Узел кластера | Наибольший показатель бездействия процессора | Наибольший показатель свободной памяти |
|---|---|---|
| viper | 93.8995 | 93.8995 |
| python | 93.8995 | 93.8995 |
| Наилучший целевой узел | cobra | viper |
Результаты тестирования сценария DNP
В результате выполнения сценария тестирования мы смогли доказать, что во время перемещения при сбое порядок в списке узлов по умолчанию игнорировался. После реинтеграции отказавшего узла мы изменили нагрузку на память и процессоры на двух бездействующих узлах и выполнили тестирование отказа узла, содержащего группы ресурсов. При определении DNP во второй раз было успешно выполнено распределение групп ресурсов по двум разным дежурным узлам.
В нашей среде мы использовали практичные команды для изменения нагрузки
на процессоры и память систем. Мы считаем, что результаты будут такими же, когда
нагрузка будет вызвана выполняющимся приложением. Во время настройки своей
среды DNP обязательно протестируйте все возможные сценарии перемещения при
сбое и выполните команды lsrscr -Ad и lssrc -ls clstrmgrES, описанные в этом
руководстве, для мониторинга текущей нагрузки на процессоры, память и дисковый
ввод-вывод на узлах кластера.
Понятие расположения, отменяющего приоритет (priority override location), появилось в HACMP 5.1 в качестве замены для прежнего атрибута "
При установке значения
Атрибут
Перемещение группы ресурсов
Обратите внимание на то, что эта операция недоступна для групп ресурсов без одновременного
Чтобы переместить группу ресурсов проделайте следующее:
clRGinfo -p. Образец результата выполнения данной команды представлен в
примере 11.14
.# /usr/es/sbin/cluster/utllitles/clRGInfo -p Cluster Name: migration2 Resource Group Name: C10RG2 Priority Override Information: Primary Instance POL: Node State viper ONLINE cobra OFFLINE Resource Group Name: C10RG1 Priority Override Information: Primary Instance POL: viper Node State cobra OFFLINE viper ONLINE
Если установлен атрибут /usr/es/sbin/
cluster/etc/clpol, который остается на этих узлах до перезагрузки кластера или перемещения группы ресурсов с установленной опцией Restore_Node_Priority_Order.
Файл содержит представление всех расположений, отменяющих приоритет, и его
можно интерпретировать в следующем формате: [RG id] [node id] [
3 2 2 1 // RG 3 on node 2 is OFFLINE persistent 3 1 2 1 // RG 3 on node 1 is OFFLINE persistent 1 1 1 0 // RG 1 on node 1 is ONLINE non-persistent
Данные файла имеют числовой формат и не предназначены для просмотра или изменения конечным пользователем.
clpol вручную НЕ сбрасывает атрибут Подключение или отключение группы ресурсов
Существует несколько дополнительных операций, при которых можно неявным
образом установить расположение, отменяющее приоритет для группы ресурсов.
При подключении или отключении группы ресурсов с использованием следующих
опций меню и выборе целевого узла происходит установка атрибута
Если при подключении группы ресурсов установить опцию Restore_Node_Priority_
Order, группа ресурсов будет подключена на узле, для которого установлен
наивысший приоритет (определяемый на основании списка узлов), и атрибут
При отключении группы ресурсов с использованием метода, приведенного выше,
следует помнить о том, что устанавливается другой тип Restore_Node_Priority_Order.
Сброс расположения, отменяющего приоритет
После установки Restore_Node_Priority_Order. В
примере 11.15
показано, как выглядит эта опция меню.
При выборе этой опции:
При использовании групп ресурсов с политикой запуска Online Using Distribution
Policy (Подключение с использованием политики распределения) опция меню
будет выглядеть по-другому. Вместо опции Restore_Node_Priority_Order для сброса
Move a Resource Group to Another Node / Site Move cursor to desired item and press Enter. Move Resource Groups to Another Node Move Resource Groups to Another Site Select a Destination Node Move cursor to desired item and press Enter. # To choose the highest priority available node for the # resource group, and to remove any Priority Override Location # that is set for the resource group, select # "Restore_Node_Priority_Order" below, Restore_Node_Priority_Order # To choose a specific node, select one below. viper Fl=Help F2=Refresh F3=Cancel F8=Image FlO=Exit Enter=Do F1/Find n=Find Next
атрибута Reset_Any_Priority_Overrides. Для группы
ресурсов данного типа восстановление приоритета узла не должно вызывать действительного перемещения ресурсов, так как в этом случае отсутствует понятие узла с
наивысшим приоритетом.
Рекомендации по использованию атрибута расположения, отменяющего приоритет
При управлении расположением своих групп ресурсов следует быть особенно внимательным к тому, где расположен атрибут
Restore_Node_Priority_Order.Restore_Node_Priority_Order.Restore_Node_Priority_Order, выбирается определенное
имя узла, атрибут Этот параметр позволяет настраивать выполнение возврата после восстановления для группы ресурсов таким образом, чтобы оно происходило в заданное время: ежедневно, еженедельно, ежемесячно, ежегодно или в заданную дату и время. Это полезно для того, чтобы планировать возвраты после восстановления на нерабочее время. схема на рис. 11.5 показывает три различных этапа при использовании таймеров отсроченного возврата после восстановления.
(рис 11.4) Этапы таймеров отсроченного возврата после восстановленияВ случае отказа происходит перемещение группы ресурсов на дежурный узел. Группа ресурсов остается там, пока не наступит время, заданное таймером отсроченного возврата после восстановления. Если в это время на основном узле активны службы кластера, группа ресурсов выполняет перемещение на узел с наивысшим приоритетом. Если узел с более высоким приоритетом в это время будет недоступен, таймер возврата после восстановления будет переустановлен и возврат после восстановления будет отсрочен до следующего повторения этого значения времени.
Принцип работы таймера отсроченного возврата после восстановления
Для эффективной реализации среды, использующей таймеры отсроченного возврата после восстановления, следует учитывать следующие аспекты:
Конфигурирование таймера возврата после восстановления для групп ресурсов
Для конфигурирования этой функции нужно выполнить следующие действия:
Change/Show All Resources and Attributes for a Resource Group Type 6r select values in entry fields. Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name fal1backl_rg Participating Nodes (Default Node Priority) cobra viper python Startup Policy Online On Home Node Only Fallover Policy Fallover To Next Priority** Fallback Policy Fallback To Higher Priori> Fallback Timer Policy (empty is immediate) [] Service IP Labels/Addresses Ap VO Us Au Fi Fi [MOR F1=H F5=R F9=S Fallback Timer Policy (empty is immediate) Move cursor to desired item and press Enter. julyl2 julyltest Fl-Help F2-Refresh F3-Cancel F8=Image F10=Exit Enter=Do /=Find n=Find Next
Вывод таймеров отсроченного возврата после восстановления в группе ресурсов
При работе в среде с запущенным кластером можно проверить наличие существующих политик возврата после восстановления для групп ресурсов путем просмотра
выходных данных команды clshowres, как показано в
примере 11.17
:
#/usr/es/sbin/cluster/uti1ities/clshowres Resource Group Name fallbackl_rg Participating Node Name(s) cobra viper python Startup Policy Online On Home Node Only Fall over Policy Fall over To Next Priority Node In The List Fallback Policy Fallback To Higher Priority Node In The List Delayed Fallback Timer july12
Для вывода значений существующей политики таймера возврата после восстановления можно выбрать
Альтернативный вариант состоит в том, чтобы опросить объектный класс HACMPtimer путем выполнения следующего кода:
#odmget HACMPtimer HACMPtimer: policy_name = "july12" recurrence = "once" year = 105 month = 6 day_of_month = 12 week_day = 0 hour = 17 minutes = 47
Сценарий тестирования таймеров отсроченного возврата после восстановления
Для того чтобы протестировать работу этой функции, мы сконфигурировали кластер из двух узлов с одной группой ресурсов, использующей таймер возврата после восстановления. В целях выполнения своего теста мы применили таймер возврата после восстановления, содержащий определенную дату.
Ниже перечислены атрибуты используемой нами группы ресурсов.
В процессе выполнения верификации/синхронизации нашего кластера мы заметили следующее сообщение в выходных данных clverify:
Resource Group ‘fallback1_rg’ is configured to use ‘july12’ fallback timer policy
После установления политики мы имитировали три этапа, представленные на рис. 11.5.
Ниже перечислены предпринятые нами действия.
cobra viper.viper.No action taken on resource group ‘fallback1_rg’ The Resource Group ‘fallback1_rg’ has been configured to fallback using ‘july12’ Timer Policy.Несмотря на то что в кластер был интегрирован узел с более высоким приоритетом, политика таймера была включена и для группы ресурсов не был выполнен немедленный возврат после восстановления. На этапе 2, представленном на рис. 11.4, как видим, группа ресурсов остается на дежурном узле до тех пор, пока не наступит период возврата после восстановления.
fallback1_rg перемещается обратно на основной узел ( cobra ). Так как основной узел
для группы ресурсов был доступен на момент проверки таймера возврата после восстановления (этап 3 на рис. 11.4), было выполнено немедленное перемещение группы ресурсов на этот узел.Результаты тестирования таймера отсроченного возврата после восстановления
В ходе теста мы доказали, что политика таймера возврата после восстановления была
реализована точно и что группа ресурсов не выполняла возврата на основной узел
до наступления заданного времени. Следует сообщить об одном нашем наблюдении, связанном с методом определения времени после реализации политики возврата после восстановления при переходе на летнее время. При включении перехода
на летнее время на компьютерах определение времени возврата после восстановления было неточным, что отразилось в файле журнала hacmp.out. Мы обнаружили это
при мониторинге применения политики таймера возврата после восстановления.
Ниже представлен пример обнаруженного нами несоответствия.
#date Wed Jul 13 17:18:09 EST 2005 #tail -f /tmp/hacmp.out No action taken on resource group ‘fallback1_rg’ The Resource Group ‘fallback1_rg’ has been configured to fallback on ‘Wed Jul 13 18:25:00 2005’
Кластер сообщил, что возврат после восстановления произойдет в 18:25:00, тогда как мы установили политику таймера возврата после восстановления на 17:25:00, как показано ниже.
#odmget HACMPtimer HACMPtimer: policy_name = "july13" recurrence = "once" year = 105 month = 6 day_of_month = 13 week_day = 0 hour = 17 minutes = 25
Тот же тест с отключенной опцией перехода на летнее время работал без несоответствий определения времени.
Появившееся в HACMP 5.2 понятие зависимости типа "
Такие зависимости могут быть полезны в бизнес-конфигурациях, использующих многоуровневые приложения. Например, в среде, в которой база данных должна быть подключена до сервера приложения, в случае отказа базы данных и ее перемещения на другой узел группа ресурсов, содержащая сервер приложения, также должна быть отключена и перемещена на любой из доступных узлов кластера. При неуспешном перемещении родительской группы ресурсов обе группы ресурсов (родительская и дочерняя) переходят в состояние ERROR и остаются отключенными.
Зависимость расположения, добавленная в HACMP 5.3, дает контроль над типом политики распространения группы ресурсов при ее получении и освобождении. Ниже описываются новые понятия, связанные с зависимостями.
Реализация зависимости дочернего объекта для группы ресурсов повышает гибкость конфигурирования приложений, зависящих друг от друга. Новым сотрудникам, осуществляющим управление кластером или пытающимся понять конфигурацию кластера, всегда следует сообщать об этих зависимостях, так как использование этой функции изменяет режим работы стандартных политик HACMP.
Можно вывести информацию об установленных зависимостях с использованием
команды clrgdependency.
Планирование зависимостей дочерних объектов для групп ресурсов
При подготовке к использованию зависимостей групп ресурсов следует учитывать множество различных аспектов конфигурирования.
Конфигурирование зависимости дочернего объекта для группы ресурсов
Помните о том, что конфигурируемые зависимости:
Ниже перечислены действия по конфигурированию зависимости дочернего объекта для группы ресурсов.
smit hacmpВ HACMP 5.3 были реализованы зависимости расположения для групп ресурсов. Их назначение состоит в том, чтобы контролировать расположение подключения зависимых групп ресурсов. Возможные варианты включают размещение всех зависимых ресурсов на одном узле и их размещение на разных узлах. При использовании сайтов можно применить политику совместного размещения групп ресурсов на одном сайте.
Ниже представлены три политики зависимости расположения.
Возможно совместное использование зависимости дочернего объекта для группы ресурсов и зависимости расположения. При этом можно указать, чтобы набор групп ресурсов всегда подключался на одном узле или чтобы набор групп ресурсов всегда подключался на разных узлах.
Планирование зависимости подключения на одном узле
Для эффективной реализации этой политики нужно помнить следующее:
Конфигурирование зависимости подключения на одном узле
Зависимость расположения на одном узле позволяет установить для набора групп ресурсов получение на одном узле. Конфигурирование этой политики осуществляется следующим образом:
smit hacmpПланирование зависимости подключения на разных узлах
Для эффективной реализации этой политики необходимо помнить о следующих правилах и ограничениях:
Конфигурирование зависимости подключения на разных узлах
Конфигурирование зависимости расположения такого типа осуществляется следующим образом:
smit hacmpПланирование зависимости подключения на одном сайте
При настройке двух или больше групп ресурсов на использование зависимости расположения эти группы ресурсов относятся к набору, связанному с определенной зависимостью. На зависимости сайтов распространяются следующие правила и ограничения:
Конфигурирование зависимости подключения на одном сайте
Для того чтобы настроить группы ресурсы на использование зависимости подключения на одном сайте, необходимо выполнить следующие действия:
smit hacmpСуществуют следующие ограничения конфигураций совмещения зависимостей. Верификация выдаст ошибку, если не следовать следующим инструкциям:
Если при получении уже существующего кластера 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)
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) Сценарий тестирования зависимости группы ресурсовМы реализовали шесть различных зависимостей, включая: зависимость "Tivoli всегда
подключаются на разных узлах, что позволяет распределить нагрузку. Мы включили
зависимость расположения на разных узлах для дочерних групп ресурсов и группы
ресурсов Testbed_Rg, чтобы в случае перемещения рабочих ресурсов на дежурный
узел python группа ресурсов с низким приоритетом, содержащая тестовое приложение, была отключена.
В табл. 11.5 описываются различные атрибуты групп ресурсов и политики запуска/перемещения при сбое/возврата после восстановления, используемые в наших группах ресурсов. Если вы незнакомы с сокращениями, указываемыми для каждой политики группы ресурсов, просмотрите в этом руководстве раздел, посвященный терминам. Также мы включили участвующие узлы, сервисные IP-метки и серверы приложений, используемые в каждой группе ресурсов.
| Группы ресурсов, определенные в кластере | ||||||
|---|---|---|---|---|---|---|
| Политика | DB2_1Rg | Child_1Rg | DB2_2Rg | Child_2Rg | Testbed_Rg | Tivoli_Rg |
| Родительский объект/дочерний объект | Да | Да | ||||
| Подключение на одном узле | Да | Да | ||||
| Родительский объект/дочерний объект | Да | Да | ||||
| Подключение на одном узле | Да | Да | ||||
| Подключение на разных узлах | Высокий | Высокий | Низкий | |||
| Подключение на разных узлах | Высокий | Высокий | Средний | |||
| Группы ресурсов, определенные в кластере | ||||||
|---|---|---|---|---|---|---|
| Атрибуты | DB2_1Rg | Child_1Rg | DB2_2Rg | Child_2Rg | Testbed_Rg | Tivoli_Rg |
| Запуск | OHNO | OHNO | OHNO | OHNO | OHNO | OHNO |
| Перемещение при сбое | FNPNL | FNPNL | FNPNL | FNPNL | FNPNL | FNPNL |
| Возврат после восстановления | NF | NF | NF | NF | NF | NF |
| Участвующие узлы | cobra, python, viper | cobra, python, viper | viper, python, cobra | viper, python, cobra | python, cobra, viper | python, cobra, viper |
| Сервисная IP-метка | app1svc | app2svc | app3svc | app4svc | ||
| Сервер приложения | db2_1 | db2_child1 | db2_2 | db2_child2 | testbed_app | tivoli_app |
Операции и результаты сценария тестирования
При тестировании мы пытались воссоздать
Наше тестирование содержало следующие действия:
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
Testbed_Rg. В этом состоянии мы попытались подключить тестовую группу ресурсов через меню HACMP. Мы
обнаружили, что не было доступных узлов для подключения группы ресурсов. Затем мы попытались выбрать опцию Restore_Node_Priority_Order, чтобы подключить
группу ресурсов; эта команда выполнилась без ошибок, однако, как и ожидалось, не
было самого действия.viper в кластер. Мы интегрировали узел обратно в кластер, и группа ресурсов Testbed_Rg была снова подключена на нем.DB2_2Rg с узла python обратно
на первоначальный узел viper.
Хотя группа ресурсов находилась в состоянии после перемещения при сбое, мы
попытались переместить первоначальные ресурсы узла viper обратно на домашний
узел через меню HACMP. Эта операция не показывала, что этот узел доступен для выполнения перемещения. Единственный способ, который позволил нам переместить
группу ресурсов обратно на узел viper, состоял в постепенном отключении узла python с передачей ресурсов.python в кластер.Мы обратили внимание на задержку при реинтеграции этого узла обратно
в кластер, однако в целом выполнение операции прошло успешно, и группа ресурсов Testbed_Rg возвратилась на узел python. Во время задержки в файлы hacmp.out
и clstrmgr.debug ничего не было записано. Группа ресурсов Tivoli_Rg осталась подключенной на узле viper, и мы решили оставить ее на этом узле.
В целом тестирование зависимостей групп ресурсов прошло успешно. Основным нашим наблюдением было то, что операции перемещения групп ресурсов были недоступны для всех групп ресурсов после реинтеграции узла, для которого прежде было выполнено перемещение при сбое. Это распространялось на группы ресурсов с высоким и низким приоритетом.
Во время тестирования мы не смогли протестировать операции DARE для изменений в политиках зависимостей групп ресурсов из-за отсутствия соответствующих функций. Однако поддержка динамических изменений в политиках зависимостей групп ресурсов будет реализована в последующих обновлениях этой версии.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.