К миллиону продолжений «Терминатора» есть много вопросиков. Мой личный топ кринж — в «Терминатор. Генезис», когда Скайнет теряет ядро сети (там реально звучит слово «ядро») и все боты вырубаются. Между тем, отказоустойчивые сетевые конфигурации начали строить ещё мы, кожаные мешки, в первой половине 21 века. 

В кампусных сетях отказоустойчивость ядра мы чаще всего реализуем за счёт объединения коммутаторов ядра в стек. Это защищает ядро от сбоев и выхода из строя оборудования. В ЦОДах же отказоустойчивость сети реализуется на основе MLAG либо же за счёт развертывания сети в виде фабрики BGP EVPN VXLAN — набора из  коммутаторов уровня spine и leaf. Такие конфигурации защищены не только от сбоев оборудования, но и от ошибок в коде и конфигурациях ПО.

Я уверен, что инфраструктура сети Скайнет реализована как минимум в одной из этих конфигураций, причём с геораспределением. Так что показанное в кино — бред (впрочем, как и многое другое). А вот для обычных кампусных сетей такая архитектура — оверкил, её используют очень редко и в специфических обстоятельствах.

Сегодня именно о таких кейсах из своей практики я расскажу в этой статье: как архитектура BGP EVPN VXLAN защищает от ошибок на уровне ПО и позволяет реализовать геораспределённую катастрофоустойчивость, какие с ней связаны подводные камни и в каких случаях компании считают такое решение целесообразным.

Проблема со стандартной реализацией ядер в виде стека коммутаторов

Ядро обычно состоит из коммутаторов класса enterprise или datacenter, объединенных в ту или иную отказоустойчивую конфигурацию. Также в сети есть коммутаторы доступа, к которым непосредственно подключаются оконечные точки, и опционально –  коммутаторы агрегации.

Выход из строя ядра означает отключение всей сети. Чаще всего для отказоустойчивости ядро реализуют в виде стека (т.е. кластера, в терминологии Cisco – VSS, Huawei – CSS) из двух коммутаторов, внутри которого происходит балансировка трафика. Стек — виртуальный коммутатор, который с точки зрения администрирования видится как одно устройство, с одним менеджмент-интерфейсом.

Конфигурация стека защищает от выхода из строя физического оборудования, но не от ошибок ПО и ошибок конфигурации. Коммутаторы стека реализуют общий control plane, и любое неправильное обновление или конфигурация реплицируется на все устройства кластера, включая и мастер и другие экземпляры, и может «положить» всю сеть.

Такие ошибки ПО, выводящие из строя всё ядро — настолько большая редкость, что большинство офисных сетей строится просто в виде стека, без учета этого сценария. Но если требуется экстремальная отказоустойчивость, сценарий ошибок ПО тоже следует исключить. Для этого есть целый ряд решений.

Первый уровень защиты от ошибок ПО: ядро сети в виде MLAG

Вместо стека ядро сети можно реализовать в виде MLAG-пары коммутаторов. Решения MLAG, или multi-chassis link aggregation group (также MLAG, MC-LAG, MEC, в документации Cisco vPC — Virtual Port Channel) используют для агрегации каналов в port channel и для сообщения устройств в составе отказоустойчивой пары. Ядро сети в виде MLAG защищено от ошибок ПО, поскольку два устройства независимы и ошибки конфигурации одного из них не реплицируются на другое.

Другое отличие от стека: ядро в виде MLAG позволяет реализовать геораспределение его устройств без риска потери всей сети при инцидентах. Обычно коммутаторы стека размещают в одной серверной. Растягивать же стек на два здания — практика сомнительная. Прерывание связи внутри стека тем вероятнее, чем дальше коммутаторы находятся друг от друга. При прерывании оба устройства начинают думать, что они единственные в сети; возникают петли трафика, и работоспособность теряет вся сеть.

В составе же MLAG можно разносить компоненты ядра на расстояние. При потерях связи между устройствами MLAG происходит падение лишь части сети за secondary-коммутатором, поскольку он блокирует все свои port channels. В результате коммутаторы в сетевом сегменте, который он обслуживает, теряют с ним связь. Не имея также связи с master-коммутатором, они в принципе теряют связность, и вся сеть сегмента за secondary-коммутатором выходит из строя. Таким образом, ядро на основе MLAG более катастрофоустойчиво.

Коммутаторы уровня офиса обычно не поддерживают MLAG, поэтому  для реализации такой отказоустойчивости приходится использовать более дорогостоящие коммутаторы для ЦОДов. Эти устройства, помимо MLAG, обладают  рядом дополнительных функций, которые обычно не требуются в кампусе, но необходимы в ЦОДе. 

Такую конфигурацию ядра кампусной сети я видел у очень крупного спортивного стадиона, для которого мы выполняли аудит сети. В виде MLAG у них уже было реализовано ядро ЦОДа, распределённое между двумя серверными. Когда им понадобилось развернуть новую кампусную сеть, они решили переиспользовать уже имеющееся оборудование и конфигурации, построив ядро кампусной сети на тех же физических устройствах, что, безусловно, снимало огромную часть расходов на оборудование и проектирование архитектуры. Разделение между ядром ЦОДа и кампуса было реализовано внутри этих устройств логически.

Проблему падения части сети решает следующий уровень усложнения архитектуры— реализация сети в виде фабрики BGP EVPN VXLAN.

Фабрика BGP EVPN VXLAN

Фабрика BGP EVPN VXLAN — особая архитектура сети, которая реализуется на базе топологии spine-leaf.

Разберём эту мысль по частям. BGP — Border Gateway Protocol, основной протокол динамической маршрутизации в интернете. Он позволяет передавать большие объемы данных о маршрутах, а за счёт гибкости может передавать служебную информацию, которая обеспечивает корректную работу протоколов на уровне data plane, например, VXLAN. И в данном случае он расширяется за счёт EVPN  и VXLAN, Ethernet-over-UDP VPN, который инкапсулирует полезный трафик в VXLAN. Таким образом, соединения между оконечными устройствами задействуют меньше бродкастов, не зависят от механизмов отказоустойчивости, завязанных на бродкаст, и снижают нагрузку на сеть.

Теперь про spine-leaf. 

Примечание. Далее в статье в контексте топологии spine-leaf мы выделяем border leafs и aggregation leafs. Последние обычно называют просто leafs, но чтобы отличать их от border leafs, которые имеют другую роль и место в топологии сети, в рамках статьи я называю их aggregation leafs.

Spine: два или более коммутатора, которые обеспечивают агрегацию подключений ядра. Коммутаторы spine реализуются в виде независимых устройств, которые не синхронизируют конфигурации control plane. Неправильная конфигурация одного из них не реплицируется на другие.

Border leafs: два или более коммутатора, которые через кластер МЭ подключаются к интернету, КСПД, другим сетевым ресурсам. Аналогично коммутаторам spine, коммутаторы border leaf являются независимыми устройствами, а с помощью MLAG реализуются как агрегация подключений со стороны МЭ.

Aggregation leafs: находятся между коммутаторами spine и подключениями изнутри сети, которые они агрегируют. На схеме выше отображено два физических сегмента во внутренней сети (например, это два здания, внутри которых организованы отдельные сегменты сети). У каждого такого сегмента есть два или более коммутатора aggregation leaf, которые агрегируют подключения внутри этого сегмента. Каждый коммутатор aggregation leaf подключен ко всем коммутаторам spine, обеспечивая бесперебойность соединений с ядром.

Коммутаторы aggregation leafs, как видно из названия, агрегируют подключения со стороны нижестоящих коммутаторов и устройств. При этом коммутаторы в составе aggregation leaf, обслуживающие один сетевой сегмент, уже можно реализовать в форме менее отказоустойчивых конфигураций — стека или MLAG: выход отдельного aggregation leaf из строя уже не затрагивает всю сеть, а только отдельный физический сегмент.

Разделение коммутаторов на три уровня позволяет независимо конфигурировать внутренние и внешние подключения, масштабировать портовую емкость коммутаторов внутри и на границе сети: если нужно добавить физический сетевой сегмент, достаточно развернуть коммутаторы уровня aggregation leaf и соответствующее оборудование ниже, без необходимости увеличивать число дорогостоящих коммутаторов spine.

Разнесение border leaf и spine на две локации позволяет реализовать геораспределённую конфигурацию ядра. Как мы обсудили ранее, при разрыве связи между компонентами ядра в стеке падает вся сеть, а в конфигурации MLAG — её часть. В фабрике BGP EVPN VXLAN компоненты ядра можно разносить смело. При потерях связи между устройствами в паре восходящие и нисходящие соединения продолжают работать, потому что L2-трафик передаётся по нужным IP-адресам в инкапсулированном виде на сетевом уровне. Единственное, что теряется при этом — возможность прямых соединений между разделёнными сегментами.

Кейс использования фабрики BGP EVPN VXLAN для ядра кампусной сети

Выбор архитектуры фабрики BGP EVPN VXLAN для офиса сопряжен с ростом стоимости оборудования на десятки процентов. Ядро в виде стека можно реализовать на 2 коммутаторах, фабрика в описанной выше конфигурации требует хотя бы 6 таких же устройств. Итого, если рассчитывать, что на одно ядро приходится около 100 коммутаторов доступа, то это минимум +30% к CAPEX всей сети. В части операционных расходов увеличивается стоимость часов инженеров, потому что нужна более высокая квалификация, чем при работе с классической кампусной сетью. Так что у компаний, которые строят ядро кампуса в виде фабрики, обычно есть очень веские причины, которые перекрывают такой рост расходов. 

Приведу пример развертывания   нами сети именно в такой конфигурации и расскажу, почему заказчик её выбрал. Это была сеть флагманского офиса крупной энергетической компании, которая строилась с нуля, как и сами здания офиса. Детали задачи:

• Сеть должна была покрыть 5 корпусов. В двух из них планировались серверные, между которыми следовало распределить ядро базе фабрики BGP EVPN VXLAN.

• При этом требовалось реализовать 3 физически разделённые сети: открытую офисную сеть с доступом в интернет, закрытую офисную сеть и сеть ЦОДа (серверный сегмент сети). Все три сегмента на уровне архитектуры организованы одинаково, за исключением того, что в сети ЦОДа к коммутаторам leaf мы планировали подключать непосредственно серверы, а в сети офиса к ним подключаются коммутаторы доступа оконечных устройств.

В качестве вендора коммутаторов мы выбрали Maipu. Первоначально проект предполагал использование коммутаторов Huawei. После ухода Huawei с российского рынка в 2022 году мы выбрали в качестве замены бренд Maipu, потому что у нас уже был опыт работы с ним в других проектах (а точнее, даже замещения Huawei на Maipu) и хороший контакт с вендором. Конкретно в этой истории, к примеру, по нашему запросу Maipu за 3 месяца реализовали функциональность, которая сняла ограничения на число записей в MAC-таблицах leaf-коммутаторов.

Архитектура решения на примере открытого офисного сегмента:

В описанной архитектуре с точки зрения отказоустойчивости выход из строя серверной или отключение целого корпуса не влияет на связность остальных частей сети.

В каждом корпусе прокладывается вертикальный «стояк» СКС, к которому подключаются все кроссовые. «Стояк» подключается к ядру через MLAG коммутаторов aggregation leaf,  обслуживающие данный корпус.

В принципе архитектура фабрики допускает подключение коммутаторов доступа напрямую к коммутаторам ядра spine. Но сложные сетевые конфигурации проще настроить на нескольких leaf-коммутаторах, чем на сотнях коммутаторов доступа внутри сети. Например, довольно сложно настраивать BPG EVPN VXLAN, к тому же на момент внедрения этого кейса устройства, которые были доступны у Maipu в роли коммутаторов доступа, ещё не поддерживали BGP EVPN VXLAN. И выделение уровня leaf-коммутаторов над уровнем коммутаторов доступа решило проблему.

Описанная архитектура реализована для всех трёх физических сетей: открытой офисной, закрытой офисной и сети ЦОДа. Они различаются в деталях — например, МЭ разрешает доступ в интернет из одной сети и не разрешает из другой. Но сам подход к организации ядра одинаковый.

Внедрение. Из-за того, что план строительства зданий предполагает их введение в эксплуатацию по очереди, мы развёртываем сеть параллельно с постройкой корпусов. При монтаже приходилось защищать оборудование от пыли стрейч-плёнкой и скотчем — стандартная история при параллельной сдаче помещений строителями и инсталляции оборудования.

Первый корпус, имеющий серверную, уже готов. И всё ядро сети в виде фабрики (два коммутатора spine и два коммутатора border leaf) мы развернули в его серверной. Таким образом, ядро ещё не геораспределено, но полностью сконфигурировано. По мере ввода в эксплуатацию новых корпусов мы сможем просто перенести в новую серверную необходимые компоненты ядра (один spine и border leaf). Параллельно в новом здании развертывается новый «стояк», и через MLAG aggregation leafs подключается ко всем коммутаторам spine.

Итоговое решение имеет большой запас масштабируемости и гибкости и позволяет:

• разносить коммутаторы внутри ядра по разным серверным;

• добавлять в ядро фабрики дополнительные коммутаторы;

• добавлять новые «стояки», обслуживающие новые корпуса или физические сегменты сети;

• добавлять больше коммутаторов доступа к имеющимся aggregation leaf-коммутаторам.

Cостав команды внедрения: технический менеджер, который координировал работу всех; архитектор / инженер по СПД; инженер,  отвечающий за взаимодействие с подрядчиками, которые ставили коммутаторы, подключали к СКС и прочее; инженеры ИБ, которые настраивали кластер МЭ; архитектор со стороны заказчика.

Причины выбора архитектуры фабрики BGP EVPN VXLAN в истории с офисной сетью следующие: 

• Реализация в виде фабрики позволяет построить геораспределённое катастрофоустойчивое ядро между несколькими серверными в разных зданиях на расстоянии сотен метров.

• У заказчика уже была экспертиза эксплуатации такой фабрики, поэтому ограничений в плане опыта команды у него не было.

• Можно было использовать одно типовое архитектурное решение и для построения ядра сети ЦОД, и для кампусных сетей.

Подводные камни использования фабрики BGP EVPN VXLAN в кампусной сети

Главные сложности сводятся к тому, что в кампусных сетях типично используются некоторые сервисы, нехарактерные для ЦОДов. Чтобы построить фабрику, вам понадобится сетевое оборудование уровня ЦОДа, и оно может просто не поддерживать то, что вам нужно. Например:

• Мультикаст-трафик в сетях ЦОД используют достаточно редко, а в кампусных сетях это стандартная история (ВКС, телевещания, радио и так далее). Если сетевое оборудование, которое вы выбрали для BGP EVPN VXLAN, не поддерживает мультикаст, вам придётся менять вендора или внедрять дополнительные решения (к примеру, мультикастные группы с использованием протоколов PIM внутри underlay-сети). Один наш заказчик как-то не обратил на это внимание при выборе оборудования и нам пришлось общаться с вендором и вместе с ним выработать решение.

• DHCP. Да, можно найти кейсы использования DHCP в ЦОДах. Но всё же он используется достаточно редко, чтобы некоторые вендоры сетевого оборудования не считали поддержку DHCP приоритетной. Следует внимательно проверять, как конкретно выбранное оборудование поддерживает DHCP в BGP EVPN VXLAN и насколько это вам подходит.

Ключевые моменты

• Фабрику BGP EVPN VXLAN обычно используют в ЦОДах для реализации отказоустойчивости и масштабируемости. Но в редких случаях на ней строят и ядра кампусных сетей.

• Для ядра сети на базе фабрики проще организовать геораспределённую катастрофоустойчивость.

• CAPEX сети на базе фабрики выше где-то на 30%, операционные расходы выше за счёт более высоких требований к квалификации сотрудников.

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

Что думаете про фабрику BGP EVPN VXLAN? Приходилось иметь с ней дело?