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

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

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

1. Проверка конфигурации адаптера Ethernet и кабелей адаптера.
2. Создание интерфейса EtherChannel.
3. Конфигурирование IP-адресов на новом интерфейсе (en6) через TCP/IP.
4. Добавление загрузочных и сервисных IP-адресов в топологию HACMP.
5. Создание группы ресурсов и назначение ей сервисного IP-адреса.
6. Синхронизация кластера.
7. Запуск служб кластера.
8. Тестирование избыточности 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.

Рис. 14.2. Параметры адаптера Ethernet

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

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

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

Рис. 14.3. Меню добавления Etherchannel

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

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

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

Этап 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.4. Конфигурирование IP на устройстве EtherChannel

увеличить изображение
Рис. 14.5. Конфигурация EtherChannel в выходных данных команды cllsif

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

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

Рис. 14.6. Группа ресурсов Etherchannel

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

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

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

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

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

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

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

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

1. Мы отключили кабель из ent3. В результате произошла передача обслуживания на ent2. Это было проверено командами netstat и entstat, а также выполнением pingопросов с клиента. AIX регистрирует это в отчете об ошибках. Однако HACMP не знает о возникновении отказа. Ошибки из отчета об ошибках представлены на рис. 14.8.
   

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

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

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

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