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

Устранение единых точек отказа

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

Первоначальная схема кластера

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

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

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

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

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

Этот список кратко описывает основные компоненты схемы кластера. Каждый элемент будет более подробно рассмотрен в процессе планирования.

Заполнение обзорной таблицы планирования кластера

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

Планирование оборудования кластера

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

При выборе узлов основное условие заключается в том, чтобы в случае перемещения при сбое оставшийся узел или узлы были способны выполнять приложения с отказавшего узла. Другими словами, если у вас есть кластер из двух узлов и при этом отказывает один узел, оставшийся узел должен иметь ресурсы, требуемые для выполнения приложений с отказавшего узла (помимо собственных приложений). Если это невозможно, можно рассмотреть вариант внедрения дополнительного узла в качестве дежурного или вариант использования динамических разделов (DLPAR, в системах POWER4™ или POWER5™). Как вы сможете заметить, HACMP допускает широкий выбор конфигураций кластера в зависимости от ваших требований.

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

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

Заполнение таблицы планирования оборудования кластера

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

Планирование программного обеспечения кластера

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

Уровни AIX и RSCT

HACMP 5.3 поддерживается в AIX версий 5.2 и 5.3. Использовавшиеся в нашей среде уровни сочетания AIX и RSCT приведены в табл. 3.4.

Поддержка Virtual LAN и Virtual SCSI

Для поддержки функций Virtual LAN (виртуальная локальная сеть) и Virtual SCSI, реализованных в IBM P5 Virtual I/O Server, необходимы следующие уровни программного обеспечения:

Обязательные наборы файлов

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

Наборы файлов безопасности AIX

Следующие наборы файлов являются обязательными, если вы планируете использовать аутентификацию или шифрование сообщений в HACMP для связи между узлами кластера. Их можно установить с диска AIX 5L Expansion Pack CD-ROM.

Программное обеспечение, необходимое для работы WebSmit

Следующее программное обеспечение является необходимым, если вы планируете установить и сконфигурировать WebSmit. Представленные версии являются наиболее актуальными на момент написания этого курса.

Выберите "AIX Toolbox Cryptographic Content" и скопируйте следующие файлы:

Наборы файлов HACMP

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

Файлы AIX, изменяемые HACMP

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

/etc/hosts

Скрипты событий кластера используют файл /etc/hosts для разрешения имен. Все IP-интерфейсы узлов кластера должны быть указаны в этом файле на всех узлах. HACMP может изменить этот файл, чтобы обеспечить наличие всей необходимой информации в файле /etc/hosts на всех узлах для корректной работы HACMP.

При удалении сервисных IP-меток из конфигурации кластера с использованием SMIT рекомендуется также удалить их из файла /etc/hosts.

/etc/inittab

Файл /etc/inittab изменяется в следующих случаях:

/etc/rc.net

Файл /etc/rc.net вызывается утилитой cfgmgr (cfgmgr – утилита AIX 5L, осуществляющая конфигурирование устройств, а также, опционально, установку программного обеспечения устройств в системе) для настройки и запуска TCP/IP в процессе загрузки. Он задает имя хоста, шлюз по умолчанию и статические маршруты.

/etc/services

HACMP использует следующие сетевые порты для связи между узлами кластера (они все перечислены в файле /etc/services):

Помимо HACMP, следующие порты используются RMC:

Версия snmpd.conf зависит от того, какая версия системы используется: AIX 5L V5.1 или более поздняя. В более поздних версиях системы AIX 5L, чем V5.1, по умолчанию используется файл snmpdv3.conf.

Демон SNMP считывает файл конфигурации /etc/snmpd.conf при запуске, а также при обновлении или выдаче сигнала kill -1. Этот файл задает имена сообществ (community names) и соответствующие привилегии доступа и представления, хосты уведомления о ловушках (trap), атрибуты журналов, конфигурации параметров snmpd, а также конфигурации SMUX для snmpd. Процесс установки HACMP добавляет clsmuxpd-пароль для этого файла.

Чтобы включить HACMP MIB с управлением из диспетчера кластера (Cluster Manager), в конец файла добавляется запись

smux 1.3.6.1.4.1.2.3.1.2.1.5 "clsmuxpd_password" # HACMP clsmuxpd
/etc/snmpd.peers

Файл /etc/snmpd.peers осуществляет настройку сторон подключения SMUX (snmpd SMUX peers). При установке HACMP добавляет следующую запись, чтобы включить clsmuxpd-пароль для этого файла:

clsmuxpd 1.3.6.1.4.1.2.3.1.2.1.5 
  "clsmuxpd_password" # HACMP clsmuxpd

/etc/syslog.conf

Файл конфигурации /etc/syslog.conf используется для управления выходными данными демона syslogd, который регистрирует системные сообщения. В процессе установки HACMP добавляет в этот файл записи, которые направляют вывод сообщений, связанных с HACMP в определенные файлы.

Пример:

Файл /etc/syslog.conf должен быть одинаковым на всех узлах.

/etc/trcfmt

Файл /etc/trcfmt представляет собой файл-шаблон для утилиты регистрации и создания отчетов трассировки системы, trcrpt. В процессе установки добавляется трассировка HACMP в файл формата трассировки. Трассировка HACMP выполняется для демонов clstrmgr и clinfo.

/var/spool/cron/crontab/root

В процессе установки HACMP в файл /var/spool/cron/crontab/root добавляется чередование файлов журналов HACMP.

0 0 * * * /usr/es/sbin/cluster/utilities/clcycle 
 1>/dev/null 2>/dev/null # >.
HACMP for AIX Logfile rotation

Программное обеспечение приложений

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

Тем не менее существует несколько приложений, в частности Oracle RAC 9i, которые в значительной степени зависят от используемой версии HACMP.

Свяжитесь с производителем приложения, чтобы убедиться в отсутствии проблем (например, с лицензированием) при использовании HACMP 5.3.

Лицензирование

Необходимо принимать во внимание два аспекта лицензирования: лицензирование HACMP (функций) и лицензирование приложения.

HACMP

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

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

Лицензирование HACMP V5 Smart Assist основано на количестве процессоров. Под количеством процессоров понимается суммарное количество процессоров, на которых установлен или выполняется HACMP V5 Smart Assist. Наличие лицензий HACMP V5 и HACMP V5 Smart Assist является обязательным на каждом компьютере, на котором устанавливается и выполняется HACMP V5 Smart Assist.

Итак, вот что это значит:

Приложение

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

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

Заполнение таблицы планирования программного обеспечения

Табл. 3.5 содержит полный список программного обеспечения, установленного в нашем примере.

Аспекты операционной системы

Помимо уровней и наборов файлов операционной системы AIX, существует еще несколько аспектов операционной системы, которые необходимо рассмотреть на этапе планирования.

Требования к дисковому пространству

HACMP требует наличия следующих объемов дискового пространства для установки в группе томов rootvg:

Кроме того, рекомендуется выделить приблизительно 100 Мб свободного пространства в /var и /tmp для журналов HACMP. (Требуемое пространство зависит от количества узлов в кластере, которое влияет на размер сообщений, записываемых в различные журналы HACMP.)

Синхронизация времени

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

Настройки операционной системы

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

Планирование безопасности

Защита узлов кластера (и приложения) от несанкционированного доступа является важным фактором общей доступности системы. Существуют некоторые общие аспекты безопасности, а также аспекты, связанные с HACMP, которые мы рассмотрим в этом разделе.

Безопасность кластера

Кластеру HACMP нужен способ аутентификации на всех своих узлах для выполнения удаленных команд, связанных с верификацией кластера, синхронизацией и некоторыми административными операциями (C-SPOC).

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

Была устранена зависимость от AIX rsh (и таким образом, от файла /.rhosts). Так как некоторые внешние для HACMP команды, например пользовательские скрипты, могут все еще требовать удаленного выполнения команд с использованием r-команд, вам нужно проанализировать, есть ли необходимость оставить файл ~/.rhosts.

Межузловая связь в HACMP осуществляется с использованием демона кластера (clcomdES), что устраняет необходимость в "классических" удаленных командах AIX.

Режимы аутентификации подключения в HACMP

Для повышения безопасности можно также использовать VPN-туннели между узлами кластера. В этом случае трафик clcomdES для IP-интерфейсов/адресов, сконфигурированных в HACMP, направляется через VPN-туннели, предоставляемые AIX. При использовании VPN следует применять постоянные адреса для VPN-туннелей. Конфигурирование VPN сначала выполняется в AIX, а потом в HACMP. Для упрощения конфигурирования HACMP предоставляет меню SMIT.

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

Для управления межузловыми коммуникациями демону коммуникаций кластера необходим список допустимых IP-меток или адресов кластера. Существует два способа предоставить эту информацию:

Автоматическое конфигурирование узлов

Если вы впервые осуществляете конфигурирование HACMP, файл /usr/es/sbin/cluster/ etc/rhosts на узле является пустым. Демон clcomdES должен выполнить аутентификацию IP-адреса входящего подключения, чтобы убедиться, что оно исходит от узла в кластере; правила проверки адресов основаны на следующем процессе:

Обычно пользователю не приходится вручную заполнять файл rhosts; это делает clcomdES. Так как после установки этот файл пуст, он будет заполнен при первом подключении с другого узла. Первое подключение обычно выполняется с целью верификации и синхронизации, после чего происходит заполнение ODM-классов HACMPnode и HACMPadapter. После синхронизации кластера файл rhosts можно очистить, но не удалить. Информация из классов HACMPnode и HACMPadapter затем используется для аутентификации clcomd.

Индивидуальное конфигурирование узлов

В качестве альтернативного решения, если вас в особенности интересует сетевая безопасность (построение кластера может выполняться на основе незащищенной сети), можно поместить все IP-адреса/метки в файл /usr/es/sbin/cluster/etc/rhosts до конфигурирования кластера.

При установке HACMP этот файл создается пустым и имеет разрешения чтения и записи только для пользователя "root".

Настройка файла /usr/es/sbin/cluster/etc/rhosts

Администрирование пользователей

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

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

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

После установки HACMP содержит средства управления учетными записями пользователей и групп AIX 5L в кластере HACMP. Также имеется утилита для авторизации заданных пользователей и изменения их пароля на всех узлах в кластере HACMP.

Группа HACMP

При установке HACMP, если группа hacmp не существует, она будет создана. При создании группы HACMP просто берет следующий доступный идентификатор GID для группы hacmp.

IP-порты HACMP

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

Планирование наборов файлов HACMP

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

Управление этими наборами файлов можно осуществлять через меню SMIT. С помощью SMIT можно добавлять, удалять и изменять наборы файлов для соответствия вашим потребностям.

Стандартные наборы файлов HACMP

При установке HACMP происходит установка следующих наборов файлов (file collections):

Configuration_Files

Набор Configuration_Files представляет контейнер для следующих важных системных файлов:

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

HACMP_Files

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

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

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

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

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

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

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

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

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

Также представлена сеть пульса через диски (а также сеть типа "точка-точка"). При использовании SAN-дисков можно легко реализовать мониторинг пульса через диски, так как это не требует дополнительного оборудования. Кроме того, в multipathконфигурации устройств применение устройства vpath, в отличие от hdisk, позволяет использовать возможности программного обеспечения SDD. Другими словами, в hdisk применяется только один путь к устройству, тогда как в vpath обычно используется несколько путей. Multipath-устройства могут быть сконфигурированы при употреблении нескольких дисковых адаптеров на узле, нескольких адаптеров хранилища или при одновременном использовании и того и другого.

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

В нашем примере мы планируем использовать сеть Ethernet и сеть пульса через диски, а не сеть RS232.

Терминология

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

IP-метки

IP-метки (IP labels) представляют собой имена, связанные с IP-адресами, подлежащими разрешению системой (/etc/hosts, BIND и т. д.).

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

Сервисная IP-метка/адрес (service IP label/address) представляет собой IP-адрес или метку, через которую осуществляется обслуживание. Обычно она представляет собой адрес, используемый клиентами для доступа к приложению. Она может быть привязана к узлу либо совместно использоваться узлами, и HACMP обеспечивает его высокую доступность.

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

Постоянная IP-метка/адрес (persistent IP label/address) – это IP-синоним, привязанный к узлу, управляемый HACMP. Другими словами, постоянный синоним никогда не перемещается на другой узел; иногда он называется привязанным к узлу (node-bound).

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

Коммуникационный интерфейс (communication interface) – это физический интерфейс, поддерживающий протокол TCP/IP. В качестве примера можно привести Ethernetадаптер. Представлен IP-меткой времени загрузки или базовой IP-меткой.

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

Коммуникационное устройство (communication device) – это физическое устройство, представляющее сторону отличной от IP сети типа "точка-точка". Например: /dev/tty1 и /dev/vpath0.

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

Коммуникационный адаптер (communication adapter) – это физический адаптер X25, высокая доступность которого поддерживается HACMP.

Сетевая интерфейсная карта (NIC)

Сетевая интерфейсная карта (Network Interface Card, NIC) – это обычный физический адаптер, используемый для предоставления доступа к сети, например Ethernetадаптер считается сетевой интерфейсной картой.

Общие аспекты сети

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

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

HACMP позволяет осуществлять межузловую связь в TCP/IP-сетях следующих типов. (следует заметить, что наиболее часто используемой сетью является Ethernet):

Следующие TCP/IP-сети не поддерживаются:

Можно сконфигурировать мониторинг пульса посредством сетей "точка-точка" следующих типов:

Сетевые подключения

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

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

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

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

На рис. 3.5 показана физическая конфигурация Ethernet с двумя Ethernet-адаптерами на каждом узле, подключенными через два коммутатора; все узлы сконфигурированы в одной физической сети (VLAN). Это иногда называется расположением в одном "домене коллизий" MAC.

Etherchannel

HACMP поддерживает применение Etherchannel (или Link Aggregation) для подключения к сети Ethernet. Etherchannel может быть полезен, если вы посчитаете нужным использовать несколько Ethernet-адаптеров как для увеличения пропускной способности сети, так и для перемещения при сбое, но при этом также требуется сохранить простоту конфигурации HACMP. При употреблении Etherchannel можно просто задать интерфейс(рис 3.5) Подключения к коммутаторам в сети EthernetEtherchannel в качестве коммуникационного интерфейса; любые отказы в сети Ethernet, за исключением отказа самой сети Ethernet, можно обрабатывать без участия HACMP.

EtherChannel представляет собой технологию агрегации сетевых портов, позволяющую объединять несколько Ethernet-адаптеров для создания одного псевдоEthernet-устройства. Например, ent0 и ent1 можно объединить в адаптер EtherChannel под названием ent3; затем можно настроить IP-адрес для интерфейса en3. Система считает эти объединенные адаптеры одним адаптером. Таким образом, IP-адрес настраивается для них как для любого Ethernet-адаптера. Кроме того, всем адаптерам в EtherChannel назначается один аппаратный (MAC) адрес, так что для удаленных систем они представляются как один адаптер.

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

В дополнение к функции агрегации также можно выполнить назначение резервного адаптера. Этот адаптер конфигурируется как часть Etherchannel, но остается неактивным, пока не откажут все основные адаптеры. Это называется резервированием сетевого интерфейса (Network Interface Backup, NIB).

EtherChannel представляет собой технологию агрегации сетевых портов, позволяющую объединять несколько Ethernet-адаптеров для создания одного псевдоEthernet-устройства. Например, ent0 и ent1 можно объединить в адаптер EtherChannel под названием ent3; затем можно настроить IP-адрес для интерфейса en3. Система считает эти объединенные адаптеры одним адаптером. Таким образом, IP-адрес настраивается для них как для любого Ethernet-адаптера. Кроме того, всем адаптерам в EtherChannel назначается один аппаратный (MAC) адрес, так что для удаленных систем они представляются как один адаптер.

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

В дополнение к функции агрегации также можно выполнить назначение резервного адаптера. Этот адаптер конфигурируется как часть Etherchannel, но остается неактивным, пока не откажут все основные адаптеры. Это называется резервированием сетевого интерфейса (Network Interface Backup, NIB).

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

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

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

Имена хостов и имена узлов

Обычно имя хоста совпадает с именем узла HACMP. При использовании пути конфигурации "Standard" ("Базовая") HACMP получает с узла имя хоста и использует его в качестве имени узла. При использовании расширенного пути конфигурирования (Extended Configuration path) можно задать имя узла самостоятельно.

В том случае, если приложение требует переноса имени хоста в AIX 5L в случае перемещения при сбое на другой узел вместе с приложением, следует использовать скрипты преди постобработки для изменения имени хоста таким образом, чтобы оно соответствовало сервисной IP-метке при перемещении группы ресурсов, содержащей это приложение, на другой узел.

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

/etc/hosts

IP-адрес и связанная с ним метка (имя) должны быть заданы в файле /etc/hosts. Мы рекомендуем выбрать один из узлов кластера для выполнения всех изменений в этом файле, а затем использовать FTP или наборы файлов HACMP для распространения файла /etc/hosts на другие узлы.

IP-метки

Постоянные IP-адреса (синонимы)

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

Постоянный синоним

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

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

Подсети

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

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

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

Аспекты шлюза (маршрута) по умолчанию

В зависимости от конфигурации вашей IP-сети при управлении интерфейсами из HACMP может произойти потеря маршрута по умолчанию.

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

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

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

Обновление ARP-кеша

При изготовлении каждой сетевой интерфейсной карте (Network Interface Card, NIC) назначается уникальный аппаратный адрес – MAC-адрес (Media Access Control). MACадрес представляет адрес, используемый сетевыми драйверами для отправки пакетов между сетевыми картами в локальной сети. Большинство систем ведут список, содержащий недавно использовавшиеся IP-адреса и соответствующие им MAC-адреса и называемый ARP-кешем. Так как HACMP может перемещать IP-адреса между сетевыми картами, некоторые записи клиентского ARP-кеша могут быть неточными.

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

HACMP в коммутируемой сети

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

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

Если требуется, чтобы алгоритм spanning tree был включен, то функция portfast также должна быть включена.

Настройки скорости передачи в Ethernet

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

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

Перехват IP-адреса (IP Address Takeover, IPAT) представляет собой механизм, используемый HACMP для перемещения сервисных адресов между коммуникационными интерфейсами.

Существует два метода: перехват IP-адреса посредством замены (IPAT via replacement) и перехват IP-адреса посредством синонимов (IPAT via aliases). Конфигурация вашей сети зависит от применяемого метода управления интерфейсами.

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

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

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

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

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

Для кластера из двух узлов требуется использование по меньшей мере одной подсети на коммуникационный интерфейс на узел (при использовании одинаковой маски подсети во всех подсетях). Для кластера с несколькими коммуникационными интерфейсами на узел требуется следующее:

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

На рис. 3.9 показано состояние сетевых адаптеров до и после запуска HACMP на узлах. Обратите внимание на то, что HACMP при запуске заменяет загрузочный/базовый адрес сервисным адресом. Перемещение при сбое выполняется на дополнительный (дежурный) адаптер(ы), где, опять же, базовый (дежурный) адрес заменяется сервисным адресом. Количество сервисных адресов ограничено количеством резервных адаптеров, определенных в той же сети HACMP.

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

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

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

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

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

Можно выполнить настройку параметров размещения сервисных IP-меток, сконфигурированных в HACMP V5.3. Можно настроить размещение синонимов через меню SMIT с использованием следующих вариантов:

Без совместного размещения (Anti-Collocation). Используется по умолчанию. HACMP распределяет сервисные IP-метки по всем доступным коммуникационным интерфейсам с использованием выбора по принципу наименьшей загруженности.

С совместным размещением (Collocation). HACMP размещает все сервисные IP-метки на одном коммуникационном интерфейсе (NIC).

Без совместного размещения и с постоянной меткой (Anti-Collocation with persistent label). HACMP размещает все сервисные IP-метки по всем активным коммуникационным интерфейсам, не содержащим постоянную IP-метку синонима. HACMP размещает сервисную IP-метку на интерфейсе, содержащем постоянную метку только в том случае, если другие сетевые интерфейсы недоступны. Если постоянные IP-метки не были сконфигурированы, HACMP позволяет выбрать метод размещения Anti-Collocation with Persistent (Без совместного размещения и с постоянной меткой), однако при этом выдается предупреждение и по умолчанию используется обычный метод без совместного размещения.(рис 3.10) Перехват IP-адреса посредством синонимов

С совместным размещением и с постоянной меткой (Collocation with persistent label). Все сервисные IP-метки располагаются на одной сетевой карте, содержащей постоянную IP-метку. Этот вариант может быть полезен при конфигурациях виртуальной частной сети (VPN) с брандмауэром, где только один интерфейс имеет внешний выход и все IP-адреса (постоянные и сервисные) должны располагаться на одном коммуникационном интерфейсе. Если постоянные IP-метки не были сконфигурированы, HACMP позволяет выбрать метод размещения Collocation with Persistent (С совместным размещением и с постоянной меткой), однако при этом выдается предупреждение и по умолчанию используется обычный метод с совместным размещением.

На рис. 3.10 показано состояние сетевых адаптеров до и после запуска HACMP на узлах. Обратите внимание на то, базовые адреса не изменяются. HACMP добавляет на базовые адаптеры сервисные и постоянные синонимы. Постоянные адреса всегда доступны, тогда как сервисные метки добавляются и удаляются при запуске и остановке HACMP. Перемещение при сбое выполняется путем переноса сервисной метки на другой доступный коммуникационный интерфейс. В нашем примере только сеть 192.168.100/24 является маршрутизируемой вне кластера.

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

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

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

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

Чтобы установить мониторинг пульса через IP-синонимы, следует настроить параметр "IP Address Offset for Heartbeating over IP Aliases" ("Смещение IP-адреса для мониторинга пульса через IP-синонимы") как часть конфигурирования сетей HACMP. IP-адреса, используемые для мониторинга пульса, определяются и назначаются системой HACMP с применением этого значения смещения. Маска подсети совпадает с той, которая используется для сервисных и несервисных адресов.

Например, можно в качестве параметра смещения IP-адреса употреблять значение 1.1.1.1. При использовании сети с двумя NIC на каждом узле следует добавить маску подсети 255.255.255.0; в результате получим следующие IP-синонимы мониторинга пульса:

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

На рис. 3.11 показано состояние сетевых адаптеров до и после запуска HACMP на узлах. Обратите внимание на то, базовые адреса не изменяются. Помимо сервисных и постоянных синонимов, добавляемых HACMP на базовые адаптеры, также добавляются синонимы пульса. Последние удаляются при остановке HACMP вместе с сервисными синонимами. В нашем примере только сеть 192.168.100/24 является маршрутизируемой вне кластера.

Команда netstat -i выводит три IP-адреса для каждого адаптера при запущенном HACMP.

Планирование сети, отличной от IP

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

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

Разделение кластера

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

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

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

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

Рис. 3.13 несколько более реалистичен; на нем представлены двойные Ethernetподключения с каждого узла. Каждый Ethernet-адаптер подключен к отдельному коммутатору. В этом случае для разделения кластера необходимо, чтобы произошел отказ двух коммутаторов или же обоих Ethernet-подключений на узле. Однако сама по себе сеть TCP/IP остается единой точкой отказа.

На рис. 3.14 представлена рекомендованная конфигурация. Имеются двойные Ethernet-подключения к нескольким Ethernet-коммутаторам, а также добавлена кольцевая сеть типа "точка-точка". В кольцевой сети каждый узел подключен к своим непосредственным соседям. При потере одного подключения RSCT все еще сможет подключиться ко всем оставшимся узлам. Для разделения кластера потребуется возникновение двойного отказа на узле и отказа сети TCP/IP.

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

Планирование последовательных сетей RS232

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

Если вы решите использовать последовательную сеть RS232, необходимо учитывать следующее:

Кабель для соединения двух последовательных портов должен быть подключен как полный нуль-модемный кабель; он не поставляется по умолчанию вместе с оборудованием. рис. 3.16 показывает нуль-модемное подключение. Фактически используемые разъемы подключения зависят от оборудования; скорее всего, будут использоваться разъемы DB9, DB25 или RJ50.

Чтобы определить, соответствуют ли ваши последовательные порты установленным требованиям, см. документацию к оборудованию и сообщения о поддержке HACMP.

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

Мониторинг пульса через диски представляет еще один тип сетей типа "точка-точка" для обнаружения отказов. В предыдущих версиях HACMP можно было сконфигурировать отличные от IP сети мониторинга пульса через диски SCSI или SSA путем настройки сетей Target Mode SCSI (TMSCSI) и Target Mode SSA (TMSSA) типа "точка-точка".

Начиная с HACMP 5.1, можно также сконфигурировать отличное от IP подключение мониторинга пульса через диски типа "точка-точка" с использованием любого общего диска, входящего в группу томов в режиме расширенного одновременного режима (enhanced concurrent mode, ECM).

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

При употреблении SAN-диска в качестве общего диска следует рассмотреть вариант использования мониторинга пульса через диски по следующим причинам:

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

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

Сеть пульса через диски в кластере содержит:

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

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

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

При установке драйвера Subsystem Device Driver (драйвер устройства для серии DS8XXX) и связывании группы томов с расширенным одновременным доступом с активным устройством vpath необходимо убедиться в том, что коммуникационное устройство мониторинга пульса через диски определено для использования устройства /dev/vpath (а не связанного устройства /dev/hdisk); это позволит применять многопутевое программное обеспечение.

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

В сети пульса через диски рекомендуется применять один LUN (диск) на пару узлов на дисковую стойку.

На рис. 3.17 показаны основные компоненты сети пульса через диски.

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

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

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

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

Все эти вопросы рассматриваются в данном разделе.

Взаимодействие HACMP с DNS и NIS

Чтобы обеспечить успешное и быстрое выполнение событий в кластере, HACMP отключает разрешение имен хоста в NIS или DNS во время обмена сервисных IP-меток путем установки следующей переменной окружения AIX 5L: NSORDER = local. Поэтому файл /etc/hosts на каждом узле кластера должен содержать все IP-метки, определенные в HACMP для всех узлов кластера.

После завершения операции обмена доступ к DNS восстанавливается. Мы предлагаем поместить запись hosts = local, bind4 в файл /etc/netsvc.conf, чтобы обеспечить чтение файла /etc/hosts перед попыткой поиска в DNS.

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

Каждая поддерживаемая сеть кластера имеет соответствующий сетевой модуль RSCT (также называемый сетевым интерфейсным модулем – network interface module, NIM), осуществляющий мониторинг трафика пульса через сеть кластера. Сетевые модули обеспечивают взаимное подключение в кластере, через которое диспетчеры кластера на всех узлах отправляют друг другу сообщения "keep-alive".

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

Скорость обнаружения отказов

Скорость обнаружения отказов (failure detection rate) определяет, через какой промежуток времени подключение считается отказавшим. Скорость обнаружения отказов включает два компонента:

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

(скорость пульса) X (цикл отказа) X 2.

Скорость обнаружения отказов для сетевого модуля можно изменить двумя способами:

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

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

p630n01# lssrc -ls topsvcs
.................. Omitted lines.......................
NIM's PID: 19978
net_ether_01_1 [1] 3 1 S 10.10.31.31 10.10.31.31
net_ether_01_1 [1] en0 0x42d56868 0x42d56872
HB Interval = 1.000 secs. Sensitivity = 10 missed beats
.................. Omitted lines.......................

usr/sbin/cluster/netmon.cf

В конфигурациях кластера, содержащих сети, которые при определенных условиях могут стать сетями с одним адаптером, может быть сложно точно определить отказ того или иного адаптера. В таких ситуациях RSCT использует файл netmon.cf. Службы топологии RSCT сканируют конфигурацию netmon.cf во время запуска кластера. Когда сетевому монитору требуется проверить сеть, чтобы убедиться в функционировании адаптера, он направляет запросы ICMP ECHO на каждый IP-адрес.

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

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

Следующие таблицы содержат требуемую информацию о сети. Табл. 3.6 содержит спецификации сети Ethernet из нашего примера.

Табл. 3.7 описывает сети типа "точка-точка", используемые в кластере. В нашем примере применяется только сеть пульса через диски, однако мы для образца дополнительно включили описание сети RS232.

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

Планирование требований к хранилищу

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

Внутренние диски

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

Общие диски

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

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

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

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

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

При работе с общей группой томов:

Пример конфигурации дисков

На рис. 3.18 показаны различные дисковые конфигурации, которые могут использоваться в кластере. Обратите внимание на то, что для внутренних дисков осуществляется зеркальное отображение (rootvg) и что на каждом узле существует несколько адаптеров Fiber Сhannel (HBA), каждый из которых подключен к отдельному SANкоммутатору (для обеспечения избыточности).

Для проверки дисков следует использовать идентификаторы PVID, так как вполне возможно, что номер vpath на разных узлах может различаться в связи с нумерацией устройств в AIX.

Общие диски представлены разделенными на зоны для обоих узлов. Разделение на зоны выполняется через программное обеспечение управления хранилищем (SAN Storage Manager).

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

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

При активизации группы томов в режиме расширенного одновременного доступа LVM разрешает доступ к группе томов для всех узлов. Однако высокоуровневые подключения например, подключения (mounts) JFS или NFS, запрещены для всех узлов, кроме узла, который на данный момент является владельцем группы томов в HACMP.

В AIX 5.x группы томов в режиме ECM служат заменой классической опции одновременного доступа в HACMP. В новых версиях AIX (5.2 и выше) можно создавать только группы томов в режиме расширенного одновременного доступа. Хотя все еще можно использовать "старые" 32-разрядные группы томов с одновременным доступом, следует проанализировать ограничения, вызываемые обслуживанием таких групп томов в своем кластере. Дополнительные сведения см. в руководстве High Availability Cluster Multi-Processing for AIX 5L Planning and Installation Guide, SC23-4861-06.

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

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

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

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

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

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

HACMP автоматически обнаруживает отказы узлов и инициирует перехват дисков в процессе перехвата группы ресурсов. Традиционный процесс перехвата диска предполагает сброс бита резервирования диска SCSI (или SSA) перед активизацией (varying on) группы томов на резервном узле. Этот процесс может быть длительным, особенно при большом количестве дисков в группе томов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В HACMP управление ресурсами осуществляется с использованием групп ресурсов.

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

К ресурсам и группам ресурсов применимы следующие правила и ограничения:

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

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

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

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

Время установления при запуске

Атрибут времени установления (settling time) относится только к группам ресурсов с подключением на первом доступном узле (Online on First Available Node, OFAN) и устанавливает ожидание в течение заданного количества времени, прежде чем активизировать группу ресурсов. По истечении времени установления HACMP активизирует группу ресурсов на доступном узле с наивысшим приоритетом. Этот атрибут используется для того, чтобы избежать многократного перемещения групп ресурсов с одного узла на другой по мере подключения узлов с более высоким приоритетом.

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

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

Настройка политики динамического приоритета узла (dynamic node priority, DNP) позволяет выбирать резервный узел на основе определенных критериев производительности. При этом для выбора резервного узла используется переменная ресурсов RMC, например "наименьшая нагрузка на процессор". При включенной политике динамического приоритета порядок резервных узлов определяется состоянием кластера на момент события, измеряемый выбранной переменной ресурсов RMC.

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

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

Таймер отсроченного возврата после восстановления

Таймер отсроченного возврата (delayed fallback timer) после восстановления позволяет выполнить для группы ресурсов возврат после восстановления на узел с более высоким приоритетом в заданное время. Группа ресурсов, для которой сконфигурирован таймер отсроченного возврата после восстановления и которая в заданный момент времени находится не на домашнем узле, выполняет возврат на узел с более высоким приоритетом.

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

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

Можно сконфигурировать:

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

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

Метод перехвата IP-адреса и группы ресурсов

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

Перехват IP-адреса не применяется к группам ресурсов с одновременным доступом.

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

Планирование диспетчера рабочей нагрузки

Диспетчер рабочей нагрузки (Workload Manager, WLM) дает возможность пользователям задавать целевые значения и ограничения применения процессора, физической памяти и пропускной способности дисковой подсистемы для различных процессов и приложений. Это обеспечивает более эффективный контроль использования критических системных ресурсов при пиковых нагрузках. HACMP позволяет выполнять конфигурирование классов WLM в группах ресурсов HACMP таким образом, чтобы запуск и остановка WLM и активная конфигурация WLM были под контролем кластера.

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

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

Таблица планирования групп ресурсов содержит всю требуемую информацию о планировании для групп ресурсов ( табл. 3.14).

Подробная схема кластера

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

Разработка плана тестирования кластера

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

Настраиваемый план тестирования

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

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

Инструмент Cluster Test Tool

Чтобы упростить тестирование кластера, HACMP 5.2 и 5.3 включают инструмент Cluster Test Tool, позволяющий протестировать функции кластера, прежде чем он станет частью рабочей среды.

Инструмент Cluster Test Tool работает только в кластере с HACMP 5.2 или более поздней версии с верифицированной и синхронизированной конфигурацией. Инструмент может работать в двух режимах:

Cluster Test Tool использует демон коммуникаций кластера HACMP для организации связи между узлами кластера с целью обеспечения безопасности кластера HACMP.

Автоматическое тестирование

Инструмент тестирования содержит автоматический метод, предназначенный для быстрого тестирования функционирования кластера. Его выполнение обычно занимает от 30 до 60 мин., в зависимости от сложности кластера; при этом выполняются тесты, перечисленные ниже. Для выполнения этих тестов вы должны иметь доступ под записью root.

Тесты общей топологии кластера

Cluster Test Tool выполняет тесты общей топологии кластера в следующем порядке:

Тесты групп ресурсов с неодновременным доступом

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

Тест групп ресурсов с одновременным доступом

Если кластер содержит одну или несколько групп ресурсов с политикой управления запуском, настроенной на подключение на всех доступных узлах (online on all available nodes, OAAN), инструмент тестирования выполняет один тест, состоящий в отключении сервера приложений и восстановлении после отказа приложения.

Тест на фатальный отказ

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

Выполнение автоматических тестов

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

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

Инструмент Cluster Test Tool выполняет заданный набор тестов, произвольным образом выбирая узлы, сети, группы ресурсов и т. д. для тестирования. В процессе тестирования инструмент тестирует различные компоненты кластера.

Для запуска автоматической процедуры тестирования:

Появится сообщение "Are you sure". Если вы еще раз нажмете Enter, запустится автоматическое тестирование.

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

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

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

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

После завершения планирования кластера и подготовки среды узлы готовы к установке HACMP.

Установка кода достаточно проста. При установке с компакт-диска следует просто использовать SMIT для установки требуемых наборов файлов. При установке из хранилища программного обеспечения можно выполнить NFS-подключение каталога, после чего использовать SMIT для установки из этого каталога. Убедитесь в том, что у вас есть лицензии на все устанавливаемые функции, такие, как Smart Assist и HACMP/XD.

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

Применить снимок кластера для конфигурирования кластера.

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

Проверьте все включенные вами уведомления об ошибках.

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

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

Резервное копирование конфигурации кластера

Основным средством резервного копирования кластера HACMP является снимок кластера. Хотя файл описания кластера системы автоматизированного планирования (Online Planning Worksheets) тоже описывает конфигурацию кластера, он менее полный, так как он не включает записи ODM.

Основной информацией, сохраненной в снимке кластера, являются данные, находящиеся в классах базы данных конфигурации HACMP (таких, как HACMPcluster, HACMPnode, HACMPnetwork, HACMPdaemons). Эта информация используется для воссоздания конфигурации кластера при применении снимка кластера.

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

Утилита создания снимков кластера сохраняет данные в двух разных файлах:

Для полного резервного копирования следует создать резервную копию (mksysb) каждого узла кластера с использованием стандартных методов. Выберите один узел для создания снимка кластера и сохраните снимок в безопасном месте в целях аварийного восстановления.

При возможности создайте снимок до создания резервной копии (mksysb) узла, чтобы он был включен в резервную копию системы.

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

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

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

В этом разделе описывается создание файла определения кластера через SMIT с последующим его использованием для создания отчета о конфигурации кластера через OLPW. Итоговый отчет имеет формат HTML и может быть просмотрен через веб-браузер.

Основные этапы создания отчета кластера следующие:

Экспорт файла определения кластера с применением SMIT

Можно создать файл определения кластера из активного кластера HACMP, после чего открыть этот файл с использованием приложения Online Planning Worksheets.

Для создания файла определения кластера из SMIT проделайте следующее:

Extended Configuration
Move cursor to desired item and press Enter.
Discover HACMP-related Information from Configured Nodes
Extended Topology Configuration
Extended Resource Configuration
Extended Cluster Service Settings
Extended Event Configuration
Extended Performance Tuning Parameters Configuration
Security and Users Configuration
Snapshot Configuration
Export Definition File for Online Planning Worksheets

Extended Verification and Synchronization
HACMP Cluster Test Tool

Создание файла определения кластера из снимка с использованием SMIT

Кроме того, файл определения кластера также можно создать из снимка кластера HACMP, после чего его можно открыть с использованием приложения Online Planning Worksheets.

Для создания файла определения кластера из снимка с применением SMIT проделайте следующее:

Создание отчета о конфигурации

Отчет о конфигурации позволяет записать информацию о состоянии конфигурации кластера в формате HTML.

Отчет содержит обзорную информацию, включающую следующее:

Отчет также содержит разделы по следующим вопросам:

Для создания отчета о конфигурации:

выберите File (Файл) > Create Report (Создать отчет);

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

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

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

Управление изменениями и проблемами

После запуска кластера начинается работа по управлению изменениями и проблемами.

Эффективные процессы управления изменениями и проблемами необходимы для обеспечения доступности кластера. В целях эффективности текущая конфигурация кластера всегда должна быть "под рукой". Можно использовать OLPW для создания html-версии конфигурации, а также (рекомендуется) схемы текущего кластера.

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

Чтобы упростить внедрение изменений в кластере, HACMP обеспечивает набор SMIT-меню C-SPOC (Cluster Single Point of Control). Всегда, когда это возможно, следует использовать меню C-SPOC для внесения изменений. Используя C-SPOC, можно вносить изменения на одном узле, после чего они распространяются на другие узлы кластера.

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

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

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

Схема кластера

Создание схемы для кластера HACMP позволяет четко представить работу кластера и помогает выявить единые точки отказа. Образец схемы кластера из двух узлов представлен на рис. 3.23.

Система автоматизированного планирования

Система автоматизированного планирования (Online Planning Worksheets, OLPW) представляет Java-версию таблиц планирования на бумаге. Используя это приложение, можно либо импортировать информацию о конфигурации HACMP из существующего кластера и отредактировать ее, либо ввести всю информацию о конфигурации вручную.

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

Следующий порядок действий представляет эффективное использование инструмента OLPW при планировании, внедрении и документировании кластера.

Запуск OLPW с компакт-диска в Windows

Запуск приложения с компакт-диска в AIX 5L

В системе AIX 5L для запуска приложения Online Planning Worksheets с компакт-диска HACMP проделайте следующее:

Установка OLPW

Установка приложения в системе AIX 5L. Установка приложения Online Planning Worksheets выполняется с установочного носителя программного обеспечения HACMP. Устанавливаемый образ приложения:

cluster.es.worksheets

Приложение Online Planning Worksheets устанавливается в каталоге /usr/es/sbin/ cluster/worksheets.

Запуск приложения OLPW из графического интерфейса AIX 5L. Выполните следующую команду:

/usr/es/sbin/cluster/worksheets/worksheets

Приложение проверяет наличие установленной требуемой версии JRE перед запуском приложения в фоновом режиме.

Установка приложения OLPW в системе Windows

Запуск приложения из системы Windows

Выполните команду worksheets.bat из командной строки либо сделайте двойной щелчок мышью по значку worksheet.jar в проводнике.

Описание главного окна

При открытии приложения Online Planning Worksheets выводится его главное окно, представленное на рис. 3.24:

Главное окно содержит две панели:

Информация о конфигурации вводится в правой панели.

Создание нового файла описания кластера

В начале планирования кластера можно либо ввести всю информацию вручную, либо считать информацию о конфигурации кластера в OLPW, после чего ввести остальную информацию вручную.

Для создания файла определения кластера проделайте следующее:

Открытие существующего файла определения кластера

Чтобы открыть файл определения кластера, выберите File (Файл) > Open (Открыть). Одновременно можно открыть только один файл определения кластера.

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

Добавление примечаний о конфигурации кластера

При планировании конфигурации в файл определения кластера можно добавлять примечания. Для этого:

Сохранение файла определения кластера

Это можно сделать двумя способами:

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

Утилита cl_opsconfig выполняет проверку файла (если приложение Online Planning Worksheets установлено локально), применяет информацию в кластере, выполняет синхронизацию и верификацию. Во время верификации на экран выводятся сообщения о возникающих событиях, а также предупреждения и ошибки. Сообщения об ошибках cl_opsconfig можно просматривать на экране либо перенаправлять в файл журнала.

Перенаправление стандартного потока вывода сообщений об ошибках осуществляется следующим образом (в оболочке korn shell; в других оболочках могут быть отличия):

/usr/sbin/cluster/utilities/cl_opsconfig 
  your_config_file 2> output_file

Таблицы планирования на бумаге

Подробно таблицы планирования на бумаге представлены в прил. "А" в руководстве HACMP 5.3 Planning and Installation Guide.

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