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

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

< Лекция 13 || Лекция 14: 1234 || Лекция 15 >

Общее представление о файле 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-адрес передан коммутатору, нужно выполнить следующие действия:

  1. Измените строку файла /usr/es/sbin/cluster/etc/clinfo.rc, которая на данный момент выглядит следующим образом:
    PING_CLIENT_LIST=" "
  2. Включите в эту строку имена или IP-адреса как минимум одного клиента из каждой подсети в коммутируемой сети Ethernet.
  3. Запустите 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.
< Лекция 13 || Лекция 14: 1234 || Лекция 15 >