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

Планирование

Заполнение таблиц планирования хранения

Следующие таблицы содержат необходимую информацию об общих группах томов. Совместно они дают достаточно полное представление об общей дисковой конфигурации.

Описание общих групп томов и физических дисков приведено в табл. 3.9:

Таблица 3.9. Общие диски
ТАБЛИЦА КЛАСТЕРА HACMP – ЧАСТЬ 7 из 11 ОБЩИЕ ДИСКИ ДАТА: июль 2005
node01 node02
VGNAME VPATH HDISK HDISK VPATH VGNAME
app1vg vpath0 hdisk0, hdisk1, hdisk2, hdisk3 hdisk0, hdisk1, hdisk2, hdisk3 vpath0
vpath1 hdisk4, hdisk5, hdisk6, hdisk7 hdisk4, hdisk5, hdisk6, hdisk7 vpath1 app2vg
КОММЕНТАРИИ. Все диски видимы с обоих узлов; app1vg обычно располагается на узле node01, app2vg обычно располагается на узле node02.

Запишите сведения об общих группах томов, как показано в табл. 3.10.

Таблица 3.10. Общие группы томов
ТАБЛИЦА КЛАСТЕРА HACMP – ЧАСТЬ 8 из 11 ОБЩИЕ ГРУППЫ ТОМОВ (БЕЗ ОДНОВРЕМЕННОГО ДОСТУПА) ДАТА: июль 2005
ГРУППА РЕСУРСОВ ГРУППА ТОМОВ 1 ГРУППА ТОМОВ 1
C10RG1 app1vg Неприменимо
Основной номер = 90
журнал = app1vglog
Логический том 1 = app1lv1
Файловая система 1 = /app1 (20 Гб)
C10RG2 app2vg Неприменимо
Основной номер = 91
журнал = app2vglog
Логический том 1 = app2lv1
Файловая система 1 = /app2 (20 Гб)
КОММЕНТАРИИ Создается общая группа томов на первом узле, после чего выполняется импорт на второй узел;
#importvg -y app1vg -V 90 vpath0 (может быть необходимо сделать pv доступным с использованием chdev -l vpath0 -a pv=yes);
#chvg -an app1vg (отключает автоматическую активизацию для группы томов);
#mount /app1 (для того, чтобы убедиться в возможности подключения файловой системы);
#umount /app1;
#varyoffvg app1vg (оставляет группу томов в отключенном режиме, оставляя HACMP управление группой)

Планирование приложений

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

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

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

Примечание. Основное условие обеспечения высокой доступности приложения состоит в том, чтобы сначала проверить корректность выполнения приложения в автономном режиме на каждом узле, на котором оно может находиться.

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

Необходимо проанализировать и учитывать следующие аспекты:

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

При планировании защиты приложения в кластере HACMP необходимо учитывать следующее:

  • Приложение должно быть совместимо с используемой версией AIX.
  • Приложение должно быть совместимо с системой общего хранилища, так как она будет содержать данные приложения.
  • Убедитесь в том, что приложения успешно работают в среде с одним узлом. Выполнять отладку приложения в кластере гораздо сложнее, чем на одном сервере.
  • Следует распределить приложение и его данные таким образом, чтобы на общих внешних дисках находились только данные. Такое распределение не только предотвращает нарушение лицензий программного обеспечения, но и упрощает восстановление после сбоя.
  • Если вы планируете включить в группы ресурсов кластера с зависимостями "родительский объект/дочерний объект" многоуровневые приложения, например базы данных или сервер приложений, HACMP предоставляет простые в использовании меню SMIT, чтобы задать такое отношение.
  • Необходимо написать надежные скрипты как для запуска, так и для остановки приложения на узлах кластера. Скрипт запуска должен быть способен восстановить приложение после аварийного завершения. Убедитесь, что скрипты корректно выполняются в среде с одним узлом, прежде чем использовать их в HACMP.
  • Проверьте требования к лицензированию. Некоторые производители требуют использования отдельной лицензии для каждого процессора, на котором выполняется приложение; это означает, что вы должны лицензировать приложение, включив информацию о процессоре в приложение при его установке. В результате, несмотря на правильную обработку отказов узла программным обеспечением HACMP, оно может быть неспособно перезапустить приложение на резервном узле из-за недостаточного количества лицензий приложения, доступных в кластере. Во избежание этой проблемы убедитесь в наличии лицензии для каждого компонента системы в кластере, на котором приложение потенциально может выполняться.
  • Если требуется обеспечить одновременный доступ, проверьте, использует ли приложение собственный механизм блокировки.

Серверы приложений

В HACMP под сервером приложения понимается просто набор скриптов, используемых для запуска и остановки приложения.

Сконфигурируйте свой сервер приложения, задав имя для использования в HACMP и выполнив привязку к скриптам запуска и остановки.

После создания сервера приложения следует связать его с группой ресурсов. Затем HACMP применяет эту информацию для управления приложением.

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

HACMP может осуществлять мониторинг приложения с использованием одного из двух методов:

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

Начиная с HACMP 5.2 можно применять несколько мониторов для одного приложения.

При определении собственного настраиваемого метода мониторинга необходимо помнить следующее:

  • Можно сконфигурировать несколько мониторов приложения с уникальными именами и связать их с одним или несколькими серверами приложения.
  • Метод мониторинга должен представлять собой исполняемую программу, например скрипт оболочки (shell script), тестирующий приложение и на выходе возвращающий целочисленное значение, указывающее состояние приложения. Код завершения должен быть нулевым при нормальном состоянии приложения и ненулевым при отказе приложения.
  • HACMP не осуществляет передачу аргументов в метод мониторинга.
  • По умолчанию метод мониторинга записывает сообщения в файл /tmp/clappmond. application_monitor_name.monitor.log. Кроме того, по умолчанию при каждом запуске приложения происходит перезапись файла журнала мониторинга.
  • Метод не должен быть слишком сложным. Если метод мониторинга не возвращает значение в течение заданного интервала опроса, он удаляется.
    Важно! Так как процесс мониторинга зависит от времени выполнения, ВСЕГДА тестируйте свой метод мониторинга при различных нагрузках, чтобы подобрать правильное значение интервала опроса.

Инструмент анализа доступности

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

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

Приложения, интегрируемые с HACMP

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

Заполнение таблиц планирования приложений

Следующие таблицы описывают требуемую информацию для каждого приложения.

Заполните таблицу приложений, включив в нее всю требуемую информацию, как показано в табл. 3.11.

Таблица 3.11. Таблица приложений
ТАБЛИЦА КЛАСТЕРА HACMP – ЧАСТЬ 9 из 11 ТАБЛИЦА ПРИЛОЖЕНИЙ ДАТА: июль 2005
APP1
ЭЛЕМЕНТ КАТАЛОГ ФАЙЛОВАЯ СИСТЕМА РАСПОЛОЖЕНИЕ ДОСТУП
ИСПОЛНЯЕМЫЕ ФАЙЛЫ /app1/bin /app1 Хранилище SAN Общий
ФАЙЛЫ КОНФИГУРАЦИИ /app1/conf /app1 Хранилище SAN Общий
ФАЙЛЫ ДАННЫХ /app1/data /app1 Хранилище SAN Общий
ФАЙЛЫ ЖУРНАЛОВ /app1/logs /app1 Хранилище SAN Общий
СКРИПТ ЗАПУСКА /cluster/local/app1/start.sh / rootvg Необщий (должен располагаться на обоих узлах)
СКРИПТ ОСТАНОВКИ /cluster/local/app1/stop.sh / rootvg Необщий (должен располагаться на обоих узлах)
СТРАТЕГИЯ ПЕРЕМЕЩЕНИЯ ПРИ СБОЕ Перемещение при сбое на узел node02
КОМАНДЫ И ПРОЦЕДУРЫ ОБЫЧНОГО ЗАПУСКА Убедиться в том, что сервер APP1 работает
КОМАНДЫ И ПРОЦЕДУРЫ ВЕРИФИКАЦИИ Выполнить следующую команду и убедиться в том, что APP1 активно. В противном случае отправить уведомление
КОМАНДЫ И ПРОЦЕДУРЫ ОБЫЧНОЙ ОСТАНОВКИ Убедиться в том, что сервер APP1 останавливается корректно
РЕИНТЕГРАЦИЯ УЗЛА Должна осуществляться во время запланированного окна обслуживания, чтобы свести к минимуму нарушение работы клиентов
APP2
ЭЛЕМЕНТ КАТАЛОГ ФАЙЛОВАЯ СИСТЕМА РАСПОЛОЖЕНИЕ ДОСТУП
ИСПОЛНЯЕМЫЕ ФАЙЛЫ /app2/bin /app2 Хранилище SAN Общий
ФАЙЛЫ КОНФИГУРАЦИИ /app2/conf /app2 Хранилище SAN Общий
ФАЙЛЫ ДАННЫХ /app2/data /app2 Хранилище SAN Общий
ФАЙЛЫ ЖУРНАЛОВ /app2/logs /app2 Хранилище SAN Общий
СКРИПТ ЗАПУСКА /cluster/local/app2/start.sh / rootvg Необщий (должен располагаться на обоих узлах)
СКРИПТ ОСТАНОВКИ /cluster/local/app2/stop.sh / rootvg Необщий (должен располагаться на обоих узлах)
СТРАТЕГИЯ ПЕРЕМЕЩЕНИЯ ПРИ СБОЕ Перемещение при сбое на узел node01
КОМАНДЫ И ПРОЦЕДУРЫ ОБЫЧНОГО ЗАПУСКА Убедиться в том, что сервер APP2 работает
КОМАНДЫ И ПРОЦЕДУРЫ ВЕРИФИКАЦИИ Выполнить следующую команду и убедиться в том, что APP2 активно. В противном случае отправить уведомление
КОМАНДЫ И ПРОЦЕДУРЫ ОБЫЧНОЙ ОСТАНОВКИ Убедиться в том, что сервер APP2 останавливается корректно
РЕИНТЕГРАЦИЯ УЗЛА Должна осуществляться во время запланированного окна обслуживания, чтобы свести к минимуму нарушение работы клиентов
КОММЕНТАРИИ Обзор приложений

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

Таблица 3.12. Таблица мониторинга приложений
ТАБЛИЦА КЛАСТЕРА HACMP – ЧАСТЬ 10 из 11 МОНИТОРИНГ ПРИЛОЖЕНИЙ ДАТА: июль 2005
APP1
Можно ли осуществлять мониторинг приложения с использованием монитора процессов? Да
Наблюдаемые процессы app1
Владелец процесса root
Счетчик экземпляров 1
Стабилизационный интервал 30
Счетчик перезапуска 3
Интервал перезапуска 95
Действие при отказе приложения Перемещение при сбое
Метод уведомления /usr/es/sbin/cluster/events/notify_app1
Метод очистки /usr/es/sbin/cluster/events/stop_app1
Метод перезапуска /usr/es/sbin/cluster/events/start_app1
APP2
Можно ли осуществлять мониторинг приложения с использованием монитора процессов? Да
Наблюдаемые процессы app2
Владелец процесса root
Счетчик экземпляров 1
Стабилизационный интервал 30
Счетчик перезапуска 3
Интервал перезапуска 95
Действие при отказе приложения Перемещение при сбое
Метод уведомления /usr/es/sbin/cluster/events/notify_app2
Метод очистки /usr/es/sbin/cluster/events/stop_app2
Метод перезапуска /usr/es/sbin/cluster/events/start_app2