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

Таймер отсроченного возврата после восстановления

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

Рис. 11.4. Этапы таймеров отсроченного возврата после восстановления

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

Принцип работы таймера отсроченного возврата после восстановления

Для эффективной реализации среды, использующей таймеры отсроченного возврата после восстановления, следует учитывать следующие аспекты:

• Таймер отсроченного возврата после восстановления используется только для групп ресурсов, применяющих политику Fallback To Higher Priority Node In The List (Возврат после восстановления на узел с более высоким приоритетом в списке). Если на промежуток времени, заданный таймером, узел с более высоким приоритетом недоступен, возврат группы ресурсов не выполняется.
• При использовании определенного значения даты в таймере возврата после восстановления повторная проверка доступности узла с более высоким приоритетом не выполняется. Только использование других значений перезапустит таймер и позволит выполнить проверку при следующей итерации.
• Если на определенном узле для группы ресурсов задан атрибут расположения, отменяющего приоритет (priority override location, POL), то в момент времени, когда таймер возврата после восстановления выполняет проверку, группа ресурсов будет перемещена на узел, заданный параметром POL.
• При использовании набора Same Node Dependency, если одна группа ресурсов в наборе имеет таймер возврата после восстановления, он применяется ко всему набору. При использовании таймера возврата после восстановления для групп ресурсов, применяющих политику Same Site Dependency, этот таймер должен быть одинаковым для всех групп ресурсов в наборе. Дополнительные сведения по этой теме см. в разделе "Зависимости групп ресурсов".
• Нельзя удалить таймер возврата после восстановления, если группа ресурсов его в данный момент использует.
• Нельзя сконфигурировать таймеры отсроченного возврата после восстановления через экраны Initialization and Standard Configuration (Инициализация и стандартное конфигурирование). Их можно сконфигурировать только с использованием пути Extended Configuration (Расширенное конфигурирование).

Конфигурирование таймера возврата после восстановления для групп ресурсов

Для конфигурирования этой функции нужно выполнить следующие действия:

1. Введите smit hacmp.
2. Выберите Extended Configuration (Расширенное конфигурирование) > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > Configure Resource Group Run-Time Policies (Конфигурирование политик времени выполнения для группы ресурсов) > Configure Delayed Fallback Timer Policies (Конфигурирование политик таймера отсроченного возврата после восстановления) > Add a Delayed Fallback Timer Policy (Добавить политику таймера отсроченного возврата после восстановления) и нажмите Enter.
3. Выберите политику из списка: daily (ежедневно), weekly (еженедельно), monthly (ежемесячно), yearly (ежегодно) – либо укажите определенную дату.
4. Введите значения следующих полей:
   • Name of Fallback Policy (Имя политики возврата после восстановления). Укажите имя политики длиной не более 32 символов. Используйте только алфавитно-цифровые символы и знаки подчеркивания. Не применяйте цифры в начале имени или зарезервированные слова.
   • Policy selected (Выбранная политика). Выберите соответствующие значения для выбранной политики. Поля будут содержать день, час, минуты, год или их сочетание.

   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

   Пример 11.16. Определение политики таймера возврата после восстановления в группе ресурсов
5. Чтобы назначить таймер группе ресурсов, нужно выбрать smit hacmp > Extended Configuration (Расширенное конфигурирование) > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > HACMP Extended Resource Group Configuration (Расширенное конфигурирование групп ресурсов HACMP), после чего выбрать требуемую группу ресурсов из списка и нажать Enter.
6. Нажмите клавишу F4, чтобы выбрать одну из политик, сконфигурированных на предыдущих этапах. Появится следующий экран ( пример 11.16 ).
7. Выберите требуемую политику таймера возврата после восстановления из списка и нажмите Enter.
8. Добавьте требуемые дополнительные ресурсы в группу ресурсов и нажмите Enter.
9. Запустите процесс верификации и синхронизации в кластере для распространения изменений на всех узлах.

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

При работе в среде с запущенным кластером можно проверить наличие существующих политик возврата после восстановления для групп ресурсов путем просмотра выходных данных команды 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

Для вывода значений существующей политики таймера возврата после восстановления можно выбрать smit hacmp > Extended Configuration (Расширенное конфигурирование) > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > Configure Resource Group Run-Time Policies (Конфигурирование политик времени выполнения для группы ресурсов) > Configure Delayed Fallback Timer Policies (Конфигурирование политик таймера отсроченного возврата после восстановления) > Change/Show a Delayed Fallback Timer Policy (Изменить/вывести политику отсроченного таймера возврата после восстановления) и выбрать политику из списка.

Альтернативный вариант состоит в том, чтобы опросить объектный класс HACMPtimer путем выполнения следующего кода:

#odmget HACMPtimer
 HACMPtimer:
   policy_name = "july12"
   recurrence = "once"
   year = 105
   month = 6
   day_of_month = 12
   week_day = 0
   hour = 17
   minutes = 47

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

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

Ниже перечислены атрибуты используемой нами группы ресурсов.

• Имя группы ресурсов: fallback1_rg.
• Участвующие узлы: cobra viper.
• Политика запуска: Online On Home Node Only (Подключение только на домашнем узле).
• Политика перемещения при сбое: Fallover To Next Priority Node In The List (Перемещение при сбое на узел из списка со следующим приоритетом).
• Политика возврата после восстановления: Fallback To Higher Priority Node In The List (Возврат после восстановления на узел с более высоким приоритетом в списке).
• Таймер отсроченного возврата после восстановления: 12 июля.

В процессе выполнения верификации/синхронизации нашего кластера мы заметили следующее сообщение в выходных данных clverify:

Resource Group ‘fallback1_rg’ is configured to 
  use ‘july12’ fallback timer policy

После установления политики мы имитировали три этапа, представленные на рис. 11.5.

Ниже перечислены предпринятые нами действия.

1. Мы запустили службы кластера на обоих узлах: cobra viper.
2. Мы имитировали отказ (этап 1 на рис. 11.4) основного узла cobra. Для этого мы выполнили на узле постепенную остановку HACMP с передачей ресурсов на резервные узлы (graceful with takeover). Мы решили выполнить перемещение группы ресурсов таким способом, чтобы избежать назначения POL при выполнении операции перемещения группы ресурсов.
3. Мы убедились в том, что группа ресурсов была подключена на узле viper.
4. Была выполнена реинтеграция узла cobra (узла с более высоким приоритетом) в кластер. Когда мы запустили службы кластера на узле, мы заметили следующее сообщение в файле /tmp/hacmp.out:

   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, как видим, группа ресурсов остается на дежурном узле до тех пор, пока не наступит период возврата после восстановления.
5. При наступлении периода времени, на который была настроена политика таймера, вызывается операция перемещения группы ресурсов и группа ресурсов 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

Тот же тест с отключенной опцией перехода на летнее время работал без несоответствий определения времени.