Компания IBM
Опубликован: 01.02.2008 | Доступ: свободный | Студентов: 613 / 22 | Оценка: 4.60 / 4.40 | Длительность: 43:55:00
Специальности: Разработчик аппаратуры
Лекция 8:

Управление кластером

Файлы журналов

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

Использование утилиты C-SPOC позволяет выполнять следующие действия над файлами журналов:

  • View/Save/Delete HACMP Event Summaries (Просмотр/сохранение/удаление обзоров событий HACMP). Эта опция позволяет выводить содержимое, сохранять или удалять обзоры событий кластера.
  • View Detailed HACMP Log Files (Просмотр подробных файлов журналов HACMP). Эта опция позволяет вывести журнал скриптов HACMP (/tmp/hacmp.out), системный журнал HACMP (/usr/es/adm/cluster.log), системный журнал C-SPOC (/tmp/cspoc.log).
  • Change/Show HACMP Log File Parameters (Изменение/вывод параметров файла журнала HACMP). Эта опция позволяет задать уровень отладки (высокий/низкий) и вариант форматирования (default, standard, html-low, html-high) для заданного узла.
  • Change/Show Cluster Manager Log File Parameters (Изменение/вывод параметров файла журнала диспетчера кластера). Эта опция позволяет задать уровень отладки диспетчера кластера (standard/high)
  • Change/Show a Cluster Log Directory (Изменение/вывод каталога журнала кластера). Это меню позволяет определить новый каталог для заданного файла журнала, как описано ниже.
  • Collect Cluster log files for Problem Reporting (Сбор файлов журналов кластера для отчетов о проблемах). Эта функция используется для сбора мгновенных данных (snap data) о кластере (командой clsnap), необходимых для дополнительного определения и анализа проблем. Здесь можно выбрать опцию отладки, включить файлы журналов RSCT и выбрать узлы, включенные в этот набор данных. По умолчанию набор мгновенных данных хранится в каталоге /tmp/ibmsupt/hacmp/ (для команды clsnap) и, например, в каталоге /tmp/phoenix.snapOut (для узла phoenix).

Список всех журналов HACMP с описанием их назначения:

  • strmgr.debug: генерируется демоном clstrmgrES, каталог по умолчанию – [/tmp].
  • cluster.log: генерируется скриптами и демонами кластера, каталог по умолчанию – [/usr/es/adm].
  • cluster.mmddyyyy: файлы истории кластера, генерируются ежедневно, каталог по умолчанию – [/usr/es/sbin/cluster/history].
  • cl_sm.log: генерируется библиотекой кластера Shared Memory, каталог по умолчанию – [/tmp].
  • cspoc.log: генерируется командами C-SPOC, каталог по умолчанию – [/tmp].
  • dms_loads.out: генерируется при работе deadman’s switch, каталог по умолчанию – [/tmp].
  • emuhacmp.out: генерируется скриптами эмулятора событий, каталог по умолчанию – [/tmp].
  • hacmp.out: генерируется при выполнении скриптов и утилит обработки событий, каталог по умолчанию – [/tmp].
  • clavan.log: генерируется утилитой доступности приложения (Application Availability), каталог по умолчанию – [/var/adm].
  • clverify.log: генерируется утилитой верификации кластера (Cluster Verification), каталог по умолчанию – [/var/hacmp/clverify].
  • clcomd.log: генерируется демоном clcomd, каталог по умолчанию – [/var/hacmp/ clcomd].
  • clcomddiag.log: генерируется демоном clcomd, отладочная информация, каталог по умолчанию – [/var/hacmp/clcomd].
  • clconfigassist.log: генерируется инструментом Two-Node Cluster Configuration Assistant, каталог по умолчанию – [/var/hacmp/log].
  • clutils.log: генерируется утилитами кластера, каталог по умолчанию – [/var/hacmp/log].
  • cl_testtool.log: генерируется инструментом тестирования кластера (Cluster Test Tool), каталог по умолчанию – [/var/hacmp/log].

Необходимо обеспечить достаточно пространства для всех файлов журналов в файловых системах. Необходимое количество пространства в файловой системе /var зависит от количества узлов в кластере. Определить общее значение для каждого узла можно, исходя из следующих соображений:

  • 2 Мб должно быть свободно для записи файлов clverify.log[0–9];
  • 4 Мб на узел для записи данных верификации с узлов;
  • 20 Мб для записи информации журнала clcomd;
  • 1 Мб на узел для записи данных кеша ODM.

Например, для кластера из четырех узлов потребуется 2 + 4x4 + 20 + 4x1 = 42 Мб свободного пространства в файловой системе /var.

Определить необходимое количество пространства в каталоге /tmp очень сложно, так как в этом каталоге находятся некоторые файлы с отладочной информацией, а также некоторые нечередующиеся файлы журналов. Размер этих журналов зависит от операций, конфигурации и состояния кластера. Из практического опыта мы рекомендуем выделить около 50 Мб свободного места в каталоге /tmp.

Через меню SMIT можно изменить стандартный каталог для определенного файла журнала; для этого нужно запустить smit hacmp > System Management (C-SPOC) > HACMP Log Viewing and Management (Просмотр и управление журналами HACMP) > Change/Show a Cluster Log Directory (Изменение/вывод каталога журнала кластера), после чего выбрать определенный файл журнала (быстрый путь SMIT: smit clusterlog_redir.select). Затем выполняется изменение стандартного каталога журналов для всех узлов в кластере. После изменения параметров журнала необходимо выполнить синхронизацию кластера.

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

Кроме того, кластер генерирует некоторые файлы отладки. (Они находятся в каталоге /tmp. Содержимое этих файлов зависит от установленного уровня отладки):

  • clinfo.debug – записываются выходные данные, генерируемые при работе скриптов обработки событий;
  • clsmuxtrmgr.debug – файл журнала функции smux peer;
  • clstlrmgr.debug – содержит отформатированные сообщения с отметками времени, генерируемые clstrmgrES.

Уведомление об ошибках

Средство уведомления об ошибках (Error Notification) AIX 5L можно использовать для добавления дополнительного уровня высокой доступности в среде HACMP. Можно добавить уведомления об отказах ресурсов, для которых HACMP не выполняет восстановление по умолчанию.

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

Мониторинг приложения

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

Начиная с HACMP 5.2 можно конфигурировать несколько мониторов приложений и связывать их с одним или несколькими серверами приложений. Каждому монитору через SMIT можно назначить уникальное имя.

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

  • система мониторинга процессов приложения обнаруживает прекращение работы одного или нескольких процессов приложения с использованием RSCT Resource Monitoring and Control (RMC);
  • настраиваемый метод мониторинга приложения регулярно проверяет работу приложения через интервал, заданный пользователем.

Конфигурирование мониторинга приложения через меню SMIT выполняется путем запуска smit hacmp -> Extended Resource Configuration1 (Расширенное конфигурирование ресурсов) -> Extended Resource Configuration (Расширенное конфигурирование ресурсов) -> HACMP Extended Resources Configuration (Расширенное конфигурирование ресурсов HACMP) -> Configure HACMP Applications (Конфигурирование приложений HACMP) -> Configure HACMP Application Monitoring (Конфигурирование мониторинга приложений HACMP), после чего выбирается либо меню Configure Process Application Monitors (Конфигурирование мониторов процессов приложений), либо меню Configure Custom Application Monitors (Конфигурирование настраиваемых мониторов приложений). Кроме того, можно использовать быстрый путь smit cm_cfg_appmon.

Мониторинг процессов приложений

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

Когда HACMP обнаруживает прекращение работы какого-либо процесса приложения, он пытается перезапустить приложение на текущем узле заданное количество раз.

Для добавления нового монитора приложения следует запустить smit hacmp > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > HACMP Extended Resources Configuration (Расширенное конфигурирование ресурсов HACMP) > Configure HACMP Applications (Конфигурирование приложений HACMP) > Configure HACMP Application Monitoring (Конфигурирование мониторинга приложений HACMP) > Configure Process Application Monitors (Конфигурирование мониторов процессов приложений) > Add a Process Application Monitor (Добавить монитор процессов приложения) либо использовать быстрый путь smit cm_cfg_process_appmon. На рис. 8.29 показан экран SMIT с полями конфигурирования монитора приложения нашего тестового процесса.

Экран добавления монитора процесса приложения

Рис. 8.29. Экран добавления монитора процесса приложения

Мы определили монитор приложения APP1_monitor для монитора приложения APP1. Мы использовали стандартный режим мониторинга: Long-running monitoring (Долгосрочный мониторинг). В этом режиме монитор приложения периодически проверяет, работает ли сервер приложения. Проверка начинается по истечении заданного стабилизационного интервала (Stabilization interval). Альтернативные варианты – Startup Monitoring (Мониторинг при запуске) и both (оба режима). При выборе опции Startup Monitoring (Мониторинг при запуске) монитор приложения проверяет успешность запуска сервера приложения в заданном стабилизационном интервале. Мы установили для параметра Stabilization interval (Стабилизационный интервал) значение 120 с.

Мы определили процессы app1d и app1testd, владельцем которых является root, и для которых будет осуществляться мониторинг с использованием данного монитора приложений.

Мы можем определить два разных варианта работы монитора в том случае, если отказ не был устранен после всех попыток, в соответствии со значением поля Restart Interval (Интервал перезапуска). Эти варианты устанавливаются через поле Action on Application Failure (Действие при отказе приложения). Возможные значения поля: notify и fallover. Если выбрано значение notify, после выполнения метода уведомления никаких действий не предпринимается. Если выбрано значение fallover, группа ресурсов, содержащая приложение, для которого осуществляется мониторинг, перемещается на другой узел в кластере.

Параметр Notification method (Метод уведомления) определяет скрипт, выполняющийся при каждом перезапуске приложения, полном отказе или перемещении на следующий узел в кластере. Настоятельно рекомендуется сконфигурировать этот метод.

Cleanup Method (Метод очистки) и Restart Method (Метод перезапуска) определяют скрипты остановки и запуска приложения после обнаружения отказа. Заданные по умолчанию скрипты запуска и остановки используются как определенные в конфигурации сервера приложения.

Настраиваемый мониторинг приложения

Настраиваемый монитор приложения представляет другой вариант мониторинга доступности приложения с использованием настраиваемых скриптов, которые могут имитировать доступ клиента к службам, предоставляемым приложением. Он использует встроенную функцию мониторинга, обеспечиваемую RSCT, и не требует настраиваемого скрипта1Здесь авторы ошиблись. Для использования этого метода необходимы скрипты (или программы), разработанные специально для мониторинга состояния конкретного приложения в конкретной среде . В зависимости от кода завершения этого скрипта, монитор определяет, доступно ли приложение. Если скрипт завершается с кодом 0, это означает, что приложение доступно. Любой другой код завершения означает, что приложение недоступно.

Можно добавить новый настраиваемый монитор приложения с использованием SMIT путем запуска smit hacmp > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > HACMP Extended Resources Configuration (Расширенное конфигурирование ресурсов HACMP) > Configure HACMP Applications (Конфигурирование приложений HACMP) > Configure HACMP Application Monitoring (Конфигурирование мониторинга приложений HACMP) > Configure Custom Application Monitors (Конфигурирование настраиваемых мониторов приложений) > Add a Custom Application Monitor (Добавление настраиваемого монитора приложения) или используя быстрый путь smit cm_cfg_custom_appmon. Экран SMIT и его опции добавления метода в конфигурацию кластера подобны экрану добавления монитора процесса приложения, как показано на рис. 8.29.

В меню конфигурирования настраиваемых мониторов приложения отличаются следующие поля:

  • Monitor Method (Метод мониторинга). Указывает полный путь к скрипту, определяющему метод проверки состояния приложения. Если приложением является база данных, этот скрипт может подключиться к базе данных и выполнить SQL-запрос select для заданной таблицы базы данных. Корректный результат SQLзапроса select означает, что база данных работает нормально.
  • Monitor Interval (Интервал мониторинга). Определяет интервал (в секундах) периодического выполнения метода монитора.
  • Hung Monitor Signal (Сигнал при зависании монитора). Определяет сигнал, отправляемый для остановки метода монитора, если ответ от него не был получен за время, заданное параметром Monitor Interval (Интервал мониторинга). По умолчанию отправляется сигнал SIGKILL(9).

Приостановка/возобновление мониторинга приложения

После конфигурирования монитора приложения необходимо его активизировать. Это можно сделать через меню Resume Application Monitoring (Возобновление мониторинга приложения) путем запуска smit cl_admin > HACMP Resource Group and Application Management (Управление группами ресурсов и приложениями HACMP) > Suspend/Resume Application Monitoring (Приостановка/возобновление мониторинга приложения) > Resume Application Monitoring (Возобновить мониторинг приложения), после чего следует выбрать сервер приложения, связанный с монитором, который требуется активизировать. Пример 8.18 содержит выходные данные после успешного возобновления монитора приложения на сервере приложения APP1 в нашем тестовом кластере.

Jul 6 2005 18:00:17 cl_RMupdate: Completed request 
 to resume monitor(s) for applic ation APP1.
Jul 6 2005 18:00:17 cl_RMupdate: The following 
monitor(s) are in use for applicati on APP1:
test
Пример 8.18.

Можно приостановить либо возобновить мониторинг приложения в любое время. Это действие не влияет на доступность сервера приложения, однако влияет на статистические результаты, выводимые инструментом анализа доступности приложения (application availability analysis tool). Дополнительные сведения об этом инструменте см. в разделе "Измерение доступности приложения".