Оцените связки в средней части схемы. Ниже к ним вернёмся
В какой-то момент вы можете столкнуться с тем, что большие сложные сети на базе L2 неизлечимо больны. В первую очередь проблемами, связанными с обработкой BUM трафика и с работой протокола STP. Во вторую — в целом морально устаревшей архитектурой. Это вызывает неприятные проблемы в виде даунтаймов и неудобства управляемости.
У нас было два параллельных проекта, где заказчики трезво оценили все плюсы и минусы вариантов и выбрали два разных оверлейных решения, а мы их внедрили.
Была возможность сравнить именно реализацию. Не эксплуатацию, про неё стоит говорить года через два-три.
Итак, что такое сетевая фабрика с наложенными сетями и SDN?
Что делать с наболевшими проблемами классической архитектуры сети?
Каждый год появляются новые технологии и идеи. На практике горячая необходимость перестраивать сети не возникала довольно долго, потому что делать всё руками по старым добрым дедовским методам тоже можно. Ну и что, что на дворе двадцать первый век? В конце концов, админ же должен работать, а не сидеть у себя в кабинете.
Потом начался бум строительства масштабных дата-центров. Тогда стало понятно, что достигнут лимит развития классической архитектуры не только в плане работоспособности, отказоустойчивости, масштабируемости. И одним из вариантов решения этих задач стала идея построения наложенных сетей поверх маршрутизируемого бэкбона.
Помимо этого, с увеличением масштабов сетей остро встала проблема управления такими фабриками, в результате чего стали появляться решения программно-определяемых сетей с возможностью управлять всей сетевой инфраструктурой как единым целым. А когда сеть управляется из единой точки, то другим компонентам ИТ-инфраструктуры проще с ней взаимодействовать, и такие процессы взаимодействия проще автоматизировать.
Практически каждый крупный производитель не только сетевого оборудования, но и виртуализации, имеет в своём портфолио варианты таких решений.
Остаётся только разобраться, что подойдёт для каких потребностей. Например, для особо крупных компаний обладающих хорошей командой разработчиков и эксплуатации, не всегда коробочные решения от вендоров удовлетворяют всем потребностям, и они прибегают к разработке собственных SD (software defined) решений. Например, это облачные провайдеры, которые постоянно расширяют ассортимент сервисов предоставляемых своим клиентам, и коробочные решения просто не в состоянии успеть за их потребностями.
Для средних компаний, функционала, предлагаемого вендором в виде коробочного решения, хватает в 99 процентов случаев.
Что это такое оверлейные сети
В чём заключается идея оверлейных сетей. По сути, вы берёте классическую маршрутизируемую сеть и строите поверх неё ещё одну сеть, чтобы получить больше фич. Чаще всего речь об эффективном распределении нагрузки на оборудование и линии связи, значительном увеличении лимита по масштабируемости, повышении надёжности и куче плюшек в безопасности (за счёт сегментации). А SDN решения в дополнении к этому дают возможность очень, очень, очень удобного гибкого администрирования и делают сеть более прозрачной для её потребителей.
В общем, если бы локальные сети изобретали в годах этак 2010-х, то они бы выглядели далеко не так, как то, что досталось нам по наследству от военных из 1970-х.
С точки зрения технологий построения фабрик с использованием наложенных сетей, в настоящее время существует множество реализаций производителей и интернет-проектов RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve и другие). Да есть стандарты, но реализация этих стандартов различными производителями может отличаться, поэтому при создании таких фабрик полностью отказаться от вендор-лока пока можно лишь в теории на бумаге.
С SD решением дела обстоят ещё запутаннее, каждый вендор имеет своё видение. Есть полностью открытые решения, которые в теории можно допиливать самому, есть полностью закрытые.
Cisco предлагает свой вариант SDN для ЦОД — ACI. Естественно это 100 % вендор-лок решение с точки зрения выбора сетевого оборудования, но при этом оно полностью интегрируется с системами виртуализации, контейнеризации, безопасности, оркестрации, балансировщиками нагрузки и др. Но по сути это всё равно некий блэк бокс, без возможности полного доступа ко всем внутренним процессам. Не все заказчики соглашаются на такой вариант, так как ты полностью зависишь от качества написанного кода решения и его реализации, но с другой стороны производитель обладает одной из лучших в мире технических поддержек и имеет выделенную команду, занимающуюся только данным решением. В качестве решения для первого проекта был выбран именно Cisco ACI.
Для второго проекта было выбрано решение на Juniper. У производителя также есть свой SDN для ЦОД, но заказчиком было принято решение отказаться от внедрения SDN. В качестве технологии построения сети была выбрана EVPN VXLAN фабрика без использования централизованных контроллеров.
Для чего нужно
Создание фабрики позволяет построить легко масштабируемую, отказоустойчивую, надёжную сеть. Архитектура (leaf-spine) учитывает особенности центров обработки данных (пути прохождения трафика, минимизация задержек и узких мест в сети). SD решения же в ЦОДах позволяют очень удобно, быстро, гибко управлять такой фабрикой, интегрировать её в экосистему ЦОД.
Обоим заказчикам был необходимо построить резервные ЦОДы для обеспечения отказоустойчивости, помимо этого трафик между ЦОДами должен был шифроваться.
Первый заказчик уже рассматривал решения без фабрики как возможный стандарт своих сетей, но на тестах у них были проблемы с совместимостью STP между несколькими вендорами железа. Возникали даунтаймы, которые вызывали падения сервисов. А для заказчика это было критично.
Cisco уже была корпоративным стандартом заказчика, они присмотрелись к ACI и другим вариантам и решили, что стоит взять именно это решение. Понравилась автоматизация управления с одной кнопки через единый контроллер. Быстрее настраиваются сервисы, быстрее управляются. Шифрование трафика решили обеспечить запустив MACSec между коммутаторами IPN и SPINE. Таким образом удалось избежать узкого места в виде криптошлюза, сэкономить на них и использовать по максимуму полосу пропускания.
Второй заказчик выбрал решение без контроллера от Juniper, поскольку в их существующем ЦОД уже была небольшая инсталляция с реализацией фабрики EVPN VXLAN. Но там она не была отказоустойчивой (использовался один коммутатор). Приняли решение расширить инфраструктуру основного ЦОД и построить фабрику в резервном ЦОД. Имеющийся EVPN не использовался в полной мере: инкапсуляция VXLAN фактически не применялась, так как все хосты были подключены к одному коммутатору, и все MAC-адреса и /32 адреса хостов были локальными, шлюзом для них являлся этот же коммутатор, не было других устройств, куда необходимо было строить VXLAN тоннели. Шифрование трафика решили обеспечить с использованием технологии IPSEC между файрволами (производительности МСЭ было достаточно).
Тоже пощупали ACI, но решили, что из-за вендор-лока придётся покупать слишком много железа, в том числе заменять недавно купленное новое оборудование, и это просто не имеет экономического смысла. Да, фабрика Cisco интегрируется со всем, но внутри самой фабрики возможны только её устройства.
С другой стороны, как говорили ранее, EVPN VXLAN фабрику с любым соседним вендором просто так не смешаешь, потому что реализации протокола отличаются. Это как скрещивать Cisco и Хуавей в одной сети — вроде бы, стандарты общие, только с бубном поплясать придётся. Поскольку это банк, и тесты на совместимость были бы очень долгими, решили, что лучше закупиться тем же вендором сейчас, и не особо увлекаться функционалом за пределами базового.
План миграции
Два ЦОДа на базе ACI:
Организация взаимодействия между ЦОДами. Выбрано Multi-Pod решение — каждый ЦОД является подом. Учтены требования к масштабированию по количеству коммутаторов и к задержкам между подами (RTT менее 50 мс). Было принято решение не строить Multi-Site решение для удобства управления (для Multi-Pod решения используется единый интерфейс управления, для Multi-Site было бы два интерфейса, либо потребовался бы Multi-Site Orchestrator), и так как не требовалось географического резервирования площадок.
С точки зрения миграции сервисов из Legacy сети, был выбран наиболее прозрачный вариант, переносить постепенно VLAN соответствующие определённым сервисам.
Для миграции каждому VLAN создавался соответствующий EPG (End-point-group) на фабрике. Сначала сеть растягивалась между старой сетью и фабрикой по L2, затем после миграции всех хостов, шлюз переносился на фабрику, и взаимодействие EPG с существующей сетью производилось через L3OUT, при этом взаимодействие между L3OUT и EPG описывалось с использованием контрактов. Примерная схема:
Примерная структура большинства политик фабрики ACI на рисунке ниже. Вся настройка строится на политиках, вложенных в другие политики и так далее. Поначалу очень непросто разобраться, но постепенно, как показывает практика, администраторы сети привыкают к такой структуре примерно за месяц, и потом только приходит понимание насколько она удобна.
Сравнение
В решении Cisco ACI нужно покупать больше оборудования (отдельные коммутаторы для Inter-Pod взаимодействия и APIC контроллеры), за счёт чего оно получилось дороже. Решение Juniper не потребовало покупку контроллеров и вспомогательного оборудования; получилось частично использовать уже существующее оборудование заказчика.
Вот архитектура EVPN VXLAN фабрики для двух ЦОДов второго проекта:
В ACI ты получаешь готовое решение — не надо ковырять, не надо оптимизировать. При первоначальном знакомстве заказчика с фабрикой не нужны разработчики, не нужны поддерживающие люди для кода и автоматизации. Достаточно просто эксплуатации, многие настройки можно делать вообще через визард, что не всегда плюс, особенно для людей, привыкших к командной строке. В любом случае нужно время для того, чтобы перестроить на новые рельсы, на особенность настроек через политики и оперированием множества вложенных друг в друга политик. Очень желательно, помимо этого, ещё иметь чёткую структуру наименования политик и объектов. При возникновении какой-либо проблемы в логике работы контроллера, её решить можно только через техподдержку.
В EVPN — консоль. Страдай или радуйся. Привычный интерфейс для старой гвардии. Да, есть типовая конфигурация и гайды. Придётся курить маны. Разные конструкции, всё понятно и детально.
Естественно, в обоих случаях лучше при миграции сначала мигрировать не самые критичные сервисы, например, тестовые среды, и только потом после поимки всех багов приступать к проду. И не настраивать в пятницу вечером. Не стоить верить вендору, что все будет ок, всегда лучше подстраховаться.
На ACI платишь больше, хотя в настоящее время Cisco активно продвигает это решение и зачастую даёт хорошие скидки на него, но экономишь на обслуживании —сопровождении. Управление и какая-либо автоматизация EVPN фабрики без контроллера требует вложений и регулярных затрат — мониторинг, автоматизация, внедрение новых сервисов. При этом первичный запуск у ACI делается дольше на 30–40 процентов. Это происходит потому, что дольше создаётся весь набор необходимых профилей и политик, которые затем будут использоваться. Но по мере роста сети количество нужных конфигураций уменьшается. Используешь уже заранее созданные политики, профили, объекты. Можешь гибко настраивать сегментацию и безопасность, централизованно управлять контрактами, которые отвечают за разрешение тех или иных взаимодействий между EPG, — объём работы резко падает.
В EVPN надо конфигурировать каждое устройство в фабрике, вероятность ошибки больше.
Если ACI медленнее внедряется, то EVPN почти вдвое дольше отлаживался. Если в случае с Cisco всегда можно позвать инженера поддержки и спросить про сеть в целом (потому что покрывается как решение), то у Juniper Networks вы покупаете только железо, и покрывается именно оно. Пакеты с устройства ушли? Ну ок, дальше ваши проблемы. Но можно открыть вопрос по выбору решения или дизайну сети — и тогда посоветуют приобрести профешнл сервис, за дополнительную плату.
ACI поддержка очень крутая, потому что отдельная: отдельная команда сидит только для этого. Есть, в том числе и русскоязычные спецы. Гайд подробный, решения предопределены. Смотрят и советуют. Быстро валидируют дизайн, что часто важно. Juniper Networks делают то же самое, но в разы медленнее (у нас было так, сейчас должно быть лучше по слухам), что заставляет тебя самостоятельно делать всё там, где мог бы посоветовать солюшн-инженер.
Cisco ACI поддерживает интеграцию с системами виртуализации и контейнеризации (VMware, Kubernetes, Hyper-V) и централизованное управление. Есть с сетевыми сервисами и сервисами безопасности — балансировка, межсетевые экраны, WAF, IPS и прочее… Хорошая микросегментация из коробки. Во втором решении интеграция с сетевыми сервисами проходится с бубном, и лучше заранее курить форумы с теми, кто так делал.
Итог
Для каждого конкретного случая необходимо подбирать решение, не только исходя из стоимости оборудовании, но и необходимо учитывать также дальнейшие расходы на эксплуатацию и основные проблемы, с которыми сталкивается заказчик сейчас, и какие есть планы по развитию ИТ-инфраструктуры.
ACI за счёт дополнительного оборудования вышел дороже, но решение готовое без необходимости допиливания, второе решение более сложно и затратно с точки зрения эксплуатации, но дешевле.
Если хотите обсудить, сколько может стоить внедрение сетевой фабрики на разных вендорах, и какая нужна архитектура, — можно встретиться и пообщаться. До чернового наброска архитектуры (с которым можно считать бюджеты) подскажем бесплатно, детальная проработка, естественно, уже платная.
Владимир Клепче, корпоративные сети.
Автор: TS_IT
