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

Коммуникационные устройства HACMP

Топология HACMP также включает отличные от IP сети (non-IP networks) типа "точка-точка", такие, как последовательная сеть RS232, target mode SCSI, target mode SSA, и подключения мониторинга пульса через диски (disk heartbeat). На обоих концах сети "точка-точка" находятся устройства AIX (определенные в каталоге /dev), такие, как /dev/tty1, /dev/tmssa1, /dev/tmscsi1 и /dev/hdisk1.

Например, при мониторинге пульса через диски имя дискового устройства (например, /dev/hdisk2) используется в качестве устройства, сконфигурированного в HACMP на каждом конце подключения.

Эти отличные от IP сети представляют собой соединения "точка-точка" между двумя узлами кластера и используются RSCT для управления трафиком сообщений и мониторинга пульса. Эти сети обеспечивают дополнительный уровень защиты кластера HACMP на случай отказа IP-сетей или подсистемы TCP/IP на узлах.

Коммуникационные адаптеры и связи включают адаптер X.25, используемый для обеспечения коммуникационной связи с высокой доступностью. В качестве ресурсов HACMP может быть определено следующее:

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

Физические и логические сети

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

HACMP, подобно AIX, поддерживает понятие логических сетей. Два или более сетевых интерфейса в одной физической сети могут быть сгруппированы, представляя логическую сеть. Эти логические сети имеют уникальное имя (например, net_ether_ 01, если оно присваивалось HACMP) и могут включать одну или несколько подсетей. Логическая сеть может быть представлена как группа интерфейсов, используемых HACMP для содержания одной или нескольких сервисных IP-меток/адресов. RSCT образует собственные сети, соединяющие интерфейсы в одной подсети, и при необходимости может обеспечивать временную маршрутизацию между подсетями.

Определения сетей можно добавить через экраны SMIT HACMP, однако мы рекомендуем выполнить процесс обнаружения (discovery) перед конфигурированием сетей. Выполнение процесса обнаружения заполнит ниспадающие списки, которые могут использоваться в процессе конфигурирования. В процессе обнаружения информация берется из файла /etc/hosts, определенных интерфейсов, определенных адаптеров, устройств target mode и существующих дисков с расширенным режимом одновременного доступа (enhanced concurrent) и создаются следующие файлы:

В процессе обнаружения также могут быть выявлены некоторые несогласованности в сети вашего сайта.

Глобальная сеть

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

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

Мониторинг пульса RSCT и HACMP

Диспетчер кластера HACMP cluster manager использует несколько источников для получения информации о возможных отказах:

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

Начиная с HACMP V5.1 мониторинг пульса основан исключительно на службах топологии RSCT. До этого HACMP Classic (до HACMP V4.5) использовал собственный код для модулей сетевых интерфейсов (Network Interface Modules, NIM). Демоны RSCT для передачи пакетов пульса используют протокол UDP. При запуске HACMP на узле HACMP передает сетевую топологию, сохраненную в конфигурации HACMP ODM в RSCT. RSCT использует эту информацию для построения своих групп связи ("колец пульса", heartbeat rings) и, в свою очередь, передает в HACMP уведомления об отказах.

Технология RSCT была разработана в начале 1990-х гг. для систем IBM SP и затем стала инфраструктурой для HACMP/ES (Enhanced Scalability).

RSCT содержит следующие компоненты:

На рис 2.3 показаны некоторые из демонов RSCT, а также их взаимодействие с другими демонами HACMP (в HACMP V5.3).

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

RSCT осуществляет мониторинг только для базовых адресов интерфейсов (если только не выбран мониторинг пульса через IP-синонимы) и не осуществляет мониторинг сервисных IP-меток (при использовании перехвата IP-адреса IPAT посредством синонимов) или постоянных IP-меток.

HACMP отвечает за отслеживание синонимов меток (сервисных IP-меток при IPAT посредством синонимов и постоянных синонимов меток) как по состоянию базового интерфейса и состоянию связи, так и посредством мониторинга счетчика полученных пакетов (подобно выходным данным команды netstat ). HACMP V5.2 и более поздние версии пытаются восстановить работоспособность интерфейса, если он находится в состоянии "down" или "detached" (по выходным данным команды lsattr ), но при этом физическое соединение остается активным.

RSCT определяет, что на одном из интерфейсов или адаптеров узла произошел отказ, если от него не приходят пакеты пульса, однако продолжает приходить информация пульса через другие интерфейсы и адаптеры узла. В этом случае HACMP сохраняет связь с узлом, переводя сервисные (и постоянные) IP-метки на другой сетевой интерфейс той же сети на том же узле.

Если все интерфейсы этой сети HACMP на этом узле становятся недоступными, HACMP переносит все группы ресурсов, содержащие IP-метки, на другой узел с доступными интерфейсами в этой же сети. Если RSCT не получает пакеты пульса через все интерфейсы или адаптеры узла, то считается, что на этом узле произошел отказ и HACMP попытается привести затронутые этим сбоем группы ресурсов в рабочее состояние на другом узле.

Коммуникации RSCT

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

Учитывая топологию кластера, представленную на рис 2.2, RSCT создает три сети пульса – по одной для каждой IP-подсети, и одну для кольца устройств, отличного от IP, как показано на рис 2.4.

В более ранних версиях HACMP количество последовательных (отличных от IP) коммуникационных устройств одного типа на узел ограничивалось двумя, так что для трех или более узлов была возможна только кольцевая конфигурация. Более новые версии HACMP (5.1 и выше) поддерживают конфигурацию с сетями, отличными от IP, с подключением между всеми узлами (каждого с каждым), если на каждом узле достаточно устройств.

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

Лидер группы (Group Leader). Узел с наивысшим IP-адресом в первой созданной группе связи, называется лидером группы. Этот узел хранит информацию о других узлах в кластере и о конфигурации сети.(рис 2.4) Наложение сетей HACMP на топологию

Резервный лидер группы (Group Leader Backup). Узел со вторым по величине IP-адресом в первой группе связи называется резервным лидером группы. Этот узел содержит резервную копию данных топологии лидера группы и принимает на себя роль лидера группы в случае выхода лидера группы из кластера.

Распорядитель (Mayor). Узел с третьим по величине IP-адресом в первой группе связи (если третий узел недоступен, используется резервный лидер группы). Этот узел отвечает за информирование всех узлов о любых изменениях в топологии кластера.

На рис 2.5 показан пример двух групп связи, сформированных для двух IP-подсетей, и RSCT-роли узлов.

Как уже обсуждалось, получение информации о состоянии топологии кластера в HACMP в значительной мере зависит от RSCT и от данных, получаемых в пакетах пульса. Тем не менее должна быть полная уверенность в том, что на узле действительно произошел отказ, прежде чем предпринимать какие-либо действия. Если(рис 2.5) Пример, иллюстрирующий группы связи RSCT и роли узловв сети отсутствует избыточность, HACMP может прийти к неправильным выводам о состоянии узлов. Например, если RSCT использует только сеть TCP/IP, отказ сетевого компонента (коммутатора, маршрутизатора, концентратора) или подсистемы TCP/IP будет некорректно интерпретироваться как отказ одного или нескольких узлов. На рис 2.6 представлен пример кластера, получающего данные пульса исключительно через TCP/IP.

В этом примере узлы 1 и 2 будут считать, что на узлах 3 и 4 произошел отказ, и будут пытаться восстановить работоспособность их ресурсов. Подобным же образом

узлы 3 и 4 будут считать, что отказ произошел на узлах 1 и 2. Такая ситуация, называемая разделенным кластером (partitioned cluster), может привести к повреждению данных, так как каждая группа узлов будет пытаться одновременно осуществлять доступ к данным и запускать приложения.

Чтобы HACMP мог отличить действительный отказ узла от отказа подсистемы TCP/IP, требуется использовать другой путь связи между узлами – такой, который бы не был основан на TCP/IP. Для этого HACMP использует последовательные сети, отличные от IP (сети "точка-точка" или сети устройств). RSCT осуществляет мониторинг как для сетей устройств, так и для сетей TCP/IP, поэтому HACMP может использовать эту информацию, чтобы отличать отказ узла от отказа IP-сети/подсистемы. Рекомендуется, чтобы каждый кластер имел как минимум одну сеть, отличную от IP, для каждого узла в кластере, чтобы не допустить разделения кластера. Если бы в примере, представленном на рис 2.6, использовались последовательные сети, HACMP мог бы правильно распознать отказ и не возникла бы опасность потери или повреждения данных (рис 2.7).

На рис 2.7 представлена рекомендованная конфигурация кластера из двух узлов.

Другая ситуация, при которой RSCT и HACMP не смогут точно определить состояние интерфейса, заключается в возникновении сети с одним интерфейсом. Если(рис 2.7) Мониторинг пульса в кластере HACMPпо причине какого-либо отказа интерфейс обнаружит, что он является единственным интерфейсом в сети, это означает, что не существует другого адреса, с которым интерфейс мог бы обмениваться пакетами пульса. В случае возникновения сети с одним интерфейсом RSCT может определить, работает ли интерфейс, путем мониторинга счетчика полученных пакетов следующим образом:

Файл /usr/es/sbin/cluster/etc/netmon.cf

Должен

Подсети и RSCT

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

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

Примечание. В AIX 5.3 реализована новая опция, mpr_policy, позволяющая настроить TCP/IP таким образом, чтобы пакеты для определенного пункта назначения поступали только с одного адаптера. Чтобы настроить TCP/IP на применение адаптера в зависимости от пункта назначения пакета, следует использовать значение mpr_policy = 5. Мы рекомендуем устанавливать это значение в том случае, если какие-либо из приложений восприимчивы к тому, с какого адаптера приходит пакет, например для NFS.

Мониторинг пульса через IP-синонимы

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

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

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

Для конфигурирования мониторинга пульса через IP-синонимы необходимо задать в конфигурации HACMP базовый (начальный) адрес синонима для мониторинга пульса (heartbeat alias address). При запуске HACMP выполняется построение сети пульса через синонимы (alias heartbeat network) начиная с этого адреса путем вычисления IP-адреса для каждого узла на основании номера узла. Эта сеть определяется как отдельная сеть HACMP с количеством подсетей, соответствующим количеству интерфейсов узла. При указании базового адреса синонима мониторинга пульса применяются следующие правила:

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

На рис 2.8 представлен пример кластера из трех узлов, где каждый узел имеет три интерфейса в одной физической сети и в одной подсети (табл. 2.1). Базовые адаптеры имеют маску подсети 255.255.255.0.

В этом примере HACMP создает три подсети IP-синонимов (по одной для каждого интерфейса) с тремя адресами для каждой (по одному для каждого узла). В табл. 2.2 указаны IP-адреса, используемые HACMP для мониторинга пульса через IP-синонимы, если был сконфигурирован базовый адрес 198.10.1.1.

Примечание. Ни одна из трех подсетей – 198.10.1/24, 198.10.2/24, 198.10.3/24) – не должна обязательно быть маршрутизируемой.

На рис 2.8 представлены три кольца мониторинга пульса (группы связи), используемые RSCT.

Мониторинг пульса через IP-синонимы поддерживает оба механизма перехвата IP-адресов:

Сети TCP/IP

В HACMP 5.1 / 5.2 / 5.3 поддерживаются следующие типы IP-сетей:

Примечание. HACMP поддерживает использование интерфейсов связи IP через агрегированный Ethernet (Etherchannel, IEEE 802.3ad) для перехвата IP-адреса в AIX 5L. Не поддерживается использование Etherchannel:

HACMP предназначен для работы с любой сетью TCP/IP; эти сети используются для того, чтобы:

Сети TCP/IP можно разделить:

Механизмы перехвата IP-адреса

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

Настройки по умолчанию можно изменить путем изменения свойств сети через расширенные меню конфигурирования HACMP.

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

Перехват IP-адреса посредством замены

Сервисная IP-метка/адрес заменяет существующий адрес интерфейса. Таким образом, только одна сервисная IP-метка/адрес может быть сконфигурирована для одного интерфейса. Сервисная IP-метка должна находиться в той же подсети, в которой находится и один из базовых IP-адресов. Этот интерфейс будет в первую очередь использоваться сервисной IP-меткой при активизации группы ресурсов на узле. Другие интерфейсы этого узла, которые не могут находиться в той же подсети, традиционно называются дежурными или резервными (standby) интерфейсами и используются при перемещении группы ресурсов с другого узла или при отказе загрузочного интерфейса (рис 2.9). Этот метод может сохранить подсети, однако требует использования дополнительного оборудования.

При перехвате IP-адреса посредством замены (также называемом классическим перехватом IP-адреса) также можно выполнить конфигурирование перехвата аппаратного адреса (hardware address takeover, HWAT). При перехвате аппаратного адреса локально администрируемый MAC-адрес становится частью определения сервисной IP-метки и во время замены MAC-адрес интерфейса также будет изменен. Это позволяет обойтись без обновления ARP-кешей в подсети, и при этом приложения, использующие MAC-адреса, все равно будут указывать на правильный узел.

В случае отказа интерфейса, содержащего сервисный IP-адрес, при перехвате посредством замены HACMP перемещает сервисный IP-адрес на другой доступный интерфейс того же узла и той же сети; в этом случае соответствующая группа ресурсов не затрагивается.

При отсутствии доступного интерфейса на том же узле группа ресурсов вместе с сервисными IP-метками перемещается на другой узел с доступным интерфейсом в той же логической сети. При отсутствии доступных узлов или интерфейсов группа ресурсов переходит в состояние ERROR (Ошибка). Когда HACMP обнаруживает адаптеры, выполняется проверка возможности перевода групп ресурсов, находящихся в состоянии ERROR, обратно в рабочее состояние.

Ограничение. При перехвате IP-адреса посредством замены RSCT и HACMP не смогут корректно осуществлять мониторинг узла, имеющего больше одной группы ресурсов, если обе сервисные IP-метки находятся в одной подсети, так как узел в этом случае будет иметь два интерфейса с базовыми адресами в одной подсети. По этой причине рекомендуется использовать мониторинг пульса через IP-синонимы или установить в AIX 5.3 для опции mpr_policy значение 5.

Перехват IP-адреса посредством синонимов

Для сервисной IP-метки/адреса выполняется создание синонима на интерфейсе без удаления базового загрузочного IP-адреса с использованием команды ifconfig (рис. 2.10). Начиная с HACMP 5.1 этот метод применяется по умолчанию. Кроме того, перехват IP-адреса посредством синонимов отменяет понятие дежурных интерфейсов – все сетевые интерфейсы считаются загрузочными.

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

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

Перехват IP-адреса посредством синонимов осуществляется только в сетях, поддерживающих функцию gratuitous ARP. Эта функция предполагает, что узел отправляет ARP-пакет до использования IP-адреса;(рис 2.10) Перехват IP-адреса посредством IP-синонимовпри этом ARP-пакет содержит запрос на получение IP-адреса. Это позволяет удостовериться в том, что этот адрес не используется ни одним другим узлом, а также обеспечить обновление ARP-кеша с записью нового адреса на каждом компьютере в подсети.

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

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

Важно! В сетях с перехватом IP-адресов посредством синонимов в HACMP какое-то время будут одновременно активными сервисные IP-адреса отказавшего интерфейса и интерфейса перехвата, что позволяет сохранить маршрутизацию. Это может вызвать запись о дублировании IP-адресов (DUPLICATE IP ADDRESS) в журнале ошибок error log, которую можно игнорировать.

Постоянная IP-метка/адрес

Постоянная IP-метка узла (Persistent node IP label) представляет собой IP-синоним, который может быть назначен определенному узлу сети и, кроме того:

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

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

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

В случае отказа узла или всех интерфейсов логической сети на узле постоянная IP-метка будет недоступна.

На постоянные IP-метки распространяются следующие ограничения по формированию подсетей:

Постоянные IP-метки узлов могут создаваться для следующих типов IP-сетей:

Ограничение. Невозможно сконфигурировать постоянные IP-метки узлов в сетях SP Switch, Classical IP Over ATM и сетях, отличных от IP.

Сети устройств, или Последовательные сети

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

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

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

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

Могут использоваться следующие типы последовательных сетей.

RS232

Последовательная сеть, использующая порты RS232, либо встроенные последовательные порты, либо многопортовый последовательный адаптер.

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

По умолчанию скорость передачи в сетях RS232 равна 38 400 бит/с; если ваш модем не поддерживает такую скорость, это значение следует изменить (в том случае, если вы хотите использовать эту сеть для связи между удаленными узлами).

Target mode SCSI

Другим вариантом сети, отличной от IP, является SCSI-подключение в target mode. При употреблении общего SCSI-устройства можно использовать шину SCSI для обмена пакетами пульса. Target mode SCSI (tmscsi) поддерживается только устройствами SCSI-2 Differential или SCSI-2 Differential Fast/Wide. SCSI-1 Single-Ended и SCSI-2 SingleEnded не поддерживают последовательные сети в кластере HACMP.

Target mode SSA

При использовании SSA-устройств общего доступа в качестве сети, отличной от IP, в HACMP можно использовать Target mode SSA. Он основан на встроенных возможностях SSA-адаптеров (применяющих протокол связи SCSI). SSA-устройства в кольце SSA (диски и адаптеры) используют связь между "инициатором" и "целевым объектом"; SSA-диски являются "целевыми объектами", тогда как SSA-адаптер может выступать как в роли "инициатора", так и в роли "целевого объекта". Таким образом, tmssaподключение использует эти возможности для установления последовательного соединения между узлами HACMP. Такая сеть представляет собой коммуникационную сеть типа "точка-точка", в которой связь осуществляется только между двумя узлами.

Чтобы сконфигурировать tmssa-сеть между двумя узлами кластера, SSA-адаптеры на каждом из узлов в одном SSA-кольце составляют конечные точки.

Сеть пульса через диски

В некоторых ситуациях подключения RS232 tmssa и tmscsi могут считаться слишком дорогостоящими или сложными для реализации. В этом случае мониторинг пульса через диски (diskhb) обеспечивает простой в конфигурировании альтернативный вариант, не требующий дополнительного оборудования. Единственное требование состоит в том, чтобы "диски" (физические диски или номера логических устройств во внешнем хранилище) работали в расширенном режиме одновременного доступа (enhanced concurrent). Диски, работающие в расширенном режиме одновременного доступа, используют службы групп RSCT для управления блокировкой и освобождением сектора диска, применяемого для связи. Раньше этот сектор использовался для дисков режима одновременного доступа SSA (SSA Concurrent mode), теперь он применяется для записи информации пульса.

Любой диск, входящий в группу томов с расширенным одновременным доступом (enhanced concurrent VG), может использоваться в сети diskhb, включая диски, применяемые для хранения данных. Более того, группа томов, содержащая диск, используемый в сети diskhb, не обязательно должна быть активизирована (varied on).

Любой тип диска может быть сконфигурирован как часть группы томов с расширенным одновременным доступом, что делает этот тип сети чрезвычайно гибким. "Адаптеры" на конечных точках этой сети определяются как пара "узел – физический том".

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

Примечание. Группа томов с расширенным одновременным доступом (enhanced concurrent volume group) не то же самое, что группа томов с одновременным доступом (concurrent volume group). Если группа второго типа представляет собой часть группы ресурсов с одновременным доступом (concurrent resourse group), первое понятие скорее указывает на режим блокировки с использованием RSCT.

Мониторинг пульса через диски

Мониторинг пульса через диски (diskhb) представляет собой новую функцию, впервые реализованную в HACMP V5.1 с целью обеспечить дополнительную защиту против разделения кластера и упростить конфигурирование сети, отличной от IP, особенно в средах, где применение соединений RS232, target mode SSA или target mode SCSI является слишком сложным или невозможным.

Этот тип сети может использовать общее дисковое хранилище любого типа (Fibre Channel, SCSI или SSA), если только диск, применяемый для обмена KA-сообщениями, является частью группы томов AIX с расширенным одновременным доступом. Диски, применяемые в сетях пульса, не выделяются исключительно для этой цели; их можно использовать для хранения общих данных приложений (дополнительные сведения см. на рис 2.7).

Наши клиенты запрашивали поддержку подключений target mode Fibre Channel, однако в связи с разнообразием (нестандартными функциями инициатора и целевого объекта) сред FC (включающими адаптеры, подсистемы хранения, SAN, коммутаторы и концентраторы) такие подключения сложны в реализации и поддержке. Используя общие диски для обмена сообщениями, внедрение сети, отличной от IP, является более надежным и не зависит от применяемого типа оборудования.

Кроме того, в среде SAN при использовании оптоволоконных соединений между устройствами длина этого соединения, отличного от IP, имеет такие же ограничения, как и в SAN, что позволяет создавать протяженные сети типа "точка-точка".

При определении диска в составе группы томов с расширенным одновременным доступом часть диска не будет использоваться для какой-либо из операций LVM, и эта часть диска (сектор) применяется для обмена сообщениями между двумя узлами.

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

Примечание. Механизм блокировки кластера для групп томов с расширенным одновременным доступом не использует зарезервированное дисковое пространство для связи (как "классический" clvmd); вместо этого он применяет службы групп RSCT.

Сетевые модули

В HACMP скорость обнаружения отказов определяется для каждого типа сети и может быть либо задана с помощью трех предопределенных значений, либо настроена. Предопределенные значения это "медленное" ( slow ), "нормальное" ( normal ) (по умолчанию) и "быстрое" ( fast ), тогда как при настройке задаются интервал между импульсами и так называемый цикл отказа ( failure cycle ).

Интервал между импульсами (скорость пульса, heartbeat rate – hbrate) определяет скорость отправления службами кластера пакетов "keep alive" между интерфейсами и устройствами в кластере. Цикл отказа ( cycle ) представляет количество идущих подряд импульсов, которое может быть пропущено, прежде чем будет считаться, что произошел отказ интерфейса. HACMP 5.3 поддерживает интервал пульсации в доли секунды. Время обнаружения отказа (в секундах) определяется по формуле

hbrate * cycle * 2

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

При использовании последовательных сетей HACMP объявляет соседний узел неработающим после завершения времени обнаружения отказа (failure detection rate), заданного для этого типа сети. HACMP будет ожидать в течение такого же периода, прежде чем объявить устройство неработающим, если за это время все еще не будет получено ни одного пакета пульса от соседнего узла. HACMP не инициирует событие network_down, пока не откажут как локальное, так и удаленное устройства.

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

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

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

Клиенты

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

Клиенты AIX 5L могут использовать службы информации кластера (clinfo) для получения сообщений о событиях кластера. Clinfo включает API, отображающий состояние кластера.

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

Но если клиент не поддерживает пакеты gratuious ARP, его кеш можно обновить с использованием /usr/es/sbin/cluster/etc/clinfo.rc. При возникновении изменений в сети clinfo.rc отправляет по одному ping-запросу на каждый адрес или метку в списке переменной PING_CLIENT_LIST. Таким образом, чтобы обеспечить обновление ARP-кеша на клиентах, нужно добавить адреса и метки всех клиентов в переменную PING_CLIENT_LIST в clinfo.rc. Однако если клиент находится в другой подсети, тогда приведенные выше условия относятся к маршрутизатору.

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

Аспекты сетевой безопасности

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

HACMP обеспечивает безопасность кластера путем:

Дополнительные сведения о доступе пользователей и безопасности кластера см. в лекции 15 и 16 руководства High Availability Cluster Multi-Processing Administration Guide, SC23-4862-06.

Аутентификация и шифрование подключения

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

Существуют следующие способы аутентификации подключения:

HACMP поддерживает следующие способы шифрования:

Файлы ключей хранятся в каталоге /usr/es/sbin/cluster/etc.

Примечание. Это шифрование распространяется только на clcomdES, но не на диспетчер кластера.

Демон коммуникаций кластера

С появлением clcomdES нет необходимости в конфигурировании файла /.rhosts. Однако некоторые приложения все же могут требовать наличия этого файла. Демон коммуникаций кластера выполняет удаленные команды, основываясь на принципе "наименьших привилегий". Это означает, что нельзя будет выполнить произвольную команду на удаленном узле с привилегиями "root". Только несколько команд HACMP считаются "доверенными" и допускают запуск с привилегиями "root"; эти команды перечислены в / usr/es/sbin/cluster. Остальные команды выполняются под учетной записью "nobody".

Демон коммуникаций кластера запускается средством inittab, где соответствующая запись создается при установке HACMP. Управление демоном осуществляет контроллер системных ресурсов SRC, так что для него доступны команды startsrc, stopsrc и refresh. В частности, refresh используется для повторного чтения /usr/es/sbin/cluster/ etc/rhosts и перемещения файлов журнала.

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

Если файл /usr/es/sbin/cluster/etc/rhosts не существует, все подключения отклоняются.

Если файл существует, то выполняется проверка подключений (по порядку):

Наполнение файла /usr/es/sbin/cluster/etc/rhosts происходит при первой синхронизации с адресом интерфейса с синхронизирующего узла (на синхронизирующем узле он остается пустым). После первой синхронизации происходит наполнение ODM-классов HACMP, так что содержимое файла rhosts можно удалить.

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

Замечание. После первоначальной синхронизации кластера происходит наполнение файла /usr/es/sbin/cluster/etc/rhosts адресами интерфейсов синхронизирующего узла.

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

Важно! При наличии недопустимой записи в файле /usr/es/sbin/cluster/etc/rhosts демон коммуникаций clcomdES будет отклонять все подключения.

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

clrexec выполняет специфические и 
потенциально опасные команды;
cl_rcp 	копирует файлы конфигурации AIX;
cl_rsh 	используется кластером для 
выполнения команд в удаленной оболочке.

Демон коммуникаций кластера также отличается от традиционных rsh/rcp-подключений более высокой производительностью (r-команды медленны); кроме того, clcomdES оставляет подключения сокетов открытыми, вместо того чтобы закрывать их после каждой операции. Так как многие операции администрирования HACMP требуют доступа к ODM, демон коммуникаций кластера также кеширует копии ODM каждого узла. Когда необходим доступ к ODM, clcomdES сравнивает контрольную сумму кешированных записей ODM с ODM на каждом узле в кластере и осуществляет обновление только в случае необходимости.

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

Демон коммуникаций кластера также используется (в HACMP 5.2 и выше):

В отличие от HACMP 5.1, начиная с HACMP 5.2 остановка демона коммуникаций кластера при активном кластере невозможна.

Ресурсы и группы ресурсов

Этот раздел описывает следующие понятия ресурсов HACMP:

Определения

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

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

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

Ресурсы

Ресурсами считаются следующие компоненты кластера HACMP.

Сервисный IP-адрес/метка

Как обсуждалось выше, сервисным IP-адресом является IP-адрес, используемый клиентами для доступа к приложениям или узлам. Этот сервисный IP-адрес (и соответствующая метка) является частью группы ресурсов, и для него осуществляется мониторинг в HACMP. Существует два типа сервисных IP-адресов (меток):

Сервисные IP-адреса становятся активными, когда HACMP переводит соответствующую группу ресурсов в активное (ONLINE) состояние.

В HACMP 5.3 при размещении сервисных IP-меток можно задавать следующие варианты размещения:

Следует отметить, что при недостаточном количестве интерфейсов, не соответствующем выбранному варианту размещения, HACMP выполняет распределение IP-меток с использованием доступных интерфейсов, чтобы обеспечить доступность сервисных IP-меток.

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

Хранилище

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

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

Существует два способа доступа к хранилищу:

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

Поддерживаемые устройства:

Важно! IBM может не поддерживать подсистемы и устройства хранения сторонних производителей. Список устройств хранения сторонних производителей можно найти на сайте http://www.availant.com

Программное обеспечение предоставления множественных путей:

Поддерживаемые параллельные SCSI-устройства:

Как правило, параллельные SCSI-устройства можно сконфигурировать в кластерах размером до четырех узлов, где все узлы подключены к одной шине SCSI. К одной шине SCSI можно подключить до 16 устройств (включая SCSI-адаптеры). Однако не рекомендуется подключать устройства, отличные от дисков (такие, как приводы CD-ROM и накопители на магнитной ленте).

Серверы хранения IBM 2105 Enterprise Storage Server

Сервер хранения IBM 2105 Enterprise Storage Server® обеспечивает подключение с одновременным доступом и общий доступ к дисковому хранилищу для различных серверов открытых систем.

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

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

В ESS реализовано дублирование практически всех компонентов и защита при отказе любого из внутренних компонентов.(рис 2.12) Хранилище ESSESS осуществляет управление внутренним хранением (SSA-дисками) встроенным кластером из двух узлов, соединенных через высокоскоростную внутреннюю шину, где каждый узел обеспечивает одни и те же функциональные возможности. Таким образом, при отказе одного из внутренних узлов доступ клиентских систем к хранилищу сохраняется.

Дополнительные сведения о планировании и использовании сервера хранения 2105800 Enterprise Storage Server (включая диаграммы подключения и т. д.) см. на веб-сайте http://www.storage.ibm.com/disk/ess/index.html

Пример стандартного кластера HACMP, использующего ESS в качестве общего хранилища, представлен на рис 2.12.

Серверы хранения IBM FAStT/DS4xxx

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

Хотя архитектура FAStT/DS4xxx и не настолько сложна, как реализованная в ESS, она также основана на максимизации избыточных компонентов – контроллеров хранения, блоков питания и адаптеров подключения хранилищ.

В архитектуре FAStT/DS4xxx реализован протокол Fibre Channel как на стороне узла, так и на стороне хранилища. Он не обеспечивает поддержку SCSI и не предоставляет выделенную высокоскоростную шину для связи между двумя контроллерами, однако он обеспечивает функцию перемещения контроллера при сбое для непрерывных операций, а также кеширование данных на стороне узла.

Полные сведения о системах хранения IBM см. на веб-сайте http://www.storage.ibm.com/disk/fastt/index.html

Стандартное подключение FAStT/DS4xxx к кластеру HACMP представлено на рис 2.13.

Дисковая подсистема IBM Serial Storage Architecture

Подсистемы хранения SSA (Serial Storage Architecture) обеспечивают решение с большей "дискретностью компонентов" и содержат средства, позволяющие сократить количество единых точек отказа.

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

Хранилище SSA также позволяет реализовать возможности RAID на уровне адаптера (Host Bus Adapter, HBA).

Примечание. При использовании SSA RAID количество узлов HACMP, допускающих совместное использование одних данных, ограничено двумя.

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

SSA-хранилище обеспечивает гибкий, достаточно простой и более "тонкий" подход к конфигурированию кластеров HACMP с существующими или устаревшими приложениями и ограниченным количеством узлов. Мы рекомендуем осуществлять внедрение всех новых конфигураций с использованием новых технологий (FC-хранилище).

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

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

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

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

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

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

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

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

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

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

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

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

При интеграции узла в кластер 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 невозможно создавать группы томов с одновременным доступом в любом режиме, кроме расширенного.

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

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

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

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

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

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

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

Расширенные меню ресурсов (extended resource) SMIT позволяют создавать настраиваемые методы работы с дисками, томами и файловыми системами. Для создания настраиваемого метода необходимо определить в 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 можно осуществлять управление:

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Накопители на магнитной ленте

Некоторые накопители на магнитной ленте с подключением SCSI или Fibre Channel могут быть сконфигурированы как ресурсы высокой доступности в составе любой группы ресурсов (кроме concurrent).

Ресурсы Fast Connect

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

Если сконфигурирован перехват IP-адреса и аппаратного адреса, клиентам не требуется повторно устанавливать свое подключение.

Интеграция с WLM

Диспетчер рабочей нагрузки (workload manager, WLM) представляет собой инструмент администрирования ресурсов AIX, позволяющий устанавливать целевые значения и ограничения по использованию процессора, физической памяти и пропускной способности дискового ввода-вывода для приложений и пользователей. Могут быть сконфигурированы WLM-классы, каждому из которых соответствует определенный набор системных ресурсов. Затем определяются правила назначения приложений или групп пользователей классу и, таким образом, набор используемых ими ресурсов.

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

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

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

Основной класс WLM

Если политика группы ресурсов предусматривает ее запуск либо только на домашнем узле (online on home node only), либо на первом доступном узле (online on first available node), то:

Если группа ресурсов имеет политику запуска либо для подключенного режима на всех доступных узлах (online on all available nodes, одновременный доступ), либо для подключенного режима с использованием политики распределения узлов (online using a node distribution policy), то узел применяет основной класс WLM.

Дополнительный класс WLM

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

Группы ресурсов

Для обеспечения высокой доступности в HACMP каждый ресурс должен быть включен в группу ресурсов (resource group, RG). Группы ресурсов позволяют HACMP осуществлять управление соответствующим набором ресурсов как единым объектом. Например, приложение может содержать скрипты запуска и остановки, базу данных и IP-адрес. Эти ресурсы включаются в группу ресурсов, которой HACMP управляет как единым объектом.

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

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

Режимы работы группы ресурсов-политики и атрибуты

Работа группы ресурсов определяется путем конфигурирования политик и режимов работы группы ресурсов. Ранние версии HACMP (до 5.1) поддерживали три предопределенные группы ресурсов:

Настраиваемые группы ресурсов

Что в действительности важно для проектировщиков и администраторов HACMP, так это работа групп ресурсов при запуске, перемещении при сбое и возврате после восстановления. HACMP 5.1 поддерживает и "настраиваемые" (custom), и "классические" группы ресурсов, однако начиная с версии 5.2 доступны только "настраиваемые" группы ресурсов. Существуют следующие опции работы настраиваемых групп ресурсов.

Опции запуска (startup options)

Эти опции контролируют работу группы ресурсов при первом запуске.

Если при подключении узла к кластеру существует несколько групп ресурсов такого типа, HACMP выбирает группу ресурсов с меньшим количеством узлов в списке узлов. Если этот показатель одинаков для всех групп ресурсов, HACMP выбирает первый узел в алфавитном порядке. Однако если один из узлов имеет зависимую группу ресурсов (т. е. является родительским объектом в отношениях зависимости), он будет иметь приоритет (рис 2.18).

Опции перемещения при сбое (fallover options)

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

Перемещение при сбое на узел из списка со следующим приоритетом (fallover to next priority node in list). Группа ресурсов выполняет перемещение при сбое на следующий узел в списке узлов группы ресурсов (рис 2.19).(рис 2.19) Перемещение при сбое на узел из списка со следующим приоритетом

Перемещение при сбое с использованием динамического приоритета узла (fallover using dynamic node priority). Узел, на который выполняется перемещение, может быть выбран на основе доступности процессора, доступности памяти или наименьшего использования дисков. HACMP применяет RSCT для сбора данных по выбранному показателю со всех узлов в списке узлов, после чего осуществляется перемещение группы ресурсов на узел, который лучше всего соответствует критериям (рис 2.20).

Перевод в отключенное состояние (только на узле с ошибкой) [Bring offline (on error only)]. В случае ошибки группа ресурсов переводится в отключенное состояние. Эта опция предназначена для групп ресурсов с подключением на всех доступных узлах (рис 2.21).(рис 2.21) Перемещение при сбое с использованием динамического приоритета узла(рис 2.20) Перевод в отключенное состояние (только на узле с ошибкой)

Опции возврата после восстановления (Fallback options)

Эти опции контролируют работу подключенной группы ресурсов при подключении узла к кластеру.

Возврат после восстановления на узел с более высоким приоритетом в списке (fallback to higher priority node in list). Группа ресурсов осуществляет возврат после восстановления на узел с более высоким приоритетом при его подключении к кластеру (рис 2.22).

Без выполнения возврата после восстановления (never fallback). Группа ресурсов не переносится на узел с более высоким приоритетом при его подключении к кластеру. Эта опция должна использоваться в группах ресурсов с подключением на всех доступных узлах. См. рис 2.23(рис 2.23) Возврат после восстановления на узел с более высоким приоритетом в списке(рис 2.22) Без выполнения возврата после восстановления

Примечание. ITO – Inactive takeover (Переход при неактивности); CWOF – Cascading without fallback (Каскадирование без возврата после восстановления); DNP – Dynamic Node Priority (Динамический приоритет узла).

Табл. 2.4 показывает соответствие опций запуска, перемещения при сбое и возврата после восстановления оригинальным каскадным группам ресурсов, ротационным группам ресурсов и группам ресурсов с одновременным доступом.

Атрибуты группы ресурсов

Работу группы ресурсов можно настроить с использованием таких атрибутов группы ресурсов, как:

Время установления (settling time)

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

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

Таймеры отсроченного возврата после восстановления (delayed fallback timers)

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

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

Политика распределения (distribution policy)

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

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

Динамический приоритет узла (dynamic node prioritiy)

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

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

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

Для вывода текущих значений используется команда lssrc -ls clstrmgrES.

odin:/# lssrc -ls clstrmgrES
Current state: ST_STABLE
sccsid = "@(#)36 1.135.1.37 
  src/43haes/usr/sbin/cluster/hacmprd/main.C,
hacmp.pe, 51haes_r530, r5300525a 6/20/05 14:13:01"
i_local_nodeid 1, i_local_siteid 1, my_handle 2
ml_idx[1]=0 ml_idx[2]=1 ml_idx[3]=2
There are 0 events on the Ibcast queue
There are 0 events on the RM Ibcast queue
CLversion: 8
Example 2-1cluster fix level is "0"
The following timer(s) are currently active:
Current DNP values
DNP Values for NodeId 1 NodeName frigg
PgSpFree = 0 PvPctBusy = 0 PctTotalTimeIdle = 0.000000
DNP Values for NodeId 2 NodeName odin
PgSpFree = 130258 PvPctBusy = 0 PctTotalTimeIdle = 99.325169
DNP Values for NodeId 3 NodeName thor
PgSpFree = 0 PvPctBusy = 0 PctTotalTimeIdle = 0.000000

Порядок обработки групп ресурсов (resource group processing order)

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

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

Расположение, отменяющее приоритет (Priority override location, POL)

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

Атрибут POL может быть задан как:

Примечание. При перемещении группы ресурсов с политикой "без выполнения возврата после восстановления" устанавливается атрибут POL и для группы ресурсов выполняется возврат на этот узел, пока атрибут POL не будет удален.

При перемещении подключенной группы ресурсов на другой узел предлагаются следующие варианты:

Зависимости групп ресурсов (resource group dependencies)

Может быть задано сочетание двух типов зависимостей групп ресурсов:

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

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

рис 2.24 иллюстрирует пример, где группа ресурсов 2 имеет две дочерние группы ресурсов, одна из которых также имеет свою дочернюю группу ресурсов. Таким образом, группа ресурсов 2 должна быть подключена прежде, чем можно будет подключить группы ресурсов 3 и 4. Подобным образом группа ресурсов 4 должна быть подключена прежде, чем можно будет подключить группу ресурсов 5. Группа ресурсов 3 имеет две родительские группы ресурсов (1 и 2), которые должны быть подключены прежде, чем можно будет ее подключить.

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

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

Подключение на том же узле (online on same node): Для заданных групп ресурсов запуск, перемещение при сбое и возврат после восстановления всегда осуществляются на одном и том же узле, т. е. узлы осуществляют перемещение набора групп. Группа ресурсов с зависимостью может быть подключена только на том узле, на котором уже подключены другие группы ресурсов из того же набора, если только она не является первой подключаемой группой ресурсов в наборе.(рис 2.24) Отношения "родительский объект / дочерний объект"

Подключение на разных узлах (online on different nodes). Для заданных групп ресурсов запуск, перемещение при сбое и возврат после восстановления осуществляются на разных узлах. Группам ресурсов назначается приоритет, так что группы ресурсов с более высоким приоритетом обслуживаются первыми и сохраняются в подключенном состоянии при ограниченном количестве узлов. Группы ресурсов с низким приоритетом отключаются, если группа ресурсов с более высоким приоритетом не имеет узла. Группы ресурсов со средним приоритетом не отключаются. Группа ресурсов с такой зависимостью может быть подключена только на узле, на котором не подключены другие группы ресурсов, являющиеся частью этой зависимости.

Подключение на том же сайте (online on same site). Заданные группы ресурсов всегда подключаются на одном и том же сайте.(рис 2.25) Зависимости групп ресурсов

Группа ресурсов с этой зависимостью может быть подключена только на том же сайте, на котором уже подключены другие группы ресурсов с этой зависимостью, если только она не является первой подключаемой группой ресурсов с этой зависимостью. На рис 2.25 представлен пример кластера из трех узлов с двумя базами данных и двумя приложениями. Приложения не могут быть запущены до подключения баз данных, поэтому устанавливается зависимость "родительский объект/дочерний объект".

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

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

odin:># clrgdepdency -t [PARENT_CHILD | NODECOLLOCATION | ANTICOLLOCATION |
SITECOLLOCATION ] -sl
odin:># clrgdepdency -t PARENT_CHILD -sl
#Parent Child
rg1 rg2
rg1 rg3
odin:># clrgdepdency -t NODECOLLOCATION -sl
odin:># clrgdepdency -t ANTILOCATION -sl
#HIGH:INTERMEDIATE:LOW
rg01::rg03frigg

odin:># clrgdepdency -t SITECOLLOCATION -sl
rg01 rg03 frigg

Другой способ проверки состоит в использовании команды odmget HACMPrg_ loc_dependency.

Управление группой ресурсов

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

Атрибут (priority override location) устанавливается в соответствии с приведенным выше описанием.

Некоторые изменения являются недопустимыми:

Состояния групп ресурсов

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

Если узел при подключении к кластеру не может перевести группу ресурсов в подключенное состояние, группа ресурсов остается в ошибочном состоянии (ERROR). При возникновении отказа, если группа ресурсов не настроена на подключение на всех доступных узлах, HACMP попытается перевести группу ресурсов в подключенное состояние на другом активном узле из списка узлов группы ресурсов.

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

Если узлу не удалось выполнить "подхват" группы ресурсов во время перемещения при сбое, группа ресурсов помечается как "восстанавливаемая" (recoverable), и HACMP попытается подключить группу ресурсов на других узлах из списка узлов группы ресурсов. Если это не удается сделать на всех узлах, группа ресурсов остается в ошибочном состоянии.

При отказе сети на определенном узле HACMP определяет, какие группы ресурсов были затронуты (которые имели сервисные IP-метки в этой сети), после чего пытается выполнить подключение на другом узле. В случае отсутствия узлов с требуемыми сетевыми ресурсами группы ресурсов остаются в ошибочном состоянии. Если какие-либо интерфейсы становятся доступными, HACMP решает, какие группы ресурсов в ошибочном состоянии могут быть подключены, после чего пытается их подключить.

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

Выборочные перемещения при сбое (selective fallovers)

Подключаемые модули HACMP

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

Каждый модуль содержит скрипты запуска и остановки приложений, скрипты мониторов приложений и скрипты удаления. В состав также входит скрипт, подтверждающий наличие корректных файлов конфигурации в общей файловой системе. Каждый подключаемый модуль содержит файл README с подробной информацией. Они находятся в каталоге /usr/es/sbin/cluster/plugin/<имя_модуля>.

Возможности (HACMP 5.1, 5.2 и 5.3)

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

Новые возможности

Усовершенствования внутрикластерной связи в демоне clinfo. Демон clinfo теперь содержит информацию о версии и имеет новый файл журнала /tmp/clinfo.debug.

В демоне диспетчера кластера были добавлены функциональные возможности SMUX peer daemon (clsmuxpd), так что выполнение SNMP-запросов возможно даже при неактивном кластере. Были созданы два новых состояния: not_configured и not_synced.

Диспетчер кластера теперь имеет два файла журнала:

/tmp/clstrmgr.debug 	файл журнала с 
настраиваемым расположением, 
содержащий стандартную регистрируемую 
информацию диспетчера кластера;
/tmp/clsmuxtrmgr.debug 	новый файл журнала, 
предназначенный для трассировки новой
функции SNMP диспетчера кластера.

Усовершенствования верификации кластера

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

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

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

Дополнительная верификация кластера

HACMP также выполняет следующие дополнительные проверки:

Автоматическое наполнение файла clhosts

Файл clhosts, используемый многими программами мониторинга, имеет две версии:

Файл определения кластера в формате XML

Формат XML является наиболее распространенным форматом для файлов определения кластера, создаваемых пользователем, и файлов системы автоматизированного планирования (Online Planning Worksheets). Для преобразования существующих файлов снимков кластера в XML-файл определения кластера можно использовать SMIT.

Тома OEM и Veritas и интеграция файловой системы

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

В частности, HACMP автоматически определяет группы томов, созданные диспетчером томов Veritas с использованием Veritas Foundation Suite (v4.0).

Функция SMS

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

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

Помимо политик, определяющих зависимости типа "родительский объект/дочерний объект" для групп ресурсов, и политики распределения при запуске, HACMP теперь предлагает зависимости в масштабе кластера для групп ресурсов:

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

Параметр распределения IP-меток/адресов

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

HACMP/XD

Параллельная обработка основного и дополнительного экземпляров реплицируемых групп ресурсов HACMP/XD выполняется по умолчанию, однако может быть задана и последовательная обработка. Процессы DARE и rg_move поддерживают параллельную обработку между сайтами.

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

Усовершенствования безопасности в WebSMIT

Осуществляется подтверждение параметров, передаваемых в WebSMIT, перед выполнением.

Средства аутентификации WebSMIT в большей мере интегрированы с механизмами аутентификации AIX.

Программы Smart assist для HACMP

HACMP теперь поддерживает:

Неподдерживаемые возможности

Ограничения

Этот раздел описывает некоторые наиболее распространенные ограничения, свойственные HACMP. Эти ограничения представлены в табл. 2.6.

Требования подсетей

Таблица маршрутизации ядра AIX 5L поддерживает наличие нескольких маршрутов к одному пункту назначения. Если несколько совпадающих маршрутов имеют одинаковый коэффициент, каждый из маршрутов подсетей используется поочередно. При этом в HACMP возникает следующая проблема: если один узел имеет несколько интерфейсов, совместно использующих один маршрут, то HACMP не имеет средства определения его состояния.

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

Аспекты хранения

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

Подсистемы хранения серии IBM DS4xxx

Эти устройства прежде назывались FAStT-серверами (Fiber Attach Storage Server, сервер хранения с оптоволоконным подключением). HACMP поддерживает несколько различных моделей подсистем хранения DS4xxx. Описание всех моделей выходит за рамки данного курса.

Мы покажем принципы настройки хранилища DS4xxx на примере сервера хранения DS4500.

Сервер хранения DS45 00

Сервер хранения DS4500 поддерживает прямое подключение до четырех узлов, каждый из которых содержит по два адаптера и которые предназначены для обеспечения максимальной избыточности как на стороне узла, так и на стороне хранилища. При использовании внешних FC-коммутаторов в сочетании с сервером хранения DS4500 можно подключить к серверу хранения DS4500 до 64 узлов (с двумя адаптерами каждый).

Перед конфигурированием хранилища DS4500 необходимо удостовериться в наличии всех аппаратных и кабельных подключений, обязательных для конфигурации. Дополнительные сведения о кабельных подключениях DS4500 см. в руководстве IBM TotalStorage DS4500 Fibre Channel Storage Server Installation Guide, GC26-7530.

Программное обеспечение DS4xxx Storage Manager

Единственный способ конфигурирования хранилища DS4500 состоит в использовании программного обеспечения DS4xxx Storage Manager, которое доступно в большинстве популярных операционных систем, в частности в AIX, Linux и Windows® XP/2000. Используя DS4xxx Storage Manager, можно выполнить конфигурирование поддерживаемых уровней RAID, логических устройств и разделов. К поддерживаемым уровням RAID относятся RAID-0, RAID-1, RAID-5 и RAID 0+1.

В DS4xxx Storage Manager отсутствует опция конфигурирования RAID-10. При выборе RAID-1 с несколькими дисками DS4xxx Manager обеспечивает чередование и зеркальное отображение данных.

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

К новым возможностям, поддерживаемым DS4xxx Storage Manager, относятся:

Сервер хранения Enterprise Storage Server (ESS/Shark)

Серверы хранения IBM Enterprise Storage Server (ESS) представляют собой второе поколение дисковой системы хранения Seascape®, обеспечивающей наилучшие в отрасли показатели доступности, производительности, управляемости и масштабируемости. Уровни RAID в ESS предопределены в виде нескольких конфигураций и имеют ограниченные возможности изменения. Доступны следующие уровни RAID: RAID-1, RAID-5 и RAID 0+1.

Сервер IBM Enterprise Storage Server (ESS) не просто осуществляет общее хранение между различными промышленными платформами; он может повысить производительность, доступность, масштабируемость и управляемость ресурсов хранения предприятия с использованием различных мощных средств. Некоторые из средств по названию сходны со средствами FAStT/DS4xxx Storage, однако их технические концепции значительно различаются. Ниже приведены некоторые из возможностей.

Дополнительные сведения о конфигурировании Enterprise Storage Server см. в руководстве IBM TotalStorage Enterprise Storage Server Service Guide 2105 Model 750/800 and Expansion Enclosure, Volume 1, SY27-7635.

Серии IBM TotalStorage DS6000 и DS8000

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

Подробные сведения о сериях DS6000 и DS8000 и об их поддержке см. на веб-сайте http://www-1.ibm.com/servers/eserver/pseries/ha/

Архитектура SSA (Serial Storage Architecture)

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

SSA поддерживает RAID-0, RAID-1, RAID-5 и RAID 0+1. Чтобы использовать любую из установок RAID, необходимо следовать правилам колец для дисковых стоек SSA. Для создания RAID-массива необходимо использование специальных соединений на дисках. Дополнительные сведения о конфигурации RAID в IBM SSA см. в руководстве IBM Advanced SerialRAID Adapters Installation Guide, SA33-3287.

Общий LVM

В кластере HACMP основным элементом являются данные, используемые приложениями высокой доступности. Эти данные хранятся в объектах диспетчера логических томов (Logical Volume Manager, LVM). Кластеры HACMP используют возможности LVM для обеспечения доступа к этим данным с нескольких узлов. Диспетчер логических томов AIX обеспечивает общий доступ к данным с нескольких узлов. К компонентам общего диспетчера логических томов относятся:

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

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

После экспорта и реимпорта владельцем группы томов является пользователь "root", и эта группа является доступной для группы system.

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

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

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

В среде неодновременного (non-concurrent) доступа HACMP обычно использует файловые системы Journaled File System для управления данными, хотя некоторые приложения баз данных могут обходить файловую систему JFS и осуществлять прямой доступ к логическому тому.

В режиме неодновременного доступа LVM поддерживаются как конфигурации с зеркальным отображением, так и конфигурации без зеркального отображения. Дополнительные сведения по созданию логических томов с зеркальным отображением и без него см. в руководстве HACMP for AIX 5L V5.3 Planning and Installation Guide, SC23-4861-06.

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

Для создания на узле общей файловой системы с неодновременным доступом, необходимо выполнить следующие действия:

Импорт группы томов на узле перемещения при сбое

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

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

При добавлении группы томов в группу ресурсов можно выбрать импорт группы томов вручную на узел перемещения при сбое либо автоматический импорт на все узлы перемещения при сбое в группе ресурсов. Дополнительные сведения об импорте групп томов см. в руководстве HACMP for AIX 5L V5.3 Planning and Installation Guide, SC23-4861-06.

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

# chvg -an -Qn <vgname>

Эта команда отключает автоматическую активизацию при перезапуске системы, а также отключает кворум группы томов.

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

Использование одновременного (concurrent) доступа в HACMP требует установки дополнительного набора файлов. Режим одновременного доступа не поддерживается в файловых системах; вместо этого необходимо использовать логические тома прямого доступа или физические диски.

Создание группы томов с одновременным доступом

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

# lsdev -Cc disk

Для использования группы томов с одновременным доступом необходимо выполнить ее создание как группы томов с возможностью одновременного доступа (concurrent capable). Группа томов с возможностью одновременного доступа может быть активизирована как в режиме неодновременного доступа, так и в режиме одновременного доступа.

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

Импорт группы томов с возможностью одновременного доступа

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

# importvg -C -y vg_name physical_volume_name

Имя диска в группе томов указывается в качестве аргумента команды importvg. По умолчанию AIX автоматически активизирует группы томов без возможности одновременного доступа при их импорте. AIX не выполняет автоматическую активизацию группы томов с возможностью одновременного доступа при их импорте.

Активизация групп томов с возможностью одновременного доступа в режиме неодновременного доступа

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

# varyonvg <vgname>

Создание логических томов в группе томов с возможностью одновременного доступа

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

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

Деактивизация группы томов

После создания логического тома необходимо выполнить деактивизацию (varyoff) группы томов с использованием команды varyoffvg так, чтобы ее активизацию можно было выполнить скриптами HACMP. Введите

# varyoffvg <vgname>

Определение группы томов с одновременным доступом в группе ресурсов HACMP

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

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

Группы томов в режиме расширенного одновременного доступа

В HACMP V5.1 была реализована возможность создания и использования групп томов с расширенным одновременным доступом (enhanced concurrent mode, ECM). Их можно использовать как для одновременного, так и для неодновременного доступа. Также можно выполнить преобразование существующих групп томов с одновременным доступом (классических) в группы томов в режиме расширенного одновременного доступа с использованием C-SPOC.

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

Примечание. В HACMP V5.1 быстрый перехват дисков доступен только в AIX 5L V5.2.

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

Активная и пассивная активизация в режиме расширенного одновременного доступа

Группа томов с расширенным одновременным доступом может быть активизирована на узле в двух режимах: активном или пассивном.

Активная активизация

В активном состоянии разрешены все высокоуровневые операции. При активизации группы томов с расширенным одновременным доступом на узле в активном состоянии возможны следующие операции:

Пассивная активизация

При активизации группы томов с расширенным одновременным доступом в пассивном состоянии LVM обеспечивает своего рода ограждение группы томов на уровне LVM. Узел, содержащий группу томов с пассивной активизацией, допускает выполнение ограниченного количества операций чтения для группы томов:

Когда группа томов активизирована в пассивном состоянии, не допускается выполнение следующих операций:

Создание группы томов с расширенным одновременным доступом

При создании групп томов с одновременным доступом в AIX 5L 5.1 или более поздней версии они автоматически создаются в режиме расширенного одновременного доступа.

Для создания группы томов с возможностью одновременного доступа из командной строки AIX следует использовать команду mkvg. Например:

# mkvg -n -s 32 -C -y myvg hdisk11 hdisk12

При этом произойдет создание группы томов с расширенным одновременным доступом для hdisk11 и hdisk12. Флаги выполняют следующие действия:

Быстрый перехват дисков

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

Группы томов с расширенным одновременным доступом поддерживают активизацию в активном и пассивном режимах и могут быть включены в группу ресурсов с неодновременным доступом.

Быстрый перехват дисков (fast disk takeover) выполняется программным обеспечением HACMP автоматически. Для всех общих групп томов, созданных в режиме расширенного одновременного доступа и содержащих файловые системы, HACMP активизирует функцию быстрого перехвата дисков. При запуске HACMP на всех узлах в группе ресурсов, совместно использующих одну группу томов с расширенным доступом, эта группа томов активизируется в пассивном режиме. При подключении группы ресурсов на узле, осуществляющем "подхват" ресурсов, группа томов активизируется в активном режиме.

Другие узлы обеспечивают активизацию группы томов в пассивном режиме.

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

Эти функции имеют следующие требования:

Дополнительные сведения о быстром перехвате дисков см. в руководстве HACMP for AIX 5L V5.3 Planning and Installation Guide, SC23-4861-06.

Конфигурация хранилища с общим доступом

Большинство конфигураций HACMP требует использования общего хранилища. К дисковым подсистемам IBM с поддержкой доступа с нескольких узлов относятся SCSI, SSA, ESS и FAStT.

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

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

HACMP также поддерживает накопители на магнитной ленте с общим доступом (SCSI или FC). Накопители на магнитной ленте с общим доступом могут быть подключены через SCSI или FC. Режим одновременного доступа к ленте не поддерживается. Некоторые из поддерживаемых подсистем работы с магнитными лентами перечислены в табл. 2.8.

Актуальный список поддерживаемых устройств хранения и накопителей на магнитной ленте см. на веб-сайте IBM http://www-1.ibm.com/servers/eserver/pseries/ha/

HACMP также можно настроить на работу с подсистемами хранения общего доступа (дисковыми подсистемами и накопителями на магнитной ленте) сторонних производителей. Список устройств хранения сторонних производителей см. на вебсайтах соответствующих производителей, а также на веб-сайте Availant http://www.availant.com/

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

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

Большая часть подсистем хранения производства IBM поддерживается в HACMP. Дополнительные сведения о поддержке серверов хранения см. в руководстве HACMP for AIX 5L V5.3 Planning and Installation Guide, SC23-4861-06.

Требования общего LVM

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

Примечание. HACMP сам по себе не обеспечивает защиту хранилища. Защита хранилища обеспечивается двумя последними системами:

В этом разделе содержится информация о методах защиты данных на уровне хранилища, а также о режимах доступа к общим дискам LVM:

Неодновременный доступ, одновременный доступ и расширенный одновременный доступ

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

В конфигурациях с неодновременным доступом диски могут совместно использоваться как:

В конфигурации с одновременным доступом данные на дисках одновременно доступны для всех дисков. Этот режим не поддерживает использование файловых систем (JFS или JFS2).

Быстрый перехват диска

В HACMP V5.1 используется новый диспетчер, AIX LVM, с расширенным одновременным доступом. В AIX 5L V5.2 каждая новая группа томов с одновременным доступом должна создаваться в режиме расширенного одновременного доступа.

Только в AIX 5L V5.2 группы томов с расширенным одновременным доступом могут также использоваться для размещения на них файловых систем (общих или необщих). Это позволяет ускорить процесс перехвата общих файловых систем в случае перемещения при сбое.

Группы томов с расширенным одновременным доступом активизируются на всех узлах в группе ресурсов, и доступ к данным координируется HACMP. Только узел с активной группой ресурсов может активизировать группу томов в "активном" режиме; остальные узлы активизируют группу томов в "пассивном" режиме. В "пассивном" режиме не разрешено выполнение высокоуровневых операций над группой томов.

Требования LVM

Диспетчер логических томов (Logical Volume Manager, LVM) осуществляет управление хранилищем, координируя постановку в соответствие данных в физических и логических хранилищах. Логическое хранилище может быть расширено и реплицировано, а также может охватывать несколько физических дисков и стоек.

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

Примечание. Хотя зеркальное отображение LVM может применяться с любым типом диска, при использовании серверов хранения IBM 2105 ESS или FAStT можете пропустить эту опцию. Эти подсистемы хранения (а также некоторые подсистемы сторонних производителей) обеспечивают собственную избыточность данных с использованием различных уровней RAID.

Принудительная активизация групп томов

HACMP V5.1 содержит новую функцию принудительной активизации группы томов на узле. Если в процессе перехвата простое выполнение команды varyon для этой группы томов будет неуспешным (из-за отсутствия кворума), HACMP проверит наличие хотя бы одной рабочей копии каждого логического раздела для каждого логического тома в этой группе томов, прежде чем выполнять активизацию этой группы томов на узле перехвата.

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

Примечание. Следует задать политику размещения "super strict" для логических томов в группах томов, используемых с опцией принудительной активизации. В этом случае LVM проверяет наличие копий логического тома на разных дисках, увеличивая вероятность успешности принудительной активизации после отказа одного или нескольких дисков.

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

HACMP при использовании принудительной активизации групп томов при перехвате сначала пытается просто выполнить команду varyonvg. В случае неуспешного выполнения команды из-за отсутствия кворума HACMP проверяет целостность данных, чтобы убедиться, что существует хотя бы одна доступная копия всех данных в группе томов, прежде чем пытаться выполнить принудительное подключение тома. Если такая копия существует, выполняется команда varyonvg -f; в противном случае группа томов остается отключенной и группа ресурсов переходит в ошибочное состояние (ERROR).

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

Дополнительные сведения см. в лекции 5, "Planning Shared LVM Components", руководства HACMP for AIX 5L V5.3 Planning and Installation Guide, SC23-4861-06.