Разработка и реализации платформы следующего поколения
В первой части статьи мы говорили о том, как архитектура IP-фабрики возникла в результате естественной эволюции трендов и опыта, накопленного за 15 лет работы. В следующих разделах мы более подробно рассмотрим этапы проектирования и реализации, не забыв обозначить роль и поддержку поставщиков в рамках общего процесса.
Процесс разработки и реализации
Думаю, будет полезно еще раз подытожить некоторые из основных требований проекта:
Распределенная leaf-spine архитектура VXLAN overlay сети и BGP/EVPN control plane.
От 1G до 100G на leaf.
100G на spine.
Полностью автоматизированное управление с самого начала.
Выбор коммутаторов Mellanox особо не нужно объяснять, попросту потому что эта аппаратная платформа уже и так выглядела многообещающе с точки зрения набора функций, производительности, доступности и выбора моделей, а сочетание с Cumulus Linux, которая в полной мере использовала возможности этой платформы, стала настоящим прорывом.
Говоря простым языком, Cumulus Linux — это операционная система для сетевого оборудования на базе Linux, которая объединяет стандартный интерфейс системы Linux с базовым аппаратным оборудованием, а все главные сетевые операции перекладывает на соответствующие ASIC’и. Иными словами: думайте о своем коммутаторе (и об управлении им), как о машине с Linux с аппаратной поддержкой сетевых функций.
В то время как для оборудования датацентров это является кардинальной переменой, поскольку наконец можно управлять серверами и сетевыми блоками в одном интерфейсе, это вносит некоторые эффективные улучшения также и в традиционно более сетевые сценарии, как, например, Internet Exchange.
Кроме того, Cumulus Linux специально разработана для использования в датацентрах и в большой степени ориентирована на реализацию IP-фабрик на базе VXLAN/EVPN. Это результирует в мириаде небольших деталей, которые упрощают рабочие будни сетевого архитектора: в целом поднятие и конфигурация базовой архитектуры фабрики — это вопрос всего нескольких строчек конфигурации на каждом узле. Кроме того, Cumulus предлагает полную встроенную поддержку сетевых платформ автоматизации, таких как, например, Ansible, что позволяет полностью автоматизировать платформу от установки до стандартных операций инициализации.
Первоначальная архитектура состояла из:
Cumulus Linux версии 4.2, установленный на всех коммутационных узлах.
FRR Routing Suite, отвечающий за управления BGP/EVPN control plane.
Netfilter (ebtables) для поддержки стандартных MAC ACL.
Автоматическое развертывание через внешний сервер управления, оснащенного Ansible.
На начальном этапе реализации, Cumulus любезно предоставили нам кастомный симулятор в их собственной виртуализированной тестовой среде (CITC, Cumulus In The Cloud), специально адаптированной под условия нашего развертывания. На основе общих шаблонов, предоставленных Cumulus, мы разработали собственную платформу развертывания Ansible, которая брала на себя следующие задачи:
Адресация узлов (петли, конечные точки туннеля).
Перекрестная ссылка, конфигурация шины.
Точная настройка интерфейса ядра и коммутатора.
Конфигурация протоколов мониторинга и управления (SNMP, sFlow, NTP).
Базовая конфигурация VLAN и VXLAN (общедоступная пиринговая VLAN сеть, изолированная VLAN сеть, тестовая VLAN сеть).
После развертывания полной конфигурации на виртуальной платформе в симуляторе, прежде чем приступить к развертыванию в реальной жизни, мы протестировали базовые конфигурации пользователей.
Во время тестирования на реальной физической платформе все узлы были подключены к административной сети, прошли базовую конфигурацию с помощью ZTP, а затем за несколько минут Ansible выполнила полную конфигурацию фабрики без единой ошибки. После чего мы начали тестирование в реальной жизни, сосредоточившись в основном на конфигурациях фильтрации, которые являются неотъемлемой частью лучших IXP технологий.
На последнем этапе фазы развертывания новая платформа была подключена к существующей работающей платформе, в рамках подготовки к миграции пользователей.
Шаги, приведшие к полной автоматизации сети
Как мы уже убедились, важной и необходимой частью развертывания платформы была автоматизация сети с помощью Ansible, поскольку сложность топологии и количество узлов могли легко привести к трудно обнаруживаемым ошибкам в случае ручного конфигурирования, узел за узлом.
С учетом этой перспективы, для автоматизации сети Cumulus Linux оказался идеальным интерфейсом, поскольку:
Он обеспечивает встроенную поддержку Ansible (локальное выполнение задач).
Конфигурация сети разделена на несколько файлов вместо одного.
Изменение конфигурации достигается путем перезаписи и перезагрузки файлов без необходимости сложного извлечения и синтаксического анализа фрагментов конфигурации (это невероятно эффективно в тех случаях, когда вам необходимо удалить определенный раздел конфигурации).
На следующем этапе нашей работы, направленном на полную автоматизацию сети, а именно автоматизацию резервных операций, были максимально учтены все ключевые аспекты. Нашей целью была разработка платформы, которая могла бы загружать конфигурацию на узлы, начиная с высокоуровневого интерфейса такого как, административная панель управления, которая в результате могла бы предоставлять пользователям услуги конфигурирования по запросу (например: “установите конфигурацию VLAN между моим портом маршрутизатора и портом маршрутизатора этого пользователя”), поэтому выбор правильного подхода имел решающее значение на этом этапе. Требовалось, чтобы платформа конфигурации Ansible действовала как промежуточный слой между системой ПО более высокого уровня (которая находится в разработке в настоящее время) и фактическими узлами.
Первый подход, который мы опробовали была попытка имитировать поведение CLI команд (да, в Cumulus есть интерфейс командной строки - nclu), но в основном этот подход подразумевал те же проблемы, что и с традиционными сетевыми операционными системами: состояние вашего устройства зашито в самом устройстве.
Прорыв произошел, когда мы осознали наиболее простой и эффективный способ - переместить состояние из каждого узла во внешний репозиторий, потому что:
Внешний репозиторий действует как прокси между любым более высокоуровневым программным обеспечением (IXP Manager или нашем собственном программном обеспечении управления, которое находится в стадии разработки).
Конфигурации могут быть оперативно созданы системой Ansible по сохраненным в репозитории данным.
Описывать желаемое конечное состояние узла и является правильным способом работы Ansible, как он и задумывался изначально.
Репозиториями состояний можно управлять, как программным кодом через систему контроля версиями, например Git.
Таким образом, мы разработали наш собственный язык конфигурации внутри платформы Ansible, который позволяет нам выполнять базовые задачи обеспечения:
Полная конфигурация интерфейса пользователя (один порт, связь, поведение VLAN).
Конфигурация VLAN пользователя и поддержка VNI.
Базовая конфигурация ACL (фильтрация MAC и протоколов).
В конце концов мы оказались в ситуации, когда, с самого начала все операции по обеспечению были автоматизированы с помощью сценариев Ansible: это хорошая отправная точка для будущей интеграции с более продвинутыми программными системами. Хотя мы все еще внедряем NVIDIA Cumulus Visibility Tool NetQ с его встроенной интеграцией телеметрии (фича What Just Happened), мы ограничиваем взаимодействие с командной строкой только проверками и мониторингом.
Выход в продакшн
Мы начали миграцию первых пользователей в конце декабря 2020 года, и сейчас мы уже проделали достаточный путь в продакшене, чтобы поразмыслить над уроками, извлеченными из этого опыта, и сделать некоторые выводы.
Наш опыт
Хотя архитектура IP-фабрики оказалась невероятно стабильной на ранних этапах ее реализации, одной из наших первоначальных проблем оставалась совместимость оборудования от различных поставщиков. Как пиринговая платформа, наша архитектура коммутации должна взаимодействовать с устройствами множества разных вендоров, от высокопроизводительных маршрутизаторов Cisco и Juniper до широко распространенных устройств Mikrotik, включая программируемые маршрутизаторы на базе Linux или BSD.
Предоставляя более высокоуровневый интерфейс по сравнению с традиционными сетевыми операционными системами, может поначалу показаться, что Cumulus Linux предлагает меньшую поддержку в настройке параметров низкоуровневого оборудования. На самом деле, нам было приятно наблюдать, как оборудование NVIDIA Mellanox автоматически решало большинство проблем совместимости без дополнительных вмешательств, к которым мы привыкли на предыдущих платформах. В конце концов, интерфейс Cumulus Linux предоставляет намного больший объем информации об используемом оборудовании, которую легко анализировать и собирать.
Одним из основных отличий от традиционных сетей, который мы обнаружили, была фильтрация на основе ACL, которая в Cumulus Linux реализована с помощью пакета Netfilter. Однако благодаря тщательной настройке конфигурации мы смогли позаботиться о самых распространенных конфигурациях пользователей.
У нас был опыт работы с NVIDIA Global TAC, и мы остались довольны уровнем предоставляемой поддержки. Кроме того, наши местные контакты NVIDIA в Италии активно взаимодействуют с нами на всех этапах, ведущих к успешному запуску платформы. Есть ощущение, что у нас с NVIDIA складывается одинаковое понимание нашего конкретного сценария.
Заключительные мысли — дальнейшие перспективы
В конце концов, по нашему мнению, переход на IP-фабрики был неизбежным и естественным, таким, который не возник на пустом месте, а явился результатом почти 20-летнего опыта работы на пиринговыми платформами сетевого взаимодействия.
IP-фабрики обеспечили нам гибкость и надежность для разработки масштабируемых (в значительной степени) платформ с модульной структурой, а также помогли нам разработать шаблонную архитектуру, которую мы можем дублировать и развертывать в любом подходящем месте с помощью простых, автоматизированных операций.
Автоматизация и открытые сети, поддерживаемые Cumulus Linux, открыли совершенно новые перспективы развития, сократив расстояние между миром программных систем и миром сетевых устройств. Вероятно, это главная граница и причина настоящего рывка вперед по сравнению с предыдущими архитектурами.
Заглядывая в будущее, мы видим, как наш мир стремительно совершает еще одну революцию: онлайн-игры, развлечения и онлайн-контент, управляемый CDN, такой как стриминг спортивных событий, быстро трансформируют IX, с поддержкой скорости пиринга 400GE и через несколько лет 800GE для поддержки такого трафика: мы чувствуем, что готовы принять этот новый вызов.
Мы знаем, что движемся в новом направлении, и уверены, что этот опыт будет полезен и поднимет нас, нашего технологического партнера NVIDIA и все сообщество IXP на новые высоты.
Материал подготовлен в рамках курса "Network engineer". Если вас интересует развитие в этом направлении с нуля до Pro, предлагаем узнать про специализацию.
