GetNet

В типовой организации есть множество отделов, и для их работы требуется оборудование. Сетевые принтеры и другие общие устройства, выведенные в общий доступ, снижают затраты на использование ресурсов. Сеть даёт и централизованное управление: при наличии большого парка серверов через систему управления конфигурацией (Puppet, Ansible, Salt) можно из одной точки устанавливать программное обеспечение, выполнять настройку, обновлять системы и доставлять пакеты.
Корпоративная сеть — фундамент для всех связанных систем. Если сеть работает нестабильно, это немедленно сказывается на всех подключённых к ней сервисах: виртуализации, системах хранения данных и прочих. Поэтому стабильно работающая сеть — фундамент всей ИТ-инфраструктуры организации.

Первая задача — обеспечить отказоустойчивый канал между провайдером и площадкой. Канал приходит по LACP: два линка объединены в одну логическую группу и заведены на два коммутатора. Тестирование проводилось на линейке CRS317.
Первым было опробовано решение по спецификации 802.1BR — «стекирование» по схеме controller bridge + port extender. Привлекала возможность подключить в такую схему несколько устройств (два-три). Однако требовалась очень высокая отказоустойчивость: выход одного устройства не должен влиять на схему в целом. Этого добиться не удалось — отказ головного устройства (controller bridge) по любой из причин превращал всю сеть в неработоспособную, полноценного failover не было. Впоследствии эта технология была объявлена deprecated и убрана из RouterOS начиная с версии 7.18.
Следующим решением стал MLAG. Технология позволяет объединить два физических линка от устройства в один логический канал через два разных коммутатора, повышая отказоустойчивость. Прирост скорости при этом не линейный: при линках 10 Гбит/с получить 20 Гбит/с не выйдет — часть полосы уходит на синхронизацию и служебный трафик. Главное преимущество — failover: при потере одного линка работа продолжается по второму.

Ограничения MLAG, которые нужно учитывать:

После перехода на MLAG канал заработал сразу: появилось резервирование линков, отказ любого из них перестал влиять на подключение в целом.

Схема была усложнена: MLAG используется и на верхнем уровне — для канала от провайдера, и ниже — для объединения линков со стороны серверов.
Здесь возникла задача резервирования шлюзов. Статические шлюзы на VLAN-ах резерва не дают: при выходе из строя коммутатора, на котором расположены шлюзы, работоспособность сети теряется. Решение — протокол VRRP. Но в одной схеме с MLAG он не заработал.
Основная проблема проявлялась при переходе мастера в бэкап и обратно (то есть при смене приоритета и перетекании трафика с одного шлюза на другой) — в этот момент схема становилась неработоспособной. Вероятная причина связана с MLAG: в прошивке 7.6 он работал стабильно, а в ряде последующих версий MAC-адреса с интерфейса peer link «перепрыгивали» на интерфейсы, входящие в группы LACP. Лечилось это откатом на старую прошивку либо переходом на существенно более новую, которой на тот момент ещё не было.

Рядом была построена аналогичная схема, а шлюзы с VRRP вынесены в отдельный слой — так, чтобы MLAG работал отдельно, а VRRP отдельно. Это привело к классической трёхуровневой модели: высокопроизводительное ядро, ниже уровень распределения, в самом низу уровень доступа. Под ядром расположены три зоны, каждая из которых представляет собой отдельную площадку либо отдельный отдел со своими сервисами.
Отдельно стоит отметить, почему ядро сделано на L3. Если всю сеть построить на L2, шанс «выстрелить себе в ноги» далеко не нулевой: при большом количестве линков, работающих в режиме active-active, VLAN легко закольцовывается сам на себя, и в сети образуется петля.

Модель не является трёхуровневой в полном каноническом смысле. Классическая модель предполагает, что на уровне distribution доступ расширяется добавлением коммутаторов. Здесь же выделен уровень ядра, а коммутаторы уровня агрегации находятся внутри каждой из зон — то есть каждая зона резервируется собственной парой коммутаторов. Пара, а не больше, потому что MLAG не позволяет добавить в группу больше двух устройств.
Если считать каждую площадку отдельным отделом (например, DevOps, разработка и так далее), отказоустойчивость проявляется в том, что неработоспособность одного отдела или падение сервисов внутри одной площадки не влияет на работу остальных.