Вы видели схемы. Шинные сети. Кольцевые топологии. У всех них есть один фатальный недостаток. Одно разрыв в цепи — и всё останавливается.
Звёздные сети выглядят безопаснее. Есть центральный коммутатор. Каждый узел подключён к нему. Если один компьютер выходит из строя, остальные остаются онлайн. Но есть подвох. Этот центральный коммутатор? Это единая точка отказа.
Посмотрите на схему ниже.
![Описание диаграммы: сеть с коммутаторами A, B и C. Узлы подключены к каждому коммутатору. Коммутаторы A и C подключены к коммутатору B.]
В этом сценарии коммутатор B является магистралью. Он соединяет коммутаторы A и C.
Если коммутатор A выходит из строя, узлы на A отключаются. Но узлы на B и C всё ещё могут общаться друг с другом. То же самое происходит, если выходит из строя коммутатор C. Частичный сбой. Управляемый.
Но если коммутатор B выйдет из строя?
Всё идёт в ноль. Вся сеть рушится. Почему? Потому что B — это мост. Нет моста — нет трафика.
Здесь вступает в игру избыточность. Речь идёт не только о резервном питании или дополнительных жёстких дисках. Речь идёт об архитектурной устойчивости.
Что, если изменить физическую компоновку?
Представьте, что добавлена прямая связь между коммутаторами A и C. Избыточный сегмент.
Теперь, если коммутатор B выйдет из строя, A всё ещё может общаться с C. Путь изменится. Трафик перенаправится. Сеть останется в рабочем состоянии.
Это и есть суть сетевой избыточности. Это не магия. Это просто второй способ добраться из точки X в точку Y.
Но добавления кабеля недостаточно. Вам нужны протоколы, которые понимают эту избыточность. В противном случае вы создадите петли. А петли обрушивают сети быстрее, чем отказ коммутатора.
Мы лишь поверхностно затрагиваем эту тему. Настоящая работа начинается, когда вы начинаете говорить о протоколах дерева Spanning Tree и временах переключения на резерв.
Но сначала вы должны увидеть проблему. А проблема проста.
Зависимость от единой точки отказа.
Устраните её — и вы переживёте следующий сбой оборудования.
Отказывает первый коммутатор. Второй берет управление на себя. Трафик продолжает двигаться.
В этом заключается красота сетевой избыточности. Вы устранили единую точку отказа. Если одно из аппаратных устройств выйдет из строя, кольцо останется замкнутым. Сеть продолжает «дышать».
Но теперь у нас появляется новая проблема.
Петля смерти
Представьте два коммутатора, соединенных двумя разными кабелями. Или, возможно, к сети присоединяется третий коммутатор. Теперь у вас есть пути повсюду.
Это отлично работает для обеспечения избыточности. До тех пор, пока это не перестает работать.
Когда коммутатор отправляет кадр и не знает, куда его доставить, он рассылает его на все порты. В простой линейной топологии этот кадр достигает конца и останавливается. В петле? Он бесконечно отражается.
Вещательные пакеты умножаются. Кадровые пакеты (unicast) летают туда-сюда. Внезапно ваша сеть становится не просто медленной. Она перестает работать. Загрузка процессора на каждом коммутате достигает 100%. Пакеты теряются. Вся инфраструктура замирает.
Это вещательная буря (broadcast storm). Это не функция. Это учебная тревога.
Остановка петли
Итак, как сохранить физическую избыточность без логического хаоса?
Вам нужен протокол. Что-то вроде: «Эй, я вижу два пути. Я заблокирую один. Если этот путь выйдет из строя, я разблокирую другой».
На сцену выходит Протокол расширенного дерева (STP).
Он существует с 80-х годов. Он старый. Он громоздкий. Но он работает. STP анализирует все соединения между коммутаторами. Он вычисляет лучший путь к корневому мосту (главному коммутатору). Затем он переводит все остальные избыточные соединения в блокированное состояние.
Трафик течет. Резервная линия остается там, простаивая. Готовая.
Если основной кабель перерезают? Заблокированный порт «просыпается». Он становится активным. Сеть восстанавливается.
Однако на это уходит несколько секунд. Может быть, тридцать. В это время пользователи смотрят на полосы загрузки.
Более быстрое решение: Быстрый протокол расширенного дерева
Тридцать секунд — это вечность в мире серверов. Если вы управляете дата-центром или даже просто занятым офисом, тридцать секунд простоя недопустимы.
На сцену выходит Быстрый протокол расширенного дерева (RSTP), или 802.1w.
Идея та же. Блокировать избыточные соединения. Разблокировать их при необходимости. Но RSTP сокращает время сходимости с секунд до долей секунды.
Он делает это за счет более быстрой переназначения ролей портов. Он не ждет таймаутов. Он общается. Он принимает решения. Он действует.
Какой из них использовать?
Если вы строите современную сеть, вы не используете базовый STP. Вы используете RSTP. Или его родственника, Протокол множественного расширенного дерева (MSTP), который позволяет запускать разные деревья расширенного дерева для разных VLAN.
Почему?
Потому что вы можете захотеть, чтобы VLAN для голоса (Voice VLAN) проходили по другому пути, чем VLAN для данных (Data VLAN). MSTP позволяет балансировать эту нагрузку. Или хотя бы не мешать друг другу.
Если вы используете оборудование Cisco, вы, вероятно, смотрите в сторону PVST+ (Per-VLAN Spanning Tree). Это проприетарное решение. Оно запускает отдельный экземпляр STP для каждой VLAN.
Это требует больших ресурсов процессора. Но оно дает вам тонкий контроль.
Итог
Избыточность — это неоспоримый факт
