Назад | Перейти на главную страницу

аварийное переключение уровня 2 в стойке

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

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

редактировать возможные варианты:

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

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

Я отвечу в этом случае сам, так как идея запуска STP на клиенте, представленном womble, меня немного пугает. Кажется, что:

  • связь между сервером и двумя независимыми коммутаторами с периодической проверкой подключения [параметр arp_ip_target]
  • RSTP в ядре / между свитчами

это наиболее разумное решение.

Мы просто не используем переключатели «наверху стойки». Мы либо используем блейд-модули со встроенными коммутаторами, которые подключены к резервному распределению или основным коммутаторам, либо подключаем серверы напрямую к резервным распределительным коммутаторам (в идеале с VSS).