неділю, 13 грудня 2009 р.

Некоторые результаты тестирования network teaming (bonding)



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

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

Краткие результаты:

  • отключение второго порта (standby). Никаких изменений в работе сети, что и следовало ожидать.

  • отключение первого порта (active). Сеть недоступна, в течении 30 сек происходит переключение, сеть снова доступна

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

  • выключаем второй порт (текущий standby). переключение на основной линк произошло за несколько секунд.




Вообще очень интересный результат - скорость переключения (реакции драйвера на проблемы) в одном направлении значительно отличается от скорости в другом.
Почему такое происходит - затрудняюсь ответить. Могу только сказать, что очень похожие результаты я получил, когда реализоваль network teaming в VMware ESXi 3.5. То ли это особенности настройки наших цисок то ли особенности работы драйверов bonding.

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

5 коментарів:

  1. У меня эти паузы исчезли, когда я выставил portfast=enable на портах, задействованных для bond-нга. Я думаю, что эти задержки связаны с перестроением spanning-tree.

    ВідповістиВидалити
  2. Спасибо, попробую при возможности

    ВідповістиВидалити
  3. Была аналогичная ситуация.
    На коммутаторе Cisco выставление ethernet-портов участвующих в группе, в режим spanning-tree portfast полностью решило проблему.
    При физическом отключении мастер-порта, переключение происходит практически мгновенно, разрывов tcp-сессий не наблюдается.

    ВідповістиВидалити
  4. Прочитал одну из ваших предыдущих статей, понял что у вас trunked-порт. В данном случае, использовать spanning-tree portfast нельзя и придется мириться с задержками в 30 секунд на перестройку дерева.

    ВідповістиВидалити
  5. А без транка тут никак, цисок-то не одна штука (подключено все к разным свичам), поэтому могут быть проблемы.
    Подключать же к одному свичу нельзя - смысл (точнее HA) теряется

    ВідповістиВидалити