Реализация мультипроцессорных кластеров высокой доступности (HACMP)

Сетевые функции

Разбить на страницы
Показывать лекцию целиком

Etherchannel

EtherChannel (EC) представляет собой метод агрегирования портов, при котором до восьми Ethernet-адаптеров определяются как один EtherChannel. Удаленные системы видят EtherChannel как один IP- и MAC-адрес, в результате при использовании одной сети пропускная способность потенциально может быть увеличена в восемь раз.

Трафик распределяется между адаптерами стандартным способом (адресный алгоритм – address algorithm) или на основе циклического (round robin) обслуживания. При отказе адаптера трафик автоматически пересылается на следующий доступный адаптер в EtherChannel, не нарушая пользовательские подключения. Если активно только одно подключение в основном EtherChannel, тест на отказ начинает немедленное обнаружение/перемещение (в течение 2-4 с) на требуемый резервный адаптер без нарушения пользовательских подключений. Возможно проведение двух тестов: на отказ физической связи адаптера с сетью и на отказ TCP/IP-пути к узлу, заданному пользователем. При обнаружении отказа на резервном адаптере активизируются MAC- и IP-адреса. При восстановлении хотя бы одного адаптера в основном канале происходит повторная активизация адресов в основном канале.

Режим конфигурации Network Interface Backup (NIB), реализованный в AIX V5.1, был заменен и усовершенствован в AIX V5.2. Новый метод состоит в использовании одного адаптера EtherChannel с резервным адаптером, обеспечивая приоритет (возврат после восстановления связи) между основными и резервными каналами, что в предыдущей версии не было реализовано. Усовершенствование функции динамического членства адаптеров (dynamic adapter membership, DAM) в AIX V 5.2 позволяют осуществлять динамическое реконфигурирование адаптеров в EtherChannel без нарушения работающего подключения.

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

Все адаптеры, состоящие из нескольких каналов, требуют использования специальной конфигурации порта EtherChannel или IEEE 802.3ad в сетевом коммутаторе. В большинстве случаев коммутатор настраивается для применения в режиме EtherChannel. Однако если коммутатор не поддерживает EC или если корпорация в качестве стандарта использует IEEE 802.3ad, то следует сконфигурировать 802.3ad и в коммутаторе и в AIX. С другой стороны, подключения с одним адаптером не требуют специального конфигурирования на уровне сетевого коммутатора. Это включает EtherChannel с одним адаптером и подключение резервного адаптера.

EtherChannel имеет следующие преимущества:

  • Более высокая пропускная способность и возможности балансировки нагрузки:
  • Каналы с несколькими адаптерами агрегируют пропускную способность.
  • Возможность использования нескольких вариантов направления трафика че рез адаптеры канала, настраиваемых пользователем.
    •
  • Встроенные функции обеспечения доступности:
  • Автоматическая обработка отказов адаптера, связей и сети.
  • Использование резервного адаптера для устранения единой точки отказа (single point of failure, SPOF) на уровне коммутатора сети. (Необязательно).
  • Методы проектирования для устранения единых точек отказа.
  • Простое, гибкое решение и возможности масштабирования:
  • Один MAC- и IP-адрес Ethernet для всей агрегированной конфигурации (вклю чая резервный адаптер).
  • Легко приспосабливается к будущим требованиям к пропускной способности.
  • Пользователь может добавлять, удалять и реконфигурировать адаптеры дина мически (не прерывая обслуживания).
  • Несколько вариантов взаимодействия с сетевым коммутатором;
  • Каналы с несколькими адаптерами для коммутаторов с поддержкой EtherChannel и 802.3ad.
  • Каналы с одним адаптером и резервные связи адаптеров прозрачны для сете вого коммутатора.
  • Опция подключения резервного адаптера канала (к другому сетевому комму татору, чтобы избежать единой точки отказа).
  • При прямой связи двух систем канал работает без коммутатора (напрямую; однако в среде HACMP это неприменимо).
  • Эта технология является бесплатной (при условии, что у вас уже установлены коммутаторы с поддержкой EC). Включена в AIX и регулярно улучшается, начиная с версии AIX v4.3.3.

    • Реализация EtherChannel в среде HACMP

    HACMP официально поддерживает использование EtherChannel. Заявление о поддержке можно найти по адресу http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10284

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

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

    Следующая информация основана на предыдущей статье, посвященной комбинации этих технологий, вышедшей в мае 2004 г., однако все еще актуальной в настоящее время. Оригинальную версию этого документа можно найти по адресу http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD101785

    Конфигурация тестовой среды

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

  • две системы pSeries p630 (с именами neo и trinity);
  • AIX V5.2 ML3;
  • HACMP V5.1;
  • сетевые подключения Ethernet ent0 – ent6:
  • ent0 и ent5 (не используется) представляют интегрированные адаптеры 10/100;
  • ent1, ent2, ent3, ent4 (не используется) представляют единый 4-портовый адап тер 10/100;
  • ent6 – EtherChannel (состоит из ent2, ent3 и ent0);
  • три кроссоверных кабеля UTP Ethernet.
    •

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

    В этом тесте мы успешно реализовали "сеть с одним адаптером", использующую перехват IP-адреса (IP Address Takeover, IPAT) с функцией EtherChannel, включенной в AIX V 5.2. EtherChannel отвечает за переключение локального адаптера, расположенного за пределами HACMP. HACMP не знает о существовании EtherChannel и полностью независим. Хотя сеть с одним адаптером не является идеальным вариантом, в EtherChannel ее использование считается нормальным, так как в действительности одно псевдоустройство EtherChannel содержит несколько физических адаптеров.

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

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

    (рис 14.1) Тестовая среда Etherchannel и HACMP

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

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

    Процедуры конфигурирования

    Перечислим основные этапы настройки кластера. Подробное описание каждого этапа для системы neo приведено ниже.

  • Проверка конфигурации адаптера Ethernet и кабелей адаптера.
  • Создание интерфейса EtherChannel.
  • Конфигурирование IP-адресов на новом интерфейсе (en6) через TCP/IP.
  • Добавление загрузочных и сервисных IP-адресов в топологию HACMP.
  • Создание группы ресурсов и назначение ей сервисного IP-адреса.
  • Синхронизация кластера.
  • Запуск служб кластера.
  • Тестирование избыточности NIC и проверка того, что HACMP не детектирует сбоев.
    •

    В начале у нас должны быть несконфигурированные адаптеры, желательно подключенные к коммутатору с поддержкой EC, где коммутатор уже настроен на конфигурацию EC. Наши адаптеры были предварительно сконфигурированы, так что мы удалили определения интерфейсов в ODM с использованием команды smitty inet. Мы выполнили эти основные действия на обеих системах, применяя IP-интерфейсы и IP-адреса, представленные на рис. 14.1.

    Этап 1. Проверка конфигурации адаптера Ethernet

    Адаптеры, которые планируется использовать в EtherChannel, должны быть настроены на одинаковую скорость и дуплексный режим. Мы настроили ent0, ent2 и ent3 на 100 Мбит/с и полный дуплекс через экран smitty eadap -> Change/Show Characteristics of an Ethernet Adapter (Изменить/показать свойства адаптера Ethernet), представленный на рис. 14.2.

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

    Этап 2. Конфигурирование Etherchannel

    Следует выполнить конфигурирование EtherChannel через быстрый путь smitty etherchannel -> Add an Etherchannel/Link Aggregation (Добавить Etherchannel/ Агрегирование связей) и выбрать требуемые адаптеры, нажав клавишу F7. В нашей конфигурации ent2 и ent3 составляют основной канал, тогда как ent0 представляет резервный адаптер. При работе со следующим меню, представленном на рис. 14.3, происходит создание нового интерфейса EtherChannel (ent6).

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

    Важно! При использовании одного интерфейса с одним резервным адаптером (в прежних версиях – network interface backup или NIB) и указании значений параметров Number of Retries (Количество попыток) и Retry Timeout (Тайм-аут попыток) убедитесь в том, что они не превышают параметры скорости обнаружения отказов в NIM. Рекомендуется, чтобы значения этих параметров составляли как минимум половину значений параметров в HACMP. (рис 14.3) Меню добавления Etherchannel

    Этап 3. Конфигурирование IP на устройстве Etherchannel

    Следует выполнить конфигурирование IP-интерфейса (en6) в EtherChannel, используя быстрый путь smitty chinet -> выбрать en6, как показано на рис. 14.4.

    Мы повторили эту процедуру на узле trinity, применяя IP-адрес 2.2.2.2.

    Примечание. Помните, что выполнение команд TCP/IP следует осуществлять для нового псевдоинтерфейса (en6), а не для отдельных интерфейсов.

    Этап 4. Конфигурирование топологии HACMP

    При тестировании мы решили использовать IP-синонимы для определения сети HACMP (channet). Мы настроили наши загрузочные IP-адреса на каждом устройстве EtherChannel (neo_boot 2.2.2.1, trinity_boot 2.2.2.2). Затем мы определили свой сервисный IP-адрес (привязанный к нескольким узлам) 192.168.43.4 и постоянные IP-адреса 192.168.43.10 для neo и 192.168.43.20 для trinity. Наша конфигурация топологии представлена на рис. 14.5 в выходных данных команды cllsif.

    (рис 14.5) Конфигурирование IP на устройстве EtherChannel(рис 14.4) Конфигурация EtherChannel в выходных данных команды cllsif

    Этап 5. Конфигурирование группы ресурсов HACMP

    Мы сконфигурировали одну каскадную группу ресурсов с одной сервисной IPметкой. Так как наша цель состояла в тестировании избыточности NIC, мы упростили конфигурацию, опустив дополнительные ресурсы в группе ресурсов. Определение нашей группы ресурсов представлено на рис. 14.6.

    Примечание. Хотя в нашем примере это опущено, в рабочей среде необходимо использовать как минимум одну последовательную сеть, отличную от IP. (рис 14.6) Группа ресурсов Etherchannel

    Этап 6. Синхронизация кластера

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

    (рис 14.7) Предупреждение при конфигурировании сети с одним адаптером

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

    Важно. При реализации подобной конфигурации сети с одним адаптером для корректного определения сети HACMP необходимо выполнить конфигурирование файла netmon.cf. Дополнительные сведения см. в разделе "Общее представление о файле netmon.cf".

    Этап 7. Запуск служб кластера

    Следует выполнить smitty clstart на каждом узле и подождать события node_ up_complete.

    Этап 8. Тестирование

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

  • Мы отключили кабель из ent3. В результате произошла передача обслуживания на ent2. Это было проверено командами netstat и entstat, а также выполнением pingопросов с клиента. AIX регистрирует это в отчете об ошибках. Однако HACMP не знает о возникновении отказа. Ошибки из отчета об ошибках представлены на рис 14.8(рис 14.8) Ошибки Etherchannel в отчете об ошибках AIX
  • Мы отключили кабель из ent2. Это вызвало перехват обслуживания дежурным адаптером ent0. Как и в первом тесте, AIX зарегистрировал отказ в отчете об ошибках, однако в HACMP отказ не был замечен. Так как мы использовали кроссоверные кабели, этот отказ имел двойное действие, вызывая подобные ошибки и переключения на обоих узлах.
  • Затем мы отключили кабель из последнего работающего адаптера ent0. Это, в свою очередь, вызвало полный отказ EtherChannel, что было зарегистрировано в HACMP как отказ сети.
    •

    Выводы по поводу технологии EtherChannel

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

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

    Варианты размещения сервисных IP-синонимов

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

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

    Существует четыре различных политики размещения:

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

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

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

  • Введите smit hacmp.
  • В SMIT выберите Extended Configuration (Расширенное конфигурирование) > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > HACMP Extended Resources Configuration (Расширенное конфигурирование ресурсов HACMP) > Configure Resource Distribution Preferences (Конфигурирование вариантовразмещения ресурсов) > Configure Service IP labels/addresses Distribution Preferences (Конфигурирование вариантов размещения сервисных IP-меток/адресов) и нажмите Enter. HACMP выводит только сети, использующие перехват IP-адресов посредством синонимов.
  • Выберите сеть, для которой требуется задать политику, и нажмите Enter.
  • На экране Configure Service IP Labels/Address Distribution Preference (Конфигурирование вариантов размещения сервисных IP-меток/адресов) выберите требуемый вариант размещения.
  • Нажмите Enter, чтобы принять выбранные значения и обновить ODM HACMP на локальном узле.
  • Для того чтобы изменения вступили в действие и были распространены на все узлы, требуется выполнить синхронизацию кластера. Перейдите в меню Initialization and Standard Configuration (Инициализация и стандартное конфигурирование) или Extended Configuration (Расширенное конфигурирование) и выберите Verification and Synchronization (Верификация и синхронизация). Это инициирует событие динамической реконфигурации.
    •  Примечание. При конфигурировании политики размещения сервисных IP-адресов мы получили следующие сообщения: cldare: Detected changes to service IP label app1svc. Please note that changing parameters of service IP label via a DARE may result in releasing resource group <name>

    Просмотр варианта размещения сервисных IP-меток

    У вас должна быть возможность выводить текущий вариант размещения для каждой сети с использованием команд cltopinfo или cllsnw.

    Выходные данные команды cltopinfo -w имеют следующий вид:

    # /usr/es/sbin/cluster/utilities/cltopinfo -w
NODE cobra:
Network net_diskhb_01
cobra_vpath0 /dev/vpath0
Network net_ether_01
app1svc 192.168.100.83
app2svc 192.168.100.82
cobraa 10.10.31.33
cobrab 10.10.32.33
NODE viper:
Network net_diskhb_01
viper_vpath0 /dev/vpath0
Network net_ether_01
app1svc 192.168.100.83
app2svc 192.168.100.82
viperb 10.10.32.32
vipera 10.10.31.32
Network net_ether_01 is using the following
 distribution preference for service labels:
Collocation with persistent - service label(s) 
will be mapped to the same
interface as the persistent label

    Ниже приведен пример выходных данных команды cllsnw -c, выводящей вариант размещения сервисной метки (service label distribution preference, sldp) для определенной сети.

    #/usr/es/sbin/cluster/utilities/cllsnw -c
#netname:attr:alias:monitor_method:sldp:
net_ether_01:public:true:default:ppstest::
 sldp_collocation_with_persistent

    Эксперименты с политикой размещения сервисных меток

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

    python-# more /etc/hosts
10.10.31.31 pythona # base address 1
10.10.32.31 pythonb # base address 2
192.168.100.31 p630n01 n1 # python persistent address
192.168.100.82 app1svc # cobra service address
192.168.100.83 app2svc # viper service address
python-# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en0 1500 link#2 0.2.55.4f.c4.ab 5044669 0 1828909 0 0
en0 1500 10.10.31 pythona 5044669 0 1828909 0 0
en0 1500 192.168.100 p630n01 5044669 0 1828909 0 0
en0 1500 192.168.100 app1svc 5044669 0 1828909 0 0
en0 1500 192.168.100 app2svc 5044669 0 1828909 0 0
en3 1500 link#3 0.20.35.e2.7f.8d 3191047 0 1410806 0 0
en3 1500 10.10.32 pythonb 3191047 0 1410806 0 0
lo0 16896 link#1 1952676 0 1957548 0 0
lo0 16896 127 localhost 1952676 0 1957548 0 0
lo0 16896 localhost 1952676 0 1957548 0 0
    Примечание. В представленных выше выходных данных узел python имел группы ресурсов для узлов cobra и viper, а также соответствующие сервисные IP-адреса. Была установлена политика распределения Collocation with persistent (С совместным размещением и с постоянной меткой).

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

    Verifying additional pre-requisites for Dynamic Reconfiguration...
cldare: Detected changes to service IP label app1svc. Please note that changing
parameters of service IP label via a DARE may result in releasing resource group
APP1_RG .
cldare: Detected changes to service IP label app2svc. Please note that changing
parameters of service IP label via a DARE may result in releasing resource group
APP2_RG .
    Примечание. В данном случае зарегистрированное сообщение является обычным, и выдается только потому, что было обнаружено изменение. Если это изменение является единственным, отключения ресурсов не произойдет.

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

    Общее представление о файле netmon.cf

    В HACMP можно создать файл конфигурации netmon.cf со списком дополнительных сетевых адресов. Эти адреса используются только для отправления ECHO-запросов ICMP службами топологии в целях определения состояния адаптера при определенных обстоятельствах.

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

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

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

    Создание файла netmon.cf

    Файл netmon.cf должен находиться в каталоге /usr/es/sbin/cluster на всех узлах кластера.

    Требования к созданию файла:

  • Файл должен содержать по одному IP-адресу или IP-метке на кабель.
  • Файл должен содержать удаленные IP-метки/адреса, не входящие в конфигурацию кластера, к которым можно получить доступ через интерфейсы HACMP. Мы рекомендуем использовать IP-адрес маршрутизатора.
  • В файле netmon.cf может быть определено не более 30 IP-адресов/меток.
  • Включите все IP-адреса и соответствующие им метки в файл /etc/hosts.
    •  Примечание. Когда процесс NIM (из служб топологии RSCT) пытается определить состояние локальных адаптеров, он может попытаться использовать разрешение имен хостов. Если IP-адрес и соответствующая метка не записаны в файле /etc/ hosts, то при возникновении проблемы или при задержке при попытке разрешения адреса может быть продлено общее время обнаружения отказа, что замедляет операции перемещения при сбое.

    Содержание файла netmon.cf может иметь примерно следующий вид:

    /usr/es/sbin/cluster/netmon.cf
192.168.100.76
p690_1_lpar3
192.168.100.35
router_lan1
/etc/hosts (corresponding entries)
192.168.100.76 node365 #client node running oracle
192.168.100.21 p690_1_lpar3 #client node hosting application 4
192.168.100.35 node367 #client node running db2
192.168.100.200 router_lan1 #router hosting production lan

    Рекомендации и дополнительные замечания

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

    Другие сценарии могут включать среды с использованием одного логического интерфейса EtherChannel, состоящего из нескольких связей Ethernet. В такой среде происходит прозрачная обработка отказов связей логикой EtherChannel, однако полный отказ канала приводит к возникновению проблем в случае, если службы топологии не имеют файла netmon.cf. Реализация EtherChannel в среде HACMP подробно описывается в разделе "Etherchannel".

    Общее представление о файле clhosts

    Файл clhosts содержит информацию об IP-адресах, позволяющую установить связь между демонами мониторинга на клиентах и на узлах кластера HACMP. К инструментам, использующим этот файл, относятся: clinfoES, HAView и clstat. Файл находится на всех серверах и клиентах кластера HACMP в каталоге /usr/es/sbin/cluster/etc/.

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

    127.0.0.1 # HACMP/ES for AIX

    Создание файла clhosts

    В предыдущих версиях требовалось вручную создавать и обслуживать клиентский файл clhosts. В HACMP 5.3 можно автоматически генерировать файл clhosts, требуемый клиентами при выполнении верификации с включенной функцией автоматического исправления ошибок. При верификации на всех узлах кластера создается файл /usr/es/sbin/cluster/etc/clhosts.client.

    Этот файл будет иметь приблизительно следующий вид:

    # /usr/es/sbin/cluster/etc/clhosts.client Created by 
 HACMP Verification / Synchronization
Corrective Actions
# Date Created: 07/01/2005 at 12:45:29
192.168.100.102 #dlpar_app2_svc
192.168.100.101 #dlpar_app1_svc
192.168.202.204 #alexis_base1
192.168.202.205 #alexis_base2
192.168.100.61 #alexis
192.168.201.203 #jessica_base2
192.168.201.202 #jessica_base1
192.168.100.72 #jessica
192.168.200.200 #jordan_base1
192.168.200.201 #jordan_base2
192.168.100.71 #jordan

    Обратите внимание на то, что указаны все адреса, включая загрузочную, сервисную и постоянную IP-метки. Перед использованием любой из утилит мониторинга с клиентского узла должно выполняться копирование файла clhosts.client на все клиенты в каталог /usr/es/sbin/cluster/etc/clhosts. Не забудьте удалить расширение .client при копировании файла на клиентские узлы.

    Важно! Файл clhosts на клиенте не должен содержать 127.0.0.1, loopback или localhost.

    Clstat на клиенте и файл clhosts

    При запуске утилиты clstat с клиента демон clinfoES получает информацию о состоянии кластера от SNMP на стороне сервера и заполняет MIB HACMP на стороне клиента. Она не сможет вести обмен данными с демоном и сообщит о том, что она не может найти кластеры при отсутствии файла clhosts.

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

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

    HAView и файл clhosts

    HAView выполняет мониторинг состояния кластера в топологии сети, используя информацию кластера в файле /usr/es/sbin/cluster/etc/clhosts. Он должен существовать на управляющем узле Tivoli NetView. Убедитесь в том, что имя хоста и сервисная метка узлов Tivoli NetView полностью одинаковы (если они неодинаковы, следует добавить синоним в файл /etc/hosts, чтобы устранить различия в именах). Если файл clhosts содержит недопустимый IP-адрес, HAView не сможет выполнить мониторинг кластера. Убедитесь в том, что применяются допустимые IP-адреса и что файл не содержит посторонних символов.

    Общее представление о файле clinfo.rc

    HACMP может быть настроен на изменение MAC-адреса сетевого интерфейса путем реализации перехвата аппаратного адреса (hardware address takeover, HWAT). В коммутируемой сетевой среде Ethernet коммутатор может не всегда получать своевременную информацию о новом MAC-адресе. В результате коммутатор не сможет направлять требуемые пакеты на сетевой интерфейс.

    Скрипт clinfo.rc используется HACMP для очистки ARP-кеша в системе, чтобы отразить изменения в сетевых IP-адресах. Он не обновляет кеш до тех пор, пока другой адрес не ответит на ping-запрос. Обычно при включенной функции переключения аппаратных адресов в HACMP очистка ARP-кеша необязательна. Это связано с тем, что функция переключения аппаратных адресов устанавливает связь между IP-адресом и аппаратным адресом.

    Примечание. HWAT поддерживается в HACMP только при использовании перехвата IP-адресов посредством замены (IPAT via replacement).

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

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

    ping -c1 $host
    Примечание. Подразумевается, что клиент подключен напрямую к одной из сетей кластера.

    Конфигурирование файла clinfo.rc

    Чтобы убедиться в том, что новый MAC-адрес передан коммутатору, нужно выполнить следующие действия:

  • Измените строку файла /usr/es/sbin/cluster/etc/clinfo.rc, которая на данный момент выглядит следующим образом:
    PING_CLIENT_LIST=" "
  • Включите в эту строку имена или IP-адреса как минимум одного клиента из каждой подсети в коммутируемой сети Ethernet.
  • Запустите clinfoES на всех узлах в кластере HACMP, подключенных к коммутируемой сети Ethernet.
    •

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

  • если вы обычно запускаете службы кластера HACMP, используя shell-скрипт /usr/ es/sbin/cluster/etc/rc.cluster, укажите опцию -i ;
  • если вы обычно запускаете службы кластера HACMP через SMIT, укажите Yes в поле Start Cluster Information Daemon? (Запускать демон информации кластера?);
  • копия скрипта /usr/es/sbin/cluster/etc/clinfo.rc должна существовать на всех серверах и клиентах в кластере, чтобы обеспечить обновление всех ARP-кешей.
    •

    Принцип работы clinfo и clinfo.rc

    Вызов clinfo.rc из clinfo имеет следующий формат:

    clinfo.rc {join,fail,swap} interface_name

    Clinfo получает информацию об интерфейсах и их текущем состоянии и выполняет проверку на изменение состояния интерфейсов:

  • при состоянии UP Clinfo вызывает clinfo.rc join interface_name ;
  • при состоянии DOWN Clinfo вызывает clinfo.rc fail interface_name ;
  • при получении события node_down_complete Clinfo вызывает clinfo.rc с параметром fail для всех интерфейсов, находящихся в состоянии UP;
  • при получении события fail_network_complete Clinfo вызывает clinfo.rc с параметром fail для всех соответствующих интерфейсов;
  • при получении события swap_complete Clinfo вызывает clinfo.rc swap interface_ name.
    •
    Страницы:

    Etherchannel

    EtherChannel (EC) представляет собой метод агрегирования портов, при котором до восьми Ethernet-адаптеров определяются как один EtherChannel. Удаленные системы видят EtherChannel как один IP- и MAC-адрес, в результате при использовании одной сети пропускная способность потенциально может быть увеличена в восемь раз.

    Трафик распределяется между адаптерами стандартным способом (адресный алгоритм – address algorithm) или на основе циклического (round robin) обслуживания. При отказе адаптера трафик автоматически пересылается на следующий доступный адаптер в EtherChannel, не нарушая пользовательские подключения. Если активно только одно подключение в основном EtherChannel, тест на отказ начинает немедленное обнаружение/перемещение (в течение 2-4 с) на требуемый резервный адаптер без нарушения пользовательских подключений. Возможно проведение двух тестов: на отказ физической связи адаптера с сетью и на отказ TCP/IP-пути к узлу, заданному пользователем. При обнаружении отказа на резервном адаптере активизируются MAC- и IP-адреса. При восстановлении хотя бы одного адаптера в основном канале происходит повторная активизация адресов в основном канале.

    Режим конфигурации Network Interface Backup (NIB), реализованный в AIX V5.1, был заменен и усовершенствован в AIX V5.2. Новый метод состоит в использовании одного адаптера EtherChannel с резервным адаптером, обеспечивая приоритет (возврат после восстановления связи) между основными и резервными каналами, что в предыдущей версии не было реализовано. Усовершенствование функции динамического членства адаптеров (dynamic adapter membership, DAM) в AIX V 5.2 позволяют осуществлять динамическое реконфигурирование адаптеров в EtherChannel без нарушения работающего подключения.

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

    Все адаптеры, состоящие из нескольких каналов, требуют использования специальной конфигурации порта EtherChannel или IEEE 802.3ad в сетевом коммутаторе. В большинстве случаев коммутатор настраивается для применения в режиме EtherChannel. Однако если коммутатор не поддерживает EC или если корпорация в качестве стандарта использует IEEE 802.3ad, то следует сконфигурировать 802.3ad и в коммутаторе и в AIX. С другой стороны, подключения с одним адаптером не требуют специального конфигурирования на уровне сетевого коммутатора. Это включает EtherChannel с одним адаптером и подключение резервного адаптера.

    EtherChannel имеет следующие преимущества:

  • Более высокая пропускная способность и возможности балансировки нагрузки:
  • Каналы с несколькими адаптерами агрегируют пропускную способность.
  • Возможность использования нескольких вариантов направления трафика че рез адаптеры канала, настраиваемых пользователем.
    •
  • Встроенные функции обеспечения доступности:
  • Автоматическая обработка отказов адаптера, связей и сети.
  • Использование резервного адаптера для устранения единой точки отказа (single point of failure, SPOF) на уровне коммутатора сети. (Необязательно).
  • Методы проектирования для устранения единых точек отказа.
  • Простое, гибкое решение и возможности масштабирования:
  • Один MAC- и IP-адрес Ethernet для всей агрегированной конфигурации (вклю чая резервный адаптер).
  • Легко приспосабливается к будущим требованиям к пропускной способности.
  • Пользователь может добавлять, удалять и реконфигурировать адаптеры дина мически (не прерывая обслуживания).
  • Несколько вариантов взаимодействия с сетевым коммутатором;
  • Каналы с несколькими адаптерами для коммутаторов с поддержкой EtherChannel и 802.3ad.
  • Каналы с одним адаптером и резервные связи адаптеров прозрачны для сете вого коммутатора.
  • Опция подключения резервного адаптера канала (к другому сетевому комму татору, чтобы избежать единой точки отказа).
  • При прямой связи двух систем канал работает без коммутатора (напрямую; однако в среде HACMP это неприменимо).
  • Эта технология является бесплатной (при условии, что у вас уже установлены коммутаторы с поддержкой EC). Включена в AIX и регулярно улучшается, начиная с версии AIX v4.3.3.

    • Реализация EtherChannel в среде HACMP

    HACMP официально поддерживает использование EtherChannel. Заявление о поддержке можно найти по адресу http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10284

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

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

    Следующая информация основана на предыдущей статье, посвященной комбинации этих технологий, вышедшей в мае 2004 г., однако все еще актуальной в настоящее время. Оригинальную версию этого документа можно найти по адресу http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD101785

    Конфигурация тестовой среды

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

  • две системы pSeries p630 (с именами neo и trinity);
  • AIX V5.2 ML3;
  • HACMP V5.1;
  • сетевые подключения Ethernet ent0 – ent6:
  • ent0 и ent5 (не используется) представляют интегрированные адаптеры 10/100;
  • ent1, ent2, ent3, ent4 (не используется) представляют единый 4-портовый адап тер 10/100;
  • ent6 – EtherChannel (состоит из ent2, ent3 и ent0);
  • три кроссоверных кабеля UTP Ethernet.
    •

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

    В этом тесте мы успешно реализовали "сеть с одним адаптером", использующую перехват IP-адреса (IP Address Takeover, IPAT) с функцией EtherChannel, включенной в AIX V 5.2. EtherChannel отвечает за переключение локального адаптера, расположенного за пределами HACMP. HACMP не знает о существовании EtherChannel и полностью независим. Хотя сеть с одним адаптером не является идеальным вариантом, в EtherChannel ее использование считается нормальным, так как в действительности одно псевдоустройство EtherChannel содержит несколько физических адаптеров.

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

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

    (рис 14.1) Тестовая среда Etherchannel и HACMP

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

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

    Процедуры конфигурирования

    Перечислим основные этапы настройки кластера. Подробное описание каждого этапа для системы neo приведено ниже.

  • Проверка конфигурации адаптера Ethernet и кабелей адаптера.
  • Создание интерфейса EtherChannel.
  • Конфигурирование IP-адресов на новом интерфейсе (en6) через TCP/IP.
  • Добавление загрузочных и сервисных IP-адресов в топологию HACMP.
  • Создание группы ресурсов и назначение ей сервисного IP-адреса.
  • Синхронизация кластера.
  • Запуск служб кластера.
  • Тестирование избыточности NIC и проверка того, что HACMP не детектирует сбоев.
    •

    В начале у нас должны быть несконфигурированные адаптеры, желательно подключенные к коммутатору с поддержкой EC, где коммутатор уже настроен на конфигурацию EC. Наши адаптеры были предварительно сконфигурированы, так что мы удалили определения интерфейсов в ODM с использованием команды smitty inet. Мы выполнили эти основные действия на обеих системах, применяя IP-интерфейсы и IP-адреса, представленные на рис. 14.1.

    Этап 1. Проверка конфигурации адаптера Ethernet

    Адаптеры, которые планируется использовать в EtherChannel, должны быть настроены на одинаковую скорость и дуплексный режим. Мы настроили ent0, ent2 и ent3 на 100 Мбит/с и полный дуплекс через экран smitty eadap -> Change/Show Characteristics of an Ethernet Adapter (Изменить/показать свойства адаптера Ethernet), представленный на рис. 14.2.

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

    Этап 2. Конфигурирование Etherchannel

    Следует выполнить конфигурирование EtherChannel через быстрый путь smitty etherchannel -> Add an Etherchannel/Link Aggregation (Добавить Etherchannel/ Агрегирование связей) и выбрать требуемые адаптеры, нажав клавишу F7. В нашей конфигурации ent2 и ent3 составляют основной канал, тогда как ent0 представляет резервный адаптер. При работе со следующим меню, представленном на рис. 14.3, происходит создание нового интерфейса EtherChannel (ent6).

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

    Важно! При использовании одного интерфейса с одним резервным адаптером (в прежних версиях – network interface backup или NIB) и указании значений параметров Number of Retries (Количество попыток) и Retry Timeout (Тайм-аут попыток) убедитесь в том, что они не превышают параметры скорости обнаружения отказов в NIM. Рекомендуется, чтобы значения этих параметров составляли как минимум половину значений параметров в HACMP. (рис 14.3) Меню добавления Etherchannel

    Этап 3. Конфигурирование IP на устройстве Etherchannel

    Следует выполнить конфигурирование IP-интерфейса (en6) в EtherChannel, используя быстрый путь smitty chinet -> выбрать en6, как показано на рис. 14.4.

    Мы повторили эту процедуру на узле trinity, применяя IP-адрес 2.2.2.2.

    Примечание. Помните, что выполнение команд TCP/IP следует осуществлять для нового псевдоинтерфейса (en6), а не для отдельных интерфейсов.

    Этап 4. Конфигурирование топологии HACMP

    При тестировании мы решили использовать IP-синонимы для определения сети HACMP (channet). Мы настроили наши загрузочные IP-адреса на каждом устройстве EtherChannel (neo_boot 2.2.2.1, trinity_boot 2.2.2.2). Затем мы определили свой сервисный IP-адрес (привязанный к нескольким узлам) 192.168.43.4 и постоянные IP-адреса 192.168.43.10 для neo и 192.168.43.20 для trinity. Наша конфигурация топологии представлена на рис. 14.5 в выходных данных команды cllsif.

    (рис 14.5) Конфигурирование IP на устройстве EtherChannel(рис 14.4) Конфигурация EtherChannel в выходных данных команды cllsif

    Этап 5. Конфигурирование группы ресурсов HACMP

    Мы сконфигурировали одну каскадную группу ресурсов с одной сервисной IPметкой. Так как наша цель состояла в тестировании избыточности NIC, мы упростили конфигурацию, опустив дополнительные ресурсы в группе ресурсов. Определение нашей группы ресурсов представлено на рис. 14.6.

    Примечание. Хотя в нашем примере это опущено, в рабочей среде необходимо использовать как минимум одну последовательную сеть, отличную от IP. (рис 14.6) Группа ресурсов Etherchannel

    Этап 6. Синхронизация кластера

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

    (рис 14.7) Предупреждение при конфигурировании сети с одним адаптером

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

    Важно. При реализации подобной конфигурации сети с одним адаптером для корректного определения сети HACMP необходимо выполнить конфигурирование файла netmon.cf. Дополнительные сведения см. в разделе "Общее представление о файле netmon.cf".

    Этап 7. Запуск служб кластера

    Следует выполнить smitty clstart на каждом узле и подождать события node_ up_complete.

    Этап 8. Тестирование

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

  • Мы отключили кабель из ent3. В результате произошла передача обслуживания на ent2. Это было проверено командами netstat и entstat, а также выполнением pingопросов с клиента. AIX регистрирует это в отчете об ошибках. Однако HACMP не знает о возникновении отказа. Ошибки из отчета об ошибках представлены на рис 14.8(рис 14.8) Ошибки Etherchannel в отчете об ошибках AIX
  • Мы отключили кабель из ent2. Это вызвало перехват обслуживания дежурным адаптером ent0. Как и в первом тесте, AIX зарегистрировал отказ в отчете об ошибках, однако в HACMP отказ не был замечен. Так как мы использовали кроссоверные кабели, этот отказ имел двойное действие, вызывая подобные ошибки и переключения на обоих узлах.
  • Затем мы отключили кабель из последнего работающего адаптера ent0. Это, в свою очередь, вызвало полный отказ EtherChannel, что было зарегистрировано в HACMP как отказ сети.
    •

    Выводы по поводу технологии EtherChannel

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

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

    Варианты размещения сервисных IP-синонимов

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

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

    Существует четыре различных политики размещения:

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

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

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

  • Введите smit hacmp.
  • В SMIT выберите Extended Configuration (Расширенное конфигурирование) > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > HACMP Extended Resources Configuration (Расширенное конфигурирование ресурсов HACMP) > Configure Resource Distribution Preferences (Конфигурирование вариантовразмещения ресурсов) > Configure Service IP labels/addresses Distribution Preferences (Конфигурирование вариантов размещения сервисных IP-меток/адресов) и нажмите Enter. HACMP выводит только сети, использующие перехват IP-адресов посредством синонимов.
  • Выберите сеть, для которой требуется задать политику, и нажмите Enter.
  • На экране Configure Service IP Labels/Address Distribution Preference (Конфигурирование вариантов размещения сервисных IP-меток/адресов) выберите требуемый вариант размещения.
  • Нажмите Enter, чтобы принять выбранные значения и обновить ODM HACMP на локальном узле.
  • Для того чтобы изменения вступили в действие и были распространены на все узлы, требуется выполнить синхронизацию кластера. Перейдите в меню Initialization and Standard Configuration (Инициализация и стандартное конфигурирование) или Extended Configuration (Расширенное конфигурирование) и выберите Verification and Synchronization (Верификация и синхронизация). Это инициирует событие динамической реконфигурации.
    •  Примечание. При конфигурировании политики размещения сервисных IP-адресов мы получили следующие сообщения: cldare: Detected changes to service IP label app1svc. Please note that changing parameters of service IP label via a DARE may result in releasing resource group <name>

    Просмотр варианта размещения сервисных IP-меток

    У вас должна быть возможность выводить текущий вариант размещения для каждой сети с использованием команд cltopinfo или cllsnw.

    Выходные данные команды cltopinfo -w имеют следующий вид:

    # /usr/es/sbin/cluster/utilities/cltopinfo -w
NODE cobra:
Network net_diskhb_01
cobra_vpath0 /dev/vpath0
Network net_ether_01
app1svc 192.168.100.83
app2svc 192.168.100.82
cobraa 10.10.31.33
cobrab 10.10.32.33
NODE viper:
Network net_diskhb_01
viper_vpath0 /dev/vpath0
Network net_ether_01
app1svc 192.168.100.83
app2svc 192.168.100.82
viperb 10.10.32.32
vipera 10.10.31.32
Network net_ether_01 is using the following
 distribution preference for service labels:
Collocation with persistent - service label(s) 
will be mapped to the same
interface as the persistent label

    Ниже приведен пример выходных данных команды cllsnw -c, выводящей вариант размещения сервисной метки (service label distribution preference, sldp) для определенной сети.

    #/usr/es/sbin/cluster/utilities/cllsnw -c
#netname:attr:alias:monitor_method:sldp:
net_ether_01:public:true:default:ppstest::
 sldp_collocation_with_persistent

    Эксперименты с политикой размещения сервисных меток

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

    python-# more /etc/hosts
10.10.31.31 pythona # base address 1
10.10.32.31 pythonb # base address 2
192.168.100.31 p630n01 n1 # python persistent address
192.168.100.82 app1svc # cobra service address
192.168.100.83 app2svc # viper service address
python-# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en0 1500 link#2 0.2.55.4f.c4.ab 5044669 0 1828909 0 0
en0 1500 10.10.31 pythona 5044669 0 1828909 0 0
en0 1500 192.168.100 p630n01 5044669 0 1828909 0 0
en0 1500 192.168.100 app1svc 5044669 0 1828909 0 0
en0 1500 192.168.100 app2svc 5044669 0 1828909 0 0
en3 1500 link#3 0.20.35.e2.7f.8d 3191047 0 1410806 0 0
en3 1500 10.10.32 pythonb 3191047 0 1410806 0 0
lo0 16896 link#1 1952676 0 1957548 0 0
lo0 16896 127 localhost 1952676 0 1957548 0 0
lo0 16896 localhost 1952676 0 1957548 0 0
    Примечание. В представленных выше выходных данных узел python имел группы ресурсов для узлов cobra и viper, а также соответствующие сервисные IP-адреса. Была установлена политика распределения Collocation with persistent (С совместным размещением и с постоянной меткой).

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

    Verifying additional pre-requisites for Dynamic Reconfiguration...
cldare: Detected changes to service IP label app1svc. Please note that changing
parameters of service IP label via a DARE may result in releasing resource group
APP1_RG .
cldare: Detected changes to service IP label app2svc. Please note that changing
parameters of service IP label via a DARE may result in releasing resource group
APP2_RG .
    Примечание. В данном случае зарегистрированное сообщение является обычным, и выдается только потому, что было обнаружено изменение. Если это изменение является единственным, отключения ресурсов не произойдет.

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

    Общее представление о файле netmon.cf

    В HACMP можно создать файл конфигурации netmon.cf со списком дополнительных сетевых адресов. Эти адреса используются только для отправления ECHO-запросов ICMP службами топологии в целях определения состояния адаптера при определенных обстоятельствах.

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

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

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

    Создание файла netmon.cf

    Файл netmon.cf должен находиться в каталоге /usr/es/sbin/cluster на всех узлах кластера.

    Требования к созданию файла:

  • Файл должен содержать по одному IP-адресу или IP-метке на кабель.
  • Файл должен содержать удаленные IP-метки/адреса, не входящие в конфигурацию кластера, к которым можно получить доступ через интерфейсы HACMP. Мы рекомендуем использовать IP-адрес маршрутизатора.
  • В файле netmon.cf может быть определено не более 30 IP-адресов/меток.
  • Включите все IP-адреса и соответствующие им метки в файл /etc/hosts.
    •  Примечание. Когда процесс NIM (из служб топологии RSCT) пытается определить состояние локальных адаптеров, он может попытаться использовать разрешение имен хостов. Если IP-адрес и соответствующая метка не записаны в файле /etc/ hosts, то при возникновении проблемы или при задержке при попытке разрешения адреса может быть продлено общее время обнаружения отказа, что замедляет операции перемещения при сбое.

    Содержание файла netmon.cf может иметь примерно следующий вид:

    /usr/es/sbin/cluster/netmon.cf
192.168.100.76
p690_1_lpar3
192.168.100.35
router_lan1
/etc/hosts (corresponding entries)
192.168.100.76 node365 #client node running oracle
192.168.100.21 p690_1_lpar3 #client node hosting application 4
192.168.100.35 node367 #client node running db2
192.168.100.200 router_lan1 #router hosting production lan

    Рекомендации и дополнительные замечания

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

    Другие сценарии могут включать среды с использованием одного логического интерфейса EtherChannel, состоящего из нескольких связей Ethernet. В такой среде происходит прозрачная обработка отказов связей логикой EtherChannel, однако полный отказ канала приводит к возникновению проблем в случае, если службы топологии не имеют файла netmon.cf. Реализация EtherChannel в среде HACMP подробно описывается в разделе "Etherchannel".

    Общее представление о файле clhosts

    Файл clhosts содержит информацию об IP-адресах, позволяющую установить связь между демонами мониторинга на клиентах и на узлах кластера HACMP. К инструментам, использующим этот файл, относятся: clinfoES, HAView и clstat. Файл находится на всех серверах и клиентах кластера HACMP в каталоге /usr/es/sbin/cluster/etc/.

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

    127.0.0.1 # HACMP/ES for AIX

    Создание файла clhosts

    В предыдущих версиях требовалось вручную создавать и обслуживать клиентский файл clhosts. В HACMP 5.3 можно автоматически генерировать файл clhosts, требуемый клиентами при выполнении верификации с включенной функцией автоматического исправления ошибок. При верификации на всех узлах кластера создается файл /usr/es/sbin/cluster/etc/clhosts.client.

    Этот файл будет иметь приблизительно следующий вид:

    # /usr/es/sbin/cluster/etc/clhosts.client Created by 
 HACMP Verification / Synchronization
Corrective Actions
# Date Created: 07/01/2005 at 12:45:29
192.168.100.102 #dlpar_app2_svc
192.168.100.101 #dlpar_app1_svc
192.168.202.204 #alexis_base1
192.168.202.205 #alexis_base2
192.168.100.61 #alexis
192.168.201.203 #jessica_base2
192.168.201.202 #jessica_base1
192.168.100.72 #jessica
192.168.200.200 #jordan_base1
192.168.200.201 #jordan_base2
192.168.100.71 #jordan

    Обратите внимание на то, что указаны все адреса, включая загрузочную, сервисную и постоянную IP-метки. Перед использованием любой из утилит мониторинга с клиентского узла должно выполняться копирование файла clhosts.client на все клиенты в каталог /usr/es/sbin/cluster/etc/clhosts. Не забудьте удалить расширение .client при копировании файла на клиентские узлы.

    Важно! Файл clhosts на клиенте не должен содержать 127.0.0.1, loopback или localhost.

    Clstat на клиенте и файл clhosts

    При запуске утилиты clstat с клиента демон clinfoES получает информацию о состоянии кластера от SNMP на стороне сервера и заполняет MIB HACMP на стороне клиента. Она не сможет вести обмен данными с демоном и сообщит о том, что она не может найти кластеры при отсутствии файла clhosts.

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

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

    HAView и файл clhosts

    HAView выполняет мониторинг состояния кластера в топологии сети, используя информацию кластера в файле /usr/es/sbin/cluster/etc/clhosts. Он должен существовать на управляющем узле Tivoli NetView. Убедитесь в том, что имя хоста и сервисная метка узлов Tivoli NetView полностью одинаковы (если они неодинаковы, следует добавить синоним в файл /etc/hosts, чтобы устранить различия в именах). Если файл clhosts содержит недопустимый IP-адрес, HAView не сможет выполнить мониторинг кластера. Убедитесь в том, что применяются допустимые IP-адреса и что файл не содержит посторонних символов.

    Общее представление о файле clinfo.rc

    HACMP может быть настроен на изменение MAC-адреса сетевого интерфейса путем реализации перехвата аппаратного адреса (hardware address takeover, HWAT). В коммутируемой сетевой среде Ethernet коммутатор может не всегда получать своевременную информацию о новом MAC-адресе. В результате коммутатор не сможет направлять требуемые пакеты на сетевой интерфейс.

    Скрипт clinfo.rc используется HACMP для очистки ARP-кеша в системе, чтобы отразить изменения в сетевых IP-адресах. Он не обновляет кеш до тех пор, пока другой адрес не ответит на ping-запрос. Обычно при включенной функции переключения аппаратных адресов в HACMP очистка ARP-кеша необязательна. Это связано с тем, что функция переключения аппаратных адресов устанавливает связь между IP-адресом и аппаратным адресом.

    Примечание. HWAT поддерживается в HACMP только при использовании перехвата IP-адресов посредством замены (IPAT via replacement).

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

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

    ping -c1 $host
    Примечание. Подразумевается, что клиент подключен напрямую к одной из сетей кластера.

    Конфигурирование файла clinfo.rc

    Чтобы убедиться в том, что новый MAC-адрес передан коммутатору, нужно выполнить следующие действия:

  • Измените строку файла /usr/es/sbin/cluster/etc/clinfo.rc, которая на данный момент выглядит следующим образом:
    PING_CLIENT_LIST=" "
  • Включите в эту строку имена или IP-адреса как минимум одного клиента из каждой подсети в коммутируемой сети Ethernet.
  • Запустите clinfoES на всех узлах в кластере HACMP, подключенных к коммутируемой сети Ethernet.
    •

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

  • если вы обычно запускаете службы кластера HACMP, используя shell-скрипт /usr/ es/sbin/cluster/etc/rc.cluster, укажите опцию -i ;
  • если вы обычно запускаете службы кластера HACMP через SMIT, укажите Yes в поле Start Cluster Information Daemon? (Запускать демон информации кластера?);
  • копия скрипта /usr/es/sbin/cluster/etc/clinfo.rc должна существовать на всех серверах и клиентах в кластере, чтобы обеспечить обновление всех ARP-кешей.
    •

    Принцип работы clinfo и clinfo.rc

    Вызов clinfo.rc из clinfo имеет следующий формат:

    clinfo.rc {join,fail,swap} interface_name

    Clinfo получает информацию об интерфейсах и их текущем состоянии и выполняет проверку на изменение состояния интерфейсов:

  • при состоянии UP Clinfo вызывает clinfo.rc join interface_name ;
  • при состоянии DOWN Clinfo вызывает clinfo.rc fail interface_name ;
  • при получении события node_down_complete Clinfo вызывает clinfo.rc с параметром fail для всех интерфейсов, находящихся в состоянии UP;
  • при получении события fail_network_complete Clinfo вызывает clinfo.rc с параметром fail для всех соответствующих интерфейсов;
  • при получении события swap_complete Clinfo вызывает clinfo.rc swap interface_ name.
    •
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^