Планирование
Заполнение таблиц планирования хранения
Следующие таблицы содержат необходимую информацию об общих группах томов. Совместно они дают достаточно полное представление об общей дисковой конфигурации.
Описание общих групп томов и физических дисков приведено в табл. 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.
Планирование приложений
Практически любое приложение, работающее на автономном сервере 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.
ТАБЛИЦА КЛАСТЕРА 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).