Компоненты и функции архитектуры HACMP

Физические и логические компоненты HACMP

High Availability Cluster MultiProcessing

Основные компоненты:

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

High Availability Кластер

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

Компоненты топологии кластера

Элементы топологии кластера – это кластер, узлы, сети и коммуникационные интерфейсы.

В контексте HACMP, под узлом подразумевается любой сервер pSeries, входящий в кластер.

Ресурсы кластера

Ресурсы (Resource) - логические компоненты, которые могут быть перенесены с одного узла кластера на другой.

Ресурсы объединяются в ресурсные группы (Resource Group).

Примеры ресурсов:

Ресурсы – это логические компоненты конфигурации кластера, которые могут быть перенесены с одного узла на другой. Они могут быть перенесены без вмешательства оператора.

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

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

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

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

Компоненты высокой надежности в AIX

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

Эти возможности должны быть в полной мере задействованы при построении кластера – надежность системы определяется по ее самому слабому звену.

Поддерживаемое аппаратное обеспечение

Серверы:

Дисковая подсистема:

Сетевая подсистема:

IP-сети

Не IP-сети (Heartbeat)

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

Есть минимальное требование к узлам – минимум 4 PCI-X слота (два – для сетевых адаптеров и два – для дисковых). По два адаптера необходимо для обеспечения резервирования в пределах узла. Интегрированные адаптеры использовать настоятельно не рекомендуется (хотя и возможно) – из-за большого времени простоя, необходимого для их замены в случае сбоя.

Основные функции HACMP

Состав ПО HACMP

HACMP состоит из набора программных компонентов. Cluster manager (clstrmgr) – основной процесс, отвечающий за мониторинг узлов.

Кластер допускает динамическое изменение конфигурации (без остановки). Эта возможность называется Dynamic Automatic Reconfiguration Event (DARE).

C-SPOC – набор меню SMIT для управления кластером из единой точки.

Событийные скрипты – это shell-скрипты, которые запускаются в ответ на какое-либо событие, касающееся кластера.

Дополнительные компоненты HACMP

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

Служба simple network management protocol peer daemon (clsmuxpd) предоставляет возможности для управления и мониторинга кластера удаленно, используя SNMP-менеджер, например, IBM Tivoli Netview.

Процесс clinfo предоставляет API для взаимодействия между clstrmgr и специфичным приложением пользователя. Clinfo также предоставляет возможности удаленного мониторинга.

Мониторинг приложений (application monitoring) может быть использован для слежения за состоянием приложений и их рестарта в случае необходимости.

Обработка событий в кластере

HACMP не является "коробочным" решением!

HACMP обладает достаточной гибкостью для детального конфигурирования

HACMP обеспечивает:

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

Планирование кластера

Вот только несколько советов для планирования кластера:

Встроенные функции HACMP

В HACMP встроено автоматическое обнаружение и реагирование на события:

HACMP реально обнаруживает только три типа сбоев.

Остальные сбои обнаруживаются компонентами AIX (например, LVM), имеется возможность инициирования кластерного события при их возникновении.

Реакция на сбой

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

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

При отсутствии резервных адаптеров, HACMP инициирует fallover.

Реинтеграция после восстановления

Если ранее вышедший из строя компонент восстанавливается, он должен быть реинтегрирован в кластер.

Типичные конфигурации

Пример конфигурации кластера (1)

В кластере из двух узлов с одним приложением (т.е., ресурсной группой), один узел обычно назначается основным, или домашним (primary, home) узлом, а второй - резервным (secondary, standby, backup). В случае выхода из строя основного узла, ресурсная группа автоматически переходит на резервный. При восстановлении основного узла, ресурсная группа возвращается на него.

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

Пример конфигурации кластера (2)

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

Администратор кластера может самостоятельно инициировать переход ресурсной группы в наиболее подходящее время.

Пример конфигурации кластера (3)

Часто распространенная конфигурация с двумя ресурсными группами, одна переходит с левого узла на правый, а вторая - с правого на левый. Это называется "взаимный подхват" (mutual takeover).

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

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

Конкурентный доступ к ресурсам

Приложение должно поддерживать параллельный режим работы.

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

Этот режим часто называется "конкурентным" (concurrent).

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

Надо учитывать, что само приложение должно уметь работать в параллельном режиме.

Основные термины HACMP

Топология кластера - компоненты кластера с точки зрения сети.

Ресурсы кластера - логические компоненты высокой доступности

Ресурсная группа - набор ресурсов, который кластер пытается сохранить доступным как единое целое, согласно политике, определенной администратором.

Подхват (fallover) - перенос ресурсной группы с одного узла на другой (при сбое).

Возврат (fallback) - перенос ресурсной группы на приоритетный узел (как правило, при реинтеграции в кластер сбойного узла).

Дополнительные замечания

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

Продуктовая линия HACMP

HACMP for AIX

HACMP XD

GeoRM

Итоги