Порты на коммутаторе в нашем нашем дата-центре
Основа работы сетевого архитектора на *aaS-проектах — это как строить здание, которое эволюционирует. Вроде была пятиэтажка, когда построили четыре этажа, стало надо делать ещё 21, потом понадобилось пристроить домики, соединённые туннелями под землёй, а потом всё это должно стать огромным жилым комплексом с крытым двориком. И ещё там внутри жильцы, и им нельзя перекрывать канализацию, водопровод и подъезды.
Ну и да. А ещё есть текущие проблемы стандартов сетей (отставших от реальных требований на лет десять). Чаще всего это означает выдумывание хитрых велосипедов вместо того, чтобы применять очевидные, казалось бы, решения. Но велосипеды есть везде, конечно.
Есть облачная платформа и сервисы рядом с ней, которые взаимосвязаны. Сервера облака втыкаются в сеть. Устройства, обеспечивающие саму по себе работу сети, втыкаются в ту же сеть. Оборудование клиентов облака иногда втыкается в ту же сеть. И ещё много чего втыкается, например, каналы в Интернет. То есть сеть должна быть, и за неё кто-то должен отвечать. Так как проект немаленький, со всякими сложными взаимосвязями (есть OpenStack-часть и VMware-часть, или иной *aaS), то мало просто настроить. Нужна какая-то сущность, которая будет обо всём этом заботиться и быть в ответе. Конечно же, это эксплуатация — они у нас огромные молодцы. Но основная их задача — эксплуатировать.
Моя задача — знать, что будет через пару лет и что хотят другие архитекторы и продуктологи, чтобы строить такую сеть, где все их части пазла будут нормально соединяться. Ещё я встречаюсь с вендрами, подрядчиками и клиентами — слушаю всех, собираю в голове мысль, как сделать лучше относительно ресурсов с учётом всей информации.
Почему нужен сетевой архитектор, а не общий системный? Потому что он может быть и системным архитектором, просто узкоспециализированым по сетевым технологиям. Это только название, которое подчёркивает специфику. Сетевой архитектор переводит бизнес-задачи в технику и деньги, в процессы. Сообщает «наверх» о своём решении в деталях, и если бизнесу нравится — всё ок. Потом я пишу документацию, сдаю систему в эксплуатацию.
Чем же особенен сетевой архитектор? По-моему, он должен:
- иметь какое-то количество лет опыта со сложными сетями, распределёнными географически как внутри предприятий и ЦОД, так и между ними. Количество лет определить сложно: один человек за 2 года может увидеть, пощупать и сделать столько, сколько другой и за 10 лет не сможет;
- знать ключевые сетевые протоколы. Ключевые — зависят от места применения архитектора;
- понимать, как работают системы с приложениями и какую роль в их работе играет сеть, как одно влияет на другое и в противоположные стороны;
- уметь взаимодействовать с сотрудниками разных уровней: от руководителей через других архитекторов и до технической поддержки, часто выступая в виде переводчика, «мостика» между часто противоположными задачами (например, сократить штат и не покупать железо/ПО/услуги vs расширить штат, купить ЗИП/железо/ПО/услуги). Нужно уметь и писать, и выступать, и разговаривать, и это не должно раздражать или заводить людей. Мало просто знать протоколы, нужно уметь их объяснить.
На что похожа работа?
Была у нас сетевая архитектура, созданная исторически. Когда-то мы строили облако, как считали правильным, по действовавшим тогда реалиям, и это стало базисом. Со временем инфраструктура росла, менялась — и через некоторое время перестала радовать нас как внутренних заказчиков. Мы иначе стали видеть нашу сеть через пару лет, начали смотреть, как и что станет узким местом. Проще говоря, в какой-то момент для нас стало очевидным, что необходимо поменять ряд качеств сети. И ещё при сохранении стоимости, желательно.
Пришёл комитет спецов. Системные архитекторы дали свои вводные и пожелания, получили варианты и нюансы, совместно обсудили ограничения и развитие. А я остался просчитывать решение. И сопровождать его.
За время развития инфраструктуры появились новые технологии, поэтому я их оценил, оценил наш накопленный опыт, разные оверхеды лишние — и предложил, что надо менять и как. Системные архитекторы скинули своё видение по характеристикам, по скоростям и масштабируемости — учёл это. Эксплуатация добавила хотелки и пожелания — учёл это.
Одним из требований, поставленных системными архитекторами, была возможность включения портов 25 Гбит/с Ethernet. Раньше всё делалось на N*10 Гб, а интерфейс 40 Гбит/с был набором 4 по 10 Гбит/с, а 100 Гбит/с — 10 по 10 Гбит/с. Сейчас можно получить сотню 4х25, что упрощает эксплуатацию, и меньше требований к СКС. Да и в протоколах хотелось кое-что поковырять. Вот целевая:
Детали
25G Ethernet – он не сильно отличается по цене, по сетевому и серверному оборудованию, чем 10GbE линки. В расчёте на порт цена почти та же, а вот прирост скорости весьма приятный. И он понадобится клиентам абсолютно точно в ближайшие годы. Заодно перешли на стыки между коммутаторами на 100 Гб. В сети внутри ЦОД с полосой сильно проще, чем между ЦОД, – оптика и трансиверы дешевле.
DAC-кабели 10 и 25 Гбит/с — на вид не отличить
Целевая архитектура построена по топологии CLOS (Leaf&Spine). Вот старая технология объединения коммутаторов по Spanning Tree:
А вот новая:
Как видите, каждый коммутатор независим сам по себе. Есть control plane (управления) и data plane (передачи данных). Уровень управления определяется ОС коммутатора и протоколами маршрутизации и сигнализации. Уровень передачи данных характеризуется тем, что делает коммутатор с данными, передаваемыми из порта в порт.
Исторически для увеличения портовой ёмкости и в основном для возможности сбора LAG (link aggregation group — отказоустойчивый линк из двух и более физических между разными коммутаторами) использовали или отдельно стоящие коммутаторы, или коммутаторы (интерфейсные карты) в едином корпусе-шасси, или отдельные коммутаторы объединяли в виртуальное шасси. В виртуальном шасси всё удобно: единый control plane объединяет разные коммутаторы под единым управлением, и инженер видит отдельные коммутаторы как интерфейсные платы в одном шасси. Но у шасси есть и свои минусы: сильное завязывание control plane может приводить к отказу всех коммутаторов в виртуальном шасси. Это не значит, что виртуальным шасси нет места в этом мире, но для наших задач и процессов они менее удобны и надёжны.
Уровень Spine — это только передача от одного узла к другому, они не имеют клиентских подключений.
Spanning Tree — старый и проверенный временем протокол, основная цель которого – избегать петли при кольцевых топологиях. Откуда берутся петли? Посмотрите на картинку выше. Петли — результат резервирования линков. Блокируются линки, которые могут привести к кольцам — они будут использоваться только при аварии и после перестроения дерева. Можно подкручивать таймеры STP, можно применять дополнительные механизмы, ускоряющие время перестроения дерева, но всё равно останутся заблокированные линки. Проблема с перестроением дерева ещё и в потерях на время перестроения: если на 100 Мбит/c и на 100 Гбит/c в одно и то же, даже минимальное время перестроения потеряется значительно больше сигналов (данных). Использование Per VLAN Spanning Tree или регионов MSTP также не решает проблематику наших задач: у нас загрузка VLAN сильно разная — их сложно распределить раз и навсегда или автоматически по линкам.
Само по себе использование VLAN для сегментирования для нас тоже становится проблемой масштабирования: в одном домене их может быть не больше 4000. Заказчики часто строят гибридные системы: часть у себя, часть в облаке. Стыки между заказчиком и облачной инфраструктурой — в 95% случаев с использованием VLAN. Пары. А потом ещё парочку добавим. И ещё одну систему размажем до облака… И ещё одну… Пересечение VLAN на входе не проблема: можно всегда их «ремапить» (remap — изменять тег на стыке с заказчиком). А вот количество VLAN и их загрузка по линкам с использованием STP — проблема.
А альтернативы особой нет. Нужно большое шасси с множеством портов, чтобы хватило на всех! Пара (для резерва)! Но у нас много разных сегментов, которые физически даже в одном ЦОД разнесены по разным залам (это произошло по разным причинам – как архитектурным, так и «исторически сложилось»), физически подсоединить все хосты к этой парочке будет сложно, а эксплуатировать — ещё сложнее. Также при падении этой парочки мы теряем весь ЦОД в худшем из вариантов: все хосты теряют друг друга. А ещё разные сегменты требуют разные параметры по задержкам и буферизации, что сложнее достичь внутри одного шасси. Резервирование линков хостов в разные коммутаторы без MLAG не решить никак, если мы хотим резерв с VLAN. Таким образом, туннелирования трафика во VLAN недостаточно для наших задач.
Рассмотрим IEEE 802.1aq, также известный как SPB, и его «убийцу» — TRILL — открытые стандарты, а мы все любим открытые стандарты! Но поддержка у вендоров сетевого оборудования этих протоколов не очень — не любят они их. Сразу ограничиваем поставщиков до 2-3. А ещё через пару лет можем потерять их поддержку в существующих платформах или не получить в новых платформах даже тех же вендоров. Cisco FabricPath — хоть почти и TRILL, но полный vendor lock.
Что-нибудь умное, сильное и само в себе — SDN! Решения Big Switch, Plexxi или OpenFlow based — очень красивые и имеют неоспоримые плюсы. Но мы увидели в них полный vendor lock, что для нас как сервис-провайдера неприемлемо. Мы отказались от них для данного проекта.
Так мы и пришли к Leaf&Spine на IP с EVPN и VXLAN.
Тут надо отвлечься и сказать, что есть 2 варианта построения Leaf&Spine: L2-фабрика или L3-фабрика с использованием оверлеев для «пробрасывания» L2 по фабрике (увы, нам нужны оверлеи, ибо у нас не полностью наше приложение, которое может работать только по IP). Если строить L2-фабрику с резервированием узлов фабрики, то необходимо использовать VLAN, число которых ограничено 4К, при этом нет возможности использовать разные домены VLAN внутри фабрики, т.е. необходимо обеспечить их уникальность. Для топологии Active-Active также необходимо использовать Multi-Chassis Link Aggregation is utilized (MC-LAG) на всех узлах. L3-фабрика позволяет с оверлеями добиться большей гибкости, не зависит от количества и уникальности VLAN. В качестве оверлея можно использовать то, что поддерживается в ASIC сетевого оборудования (и, конечно же, в ПО коммутаторов), и сейчас это MPLS и VXLAN (RFC 7348). VXLAN необходимо «сигнализировать», для этого можно использовать multicast, EVPN, MP-BGP EVPN (Multiprotocol Border Gateway Protocol Ethernet Virtual Private Network) или контроллеры. EVPN выбран как более масштабируемый и дешёвый вариант, ибо это открытый и индустриальный стандарт — в теории позволит достичь межвендорного взаимодействия оборудования и ПО (как, например, случилось с «простым» или «основным» BGP). Протокол не вводит в корне новой сигнализации (в отличие от SPB или TRILL) и не накладывает ограничения на data plane (нет требований к иной инкапсуляции — подойдёт VXLAN или MPLS, в отличие, например, от Geneve). Протокол также не требует дополнительных возможностей или настроек типа multicast. EVPN address family включает в себя информацию и по layer 2 (MAC), и по layer 3 (IP), а также имеет механизмы ARP suppression, что совместно с локализацией MAC/ARP learning позволяет минимизировать flooding на сети за счёт EVPN децентрализован: каждое сетевое устройство строит свою топологию на основе полученных данных от «соседей». Конечно, это спорный момент: для кого-то централизация управления и решения может быть плюсом (например, наличие контроллеров а-ля SDN). EVPN позволяет достичь multihoming LAG: оконечные хосты будут «думать», что подключены к одному коммутатору. С учётом, что EVPN ещё пять лет не прожил, непонятно, насколько у него прочное будущее. В целом мы можем сменить вендора, не поменяв протоколы. Для нас важно, что часть стандарта не прибита гвоздями — она уже пятый год в режиме черновика. Некоторые вендоры реализовали даже записанные стандарты по-своему, причём каждый — в своём объёме и по своему сценарию. Ни у одного вендора нет полного набора фич новой технологии в одном месте. Например, разный набор типов маршрутов в разные направления. Код ещё не вылизан до блеска за счёт многих лет эксплуатации и большой инсталляционной базы.
Когда-нибудь зоопарк кончится
Если посмотреть на все наши решения выше, то можно увидеть, что в принципе всё это когда-нибудь решится одним более-менее внятным стандартом. Проблема в том, что вендоров много, каждый хочет своего, и сеть как таковая развивается медленно. Однажды нас, архитекторов, возможно, заменят простым скриптом, но до этого ещё очень-очень далеко.
Поэтому если вы хотите ковыряться в недокументированных возможностях железа и ПО, узнавать много нового о том, что не пишут в инструкциях, и быть бесплатным тестером для вендора — идите в сетевые архитекторы. Дабы не было «какой идиот вам это конфигурировал?», нужна командная игра с бизнесом, архитекторами, продуктологами и эксплуатацией. Например, если не поговорить с эксплуатацией, которая в целом, по логике, не нужна в процессе проектирования, то можно не узнать ряд особенностей, которые видно только тогда, когда ты крутишь гайки руками. В общем, командная игра. В общем, сетевой архитектор — он и архитектор, и переводчик, и человек, который перестраивает корабль на плаву. Только разница в том, что это его корабль, и если сработаться со всеми — будет космически классно.
Текст подготовлен Олегом Алексеенко, сетевым архитектором Техносерв Cloud.
Автор: Техносерв Cloud
