Контроль и тестирование изменений
Осуществление контроля за изменениями является необходимым условием эффективного обеспечения высокой доступности в кластерных системах. Управление изменениями представляет собой набор всесторонне документированных процедур.
Оно включает несколько компонентов и является обязательным.
Управление изменениями среди прочего включает:
ограниченный административный доступ;
тщательно документированные и протестированные процедуры;
надлежащее планирование и утверждение изменений.
Тестовый кластер
Тестовый кластер является важным элементом в обеспечении надлежащего управления изменениями и в общей эффективности рабочего кластера. Тестовые кластеры
позволяют осуществлять тщательное тестирование административных процедур
и/или процедур обслуживания с целью обнаружения проблем до того, как они достигнут рабочего кластера. Тестовые кластеры – это не роскошь, а обязательный
элемент.
Многие существующие клиенты HACMP имеют тестовый кластер или по меньшей
мере начинают с тестового кластера. Однако со временем узлы тестового кластера
часто начинают применять в компании для других целей. Использование этих систем
требует запланированного окна обслуживания, подобно рабочему кластеру. В такой ситуации не следует считать, что эти узлы больше не представляют тестовый кластер.
В идеале тестовый кластер должен использовать те же версии и обновления AIX,
HACMP и приложений, которые использует и рабочий кластер. Предпочтительно
также использовать максимально похожее оборудование. В большинстве случаев
нецелесообразно полностью копировать рабочую среду, особенно при применении
нескольких рабочих кластеров. Существует несколько методов, которые можно применять для обеспечения максимальной эффективности тестового кластера при употреблении нескольких рабочих кластеров с различным программным обеспечением.
Например, часто используются логические разделы (LPAR) и несколько различных
образов rootvg с применением alt_disk_install. Логические разделы позволяют без
труда создать тестовый кластер с минимальным использованием физических ресурсов; например, тестовый кластер даже может разместиться на одном физическом компьютере. Использование нескольких загрузочных образов позволяет клиентам легко
сменить кластерную среду путем перезагрузки раздела с другого образа. Это также
позволяет осуществлять тестирование многих программных процедур:
обслуживание AIX;
применение исправлений HACMP;
обслуживание приложений.
Этот тип тестового кластера требует употребления как минимум одного диска
на образ на LPAR. Например, если тестовый кластер содержит два узла и три разных образа rootvg, требуется использовать по меньшей мере шесть жестких дисков. Тем
не менее это гораздо проще, чем применять шесть отдельных узлов в трех тестовых
кластерах.
Общую стоимость тестового кластера можно еще больше сократить с использованием расширенной виртуализации Power5. Расширенная виртуализация (advanced
virtualization) позволяет располагать несколько образов rootvg на одном физическом
диске. Она также позволяет логическим разделам использовать общую физическую
сеть и DASD-адаптеры через VLAN и VSCSI. Дополнительные сведения об этих возможностях см. в книге Advanced POWER Virtualization on IBM Eserver p5 Servers:
Introduction and Basic Configuration, SG24-7940
Тестовый кластер также позволяет выполнять тестирование процедур обслуживания оборудования. Эти процедуры в числе прочего включают:
обновление микрокода компьютера;
обновление микрокода адаптера;
замена адаптера;
замена диска.
Другие операции тестирования можно выполнить с использованием инструмента
тестирования кластера (Cluster Test Tool) и/или эмуляции событий.
Запуск и остановка кластера
Под запуском служб кластера подразумевается процесс запуска подсистем RSCT,
необходимых для работы HACMP, с последующим запуском демонов HACMP, обеспечивающих необходимое согласование между узлами кластера. Во время запуска
диспетчер кластера (Cluster Manager) выполняет событие node_up, после чего осуществляется подхват групп ресурсов. Под остановкой служб кластера понимается
остановка этих демонов на узле, которая в зависимости от типа остановки может
вызывать выполнение дополнительных скриптов HACMP.
Важно! Начиная с HACMP V5.3 процесс диспетчера кластера (clstrmgrES) всегда
выполняется. Он может находиться в одном из двух состояний, выводимых
следующей командой:lssrc -ls clstrmgrES
ST_INIT (событие запуска выполняется)
ST_NOTCONFIGURED (событие запуска не выполняется)
Изменения в состоянии кластера называются событиями кластера (cluster events).
Диспетчер кластера (Cluster Manager) на каждом узле осуществляет мониторинг локальной аппаратной и программной подсистем на такие события, как, например,
событие отказа приложения (application failure). При возникновении таких
событий диспетчер кластера выполняет один или несколько скриптов, например
скрипт перезапуска приложения (restart application). Диспетчеры кластера,
выполняющиеся на всех узлах, обмениваются сообщениями в целях согласования
необходимых действий в при возникновении событий.
Во время периодов обслуживания часто бывает необходимо остановить и запустить службы кластера. Однако перед этим необходимо понять, какие при этом возникают взаимодействия между узлами, а также каково воздействие на доступность системы. Кластер должен быть синхронизирован, и верификация не должна обнаруживать ошибок. Следующий раздел кратко описывает эти процессы, а также обработку,
выполняемую при запуске или остановке этих служб. Далее в этом разделе приведено
описание процедур, необходимых для запуска или остановки служб кластера на узле.
Службы кластера
Ниже перечислены основные демоны HACMP и RSCT.
Демон диспетчера кластера (Cluster Manager daemon, clstrmgrES). Основной демон HACMP. Он обеспечивает глобальное представление топологии кластера и ресурсов, а также запускает скрипты обработки событий в ответ на изменения
состояния узлов, интерфейсов или ресурсов (или по запросу пользователя).
Диспетчер кластера получает информацию о состоянии интерфейсов от служб
топологии (Topology Services). Диспетчер кластера обеспечивает актуальную информацию о расположении и состоянии всех групп ресурсов. Диспетчер кластера
является клиентом служб групп (Group Services) и использует последние для обеспечения надежной связи между демонами.
В версиях 5.1 и 5.2 этот демон запускается после служб кластера. В версии 5.3 демон clstrmgr запускается через процесс init и должен выполняться постоянно.
Кроме того, так как в версии 5.3 демон clstrmgr является постоянно выполняющимся процессом, нельзя использовать команду lssrc -s clstrmgrES для определения состояния кластера. Вместо этого следует использовать команду /usr/es/
sbin/cluster/utilities/clcheck_server grpsvcs.
Демон диспетчера блокировки кластера (Cluster Lock Manager daemon,
cllockd). Этот демон представляет информационные службы блокировки. Использование демона cllockd на узлах кластера необходимо только в том случае,
если эти узлы входят в конфигурацию с одновременным доступом. Обратите внимание на то, что диспетчер блокировки не поддерживается на 64-разрядном ядре
и полностью удален начиная с HACMP V5.2.
Демон коммуникаций кластера (Cluster Communication Daemon, clcomdES).
Этот демон, впервые появившийся в версии 5.1, обеспечивает безопасную
связь между узлами кластера для всех утилит кластера, в частности утилит верификации и синхронизации и управления системой (C-SPOC). Демон clcomd запускается автоматически при загрузке через процесс init. Начиная с версии 5.2,
clcomdES должен быть запущен, прежде чем можно будет запустить какие-либо
службы кластера.
Демон информации кластера (Cluster Information Program, clinfoES).
Этот демон предоставляет информацию о состоянии кластера узлам кластера и
клиентам, а также вызывает скрипт /usr/es/sbin/cluster/etc/clinfo.rc при возникновении событий кластера. Демон clinfo является необязательным на узлах
кластера и клиентах.
Демон Cluster SMUX Peer daemon (clsmuxpd). Этот демон предоставляет информацию о состоянии объектов кластера. Он публикует информацию о состоянии топологии и ресурсов кластера для MIB. Он является клиентом диспетчера
кластера (Cluster Manager). Этот демон работает совместно с демоном протокола
SNMP (snmpd). Демон clsmuxpd должен выполняться на всех узлах кластера.Примечание. Демон clsmuxpd нельзя запустить при отключенном демоне snmpd.
В HACMP 5.3 clsmuxpd больше не используется.
Подсистема служб топологии кластера (Cluster Topology Services Subsystem).
Подсистема служб топологии кластера RSCT обеспечивает мониторинг состояния сетевых интерфейсов и публикует состояние для клиентов, осуществляющих доступ к информации посредством членства в службах групп. Основным демоном является демон hatsd. Службы топологии также включают сетевые интерфейсные модули hats_nim*, отправляющие и получающие пакеты пульса. Подсистема служб топологии кластера должна выполняться на всех узлах кластера.
Подсистема управления событиями кластера (Cluster Event Management
Subsystem). Эта подсистема RSCT сопоставляет информацию о состоянии системных ресурсов с информацией о состоянии ресурсов, требуемых для клиентских программ (приложений, подсистем и прочих программ). Демон haemd выполняется на всех узлах домена.Примечание. Подсистема управления событиями кластера используется только
в Oracle 9i; в HACMP 5.2 и более поздних версиях он заменен подсистемой RMC
(Resource Monitoring and Control).
Монитор ресурсов подсистемы управления событиями операционной
системы AIX (Event Management AIX Operating System Resource Monitor).
Этот демон RSCT выступает в качестве монитора ресурсов для подсистемы управления событиями и обеспечивает информацию о параметрах и использовании
операционной системы. Демон emaixos автоматически запускается подсистемой
управления событиями.
Подсистема служб групп кластера (Cluster Group Services Subsystem). Эта
подсистема RSCT обеспечивает надежную связь и протоколы, необходимые для
работы кластера. Клиенты – это распределенные демоны, такие, как диспетчер
кластера HACMP (HACMP Cluster Manager) и диспетчер логических томов с расширенным одновременным доступом (Enhanced Concurrent Logical Volume Manager).
Демон hagsd должен выполняться на всех узлах кластера.
Демон сервера глобализации кластера (Cluster Globalized Server daemon,
grpglsmd). Этот демон RSCT выполняется в качестве клиента служб групп; его функция состоит в том, чтобы обеспечить глобальное членство адаптера коммутатора
по всем узлам кластера. Демон grpglsmd должен выполняться на всех узлах кластера.
Подсистема мониторинга и управления ресурсами (Resource Monitoring
and Control Subsystem). Эта подсистема RSCT выполняется в качестве монитора
ресурсов для подсистемы управления событиями и обеспечивает информацию о параметрах и использовании операционной системы. Подсистема RMC должна
выполняться на всех узлах кластера. По умолчанию демон rmcd после установки
настроен на запуск из inittab. Скрипт rc.cluster обеспечивает работу подсистемы
RMC.
Запуск служб кластера
В этом разделе описываются опции запуска служб кластера на одном узле, на нескольких узлах или даже на всех узлах. Запуск служб кластера следует всегда выполнять с использованием SMIT. Экран SMIT представлен на рис 7.1.
(рис 7.1) Меню запуска служб кластераИз учетной записи пользователя "root" следует выполнить следующие действия
для запуска служб кластера на узле:
Введите быстрый путь smit cl_admin.
В SMIT выберите Manage HACMP Services (Управление службами HACMP)
> Start Cluster Services (Запустить службы кластера) и нажмите Enter.
Введите следующие значения полей:Start now, on system restart or both (Запустить сейчас, при перезапуске
системы или в обоих случаях). Определяет, когда следует запускать службы кластера и clinfoES: при вводе значений в этой панели нажатием Enter (now) при перезагрузке операционной системы ( on system restart ) или в обоих случаях ( both ).
Примечание. В рабочей среде обычно не рекомендуется задавать автоматический
запуск служб кластера при перезапуске системы.
Причина этого непосредственно связана с последствиями отказа системы. Если
происходит отказ системы, владеющей группой ресурсов и AIX настроен на
перезагрузку после отказа, может произойти перезапуск службы кластера посреди
перехвата ресурсов. В зависимости от конфигурации кластера это может вызвать
конфликт группы ресурсов, ошибки обработки группы ресурсов или даже возврат.
Все это может увеличить перерыв в обслуживании.
Однако при тестировании и обслуживании, а также на выделенных дежурных узлах
использование этой опции может быть удобным.
Start Cluster Services on these nodes (Запустить службы кластера на этих
узлах). Следует ввести имена одного или нескольких узлов, на которых требуется
запустить службы кластера. Узлы также можно выбрать из списка. При указании
нескольких узлов вручную следует разделять имена запятыми, как показано
на рис. 7.1.
BROADCAST message at startup? (Отправлять широковещательное сообщение при запуске?). Указывает, требуется ли отправлять широковещательное
сообщение на все узлы при запуске служб кластера.
Startup Cluster Lock Services (Запустить службу блокировки кластера).
Выберите true или false, чтобы определить, нужно ли запускать демон cllockd / cllockdES. Используется только в среде с одновременным доступом.Примечание. HACMP 5.2 и более поздние версии больше не поддерживают cllockd
и cllockdES (Cluster Lock Manager, диспетчер блокировки кластера).
Startup Cluster Information Daemon? (Запустить демон информации
кластера?). Указывает, требуется ли запустить демон clinfo. Если ваше приложение применяет Clinfo, если вы используете монитор clstat или если вы хотите запустить эмуляцию событий, установите в этом поле значение true. В противном
случае установите значение false.
Reacquire Resources after Forced Down? (Выполнить повторный перехват
ресурсов после принудительного отключения?). По умолчанию установлено
значение false, так как HACMP ожидает, что ресурсы будут в подключенном состоянии, так как они не были переведены в отключенное состояние. Если службы
были предварительно остановлены с использованием опции forced и ресурсы
были переведены в отключенное состояние после остановки служб и при этом
требуется, чтобы ресурсы автоматически переводились в подключенное состояние, надо выбрать true.
В HACMP V5.3 были добавлены две новые опции:
Ignore Verification Errors? (Игнорировать ошибки верификации?). Если
требуется запускать службы кластера при обнаружении в процессе верификации
ошибок на заданных узлах или в кластере в общем, следует установить значение true для заданных узлов. Если не требуется запускать службы кластера на заданных узлах при обнаружении ошибок на каком-либо узле в процессе верификации,
следует установить значение false.
Automatically correct errors found during cluster start? (Автоматическое
исправление ошибок, обнаруженных при запуске кластера?). Возможные
значения: Yes (Да), No (Нет) и Interactively (Интерактивное).
При значении Yes (Да) выполняется автоматическое исправление ошибок без
предупреждения. При значении No (Нет) исправление не осуществляется и кластер
не запускается при обнаружении ошибок. При значении Interactively (Интерактивное) выполняются запросы к пользователю при запуске с указанием обнаруженных
ошибок и выбором действия (исправлять или не исправлять).
Нажмите Enter. Система запускает службы кластера на заданном узле, активизируя определенную вами конфигурацию кластера. Продолжительность выполнения
команд и скриптов зависит от вашей конфигурации (другими словами, от количества
дисков, количества конфигурируемых интерфейсов, количества подключаемых файловых систем и количества запускаемых приложений).
Во время события node_up выполняется подхват группы ресурсов. Продолжительность выполнения каждого события node_up зависит от обработки ресурсов
во время события. События node_up для объединения узлов обрабатываются
последовательно.
При выполнении команды, когда службы кластера HACMP запущены на всех заданных узлах, SMIT выводит окно состояния команды. Обратите внимание на то,
что, когда панель SMIT указывает завершение запуска кластера, обработка событий
в большинстве случаев еще не завершена. Чтобы проверить, работают ли узлы, можно использовать clstat, WebSmit или даже просмотр ( tail ) файла /tmp/hacmp.out на
любом узле. Дополнительные сведения по этой теме см. в разделе "Утилиты проверки
состояния кластера".
Остановка служб кластера
Ниже приведен список действий, представляющих процедуру остановки служб кластера на одном узле, на нескольких узлах или на всех узлах кластера с использованием
утилиты C-SPOC на одном из узлов кластера. C-SPOC останавливает узлы последовательно, а не параллельно. Если какой-либо из заданных узлов неактивен, операция
завершения работы на этом узле прерывается. Как и при запуске служб, для остановки служб кластера следует всегда использовать SMIT. Экран SMIT остановки кластера
представлен на рис. 7.2.
Чтобы остановить службы кластера:
Введите быстрый путь smit cl_admin.
В SMIT выберите Manage HACMP Services (Управление службами HACMP) > Start Cluster Services (Запустить службы кластера) и нажмите Enter.
Введите следующие значения полей:Stop now, on system restart or both (Остановить сейчас, при перезапуске
системы или в обоих случаях).
(рис 7.2) Меню остановки служб кластераОпределяет, когда следует останавливать службы кластера: в данный момент
(now), при перезагрузке операционной системы (restart) или в обоих случаях
(both). При выборе значений restart или both в файле /etc/inittab происходит
удаление записи, запускающей службы кластера. Службы кластера больше не будут
автоматически запускаться после перезагрузки.
BROADCAST cluster shutdown? (Отправлять широковещательное сообщение при завершении работы кластера?). Указывает, требуется ли отправлять
широковещательное сообщение пользователям перед остановкой служб кластера.
Если задано значение true, выполняется широковещательная рассылка сообщения на все узлы кластера.
Shutdown mode (Режим завершения работы). Указывает тип остановки:graceful (постепенная). Завершение работы после запуска скрипта /usr/es/
sbin/cluster/events/node_down_complete на узле для освобождения ресурсов кластера. Другие узлы кластера не выполняют перехват ресурсов остановленного узла.
graceful with takeover (постепенная с передачей ресурсов на резервные узлы). Завершение работы после запуска скрипта /usr/es/sbin/cluster/
events/node_down_complete для освобождения ресурсов кластера. Другие
узлы выполняют перехват ресурсов остановленного узла.
forced (принудительная). Немедленное завершение работы. Узел сохраняет
управление всеми своими ресурсами. Эту опцию можно использовать для отключения узла при выполнении обслуживания или внесении изменений в
конфигурацию кластера, в частности при добавлении сетевой карты.
Однако после остановки служб кластера больше не обеспечивается высокая доступность приложений. При возникновении отказа восстановление выполняться
не будет.
Примечание. При использовании групп томов с расширенным одновременным
доступом в любом из режимов одновременного доступа для мониторинга пульса
через диски или в режиме быстрого перехвата дисков опция forced недоступна.
Наблюдения
В прежних версиях HACMP после остановки диспетчера кластера (Cluster Manager)
больше не обеспечивалась высокая доступность приложений. При возникновении
отказа восстановление приложений не обеспечивалось. В HACMP 5.3 диспетчер кластера (Cluster Manager) продолжает работать даже после остановки служб кластера.
Скрипты rc.cluster и clstop выдают диспетчеру кластера команды IPC™. Диспетчер
кластера выполняет скрипт обработки событий для запуска стека RSCT (rc.cluster).
Кроме того, в HACMP 5.3 node_down_complete вызывает процедуру остановки стека RSCT. Диспетчер кластера реагирует на команды stopsrc немедленной остановкой
без запуска события node_down, что необходимо перед установкой, обслуживанием
или заменой демона clstrmgr или зависимых библиотек (например, libclstr.a).
Важно! Никогда не используйте команду kill – 9 для остановки диспетчера кластера
или демонов RSCT. Это вызывает аварийное завершение. SRC запускает скрипт clexit.
rc и немедленно останавливает систему. Это, в свою очередь, инициирует
перемещение при сбое на других узлах.
Управление группами ресурсов и приложениями
В этом разделе обсуждаются следующие темы:
перевод группы ресурсов в отключенное состояние;
перевод группы ресурсов в подключенное состояние;
перемещение группы ресурсов;
приостановка/возобновление мониторинга приложения.
Понимание этих вопросов так же важно, как и понимание остановки и запуска
служб кластера, так как эти операции часто применяются в периоды обслуживания.
В следующих разделах мы начинаем с предположения, что службы кластера выполняются, группы ресурсов подключены, приложения работают и кластер стабилен.
Если кластер находится в нестабильном состоянии, то операции с группами ресурсов невозможны.
Все три обсуждаемые нами операции с группами ресурсов могут быть выполнены
с использованием команды clRGmove. Однако в наших примерах мы будем применять C-SPOC. Все эти операции имеют похожие экраны SMIT и списки для выбора.
Чтобы сократить объем главы, мы представим только по одному экрану SMIT в каждом из последующих разделов.
При выполнении любой из операций с группами ресурсов важно понимать действие параметра priority override location (расположение, отменяющее приоритет). Это настолько важно, что мы посвятили этому целый раздел – "Расположение, отменяющее приоритет".
Перевод группы ресурсов в отключенное состояние
через SMIT
Чтобы перевести группу ресурсов в отключенное состояние:
Введите быстрый путь smit cl_admin.
В SMIT выберите HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Bring a Resource
Group Offline (Перевести группу ресурсов в отключенное состояние). Выводится список, как показано на рис. 7.3. Он отображает только группы ресурсов,
находящиеся в подключенном состоянии или в состоянии ERROR (Ошибка) на всех
узлах в кластере.
Выберите требуемую группу ресурсов из списка и нажмите Enter. После выбора группы ресурсов появляется другой список, Select a Destination Node (Выбор
целевого узла). Список будет содержать только активные на данный момент узлы
кластера, участвующие в ранее выбранной группе ресурсов.
Выберите целевой узел из списка и нажмите Enter.
Появляется последнее меню SMIT с информацией, выбранной в предыдущих
списках. Кроме того, необходимо задать значение еще одного дополнительного поля, Persist across Cluster Reboot?. Вообще говоря, следует оставить в этом поле значение по умолчанию или false. Это поле непосредственно связано с параметром POL;
дополнительные сведения см. в разделе "Расположение, отменяющее приоритет".
Просмотрите ранее заданные записи, после чего нажмите Enter, чтобы начать
обработку отключаемой группы ресурсов.
После завершения обработки группа ресурсов будет отключена, тогда как службы
кластера на узле останутся активными.
Перевод группы ресурсов в подключенное состояние через SMIT
Чтобы перевести группу ресурсов в подключенное состояние:
Введите быстрый путь smit cl_admin.
В SMIT выберите HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Bring a Resource
Group Online (Перевести группу ресурсов в подключенное состояние). Выводится список. Он отображает только группы ресурсов, находящиеся в подключенном состоянии или в состоянии ERROR (Ошибка) на всех узлах в кластере.
Выберите требуемую группу ресурсов из списка и нажмите Enter. После выбора группы ресурсов появляется другой список, Select a Destination Node (Выбор
целевого узла). Список будет содержать только активные на данный момент узлы
кластера, участвующие в ранее выбранной группе ресурсов.
(рис 7.3) Список целевых узлов
Выберите целевой узел из списка, как показано на рис. 7.4. После выбора этого
узла он становится расположением, отменяющим приоритет (priority override location)
для данной группы ресурсов.
Появляется последнее меню SMIT с информацией, выбранной в предыдущих списках. Кроме того, необходимо задать значение еще одного дополнительного поля, Persist
across Cluster Reboot?. Вообще говоря, следует оставить в этом поле значение по умолчанию или false. Это поле непосредственно связано с параметром POL ; дополнительные
сведения см. в разделе "Расположение, отменяющее приоритет".
Просмотрите ранее заданные записи, после чего нажмите Enter, чтобы начать
обработку подключаемой группы ресурсов.
(рис 7.4) Список целевых узловПосле успешного завершения HACMP выводит сообщение о состоянии, расположении и типе расположения (постоянное или нет) группы ресурсов, которая была
успешно остановлена на заданном узле.
Перемещение группы ресурсов через SMIT
Перемещение группы ресурсов включает постепенную остановку ресурсов на текущем узле-владельце с последующим выполнением обычной процедуры запуска
группы ресурсов на целевом узле. При этом возникает короткий перерыв в обслуживании, во время которого доступ к приложению отсутствует.
В HACMP V5.3 была добавлена возможность перемещения группы ресурсов на другой сайт. Общая идея такая же, как и при перемещении между локальными узлами. В нашем случае мы будем выполнять перемещение на другой узел, а не на другой сайт.
Чтобы переместить группу ресурсов:
Введите быстрый путь smit cl_admin.
В SMIT выберите HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Move Resource
Groups to Another Node (Переместить группу ресурсов на другой узел). Выводится список. Он отображает только группы ресурсов, находящиеся в подключенном
состоянии или в состоянии ERROR (Ошибка) на всех узлах в кластере.
Выберите требуемую группу ресурсов из списка и нажмите Enter. После выбора группы ресурсов появляется другой список, Select a Destination Node (Выбор
целевого узла). Список будет содержать только активные на данный момент узлы
кластера, участвующие в ранее выбранной группе ресурсов.
Выберите целевой узел из списка. После выбора этого узла он становится расположением, отменяющим приоритет (priority override location) для данной группы
ресурсов.
Появляется последнее меню SMIT с информацией, выбранной в предыдущих
списках. Кроме того, необходимо задать значение еще одного дополнительного поля, Persist across Cluster Reboot?. Вообще говоря, следует оставить в этом поле
значение по умолчанию или false. Параметр POL устанавливается в любом случае;
вопрос в том, нужно ли, чтобы он оставался установленным после остановки/запуска
кластера. Дополнительные сведения см. в разделе "Расположение, отменяющее приоритет".
Просмотрите ранее заданные записи, после чего нажмите Enter, чтобы начать
выполнять перемещение группы ресурсов.
После успешного завершения HACMP выводит сообщение о состоянии, расположении и типе расположения (постоянное или нет) группы ресурсов, которая была
успешно перемещена на заданном узле, как показано на рис. 7.6.
(рис 7.6) Экран перемещения группы ресурсов(рис 7.5) Состояние группы ресурсов с выводом параметра POLВнимание! В показанном выше примере обратите внимание на то, что параметр POL
установлен.
При каждом перемещении группы ресурсов на другой узел мониторинг приложений приостанавливается на время остановки приложения. После перезапуска
приложения на целевом узле мониторинг приложения возобновляется. Дополнительные сведения см. в разделе "Приостановка/возобновление мониторинга приложения".
Расположение, отменяющее приоритет
В версиях до HACMP 5.1 можно было установить атрибут "sticky" для перемещенной группы ресурсов. В HACMP 5.1 атрибут "sticky" отсутствует. Вместо этого можно
задать атрибут расположения, отменяющего приоритет (priority override location).
Действие атрибута "sticky" в версиях до HACMP 5.1 эквивалентно действию атрибута
постоянного расположения, отменяющего приоритет. Атрибут расположения, отменяющего приоритет, указывает целевой узел, на котором имеет место миграция
группы ресурсов.
Параметр расположения, отменяющего приоритет (priority override location),
в действительности "отменяет" параметры конфигурации перемещения при сбое
и возврата после восстановления для группы ресурсов. Для этого параметра могут
быть установлены значения persistent (постоянный) или not-persistent (непостоянный). Этот параметр непосредственно связан с полем Persist Across Cluster
Reboot в экране SMIT. Два возможных значения: true и false. По умолчанию для параметра POL установлено значение false.
Ниже приведена информация по работе атрибута POL в группах ресурсов без одновременного доступа при использовании различных флагов clRGmove.
Примечание. Одновременно с помощью clRGmove можно перемещать только одну
группу ресурсов.
При каждом перемещении группы ресурсов без одновременного доступа, при котором используется флаг -n для явного указания целевого узла вместо флага -r
(restoring node priority, восстановление приоритета узла), целевой узел становится
расположением, отменяющим приоритет (Priority Override Location). Расположение, отменяющее приоритет, действует до явного использования параметра -r для
указания целевого узла вместо параметра -n при повторном перемещении группы
ресурсов вручную.
При отключении группы ресурсов группа ресурсов остается в отключенном состоянии до тех пор, пока она не будет вручную переведена в подключенное состояние. При ее переводе в подключенное состояние вручную с использованием
флага -n при указании узла этот узел становится расположением, отменяющим
приоритет.
При переводе группы ресурсов обратно в подключенное состояние с использованием флага -r применяется активный узел с наивысшим приоритетом и расположение, отменяющее приоритет, удаляется из группы ресурсов.
Для групп ресурсов с одновременным доступом имеет место следующее:
При переводе группы ресурсов с одновременным доступом в отключенное состояние на всех узлах расположение, отменяющее приоритет, переходит в состояние
OFFLINE для всех узлов в группе ресурсов. При переводе группы ресурсов с одновременным доступом в отключенное состояние только на одном узле состояние
OFFLINE для группы ресурсов на узле добавляется в список расположений, отменяющих приоритет.
При переводе группы ресурсов с одновременным доступом в подключенное состояние на всех узлах расположение, отменяющее приоритет, удаляется для всех
узлов в группы ресурсов.
При переводе группы ресурсов с одновременным доступом в подключенное состояние только на одном узле состояние OFFLINE для группы ресурсов на этом
узле удаляется из списка расположений, отменяющих приоритет.
Параметр POL групп ресурсов можно просмотреть с использованием команды
clRGinfo -p. Выходные данные этой команды соответствуют результатам выполнения операции с группой ресурсов через SMIT, представленным на рис. 7.6.
Приостановка/возобновление мониторинга приложения
В периоды обслуживания приложения часто возникает необходимость перевести
приложение в отключенное состояние, не останавливая службы кластера. Если включен мониторинг приложения, то перед остановкой приложения требуется приостановить мониторинг приложения. В противном случае, когда обнаружится, что приложение отключено, HACMP выполнит предписанные процедуры восстановления,
что нежелательно во время обслуживания. Определение мониторов приложения
описывается в разделе "Мониторинг приложения".
Чтобы приостановить мониторинг приложения:
Введите smit cl_admin.
В SMIT выберите HACMP System Management (Управление системой HACMP)
> Suspend/Resume Application Monitoring (Приостановка/возобновление мониторинга приложения) > Suspend Application Monitoring (Приостановить мониторинг приложения) и нажмите Enter.
Система запросит вас выбрать сервер приложения, для которого этот монитор
сконфигурирован. Если используется несколько мониторов приложения, все они
приостанавливаются до тех пор, пока вы не возобновите их работу или пока не возникнет событие кластера, вызывающее автоматическое возобновление их работы,
как описано выше.
Мониторинг будет приостановлен либо до его возобновления вручную, либо
до остановки/перезапуска группы ресурсов.
Чтобы возобновить мониторинг приложения:
Введите smit cl_admin.
В SMIT выберите HACMP System Management (Управление системой HACMP)
> Suspend/Resume Application Monitoring (Приостановка/возобновление мониторинга приложения) > Resume Application Monitoring (Возобновить мониторинг приложения) и нажмите Enter.
Выберите соответствующий сервер приложения, связанный с монитором приложения, работу которого требуется возобновить.
Мониторинг приложения остается активным либо до его приостановки вручную,
либо до перевода группы ресурсов в отключенное состояние.
Сценарии
В этом разделе мы рассмотрим следующие распространенные сценарии:
"горячая замена" сетевой карты PCI;
загрузка исправлений AIX и HACMP;
замена зеркального диска LVM;
обслуживание приложения.
"Горячая замена" сетевой карты PCI
Этот раздел описывает процесс "горячей замены" (hot-plug replacement) сетевой карты
PCI с использованием средства C-SPOC "PCI Hot Plug Replace a Network Interface Card".
Специальные аспекты
При выполнении "горячей замены" сетевой интерфейсной карты PCI необходимо учитывать следующее:
Если сетевой интерфейс, для которого вы выполняете "горячую замену", представляет единственный доступный keepalive-путь на узле, где он находится, вы
должны отключить HACMP на этом узле, чтобы не допустить разделение кластера
при замене интерфейса. Этого можно избежать при наличии рабочей сети, отличной от IP, между узлами кластера.
SMIT позволяет выполнить постепенное завершение работы (graceful shutdown)
на этом узле. При этом можно выполнить "горячую замену" сетевой интерфейсной карты вручную.
Поддерживается "горячая замена" сетевых интерфейсных карт Ethernet, TokenRing, FDDI и ATM. Этот процесс не поддерживается на коммуникационных устройствах, отличных от IP.
Следует вручную записать параметры IP-адреса для сетевого интерфейса, для которого выполняется замена, чтобы подготовиться к незапланированным отказам.
Не следует пытаться изменять какие-либо параметры конфигурации в ходе выполнения "горячей замены".
SMIT-интерфейс упрощает процесс "горячей замены" сетевой интерфейсной карты PCI. HACMP поддерживает одновременное выполнение "горячей замены" только
для одной сетевой карты PCI на узле.
Примечание. Если сетевой интерфейс был в рабочем состоянии до начала процесса
замены, то между началом и завершением "горячей замены" интерфейс, для которого
выполняется замена, находится в режиме обслуживания. На это время
приостанавливается мониторинг связи в сети, пока не будет завершен процесс замены.
Сценарий 1 (только для работающих NIC)
Необходимо следовать приведенной ниже процедуре при "горячей замене" таких
компонентов, как:
работающий сервисный сетевой интерфейс PCI в группе ресурсов с доступным
несервисным интерфейсом;
работающий сервисный сетевой интерфейс PCI не в группе ресурсов с доступным
несервисным интерфейсом;
доступный загрузочный сетевой интерфейс PCI с доступным несервисным интерфейсом.
Перейдите на узел, на котором требуется выполнить "горячую замену" сетевой
интерфейсной карты PCI.
Введите smit hacmp.
В SMIT выберите System Management (C-SPOC) > HACMP Communication
Interface Management (Управление коммуникационными интерфейсами
HACMP) > PCI Hot Plug Replace a Network Interface Card (Горячая замена сетевой интерфейсной карты PCI) и нажмите Enter.
К этой панели также можно перейти с использованием быстрого пути smitty cl_pcihp.
SMIT отображает список доступных сетевых интерфейсов PCI с возможностью
"горячей замены".
Выберите сетевой интерфейс, для которого требуется выполнить "горячую замену". Нажмите Enter. Сервисный адрес интерфейса PCI переносится на доступный
несервисный интерфейс.
SMIT предложит физически заменить сетевую интерфейсную карту. После замены карты система запросит подтверждения выполнения замены.
Если вы выберете Yes (Да), сервисный адрес будет перенесен обратно на сетевой
интерфейс, для которого была выполнена "горячая замена". В сетях с синонимами
сервисный адрес не будет перенесен обратно на первоначальный сетевой интерфейс,
а останется синонимом на том же сетевом интерфейсе. "Горячая замена" завершена.
Если вы выберете No (Нет), необходимо вручную установить первоначальные
значения параметров интерфейса:
выполните команду drslot, чтобы вывести PCI-слот из удаленного состояния
(removed state);
выполите mkdev на физическом интерфейсе.
используйте команду ifconfig вместо smit chinet, cfgmgr или mkdev, чтобы
не допустить конфигурирования повторяющихся IP-адресов или нежелательного
загрузочного адреса.
Сценарий 2 (только для работающих NIC)
При "горячей замене" работающего сервисного сетевого интерфейса PCI в группе
ресурсов без доступного несервисного интерфейса необходимо следовать приведенной ниже процедуре. Действия пп. 1–3 совпадают с предыдущим сценарием, так что
в этом сценарии мы начинаем с быстрого пути smitty cl_pcihp.
Выберите сетевой интерфейс, для которого требуется выполнить "горячую замену", и нажмите Enter.
SMIT предложит указать, следует ли перемещать группу ресурсов на другой узел
в процессе замены, чтобы обеспечить ее доступность.
Если вы укажете, что это нужно сделать, SMIT предложит переместить группу
ресурсов обратно на узел, на котором произошла "горячая замена" после завершения
процесса замены.
Если вы не переместите группу ресурсов на другой узел, он будет отключен в продолжение процесса замены.
SMIT предложит физически заменить сетевую интерфейсную карту. После замены карты система запросит подтверждения выполнения замены.
Если вы выберите Yes (Да), "горячая замена" будет завершена.
Если вы выберите No (Нет), необходимо вручную установить первоначальные
значения параметров интерфейса:выполните команду drslot, чтобы вывести PCI-слот из удаленного состояния
(removed state);
выполите mkdev на физическом интерфейсе;
используйте команду ifconfig вместо smit chinet, cfgmgr или mkdev, чтобы
не допустить конфигурирования повторяющихся IP-адресов или нежелательного
загрузочного адреса;
(если применимо) переместите группу ресурсов обратно на узел, с которого он
был перемещен на этапе 2.
Сценарий 3 (только для неработающих NIC)
Необходимо следовать приведенной ниже процедуре при "горячей замене" таких
компонентов, как:
неработающий сервисный сетевой интерфейс PCI в группе ресурсов с доступным
несервисным интерфейсом;
неработающий сервисный сетевой интерфейс PCI не в группе ресурсов с доступным несервисным интерфейсом;
неработающий загрузочный сетевой интерфейс PCI с доступным несервисным
интерфейсом.
Как и в предыдущем сценарии, мы снова начинаем с быстрого пути smitty. cl_pcihp.
Выберите сетевой интерфейс, для которого требуется выполнить "горячую
замену", и нажмите Enter. SMIT предложит физически заменить сетевую интерфейсную карту.
После выполнения физической замены SMIT запросит подтверждение выполнения замены.
Если вы выберете Yes (Да), "горячая замена" будет завершена.
Если вы выберете No (Нет), необходимо вручную установить первоначальные
значения параметров интерфейса:выполните команду drslot, чтобы вывести PCI-слот из удаленного состояния
(removed state);
выполите mkdev на физическом интерфейсе;
используйте команду ifconfig вместо smit chinet, cfgmgr или mkdev, чтобы
не допустить конфигурирования повторяющихся IP-адресов или нежелательного
загрузочного адреса.
"Горячая замена" сетевой интерфейсной карты ATM
Сетевые интерфейсные карты ATM поддерживают использование нескольких логических интерфейсов на одной сетевой интерфейсной карте. "Горячая замена" сетевого интерфейса ATM выполняется так же, как и для других сетевых интерфейсных
карт, за исключением следующего:
Все логические интерфейсы на заменяемой карте, не сконфигурированные для
замены и управляемые HACMP, утрачиваются в процессе замены. Они не будут
повторно сконфигурированы на новой установленной интерфейсной карте ATM.
Все остальные логические интерфейсы на заменяемой сетевой интерфейсной
карте ATM, сконфигурированные для замены и управляемые HACMP, восстанавливаются после завершения замены.
Так как на сетевой интерфейсной карте ATM можно сконфигурировать несколько
сервисных интерфейсов, а значит, и несколько групп ресурсов для одного сетевого интерфейса ATM, то при "горячей замене" сетевой интерфейсной карты ATM,
через SMIT выполняется процесс поочередного перемещения каждой группы ресурсов на интерфейсе ATM.
Исправления
Этот раздел описывает установку исправлений (APAR/PTFS) как в AIX, так и в HACMP.
Мы рекомендуем загружать исправления и осуществлять обслуживание ежеквартально. Однако опрос клиентов показывает, что чаще эти операции выполняются два раза в год в сезоны отпусков. В некоторых случаях приходится отклоняться от стандартной практики при возникновении серьезных проблем.
Некоторые исправления AIX можно загружать динамически без перезагрузки
системы. Обновления ядра и драйвера устройств часто требуют перезагрузки, так как
при их установке запускается bosboot. Чтобы определить, необходима ли перезагрузка системы, следует просмотреть файл .toc, создаваемый командой inutoc перед
установкой исправлений. Файл содержит информацию о наборах файлов (filesets),
подобную представленной в примере 7.1.
bos.64bit 5.3.0.0 i, b, usr, root
# base operating system 64 bit Runtime
bos.INed 5.3.0.0 i, b, usr, root
# INed Editor
В приведенном примере набор файлов bos.64bit требует перезагрузки, на что
указывает символ b в четвертом столбце. Символ N указывает на то, что перезагрузка
необязательна.
Применение исправлений HACMP подобно применению исправлений AIX. Наборы файлов, подлежащие обновлению, указывают, необходимо ли выполнять перезапуск кластера с использованием метода, указанного выше. Если есть неуверенность
в последствиях загрузки тех или иных исправлений, следует проконсультироваться
с группой поддержки.
При обновлении программного обеспечения AIX или HACMP рекомендуется выполнить следующие действия:
Создать снимок кластера и сохранить его вне кластера.
Выполнить резервное копирование операционной системы и данных до выполнения обновления. Подготовьте план возврата в случае возникновения проблем
при обновлении.
Всегда выполняйте первый запуск в тестовом кластере.
Если возможно, используйте обновление дисков.
Следуйте этим же общим правилам при применении исправлений приложения;
следуйте также указаниям для приложения.
Общая процедура применения исправлений AIX и HACMP имеет следующий вид:
Примените (apply), не фиксируя (commit), APAR на дежурном узле (standby node).
Выполняйте перемещение при сбое (постепенную остановку с переносом ресурсов, graceful shutdown with takeover) на дежурном компьютере (standby machine).
Примените (apply) APAR на основном узле (primary node).
Перед применением исправлений на дежурном узле (standby node) необходимо
остановить службы кластера. После применения исправлений при необходимости
нужно перезагрузить узел. Для реинтеграции узла в кластер в качестве дежурного узла следует перезапустить службы кластера.
Для того чтобы применить исправления на рабочих узлах, следует выполнить
постепенную остановку служб кластера с переносом ресурсов (gracefully with takeover).
После завершения переноса ресурсов службы кластера должны продолжить
процесс остановки. После полной остановки служб кластера следует применить исправления, при необходимости перезагрузить узел и перезапустить службы кластера.
В зависимости от политики перемещения при сбое для группы ресурсов, при реинтеграции узла в кластер, он может "подхватить" ресурсы. Если этого не произошло,
можно использовать C-SPOC для перемещения группы ресурсов обратно на первоначальный узел.
Хранение
В большинстве современных общих сред хранения применяется определенный уровень технологии RAID для защиты и дублирования данных. При использовании устройств RAID (1, 5 или 10) отказы отдельных дисков обычно не требуют выполнения
обслуживания AIX LVM. Все требуемые процедуры часто являются внешними по отношению к узлам кластера и не влияют на сам кластер. Однако если защита осуществляется с использованием зеркального отображения (mirroring) LVM, то необходимо
выполнять процедуры обслуживания LVM.
C-SPOC содержит средство поддержки при замене отказавшего диска с зеркальным отображением LVM. Это средство имеет название Cluster Disk Replacement
и выполняет все необходимые операции LVM по замене диска с зеркальным отображением LVM. Для использования этого средства необходимо следующее:
наличие привилегий пользователя "root";
должно осуществляться зеркальное отображение отказавшего диска (и желательно всей группы томов);
требуемый резервный диск должен быть доступен для всех узлов; ему уже должен
быть назначен PVID, который должен отображаться на всех узлах при вводе команды lspv.
При физической замене существующего диска следует удалить старый диск и установить на его место новый диск. Это, конечно же, предполагает, что привод допускает "горячую замену", что в настоящее время является стандартом.
Для замены диска с зеркальным отображением через C-SPOC проделайте
следующее:
Найдите отказавший диск. Запишите PVID для физического тома (диска).
Введите smitty cl_admin.
В SMIT выберите HACMP Physical Volume Management (Управление физическими томами HACMP) > Cluster Disk Replacement (Замена дисков кластера) и нажмите Enter. SMIT выводит список дисков, входящих в группы томов, содержащихся в группах
ресурсов кластера. Группа томов, в которой расположен отказавший диск, должна
содержать два диска или более. Список включает группу томов, hdisk, PVID диска и
опорный узел кластера (reference cluster node; обычно подразумевается узел кластера,
на котором активизирована группа томов).
Выберите диск, для которого требуется выполнить замену (исходный диск;
source disk) и нажмите Enter. SMIT выводит список доступных дисков, которым
назначен PVID и которые можно использовать для замены (для замены отказавшего
диска подходят только диски такого же или большего объема).
Выберите требуемый диск для замены (целевой диск; destination disk) и нажмите Enter. SMIT выводит выбранные вами параметры с двух предыдущих панелей.
Нажмите Enter для продолжения или Cancel для отмены процесса замены
дисков. Появится предупреждение, сообщающее о том, что продолжение операции
удалит всю информацию, хранящуюся на целевом диске.
Нажмите Enter для продолжения или Cancel для отмены. SMIT отображает панель
состояния команды и отображает каталог восстановления replacepv. Если при отказе
дисковой конфигурации требуется продолжить замену дисков, необходимо сконфигурировать целевой диск вручную. Учтите, что при отмене процедуры на данном этапе
целевой диск может быть сконфигурирован на нескольких узлах в кластере.
Утилита replacepv выполняет обновление группы томов, используемой в процессе замены дисков (только на опорном узле).
Примечание. В процессе выполнения команды SMIT сообщает имя каталога
восстановления, который следует использовать при отказе replacepv. Запишите эту
информацию, так как она необходима в процессе восстановления.
Выполняется конфигурирование целевого диска на всех узлах в группе ресурсов.
В случае неудачного импортирования обновленной группы томов узлом в группе
ресурсов можно использовать средство C-SPOC Import a Shared Volume Group.
C-SPOC не удаляет информацию об отказавшем дисковом устройстве с узлов кластера. Это нужно сделать вручную командой rmdev -dl <devicename>.
Приложения
Конечно же, каждое приложение имеет свои особенности, однако в большинстве
случаев для выполнения обслуживания приложения требуется перевести его в отключенный режим. Это можно сделать несколькими способами. Наиболее оптимальный
метод для каждой конкретной среды зависит от общей конфигурации кластера.
В многоуровневой среде (multi-tier environment), где сервер приложения зависит
от базы данных, и следует производить обслуживание базы данных обычно нужно
останавливать как приложение, так и базу данных. Чаще всего хотя бы база данных
находится в кластере. При использовании зависимостей группы ресурсов сервер
приложения можно легко реализовать в этом же кластере.
Кроме того, для того чтобы сократить общее время простоя приложения, часто обслуживание приложения сначала выполняется на нерабочих узлах. Традиционно под такими узлами подразумеваются дежурные узлы (standby nodes), однако очень редко
резервные узлы (backup/fallover node) используются только как дежурные. В таких
случаях следует учитывать текущую рабочую нагрузку или приложения, выполняющиеся на этом узле, чтобы свести к минимуму неблагоприятное воздействие процесса
обслуживания. Рекомендуется прежде выполнить тестирование в тестовом кластере.
В большинстве случаев останавливать службы кластера не требуется. Можно просто перевести группу ресурсов в отключенное состояние, как описано в разделе "Перевод группы ресурсов в отключенное состояние через SMIT". Если общая группа томов должна быть подключена во время обслуживания, можно просто приостановить
мониторинг приложения и выполнить скрипт остановки сервера приложения, чтобы
перевести приложение в отключенное состояние. Однако при этом сервисный IP-адрес останется подключенным, что может быть нежелательным.
В среде, где несколько групп ресурсов и/или несколько приложений выполняются
на одном узле, остановка служб кластера на локальном узле может быть невозможна.
Помните о возможных последствиях остановки служб кластера на узле, на котором
выполняется обслуживание приложения.
Если во время обслуживания возникнет фатальная ошибка, вызывающая отказ,
произойдет перемещение при сбое. Это может быть нежелательным, если прежде
не было выполнено обслуживание на резервных узлах и/или если не завершено обслуживание на локальном узле. Хотя такие ситуации возникают редко, вероятность
их возникновения все-таки существует, и это нужно учитывать.
В случае отказа другого рабочего узла в процессе обслуживания может произойти
успешное перемещение при сбое на локальном узле без неблагоприятных эффектов.
Если это нежелательно и существует несколько групп ресурсов, может потребоваться сначала переместить другие группы ресурсов на другой узел и затем остановить
службы кластера на локальном узле.
Если при использовании постоянных адресов выполняется остановка служба
кластера, защита от переключения локального адаптера (local adapter swap protection)
отключается. Хотя опять же такие ситуации редки, существует вероятность того,
что в случае отказа содержащей адрес сетевой карты при использовании постоянного адреса для выполнения обслуживания подключение будет разорвано.
После выполнения обслуживания приложения всегда следует выполнять повторное тестирование кластера. В зависимости от способа остановки приложения потребуется либо перезапустить службы кластера, обратно подключить группу ресурсов
через C-SPOC, либо вручную запустить скрипт запуска сервера приложения и при
необходимости продолжить мониторинг приложения.
Контроль и тестирование изменений
Осуществление контроля за изменениями является необходимым условием эффективного обеспечения высокой доступности в кластерных системах. Управление изменениями представляет собой набор всесторонне документированных процедур.
Оно включает несколько компонентов и является обязательным.
Управление изменениями среди прочего включает:
ограниченный административный доступ;
тщательно документированные и протестированные процедуры;
надлежащее планирование и утверждение изменений.
Тестовый кластер
Тестовый кластер является важным элементом в обеспечении надлежащего управления изменениями и в общей эффективности рабочего кластера. Тестовые кластеры
позволяют осуществлять тщательное тестирование административных процедур
и/или процедур обслуживания с целью обнаружения проблем до того, как они достигнут рабочего кластера. Тестовые кластеры – это не роскошь, а обязательный
элемент.
Многие существующие клиенты HACMP имеют тестовый кластер или по меньшей
мере начинают с тестового кластера. Однако со временем узлы тестового кластера
часто начинают применять в компании для других целей. Использование этих систем
требует запланированного окна обслуживания, подобно рабочему кластеру. В такой ситуации не следует считать, что эти узлы больше не представляют тестовый кластер.
В идеале тестовый кластер должен использовать те же версии и обновления AIX,
HACMP и приложений, которые использует и рабочий кластер. Предпочтительно
также использовать максимально похожее оборудование. В большинстве случаев
нецелесообразно полностью копировать рабочую среду, особенно при применении
нескольких рабочих кластеров. Существует несколько методов, которые можно применять для обеспечения максимальной эффективности тестового кластера при употреблении нескольких рабочих кластеров с различным программным обеспечением.
Например, часто используются логические разделы (LPAR) и несколько различных
образов rootvg с применением alt_disk_install. Логические разделы позволяют без
труда создать тестовый кластер с минимальным использованием физических ресурсов; например, тестовый кластер даже может разместиться на одном физическом компьютере. Использование нескольких загрузочных образов позволяет клиентам легко
сменить кластерную среду путем перезагрузки раздела с другого образа. Это также
позволяет осуществлять тестирование многих программных процедур:
обслуживание AIX;
применение исправлений HACMP;
обслуживание приложений.
Этот тип тестового кластера требует употребления как минимум одного диска
на образ на LPAR. Например, если тестовый кластер содержит два узла и три разных образа rootvg, требуется использовать по меньшей мере шесть жестких дисков. Тем
не менее это гораздо проще, чем применять шесть отдельных узлов в трех тестовых
кластерах.
Общую стоимость тестового кластера можно еще больше сократить с использованием расширенной виртуализации Power5. Расширенная виртуализация (advanced
virtualization) позволяет располагать несколько образов rootvg на одном физическом
диске. Она также позволяет логическим разделам использовать общую физическую
сеть и DASD-адаптеры через VLAN и VSCSI. Дополнительные сведения об этих возможностях см. в книге Advanced POWER Virtualization on IBM Eserver p5 Servers:
Introduction and Basic Configuration, SG24-7940
Тестовый кластер также позволяет выполнять тестирование процедур обслуживания оборудования. Эти процедуры в числе прочего включают:
обновление микрокода компьютера;
обновление микрокода адаптера;
замена адаптера;
замена диска.
Другие операции тестирования можно выполнить с использованием инструмента
тестирования кластера (Cluster Test Tool) и/или эмуляции событий.
Запуск и остановка кластера
Под запуском служб кластера подразумевается процесс запуска подсистем RSCT,
необходимых для работы HACMP, с последующим запуском демонов HACMP, обеспечивающих необходимое согласование между узлами кластера. Во время запуска
диспетчер кластера (Cluster Manager) выполняет событие node_up, после чего осуществляется подхват групп ресурсов. Под остановкой служб кластера понимается
остановка этих демонов на узле, которая в зависимости от типа остановки может
вызывать выполнение дополнительных скриптов HACMP.
Важно! Начиная с HACMP V5.3 процесс диспетчера кластера (clstrmgrES) всегда
выполняется. Он может находиться в одном из двух состояний, выводимых
следующей командой:lssrc -ls clstrmgrES
ST_INIT (событие запуска выполняется)
ST_NOTCONFIGURED (событие запуска не выполняется)
Изменения в состоянии кластера называются событиями кластера (cluster events).
Диспетчер кластера (Cluster Manager) на каждом узле осуществляет мониторинг локальной аппаратной и программной подсистем на такие события, как, например,
событие отказа приложения (application failure). При возникновении таких
событий диспетчер кластера выполняет один или несколько скриптов, например
скрипт перезапуска приложения (restart application). Диспетчеры кластера,
выполняющиеся на всех узлах, обмениваются сообщениями в целях согласования
необходимых действий в при возникновении событий.
Во время периодов обслуживания часто бывает необходимо остановить и запустить службы кластера. Однако перед этим необходимо понять, какие при этом возникают взаимодействия между узлами, а также каково воздействие на доступность системы. Кластер должен быть синхронизирован, и верификация не должна обнаруживать ошибок. Следующий раздел кратко описывает эти процессы, а также обработку,
выполняемую при запуске или остановке этих служб. Далее в этом разделе приведено
описание процедур, необходимых для запуска или остановки служб кластера на узле.
Службы кластера
Ниже перечислены основные демоны HACMP и RSCT.
Демон диспетчера кластера (Cluster Manager daemon, clstrmgrES). Основной демон HACMP. Он обеспечивает глобальное представление топологии кластера и ресурсов, а также запускает скрипты обработки событий в ответ на изменения
состояния узлов, интерфейсов или ресурсов (или по запросу пользователя).
Диспетчер кластера получает информацию о состоянии интерфейсов от служб
топологии (Topology Services). Диспетчер кластера обеспечивает актуальную информацию о расположении и состоянии всех групп ресурсов. Диспетчер кластера
является клиентом служб групп (Group Services) и использует последние для обеспечения надежной связи между демонами.
В версиях 5.1 и 5.2 этот демон запускается после служб кластера. В версии 5.3 демон clstrmgr запускается через процесс init и должен выполняться постоянно.
Кроме того, так как в версии 5.3 демон clstrmgr является постоянно выполняющимся процессом, нельзя использовать команду lssrc -s clstrmgrES для определения состояния кластера. Вместо этого следует использовать команду /usr/es/
sbin/cluster/utilities/clcheck_server grpsvcs.
Демон диспетчера блокировки кластера (Cluster Lock Manager daemon,
cllockd). Этот демон представляет информационные службы блокировки. Использование демона cllockd на узлах кластера необходимо только в том случае,
если эти узлы входят в конфигурацию с одновременным доступом. Обратите внимание на то, что диспетчер блокировки не поддерживается на 64-разрядном ядре
и полностью удален начиная с HACMP V5.2.
Демон коммуникаций кластера (Cluster Communication Daemon, clcomdES).
Этот демон, впервые появившийся в версии 5.1, обеспечивает безопасную
связь между узлами кластера для всех утилит кластера, в частности утилит верификации и синхронизации и управления системой (C-SPOC). Демон clcomd запускается автоматически при загрузке через процесс init. Начиная с версии 5.2,
clcomdES должен быть запущен, прежде чем можно будет запустить какие-либо
службы кластера.
Демон информации кластера (Cluster Information Program, clinfoES).
Этот демон предоставляет информацию о состоянии кластера узлам кластера и
клиентам, а также вызывает скрипт /usr/es/sbin/cluster/etc/clinfo.rc при возникновении событий кластера. Демон clinfo является необязательным на узлах
кластера и клиентах.
Демон Cluster SMUX Peer daemon (clsmuxpd). Этот демон предоставляет информацию о состоянии объектов кластера. Он публикует информацию о состоянии топологии и ресурсов кластера для MIB. Он является клиентом диспетчера
кластера (Cluster Manager). Этот демон работает совместно с демоном протокола
SNMP (snmpd). Демон clsmuxpd должен выполняться на всех узлах кластера.Примечание. Демон clsmuxpd нельзя запустить при отключенном демоне snmpd.
В HACMP 5.3 clsmuxpd больше не используется.
Подсистема служб топологии кластера (Cluster Topology Services Subsystem).
Подсистема служб топологии кластера RSCT обеспечивает мониторинг состояния сетевых интерфейсов и публикует состояние для клиентов, осуществляющих доступ к информации посредством членства в службах групп. Основным демоном является демон hatsd. Службы топологии также включают сетевые интерфейсные модули hats_nim*, отправляющие и получающие пакеты пульса. Подсистема служб топологии кластера должна выполняться на всех узлах кластера.
Подсистема управления событиями кластера (Cluster Event Management
Subsystem). Эта подсистема RSCT сопоставляет информацию о состоянии системных ресурсов с информацией о состоянии ресурсов, требуемых для клиентских программ (приложений, подсистем и прочих программ). Демон haemd выполняется на всех узлах домена.Примечание. Подсистема управления событиями кластера используется только
в Oracle 9i; в HACMP 5.2 и более поздних версиях он заменен подсистемой RMC
(Resource Monitoring and Control).
Монитор ресурсов подсистемы управления событиями операционной
системы AIX (Event Management AIX Operating System Resource Monitor).
Этот демон RSCT выступает в качестве монитора ресурсов для подсистемы управления событиями и обеспечивает информацию о параметрах и использовании
операционной системы. Демон emaixos автоматически запускается подсистемой
управления событиями.
Подсистема служб групп кластера (Cluster Group Services Subsystem). Эта
подсистема RSCT обеспечивает надежную связь и протоколы, необходимые для
работы кластера. Клиенты – это распределенные демоны, такие, как диспетчер
кластера HACMP (HACMP Cluster Manager) и диспетчер логических томов с расширенным одновременным доступом (Enhanced Concurrent Logical Volume Manager).
Демон hagsd должен выполняться на всех узлах кластера.
Демон сервера глобализации кластера (Cluster Globalized Server daemon,
grpglsmd). Этот демон RSCT выполняется в качестве клиента служб групп; его функция состоит в том, чтобы обеспечить глобальное членство адаптера коммутатора
по всем узлам кластера. Демон grpglsmd должен выполняться на всех узлах кластера.
Подсистема мониторинга и управления ресурсами (Resource Monitoring
and Control Subsystem). Эта подсистема RSCT выполняется в качестве монитора
ресурсов для подсистемы управления событиями и обеспечивает информацию о параметрах и использовании операционной системы. Подсистема RMC должна
выполняться на всех узлах кластера. По умолчанию демон rmcd после установки
настроен на запуск из inittab. Скрипт rc.cluster обеспечивает работу подсистемы
RMC.
Запуск служб кластера
В этом разделе описываются опции запуска служб кластера на одном узле, на нескольких узлах или даже на всех узлах. Запуск служб кластера следует всегда выполнять с использованием SMIT. Экран SMIT представлен на рис 7.1.
(рис 7.1) Меню запуска служб кластераИз учетной записи пользователя "root" следует выполнить следующие действия
для запуска служб кластера на узле:
Введите быстрый путь smit cl_admin.
В SMIT выберите Manage HACMP Services (Управление службами HACMP)
> Start Cluster Services (Запустить службы кластера) и нажмите Enter.
Введите следующие значения полей:Start now, on system restart or both (Запустить сейчас, при перезапуске
системы или в обоих случаях). Определяет, когда следует запускать службы кластера и clinfoES: при вводе значений в этой панели нажатием Enter (now) при перезагрузке операционной системы ( on system restart ) или в обоих случаях ( both ).
Примечание. В рабочей среде обычно не рекомендуется задавать автоматический
запуск служб кластера при перезапуске системы.
Причина этого непосредственно связана с последствиями отказа системы. Если
происходит отказ системы, владеющей группой ресурсов и AIX настроен на
перезагрузку после отказа, может произойти перезапуск службы кластера посреди
перехвата ресурсов. В зависимости от конфигурации кластера это может вызвать
конфликт группы ресурсов, ошибки обработки группы ресурсов или даже возврат.
Все это может увеличить перерыв в обслуживании.
Однако при тестировании и обслуживании, а также на выделенных дежурных узлах
использование этой опции может быть удобным.
Start Cluster Services on these nodes (Запустить службы кластера на этих
узлах). Следует ввести имена одного или нескольких узлов, на которых требуется
запустить службы кластера. Узлы также можно выбрать из списка. При указании
нескольких узлов вручную следует разделять имена запятыми, как показано
на рис. 7.1.
BROADCAST message at startup? (Отправлять широковещательное сообщение при запуске?). Указывает, требуется ли отправлять широковещательное
сообщение на все узлы при запуске служб кластера.
Startup Cluster Lock Services (Запустить службу блокировки кластера).
Выберите true или false, чтобы определить, нужно ли запускать демон cllockd / cllockdES. Используется только в среде с одновременным доступом.Примечание. HACMP 5.2 и более поздние версии больше не поддерживают cllockd
и cllockdES (Cluster Lock Manager, диспетчер блокировки кластера).
Startup Cluster Information Daemon? (Запустить демон информации
кластера?). Указывает, требуется ли запустить демон clinfo. Если ваше приложение применяет Clinfo, если вы используете монитор clstat или если вы хотите запустить эмуляцию событий, установите в этом поле значение true. В противном
случае установите значение false.
Reacquire Resources after Forced Down? (Выполнить повторный перехват
ресурсов после принудительного отключения?). По умолчанию установлено
значение false, так как HACMP ожидает, что ресурсы будут в подключенном состоянии, так как они не были переведены в отключенное состояние. Если службы
были предварительно остановлены с использованием опции forced и ресурсы
были переведены в отключенное состояние после остановки служб и при этом
требуется, чтобы ресурсы автоматически переводились в подключенное состояние, надо выбрать true.
В HACMP V5.3 были добавлены две новые опции:
Ignore Verification Errors? (Игнорировать ошибки верификации?). Если
требуется запускать службы кластера при обнаружении в процессе верификации
ошибок на заданных узлах или в кластере в общем, следует установить значение true для заданных узлов. Если не требуется запускать службы кластера на заданных узлах при обнаружении ошибок на каком-либо узле в процессе верификации,
следует установить значение false.
Automatically correct errors found during cluster start? (Автоматическое
исправление ошибок, обнаруженных при запуске кластера?). Возможные
значения: Yes (Да), No (Нет) и Interactively (Интерактивное).
При значении Yes (Да) выполняется автоматическое исправление ошибок без
предупреждения. При значении No (Нет) исправление не осуществляется и кластер
не запускается при обнаружении ошибок. При значении Interactively (Интерактивное) выполняются запросы к пользователю при запуске с указанием обнаруженных
ошибок и выбором действия (исправлять или не исправлять).
Нажмите Enter. Система запускает службы кластера на заданном узле, активизируя определенную вами конфигурацию кластера. Продолжительность выполнения
команд и скриптов зависит от вашей конфигурации (другими словами, от количества
дисков, количества конфигурируемых интерфейсов, количества подключаемых файловых систем и количества запускаемых приложений).
Во время события node_up выполняется подхват группы ресурсов. Продолжительность выполнения каждого события node_up зависит от обработки ресурсов
во время события. События node_up для объединения узлов обрабатываются
последовательно.
При выполнении команды, когда службы кластера HACMP запущены на всех заданных узлах, SMIT выводит окно состояния команды. Обратите внимание на то,
что, когда панель SMIT указывает завершение запуска кластера, обработка событий
в большинстве случаев еще не завершена. Чтобы проверить, работают ли узлы, можно использовать clstat, WebSmit или даже просмотр ( tail ) файла /tmp/hacmp.out на
любом узле. Дополнительные сведения по этой теме см. в разделе "Утилиты проверки
состояния кластера".
Остановка служб кластера
Ниже приведен список действий, представляющих процедуру остановки служб кластера на одном узле, на нескольких узлах или на всех узлах кластера с использованием
утилиты C-SPOC на одном из узлов кластера. C-SPOC останавливает узлы последовательно, а не параллельно. Если какой-либо из заданных узлов неактивен, операция
завершения работы на этом узле прерывается. Как и при запуске служб, для остановки служб кластера следует всегда использовать SMIT. Экран SMIT остановки кластера
представлен на рис. 7.2.
Чтобы остановить службы кластера:
Введите быстрый путь smit cl_admin.
В SMIT выберите Manage HACMP Services (Управление службами HACMP) > Start Cluster Services (Запустить службы кластера) и нажмите Enter.
Введите следующие значения полей:Stop now, on system restart or both (Остановить сейчас, при перезапуске
системы или в обоих случаях).(рис 7.2) Меню остановки служб кластераОпределяет, когда следует останавливать службы кластера: в данный момент
(now), при перезагрузке операционной системы (restart) или в обоих случаях
(both). При выборе значений restart или both в файле /etc/inittab происходит
удаление записи, запускающей службы кластера. Службы кластера больше не будут
автоматически запускаться после перезагрузки.
BROADCAST cluster shutdown? (Отправлять широковещательное сообщение при завершении работы кластера?). Указывает, требуется ли отправлять
широковещательное сообщение пользователям перед остановкой служб кластера.
Если задано значение true, выполняется широковещательная рассылка сообщения на все узлы кластера.
Shutdown mode (Режим завершения работы). Указывает тип остановки:graceful (постепенная). Завершение работы после запуска скрипта /usr/es/
sbin/cluster/events/node_down_complete на узле для освобождения ресурсов кластера. Другие узлы кластера не выполняют перехват ресурсов остановленного узла.
graceful with takeover (постепенная с передачей ресурсов на резервные узлы). Завершение работы после запуска скрипта /usr/es/sbin/cluster/
events/node_down_complete для освобождения ресурсов кластера. Другие
узлы выполняют перехват ресурсов остановленного узла.
forced (принудительная). Немедленное завершение работы. Узел сохраняет
управление всеми своими ресурсами. Эту опцию можно использовать для отключения узла при выполнении обслуживания или внесении изменений в
конфигурацию кластера, в частности при добавлении сетевой карты.
Однако после остановки служб кластера больше не обеспечивается высокая доступность приложений. При возникновении отказа восстановление выполняться
не будет.
Примечание. При использовании групп томов с расширенным одновременным
доступом в любом из режимов одновременного доступа для мониторинга пульса
через диски или в режиме быстрого перехвата дисков опция forced недоступна.
Наблюдения
В прежних версиях HACMP после остановки диспетчера кластера (Cluster Manager)
больше не обеспечивалась высокая доступность приложений. При возникновении
отказа восстановление приложений не обеспечивалось. В HACMP 5.3 диспетчер кластера (Cluster Manager) продолжает работать даже после остановки служб кластера.
Скрипты rc.cluster и clstop выдают диспетчеру кластера команды IPC™. Диспетчер
кластера выполняет скрипт обработки событий для запуска стека RSCT (rc.cluster).
Кроме того, в HACMP 5.3 node_down_complete вызывает процедуру остановки стека RSCT. Диспетчер кластера реагирует на команды stopsrc немедленной остановкой
без запуска события node_down, что необходимо перед установкой, обслуживанием
или заменой демона clstrmgr или зависимых библиотек (например, libclstr.a).
Важно! Никогда не используйте команду kill – 9 для остановки диспетчера кластера
или демонов RSCT. Это вызывает аварийное завершение. SRC запускает скрипт clexit.
rc и немедленно останавливает систему. Это, в свою очередь, инициирует
перемещение при сбое на других узлах.
Управление группами ресурсов и приложениями
В этом разделе обсуждаются следующие темы:
перевод группы ресурсов в отключенное состояние;
перевод группы ресурсов в подключенное состояние;
перемещение группы ресурсов;
приостановка/возобновление мониторинга приложения.
Понимание этих вопросов так же важно, как и понимание остановки и запуска
служб кластера, так как эти операции часто применяются в периоды обслуживания.
В следующих разделах мы начинаем с предположения, что службы кластера выполняются, группы ресурсов подключены, приложения работают и кластер стабилен.
Если кластер находится в нестабильном состоянии, то операции с группами ресурсов невозможны.
Все три обсуждаемые нами операции с группами ресурсов могут быть выполнены
с использованием команды clRGmove. Однако в наших примерах мы будем применять C-SPOC. Все эти операции имеют похожие экраны SMIT и списки для выбора.
Чтобы сократить объем главы, мы представим только по одному экрану SMIT в каждом из последующих разделов.
При выполнении любой из операций с группами ресурсов важно понимать действие параметра priority override location (расположение, отменяющее приоритет). Это настолько важно, что мы посвятили этому целый раздел – "Расположение, отменяющее приоритет".
Перевод группы ресурсов в отключенное состояние
через SMIT
Чтобы перевести группу ресурсов в отключенное состояние:
Введите быстрый путь smit cl_admin.
В SMIT выберите HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Bring a Resource
Group Offline (Перевести группу ресурсов в отключенное состояние). Выводится список, как показано на рис. 7.3. Он отображает только группы ресурсов,
находящиеся в подключенном состоянии или в состоянии ERROR (Ошибка) на всех
узлах в кластере.
Выберите требуемую группу ресурсов из списка и нажмите Enter. После выбора группы ресурсов появляется другой список, Select a Destination Node (Выбор
целевого узла). Список будет содержать только активные на данный момент узлы
кластера, участвующие в ранее выбранной группе ресурсов.
Выберите целевой узел из списка и нажмите Enter.
Появляется последнее меню SMIT с информацией, выбранной в предыдущих
списках. Кроме того, необходимо задать значение еще одного дополнительного поля, Persist across Cluster Reboot?. Вообще говоря, следует оставить в этом поле значение по умолчанию или false. Это поле непосредственно связано с параметром POL;
дополнительные сведения см. в разделе "Расположение, отменяющее приоритет".
Просмотрите ранее заданные записи, после чего нажмите Enter, чтобы начать
обработку отключаемой группы ресурсов.
После завершения обработки группа ресурсов будет отключена, тогда как службы
кластера на узле останутся активными.
Перевод группы ресурсов в подключенное состояние через SMIT
Чтобы перевести группу ресурсов в подключенное состояние:
Введите быстрый путь smit cl_admin.
В SMIT выберите HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Bring a Resource
Group Online (Перевести группу ресурсов в подключенное состояние). Выводится список. Он отображает только группы ресурсов, находящиеся в подключенном состоянии или в состоянии ERROR (Ошибка) на всех узлах в кластере.
Выберите требуемую группу ресурсов из списка и нажмите Enter. После выбора группы ресурсов появляется другой список, Select a Destination Node (Выбор
целевого узла). Список будет содержать только активные на данный момент узлы
кластера, участвующие в ранее выбранной группе ресурсов.(рис 7.3) Список целевых узлов
Выберите целевой узел из списка, как показано на рис. 7.4. После выбора этого
узла он становится расположением, отменяющим приоритет (priority override location)
для данной группы ресурсов.
Появляется последнее меню SMIT с информацией, выбранной в предыдущих списках. Кроме того, необходимо задать значение еще одного дополнительного поля, Persist
across Cluster Reboot?. Вообще говоря, следует оставить в этом поле значение по умолчанию или false. Это поле непосредственно связано с параметром POL ; дополнительные
сведения см. в разделе "Расположение, отменяющее приоритет".
Просмотрите ранее заданные записи, после чего нажмите Enter, чтобы начать
обработку подключаемой группы ресурсов.
(рис 7.4) Список целевых узловПосле успешного завершения HACMP выводит сообщение о состоянии, расположении и типе расположения (постоянное или нет) группы ресурсов, которая была
успешно остановлена на заданном узле.
Перемещение группы ресурсов через SMIT
Перемещение группы ресурсов включает постепенную остановку ресурсов на текущем узле-владельце с последующим выполнением обычной процедуры запуска
группы ресурсов на целевом узле. При этом возникает короткий перерыв в обслуживании, во время которого доступ к приложению отсутствует.
В HACMP V5.3 была добавлена возможность перемещения группы ресурсов на другой сайт. Общая идея такая же, как и при перемещении между локальными узлами. В нашем случае мы будем выполнять перемещение на другой узел, а не на другой сайт.
Чтобы переместить группу ресурсов:
Введите быстрый путь smit cl_admin.
В SMIT выберите HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Move Resource
Groups to Another Node (Переместить группу ресурсов на другой узел). Выводится список. Он отображает только группы ресурсов, находящиеся в подключенном
состоянии или в состоянии ERROR (Ошибка) на всех узлах в кластере.
Выберите требуемую группу ресурсов из списка и нажмите Enter. После выбора группы ресурсов появляется другой список, Select a Destination Node (Выбор
целевого узла). Список будет содержать только активные на данный момент узлы
кластера, участвующие в ранее выбранной группе ресурсов.
Выберите целевой узел из списка. После выбора этого узла он становится расположением, отменяющим приоритет (priority override location) для данной группы
ресурсов.
Появляется последнее меню SMIT с информацией, выбранной в предыдущих
списках. Кроме того, необходимо задать значение еще одного дополнительного поля, Persist across Cluster Reboot?. Вообще говоря, следует оставить в этом поле
значение по умолчанию или false. Параметр POL устанавливается в любом случае;
вопрос в том, нужно ли, чтобы он оставался установленным после остановки/запуска
кластера. Дополнительные сведения см. в разделе "Расположение, отменяющее приоритет".
Просмотрите ранее заданные записи, после чего нажмите Enter, чтобы начать
выполнять перемещение группы ресурсов.
После успешного завершения HACMP выводит сообщение о состоянии, расположении и типе расположения (постоянное или нет) группы ресурсов, которая была
успешно перемещена на заданном узле, как показано на рис. 7.6.
(рис 7.6) Экран перемещения группы ресурсов(рис 7.5) Состояние группы ресурсов с выводом параметра POLВнимание! В показанном выше примере обратите внимание на то, что параметр POL
установлен.
При каждом перемещении группы ресурсов на другой узел мониторинг приложений приостанавливается на время остановки приложения. После перезапуска
приложения на целевом узле мониторинг приложения возобновляется. Дополнительные сведения см. в разделе "Приостановка/возобновление мониторинга приложения".
Расположение, отменяющее приоритет
В версиях до HACMP 5.1 можно было установить атрибут "sticky" для перемещенной группы ресурсов. В HACMP 5.1 атрибут "sticky" отсутствует. Вместо этого можно
задать атрибут расположения, отменяющего приоритет (priority override location).
Действие атрибута "sticky" в версиях до HACMP 5.1 эквивалентно действию атрибута
постоянного расположения, отменяющего приоритет. Атрибут расположения, отменяющего приоритет, указывает целевой узел, на котором имеет место миграция
группы ресурсов.
Параметр расположения, отменяющего приоритет (priority override location),
в действительности "отменяет" параметры конфигурации перемещения при сбое
и возврата после восстановления для группы ресурсов. Для этого параметра могут
быть установлены значения persistent (постоянный) или not-persistent (непостоянный). Этот параметр непосредственно связан с полем Persist Across Cluster
Reboot в экране SMIT. Два возможных значения: true и false. По умолчанию для параметра POL установлено значение false.
Ниже приведена информация по работе атрибута POL в группах ресурсов без одновременного доступа при использовании различных флагов clRGmove.
Примечание. Одновременно с помощью clRGmove можно перемещать только одну
группу ресурсов.
При каждом перемещении группы ресурсов без одновременного доступа, при котором используется флаг -n для явного указания целевого узла вместо флага -r
(restoring node priority, восстановление приоритета узла), целевой узел становится
расположением, отменяющим приоритет (Priority Override Location). Расположение, отменяющее приоритет, действует до явного использования параметра -r для
указания целевого узла вместо параметра -n при повторном перемещении группы
ресурсов вручную.
При отключении группы ресурсов группа ресурсов остается в отключенном состоянии до тех пор, пока она не будет вручную переведена в подключенное состояние. При ее переводе в подключенное состояние вручную с использованием
флага -n при указании узла этот узел становится расположением, отменяющим
приоритет.
При переводе группы ресурсов обратно в подключенное состояние с использованием флага -r применяется активный узел с наивысшим приоритетом и расположение, отменяющее приоритет, удаляется из группы ресурсов.
Для групп ресурсов с одновременным доступом имеет место следующее:
При переводе группы ресурсов с одновременным доступом в отключенное состояние на всех узлах расположение, отменяющее приоритет, переходит в состояние
OFFLINE для всех узлов в группе ресурсов. При переводе группы ресурсов с одновременным доступом в отключенное состояние только на одном узле состояние
OFFLINE для группы ресурсов на узле добавляется в список расположений, отменяющих приоритет.
При переводе группы ресурсов с одновременным доступом в подключенное состояние на всех узлах расположение, отменяющее приоритет, удаляется для всех
узлов в группы ресурсов.
При переводе группы ресурсов с одновременным доступом в подключенное состояние только на одном узле состояние OFFLINE для группы ресурсов на этом
узле удаляется из списка расположений, отменяющих приоритет.
Параметр POL групп ресурсов можно просмотреть с использованием команды
clRGinfo -p. Выходные данные этой команды соответствуют результатам выполнения операции с группой ресурсов через SMIT, представленным на рис. 7.6.
Приостановка/возобновление мониторинга приложения
В периоды обслуживания приложения часто возникает необходимость перевести
приложение в отключенное состояние, не останавливая службы кластера. Если включен мониторинг приложения, то перед остановкой приложения требуется приостановить мониторинг приложения. В противном случае, когда обнаружится, что приложение отключено, HACMP выполнит предписанные процедуры восстановления,
что нежелательно во время обслуживания. Определение мониторов приложения
описывается в разделе "Мониторинг приложения".
Чтобы приостановить мониторинг приложения:
Введите smit cl_admin.
В SMIT выберите HACMP System Management (Управление системой HACMP)
> Suspend/Resume Application Monitoring (Приостановка/возобновление мониторинга приложения) > Suspend Application Monitoring (Приостановить мониторинг приложения) и нажмите Enter.
Система запросит вас выбрать сервер приложения, для которого этот монитор
сконфигурирован. Если используется несколько мониторов приложения, все они
приостанавливаются до тех пор, пока вы не возобновите их работу или пока не возникнет событие кластера, вызывающее автоматическое возобновление их работы,
как описано выше.
Мониторинг будет приостановлен либо до его возобновления вручную, либо
до остановки/перезапуска группы ресурсов.
Чтобы возобновить мониторинг приложения:
Введите smit cl_admin.
В SMIT выберите HACMP System Management (Управление системой HACMP)
> Suspend/Resume Application Monitoring (Приостановка/возобновление мониторинга приложения) > Resume Application Monitoring (Возобновить мониторинг приложения) и нажмите Enter.
Выберите соответствующий сервер приложения, связанный с монитором приложения, работу которого требуется возобновить.
Мониторинг приложения остается активным либо до его приостановки вручную,
либо до перевода группы ресурсов в отключенное состояние.
Сценарии
В этом разделе мы рассмотрим следующие распространенные сценарии:
"горячая замена" сетевой карты PCI;
загрузка исправлений AIX и HACMP;
замена зеркального диска LVM;
обслуживание приложения.
"Горячая замена" сетевой карты PCI
Этот раздел описывает процесс "горячей замены" (hot-plug replacement) сетевой карты
PCI с использованием средства C-SPOC "PCI Hot Plug Replace a Network Interface Card".
Специальные аспекты
При выполнении "горячей замены" сетевой интерфейсной карты PCI необходимо учитывать следующее:
Если сетевой интерфейс, для которого вы выполняете "горячую замену", представляет единственный доступный keepalive-путь на узле, где он находится, вы
должны отключить HACMP на этом узле, чтобы не допустить разделение кластера
при замене интерфейса. Этого можно избежать при наличии рабочей сети, отличной от IP, между узлами кластера.
SMIT позволяет выполнить постепенное завершение работы (graceful shutdown)
на этом узле. При этом можно выполнить "горячую замену" сетевой интерфейсной карты вручную.
Поддерживается "горячая замена" сетевых интерфейсных карт Ethernet, TokenRing, FDDI и ATM. Этот процесс не поддерживается на коммуникационных устройствах, отличных от IP.
Следует вручную записать параметры IP-адреса для сетевого интерфейса, для которого выполняется замена, чтобы подготовиться к незапланированным отказам.
Не следует пытаться изменять какие-либо параметры конфигурации в ходе выполнения "горячей замены".
SMIT-интерфейс упрощает процесс "горячей замены" сетевой интерфейсной карты PCI. HACMP поддерживает одновременное выполнение "горячей замены" только
для одной сетевой карты PCI на узле.
Примечание. Если сетевой интерфейс был в рабочем состоянии до начала процесса
замены, то между началом и завершением "горячей замены" интерфейс, для которого
выполняется замена, находится в режиме обслуживания. На это время
приостанавливается мониторинг связи в сети, пока не будет завершен процесс замены.
Сценарий 1 (только для работающих NIC)
Необходимо следовать приведенной ниже процедуре при "горячей замене" таких
компонентов, как:
работающий сервисный сетевой интерфейс PCI в группе ресурсов с доступным
несервисным интерфейсом;
работающий сервисный сетевой интерфейс PCI не в группе ресурсов с доступным
несервисным интерфейсом;
доступный загрузочный сетевой интерфейс PCI с доступным несервисным интерфейсом.
Перейдите на узел, на котором требуется выполнить "горячую замену" сетевой
интерфейсной карты PCI.
Введите smit hacmp.
В SMIT выберите System Management (C-SPOC) > HACMP Communication
Interface Management (Управление коммуникационными интерфейсами
HACMP) > PCI Hot Plug Replace a Network Interface Card (Горячая замена сетевой интерфейсной карты PCI) и нажмите Enter.
К этой панели также можно перейти с использованием быстрого пути smitty cl_pcihp.
SMIT отображает список доступных сетевых интерфейсов PCI с возможностью
"горячей замены".
Выберите сетевой интерфейс, для которого требуется выполнить "горячую замену". Нажмите Enter. Сервисный адрес интерфейса PCI переносится на доступный
несервисный интерфейс.
SMIT предложит физически заменить сетевую интерфейсную карту. После замены карты система запросит подтверждения выполнения замены.
Если вы выберете Yes (Да), сервисный адрес будет перенесен обратно на сетевой
интерфейс, для которого была выполнена "горячая замена". В сетях с синонимами
сервисный адрес не будет перенесен обратно на первоначальный сетевой интерфейс,
а останется синонимом на том же сетевом интерфейсе. "Горячая замена" завершена.
Если вы выберете No (Нет), необходимо вручную установить первоначальные
значения параметров интерфейса:
выполните команду drslot, чтобы вывести PCI-слот из удаленного состояния
(removed state);
выполите mkdev на физическом интерфейсе.
используйте команду ifconfig вместо smit chinet, cfgmgr или mkdev, чтобы
не допустить конфигурирования повторяющихся IP-адресов или нежелательного
загрузочного адреса.
Сценарий 2 (только для работающих NIC)
При "горячей замене" работающего сервисного сетевого интерфейса PCI в группе
ресурсов без доступного несервисного интерфейса необходимо следовать приведенной ниже процедуре. Действия пп. 1–3 совпадают с предыдущим сценарием, так что
в этом сценарии мы начинаем с быстрого пути smitty cl_pcihp.
Выберите сетевой интерфейс, для которого требуется выполнить "горячую замену", и нажмите Enter.
SMIT предложит указать, следует ли перемещать группу ресурсов на другой узел
в процессе замены, чтобы обеспечить ее доступность.
Если вы укажете, что это нужно сделать, SMIT предложит переместить группу
ресурсов обратно на узел, на котором произошла "горячая замена" после завершения
процесса замены.
Если вы не переместите группу ресурсов на другой узел, он будет отключен в продолжение процесса замены.
SMIT предложит физически заменить сетевую интерфейсную карту. После замены карты система запросит подтверждения выполнения замены.
Если вы выберите Yes (Да), "горячая замена" будет завершена.
Если вы выберите No (Нет), необходимо вручную установить первоначальные
значения параметров интерфейса:выполните команду drslot, чтобы вывести PCI-слот из удаленного состояния
(removed state);
выполите mkdev на физическом интерфейсе;
используйте команду ifconfig вместо smit chinet, cfgmgr или mkdev, чтобы
не допустить конфигурирования повторяющихся IP-адресов или нежелательного
загрузочного адреса;
(если применимо) переместите группу ресурсов обратно на узел, с которого он
был перемещен на этапе 2.
Сценарий 3 (только для неработающих NIC)
Необходимо следовать приведенной ниже процедуре при "горячей замене" таких
компонентов, как:
неработающий сервисный сетевой интерфейс PCI в группе ресурсов с доступным
несервисным интерфейсом;
неработающий сервисный сетевой интерфейс PCI не в группе ресурсов с доступным несервисным интерфейсом;
неработающий загрузочный сетевой интерфейс PCI с доступным несервисным
интерфейсом.
Как и в предыдущем сценарии, мы снова начинаем с быстрого пути smitty. cl_pcihp.
Выберите сетевой интерфейс, для которого требуется выполнить "горячую
замену", и нажмите Enter. SMIT предложит физически заменить сетевую интерфейсную карту.
После выполнения физической замены SMIT запросит подтверждение выполнения замены.
Если вы выберете Yes (Да), "горячая замена" будет завершена.
Если вы выберете No (Нет), необходимо вручную установить первоначальные
значения параметров интерфейса:выполните команду drslot, чтобы вывести PCI-слот из удаленного состояния
(removed state);
выполите mkdev на физическом интерфейсе;
используйте команду ifconfig вместо smit chinet, cfgmgr или mkdev, чтобы
не допустить конфигурирования повторяющихся IP-адресов или нежелательного
загрузочного адреса.
"Горячая замена" сетевой интерфейсной карты ATM
Сетевые интерфейсные карты ATM поддерживают использование нескольких логических интерфейсов на одной сетевой интерфейсной карте. "Горячая замена" сетевого интерфейса ATM выполняется так же, как и для других сетевых интерфейсных
карт, за исключением следующего:
Все логические интерфейсы на заменяемой карте, не сконфигурированные для
замены и управляемые HACMP, утрачиваются в процессе замены. Они не будут
повторно сконфигурированы на новой установленной интерфейсной карте ATM.
Все остальные логические интерфейсы на заменяемой сетевой интерфейсной
карте ATM, сконфигурированные для замены и управляемые HACMP, восстанавливаются после завершения замены.
Так как на сетевой интерфейсной карте ATM можно сконфигурировать несколько
сервисных интерфейсов, а значит, и несколько групп ресурсов для одного сетевого интерфейса ATM, то при "горячей замене" сетевой интерфейсной карты ATM,
через SMIT выполняется процесс поочередного перемещения каждой группы ресурсов на интерфейсе ATM.
Исправления
Этот раздел описывает установку исправлений (APAR/PTFS) как в AIX, так и в HACMP.
Мы рекомендуем загружать исправления и осуществлять обслуживание ежеквартально. Однако опрос клиентов показывает, что чаще эти операции выполняются два раза в год в сезоны отпусков. В некоторых случаях приходится отклоняться от стандартной практики при возникновении серьезных проблем.
Некоторые исправления AIX можно загружать динамически без перезагрузки
системы. Обновления ядра и драйвера устройств часто требуют перезагрузки, так как
при их установке запускается bosboot. Чтобы определить, необходима ли перезагрузка системы, следует просмотреть файл .toc, создаваемый командой inutoc перед
установкой исправлений. Файл содержит информацию о наборах файлов (filesets),
подобную представленной в примере 7.1.
bos.64bit 5.3.0.0 i, b, usr, root
# base operating system 64 bit Runtime
bos.INed 5.3.0.0 i, b, usr, root
# INed Editor
В приведенном примере набор файлов bos.64bit требует перезагрузки, на что
указывает символ b в четвертом столбце. Символ N указывает на то, что перезагрузка
необязательна.
Применение исправлений HACMP подобно применению исправлений AIX. Наборы файлов, подлежащие обновлению, указывают, необходимо ли выполнять перезапуск кластера с использованием метода, указанного выше. Если есть неуверенность
в последствиях загрузки тех или иных исправлений, следует проконсультироваться
с группой поддержки.
При обновлении программного обеспечения AIX или HACMP рекомендуется выполнить следующие действия:
Создать снимок кластера и сохранить его вне кластера.
Выполнить резервное копирование операционной системы и данных до выполнения обновления. Подготовьте план возврата в случае возникновения проблем
при обновлении.
Всегда выполняйте первый запуск в тестовом кластере.
Если возможно, используйте обновление дисков.
Следуйте этим же общим правилам при применении исправлений приложения;
следуйте также указаниям для приложения.
Общая процедура применения исправлений AIX и HACMP имеет следующий вид:
Примените (apply), не фиксируя (commit), APAR на дежурном узле (standby node).
Выполняйте перемещение при сбое (постепенную остановку с переносом ресурсов, graceful shutdown with takeover) на дежурном компьютере (standby machine).
Примените (apply) APAR на основном узле (primary node).
Перед применением исправлений на дежурном узле (standby node) необходимо
остановить службы кластера. После применения исправлений при необходимости
нужно перезагрузить узел. Для реинтеграции узла в кластер в качестве дежурного узла следует перезапустить службы кластера.
Для того чтобы применить исправления на рабочих узлах, следует выполнить
постепенную остановку служб кластера с переносом ресурсов (gracefully with takeover).
После завершения переноса ресурсов службы кластера должны продолжить
процесс остановки. После полной остановки служб кластера следует применить исправления, при необходимости перезагрузить узел и перезапустить службы кластера.
В зависимости от политики перемещения при сбое для группы ресурсов, при реинтеграции узла в кластер, он может "подхватить" ресурсы. Если этого не произошло,
можно использовать C-SPOC для перемещения группы ресурсов обратно на первоначальный узел.
Хранение
В большинстве современных общих сред хранения применяется определенный уровень технологии RAID для защиты и дублирования данных. При использовании устройств RAID (1, 5 или 10) отказы отдельных дисков обычно не требуют выполнения
обслуживания AIX LVM. Все требуемые процедуры часто являются внешними по отношению к узлам кластера и не влияют на сам кластер. Однако если защита осуществляется с использованием зеркального отображения (mirroring) LVM, то необходимо
выполнять процедуры обслуживания LVM.
C-SPOC содержит средство поддержки при замене отказавшего диска с зеркальным отображением LVM. Это средство имеет название Cluster Disk Replacement
и выполняет все необходимые операции LVM по замене диска с зеркальным отображением LVM. Для использования этого средства необходимо следующее:
наличие привилегий пользователя "root";
должно осуществляться зеркальное отображение отказавшего диска (и желательно всей группы томов);
требуемый резервный диск должен быть доступен для всех узлов; ему уже должен
быть назначен PVID, который должен отображаться на всех узлах при вводе команды lspv.
При физической замене существующего диска следует удалить старый диск и установить на его место новый диск. Это, конечно же, предполагает, что привод допускает "горячую замену", что в настоящее время является стандартом.
Для замены диска с зеркальным отображением через C-SPOC проделайте
следующее:
Найдите отказавший диск. Запишите PVID для физического тома (диска).
Введите smitty cl_admin.
В SMIT выберите HACMP Physical Volume Management (Управление физическими томами HACMP) > Cluster Disk Replacement (Замена дисков кластера) и нажмите Enter. SMIT выводит список дисков, входящих в группы томов, содержащихся в группах
ресурсов кластера. Группа томов, в которой расположен отказавший диск, должна
содержать два диска или более. Список включает группу томов, hdisk, PVID диска и
опорный узел кластера (reference cluster node; обычно подразумевается узел кластера,
на котором активизирована группа томов).
Выберите диск, для которого требуется выполнить замену (исходный диск;
source disk) и нажмите Enter. SMIT выводит список доступных дисков, которым
назначен PVID и которые можно использовать для замены (для замены отказавшего
диска подходят только диски такого же или большего объема).
Выберите требуемый диск для замены (целевой диск; destination disk) и нажмите Enter. SMIT выводит выбранные вами параметры с двух предыдущих панелей.
Нажмите Enter для продолжения или Cancel для отмены процесса замены
дисков. Появится предупреждение, сообщающее о том, что продолжение операции
удалит всю информацию, хранящуюся на целевом диске.
Нажмите Enter для продолжения или Cancel для отмены. SMIT отображает панель
состояния команды и отображает каталог восстановления replacepv. Если при отказе
дисковой конфигурации требуется продолжить замену дисков, необходимо сконфигурировать целевой диск вручную. Учтите, что при отмене процедуры на данном этапе
целевой диск может быть сконфигурирован на нескольких узлах в кластере.
Утилита replacepv выполняет обновление группы томов, используемой в процессе замены дисков (только на опорном узле).
Примечание. В процессе выполнения команды SMIT сообщает имя каталога
восстановления, который следует использовать при отказе replacepv. Запишите эту
информацию, так как она необходима в процессе восстановления.
Выполняется конфигурирование целевого диска на всех узлах в группе ресурсов.
В случае неудачного импортирования обновленной группы томов узлом в группе
ресурсов можно использовать средство C-SPOC Import a Shared Volume Group.
C-SPOC не удаляет информацию об отказавшем дисковом устройстве с узлов кластера. Это нужно сделать вручную командой rmdev -dl <devicename>.
Приложения
Конечно же, каждое приложение имеет свои особенности, однако в большинстве
случаев для выполнения обслуживания приложения требуется перевести его в отключенный режим. Это можно сделать несколькими способами. Наиболее оптимальный
метод для каждой конкретной среды зависит от общей конфигурации кластера.
В многоуровневой среде (multi-tier environment), где сервер приложения зависит
от базы данных, и следует производить обслуживание базы данных обычно нужно
останавливать как приложение, так и базу данных. Чаще всего хотя бы база данных
находится в кластере. При использовании зависимостей группы ресурсов сервер
приложения можно легко реализовать в этом же кластере.
Кроме того, для того чтобы сократить общее время простоя приложения, часто обслуживание приложения сначала выполняется на нерабочих узлах. Традиционно под такими узлами подразумеваются дежурные узлы (standby nodes), однако очень редко
резервные узлы (backup/fallover node) используются только как дежурные. В таких
случаях следует учитывать текущую рабочую нагрузку или приложения, выполняющиеся на этом узле, чтобы свести к минимуму неблагоприятное воздействие процесса
обслуживания. Рекомендуется прежде выполнить тестирование в тестовом кластере.
В большинстве случаев останавливать службы кластера не требуется. Можно просто перевести группу ресурсов в отключенное состояние, как описано в разделе "Перевод группы ресурсов в отключенное состояние через SMIT". Если общая группа томов должна быть подключена во время обслуживания, можно просто приостановить
мониторинг приложения и выполнить скрипт остановки сервера приложения, чтобы
перевести приложение в отключенное состояние. Однако при этом сервисный IP-адрес останется подключенным, что может быть нежелательным.
В среде, где несколько групп ресурсов и/или несколько приложений выполняются
на одном узле, остановка служб кластера на локальном узле может быть невозможна.
Помните о возможных последствиях остановки служб кластера на узле, на котором
выполняется обслуживание приложения.
Если во время обслуживания возникнет фатальная ошибка, вызывающая отказ,
произойдет перемещение при сбое. Это может быть нежелательным, если прежде
не было выполнено обслуживание на резервных узлах и/или если не завершено обслуживание на локальном узле. Хотя такие ситуации возникают редко, вероятность
их возникновения все-таки существует, и это нужно учитывать.
В случае отказа другого рабочего узла в процессе обслуживания может произойти
успешное перемещение при сбое на локальном узле без неблагоприятных эффектов.
Если это нежелательно и существует несколько групп ресурсов, может потребоваться сначала переместить другие группы ресурсов на другой узел и затем остановить
службы кластера на локальном узле.
Если при использовании постоянных адресов выполняется остановка служба
кластера, защита от переключения локального адаптера (local adapter swap protection)
отключается. Хотя опять же такие ситуации редки, существует вероятность того,
что в случае отказа содержащей адрес сетевой карты при использовании постоянного адреса для выполнения обслуживания подключение будет разорвано.
После выполнения обслуживания приложения всегда следует выполнять повторное тестирование кластера. В зависимости от способа остановки приложения потребуется либо перезапустить службы кластера, обратно подключить группу ресурсов
через C-SPOC, либо вручную запустить скрипт запуска сервера приложения и при
необходимости продолжить мониторинг приложения.
