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

Составляющие высокой доступности

Выбор способа защиты данных

Защита хранилища (данных или чего-либо другого) осуществляется независимо от HACMP; для обеспечения высокой доступности хранилища необходимо использовать хранилище с надлежащим уровнем избыточности и отказоустойчивости. HACMP не имеет какого-либо контроля над доступностью хранилища. Для защиты данных можно технологию RAID либо применять (на уровне хранилища или адаптера), либо зеркальное отображение AIX LVM (RAID 1).

Дисковые массивы RAID (Redundant Array of Independent Disks) представляют собой группы совместно работающих дисковых приводов, обеспечивающих более высокую скорость передачи, чем одиночные (независимые) приводы. Массивы также могут обеспечивать избыточность данных, чтобы не возникало потерь данных при отказе одного привода (физического диска) в массиве. В зависимости от уровня RAID выполняется либо зеркальное отображение данных, либо чередование данных, либо совмещение обоих методов. Ниже дается описание подуровней RAID.

  • RAID-0. Также называется "чередованием данных" ( striping ). Обычно файл последовательно записывается на один диск. При чередовании информация разделяется на фрагменты – chunks (при фиксированном размере такие фрагменты обычно называются блоками – blocks ), а фрагменты параллельно записываются на набор дисков (или считываются с него). Это дает следующие преимущества с точки зрения производительности: более высокую скорость передачи данных при последовательных операциях в связи с наложением нескольких потоков ввода-вывода; более высокую пропускную способность при произвольном доступе, так как устраняется сдвиг схемы доступа в связи с распределением данных. Это означает, что при равномерном распределении данных по нескольким дискам требуемая информация, скорее всего, будет расположена на нескольких дисках, вследствие чего повышается пропускная способность нескольких приводов. RAID-0 предназначен только для повышения производительности. Избыточность отсутствует, так что каждый диск является единой точкой сбоя.
  • RAID-1. RAID-1 также называется "зеркальным отображением дисков". При такой схеме разные диски содержат идентичные копии каждого фрагмента данных; другими словами, у каждого диска есть "двойник", содержащий точную реплику (зеркальный образ) информации. При отказе какого-либо диска в массиве наличие зеркального диска обеспечивает доступность данных. Это также позволяет повысить производительность чтения, так как всегда используется тот диск, у которого привод (головка диска) расположен ближе к требуемым данным, что сокращает время поиска. Время реакции при записи может быть дольше, чем при одном диске, в зависимости от политики записи; операции записи могут выполняться либо параллельно (для более быстрой реакции), либо последовательно (для надежности).
  • RAID-2 и RAID-3. Представляют собой массивы с механизмом параллельной обработки, где все приводы в массиве работают в согласии. Подобно чередованию данных, записываемая на диск информация разделяется на фрагменты (фиксированные блоки данных) и каждый фрагмент записывается в одну и ту же физическую позицию на различных дисках (параллельно). При чтении на каждый диск могут направляться одновременные запросы данных. Такая архитектура требует записи данных четности для каждой полосы данных; различие между RAID-2 и RAID-3 состоит в том, что RAID-2 может использовать несколько дисковых приводов для записи данных четности, тогда как RAID-3 может использовать только один дисковый привод. При отказе привода система может воссоздать потерянные данные по оставшимся дискам и данным четности. При больших объемах данных производительность очень высокая, однако на небольших запросах производительность низкая, так как во всех операциях всегда применяются все приводы и не может иметь место наложение или независимое выполнение операций.
  • RAID-4. Эта технология призвана решить некоторые недостатки технологии RAID3 путем использования фрагментов данных более крупного размера и чередования данных по всем дискам, кроме одного, зарезервированного для данных четности. Использование чередования данных означает, что запросы ввода-вывода должны только указывать привод, на котором требуемые данные находятся в действительности. Это означает, что возможно одновременное и независимое выполнение операций чтения. Однако запросы записи требуют использования цикла "чтение/изменение/обновление", что создает "узкое место" на одном диске четности. Необходимо считать каждую полосу, вставить новые данные, после чего вычислить новые данные четности, прежде чем записать полосу обратно на диск. Затем на диск четности записываются новые данные четности, и этот диск не может использоваться для других операций записи, пока не будет завершена эта операция. Из-за этого "узкого места" технология RAID-4 не используется настолько часто, как RAID-5, в которой тот же процесс реализован без "узкого места".
  • RAID 5. Эта технология очень похожа на RAID-4. Разница состоит в том, что данные четности также распределяются по тем же дискам, которые используются для данных, устраняя, таким образом, "узкое место". Данные четности никогда не сохраняются на том же приводе, на котором сохраняются и защищаемые им фрагменты. Это позволяет выполнять одновременные операции чтения и записи, увеличивая производительность по причине доступности дополнительного диска (диска, который ранее использовался для данных четности). Существуют другие функции, позволяющие еще больше повысить скорость передачи данных, такие как кеширование одновременных операций чтения с дисков и передача этой информации во время чтения следующих блоков. Это позволяет достичь скорости передачи данных на уровне скорости адаптера. Как и в технологии RAID-3, при отказе диска информация может быть воссоздана с других приводов. Массив RAID-5 всегда использует данные четности, однако все равно важно регулярно создавать резервные копии данных в массиве. Массивы RAID-5 распределяют данные по всем дискам массива, по одному сегменту за раз (сегмент может содержать несколько блоков). В массиве из n приводов полоса содержит сегменты данных, записываемые на n-1 дисков, и сегмент четности, записываемый на n-й диск. Использование этого механизма также означает, что не все дисковое пространство доступно для записи данных. Например, в массиве из пяти дисков по 72 Гб, несмотря на то что суммарный размер составляет 360 Гб, только 288 Гб доступны для записи данных.
  • RAID 0+1 (RAID-10), также известный как IBM RAID-1 Enhanced или RAID-10, представляет сочетание RAID-0 (чередование данных) и RAID-1 (зеркальное отображение данных). RAID-10 имеет такие же преимущества производительности, как и RAID-0, обеспечивая при этом доступность данных, характерную для RAID-1. В конфигурации RAID-10 осуществляется чередование как для данных, так и для их зеркального отображения по всем дискам массива. Первая полоса представляет полосу данных, тогда как вторая полоса представляет зеркальное отображение, где зеркальное отображение записывается на другой физический диск. Реализации RAID-10 обеспечивают отличную производительность записи, так как им не приходится вычислять и записывать данные четности. RAID-10 может быть реализован программным способом (AIX LVM), аппаратным способом (уровень подсистемы хранения) либо сочетанием аппаратного и программного способов. Выбор подходящего решения зависит от общих требований. RAID-10 имеет такие же стоимостные характеристики, как и RAID-1.
Таблица 2.3. Характеристики широко используемых уровней RAID
Уровень RAID Доступное дисковое пространство, % Производительность операций чтения-записи Стоимость Защита данных
RAID-0 100 Высокая и для чтения и для записи Низкая Нет
RAID-1 50 Средневысокая для чтения, средняя для записи Высокая Есть
RAID-5 80 Высокая для чтения, средняя для записи Средняя Есть
RAID 0+1 50 Высокая и для чтения и для записи Высокая Есть

Важно! Несмотря на то, что на всех уровнях технологии RAID (кроме RAID-0) реализуется избыточность данных, необходимо регулярно осуществлять резервное копирование данных. Это единственный способ восстановления данных в случае случайного повреждения или удаления файла или каталога.

Наиболее распространенные уровни RAID, используемые в современных реализациях информационных систем, приведены в табл. 2.3

Аспекты кворума LVM

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

Если кворум оставлен включенным (по умолчанию), то в случае потери кворума происходит перемещение при сбое для группы ресурсов и для группы томов будетвыполнена принудительная активизация (forced varyon) на другом узле, если принудительная активизация групп томов включена. Если принудительная активизация групп томов включена, HACMP проверяет:

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

Если эти условия выполняются, HACMP осуществляет принудительную активизацию группы томов.

Использование групп томов с режимом расширенного одновременного доступа

В ранних версиях контроль доступа к группе томов осуществлялся блокировками SCSI, тогда как HACMP включал утилиты для отключения этих блокировок в случае, если узел не освободил группы томов надлежащим образом. В AIX 5.x появились группы томов с расширенным одновременным доступом (enhanced concurrent volume groups) и для блокировки используются RSCT. Еще одно усовершенствование состоит в возможности активизации группы томов в одном из двух режимов:

  • Активное состояние (active). Группа томов работает так же, как при традиционной активизации, допускается выполнение операций для группы томов и логических томов, файловые системы могут быть смонтированы.
  • Пассивное состояние (passive). При пассивном состоянии допускается ограниченный доступ к VGDA и LVCB только для чтения.

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

Когда группа ресурсов переходит на узле в подключенное (online) состояние (или, по-другому, активизируется), тогда группы томов с расширенным одновременным доступом активизируются в активном режиме. Когда группа ресурсов на узле переходит в отключенное (offline)состояние (деактивизируется), группа томов возвращается в пассивный режим.

Для отображения состояния группы томов с режимом расширенного одновременного доступа используются команды lspv и lsvg; команда lspv выводит значения "active" и "passive", тогда как команда lsvg выводит значение "active" в поле VG STATE при обоих режимах, а в поле VG PERMISSION выводит значение либо "read / write", либо "passive-only".

Важно! При использовании групп томов с расширенным одновременным доступом важно, чтобы для мониторинга пульса RSCT использовалось несколько сетей. При отсутствии SCSI-блокировки разделенный кластер может очень быстро активизировать группу томов и таким образом повредить данные.

Режим одновременного доступа RAID и SSA

Начиная с HACMP 5.x системы с 64-разрядным ядром должны использовать группы томов с режимом расширенного одновременного доступа (Enhanced Concurrent Mode, ECM). В системах с 32-разрядным ядром осталась поддержка режимов одновременного доступа RAID и SSA, однако начиная с AIX 5.2 невозможно создавать группы томов с одновременным доступом в любом режиме, кроме расширенного.

Режим расширенного одновременного доступа является рекомендуемым, так как:

  • он поддерживает мониторинг пульса дисков – обеспечивает большую гибкость, чем при использовании последовательных соединений;
  • он обеспечивает быстрый перехват диска (fast disk takeover) – сокращает время на перемещение при сбое;
  • в нем легче обеспечить согласованность VGDA между узлами.

Общие физические тома

Для приложений, осуществляющих доступ к диску прямого доступа (raw disk), в качестве ресурса в группу ресурсов может быть добавлен идентификатор физического тома (Physical Volume Identifier, PVID).

Общие логические тома

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

Хотя это и не относится непосредственно к HACMP, помните о том, что некоторые приложения, использующие логические тома прямого доступа (raw logical volumes), начинают запись с начала устройства, перезаписывая таким образом контрольный блок логического тома (logical volume control block, LVCB).

Настраиваемые методы работы с дисками

Расширенные меню ресурсов (extended resource) SMIT позволяют создавать настраиваемые методы работы с дисками, томами и файловыми системами. Для создания настраиваемого метода необходимо определить в HACMP соответствующие скрипты управления устройствами в среде высокой доступности, например:

  • для настраиваемых дисков: HACMP предоставляет скрипты выявления фантомных дисков (ghost disks), определяет, есть ли резервирование (блокировка) диска узлом, сбрасывает бит резервирования и делает диск доступным;
  • для групп томов: HACMP предоставляет скрипты для вывода имен групп томов, вывода дисков в группе томов, перевода группы томов в подключенное и отключенное состояние;
  • для файловых систем: HACMP предоставляет скрипты подключения (монтирования), отключения, вывода списка и проверки состояния.

HACMP 5.3 содержит настраиваемые методы для Veritas Volume Manager (VxVM), использующего Veritas Foundation Suite v4.0.

Файловые системы (jfs и jfs2) fsck и logredo

Собственные файловые системы AIX используют технологии ведения журналов баз данных для поддержки своей структурной целостности. Таким образом, после отказа AIX использует журнал файловой системы (JFSlog) для восстановления последнего согласованного состояния файловой системы. Этот метод работает быстрее, чем при использовании утилиты fsck. В случае отказа процесса восстановления с использованием журнала JFSlog возникнет ошибка и файловая система подключена не будет. Утилита fsck выполняет проверку согласованности файловой системы, проверяя индексные дескрипторы (inodes), структуру каталогов и файлы. Хотя при ее использовании больше шансов восстановить поврежденные файловые системы, ее выполнение занимает больше времени.

Важно! Восстановление согласованного состояния файловой системы не гарантирует согласованности данных, за это отвечает приложение.

NFS

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

При конфигурировании NFS через HACMP можно осуществлять управление:

  • Сетью, которую HACMP использует для подключения NFS.
  • Экспортом и подключениями NFS на уровне каталогов.
  • Способами экспорта для экспортируемых каталогов и файловых систем NFS. Эта информация хранится в файле /usr/es/sbin/cluster/etc/exports, имеющем такой же формат, как и файл exports операционной системы AIX – /etc/exports

Ограничения NFS и HACMP

  • Кластер может содержать только два узла
  • Общие группы томов, содержащие файловые системы, подлежащие экспорту с использованием NFS, должны иметь один и тот же старший номер устройства (major number) на всех узлах; в противном случае восстановление клиентских приложений во время перемещения при сбое будет невозможно.
  • Если операции экспорта NFS определены на узле посредством HACMP, все операции экспорта NFS должны контролироваться HACMP. Нельзя смешивать операции экспорта AIX и HACMP NFS.
  • Если в группе ресурсов определены операции экспорта NFS, в поле file systems mounted before IP configured нужно установить значение true.
  • По умолчанию для группы ресурсов, содержащей экспортированные файловые системы NFS, автоматически выполняется перекрестное подключение (crossmount). Это подразумевает также, что каждый узел в группе ресурсов будет действовать как NFS-клиент, так что он должен иметь IP-метку в той же подсети, в которой ее имеет и сервисная IP-метка NFS-сервера.

Перекрестные подключения NFS

Перекрестные подключения (cross-mounts) NFS работают следующим образом:

  • узел, содержащий группу ресурсов NFS, осуществляет экспорт всех файловых систем NFS;
  • каждый узел в группе ресурсов монтирует все файловые системы NFS, определенные в группе ресурсов;
  • при "подхвате" группы ресурсов другим узлом этот узел выполнит монтирование файловых систем NFS и их повторный экспорт.

Например:

  • узел1 с сервисной IP-меткой svc1 монтирует и экспортирует /fs1;
  • узел2 монтирует svc1:/fs1 к /mntfs1;
  • узел1 также монтирует svc1:/fs1 к /mntfs1.

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

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

Приложения определяются в HACMP как сервер приложений (application server) со следующими атрибутами:

  • Скрипт запуска (start script). Этот скрипт должен быть способен запустить приложение как после обычной, так и после неожиданной остановки. Выходные данные скрипта записываются в файл журнала hacmp.out. Код завершения скрипта отслеживается HACMP.
  • Скрипт остановки (stop script). Этот скрипт должен быть способен успешно остановить приложение. Выходные данные скрипта также записываются в журнал, и код завершения также отслеживается.
  • Мониторы приложений (application monitors). Для обеспечения высокой доступности приложений HACMP может осуществлять мониторинг самого приложения, а не только требуемых ресурсов.

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

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

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

  • Совместимо ли приложение с версией AIX.
  • Совместима ли среда хранения с кластером высокой доступности.
  • Нужно хорошо понимать взаимозависимости приложения и платформы. Расположение кода приложения, данных, временных файлов, сокетов, каналов и прочих компонентов системы, например принтеров, должно реплицироваться по всем узлам, на которых будет располагаться приложение.
  • Как уже обсуждалось, должна быть реализована возможность запуска и остановки приложения без вмешательства оператора, в частности после неожиданной остановки узла. Скрипты запуска и остановки приложения должны быть тщательным образом протестированы перед внедрением и при каждом изменении в среде.
  • Группа ресурсов, содержащая приложение, должна содержать все ресурсы, требуемые для работы приложения, или быть дочерней группой ресурсов для такой группы ресурсов.
  • Необходимо учитывать лицензирование приложения. Многие приложения имеют лицензии, основанные на коде процессора; необходимо провести тщательное планирование, чтобы убедиться в том, что приложение может быть запущено на любом узле из списка узлов группы ресурсов. Также следует быть внимательным с количеством процессоров на каждом узле и т. п., так как некоторые лицензии восприимчивы к таким показателям.

Мониторы приложений

HACMP использует мониторы приложений (application monitors) для обеспечения высокой доступности приложений. Начиная с HACMP 5.2 каждое приложение может иметь несколько мониторов.

HACMP использует два типа мониторов приложений:

  • Мониторы процессов (process monitors). Обнаруживают прерывание одного или нескольких процессов с использованием RSCT Resource Monitoring and Control (RMC). Следует быть внимательным, чтобы выбрать правильное имя процесса, – используйте выходные данные команды ps -el, чтобы быть уверенным в том, что выбран требуемый процесс. Можно осуществлять мониторинг нескольких процессов. Один монитор приложения может осуществлять мониторинг определенного количества экземпляров одного процесса или единичных экземпляров множества процессов.
  • Настраиваемые мониторы (custom monitors). Тестируют состояние приложения с использованием настраиваемого пользовательского скрипта. В качестве метода должна применяться исполняемая программа (может использоваться shell-скрипт), тестирующая приложение и завершающаяся после этого. При возврате нулевого значения приложение считается нормально работающим, ненулевое значение указывает на неудачный запуск или отказ приложения.

Например, монитор базы данных может выполнять запросы к базе данных и возвращать код завершения, соответствующий ответу базы данных.

Начиная с HACMP 5.2 каждый тип монитора может иметь различные режимы работы:

  • Монитор запуска (startup monitor). Монитор приложения проверяет, был ли сервер приложения успешно запущен в заданный интервал стабилизации. Данный тип монитора специально предназначен для родительских групп ресурсов в отношениях зависимости между родительскими и дочерними группами ресурсов, так как HACMP запускает скрипт запуска приложения в фоновом режиме и не ожидает его завершения. При использовании монитора запуска дочерние группы ресурсов не переводятся в подключенный режим, пока монитор не подтвердит, что приложение было успешно запущено. Если для приложения сконфигурировано несколько мониторов запуска, используется самый длинный стабилизационный интервал, соответствующий времени события.
  • Монитор выполнения (long running monitor). Монитор приложения периодически проверяет, работает ли сервер приложения после завершения интервала стабилизации. Этот режим используется по умолчанию.
  • Двойной монитор (both). Монитор приложения проверяет, было ли приложение запущено за период стабилизации, после чего осуществляет периодический мониторинг после завершения периода стабилизации.

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

  • Имя монитора. Уникальное имя.
  • Режим монитора. Монитор запуска, монитор выполнения или двойной монитор.
  • Сервер приложения. Сервер приложения, подлежащий мониторингу.
  • Интервал стабилизации. В зависимости от режима:
    • В режиме запуска осуществляется регулярный мониторинг приложения в течение заданного периода, чтобы определить, было ли оно успешно запущено. Если монитор сообщает, что приложение было успешно запущено, то HACMP закрывает монитор и продолжает обработку. Однако если приложение не было успешно запущено к концу периода, то считается, что произошел отказ при "подхвате" группы ресурсов и HACMP предпринимает действия по восстановлению.
    • В режиме выполнения HACMP в течение заданного периода ожидает стабилизации приложения перед началом мониторинга приложения.
    • В двойном режиме выполняется периодическая проверка приложения в течение заданного периода, чтобы убедиться в том, что приложение было запущено успешно; после завершения этого периода осуществляется мониторинг приложения, чтобы убедиться, что оно продолжает выполняться.
  • Счетчик перезапусков. Указывает количество попыток перезапуска приложения, прежде чем HACMP предпримет действия, описанные ниже. При мониторинге запуска этот параметр имеет значение 0.
  • Интервал перезапуска. Указывает время, в течение которого приложение должно быть стабильным, прежде чем сбросить счетчик перезапусков. Рекомендуется, чтобы этот показатель содержал значение, равное или больше чем значение счетчик перезапуска x интервал стабилизации. По умолчанию задается 110 % этого значения.
  • Действие, выполняемое при отказе приложения2Не относится к мониторам запуска. . Можно задать действие, предпринимаемое HACMP, если приложение не удалось перезапустить по истечении количества перезапусков, заданных счетчиком перезапусков. По умолчанию задано уведомление, которое инициирует событие уведомления. Другой вариант – перемещение при сбое, при котором HACMP выполняет "подхват" группы ресурсов на другом узле из списка узлов групп ресурсов либо на следующий узел, соответствующий критериям динамического приоритета узла.
  • Метод уведомления. Используется при отказе приложения.
  • Метод удаления3Не относится к мониторам запуска. . Необязательный параметр, определяющий метод, используемый HACMP для удаления приложения после его отказа перед попыткой перезапуска приложения. Если используется только один сервер приложения, по умолчанию этот параметр указывает на его скрипт остановки; однако необходимо быть внимательным, так как, если приложение уже остановлено, этот скрипт может дать сбой.
  • Метод перезапуска 4Не относится к мониторам запуска. . Необязательный параметр, определяющий метод, используемый HACMP при попытке перезапуска приложения, если счетчик перезапусков не равен нулю. И опять же, если используется только один сервер приложения, по умолчанию этот параметр указывает на его скрипт запуска.

Для мониторов процессов следует определить следующее:

  • Наблюдаемый процесс. Имя процесса, для которого осуществляется мониторинг (чтобы определить корректное имя процесса, воспользуйтесь командой ps-el ).
  • Владелец процесса. Имя пользователя, владеющего всеми процессами, для которых осуществляется мониторинг (например, db2adm ).
  • Счетчик экземпляров. Должно быть задано количество экземпляров. Если мониторинг осуществляется только для одного процесса, то значение этого параметра должно быть равным количеству экземпляров, и в случае, если оно будет большим или меньшим, выдается ошибка. Если осуществляется мониторинг нескольких процессов, то допускается только один экземпляр для каждого процесса.

Для настраиваемых мониторов следует определить:

  • Метод мониторинга. Имя программы, используемое HACMP для мониторинга сервера приложений. При возвращении ненулевого кода завершения HACMP предполагает, что возникла проблема с приложением.
  • Интервал мониторинга. Количество секунд, в течение которых HACMP ожидает возврата кода завершения от метода мониторинга. Если за это время монитор не отреагирует, HACMP предположит, что он завис.
  • Сигнал при зависании монитора. Сигнал, отправляемый HACMP монитору приложения в том случае, если ответ не был получен за время, заданное интервалом мониторинга. По умолчанию отправляется сигнал SIGKILL.

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

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

Доступность приложения

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

Коммуникационные адаптеры и каналы

HACMP поддерживает три типа коммуникационных каналов (communication links):

  • SNA, сконфигурированная через интерфейс локальной сети;
  • SNA через X.25;
  • X.25.
  • Из-за способа использования X.25 эти интерфейсы воспринимаются как отдельный класс интерфейсов или как устройства, не включенные в топологию HACMP, и поэтому управление ими осуществляется с использованием нестандартных методов. В частности, для мониторинга интерфейсов X.25 не применяется мониторинг пульса. Новый демон clcommlinkd для мониторинга состояния ссылки X.25 использует x25status.
Динар Валеев
Динар Валеев
Россия
Lichodedov Andrej
Lichodedov Andrej
Литва