🥇 Опит в реализирането на мрежови фабрики на базата на EVPN VXLAN и Cisco ACI и малко сравнение

Оценете връзките в средната част на схемата. Под тях ще се върнем.

В определен момент може да се сблъскате с факта, че големи сложни мрежи на базата на L2 са неизлечимо болни. Първоначално, проблемите са свързани с обработката на BUM трафика и работата на протокола STP. Второ, архитектурата е морално остаряла. Това води до неприятни проблеми под формата на даунтайм и неудобства в управлението.

Имахме два паралелни проекта, където клиентите оцениха трезво всичките плюсове и минуси на вариантите и избраха две различни overlay решения, които след това въведохме.

Имаше възможност да се сравни именно реализацията. Не експлоатацията, за нея ще говорим след две-три години.

Така че какво е мрежова фабрика с overlay мрежи и SDN?

Какво да правим с насъбраните проблеми на класическата архитектура на мрежата?

Всяка година се появяват нови технологии и идеи. На практика, спешната необходимост от реконструкция на мрежите не е възниквала доста дълго, защото всичко може да се прави ръчно по старомодния начин. И какво от това, че сме в двадесет и първи век? В крайна сметка, администраторът трябва да работи, а не да седи в кабинета си.

След това започна бумът на строителството на мащабни дата центрове. Тогава стана ясно, че е достигнат лимитът на развитие на класическата архитектура не само по отношение на работоспособността, устойчивостта на откази и мащабируемостта. И едно от решенията на тези задачи стана идеята за изграждане на overlay мрежи върху маршрутизируемия бекбън.

Освен това, с нарастващия мащаб на мрежите, остро възникна проблемът с управлението на подобни фабрики, в резултат на което започнаха да се появяват решения за софтуерно определени мрежи с възможност за управление на цялата мрежова инфраструктура като едно цяло. А когато мрежата се управлява от една точка, на другите компоненти на ИТ инфраструктурата им е по-лесно да взаимодействат с нея и такива взаимодействия по-лесно се автоматизират.

Практически всеки голям производител не само на мрежово оборудване, но и на виртуализация, има в портфолиото си варианти на такива решения.

Остава само да разберете какво ще е подходящо за различните нужди. Например, за особено големи компании с добра разработваща и експлойтинг команда, стандартните решения на доставчиците не винаги отговарят на всички нужди и те прибягват до разработване на собствени 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 между защитните стени (производителността на MSCE беше достатъчна).

Също така разгледаха ACI, но решиха, че заради зависимостта от доставчика ще трябва да закупят твърде много оборудване, включително да заменят наскоро закупеното ново оборудване, и просто няма икономически смисъл. Да, фабриката Cisco се интегрира с всичко, но вътре в самата фабрика са възможни само нейни устройства.

От друга страна, както споменахме по-рано, фабриката EVPN VXLAN не може просто да се смеси с произволен съседен доставчик, тъй като реализацията на протокола варира. Това е като да комбинирате Cisco и Huawei в една мрежа — стандарта са общи, но ще трябва да се потрудите. Понеже става дума за банка и тестовете за съвместимост биха били много дълги, решиха, че е по-добре да закупят от същия доставчик сега и да не се увлекат с функционалността извън основната.

План за миграция

Два ЦОД-а на база ACI:

Организация на взаимодействие между ЦОД-ов. Избрано решение Multi-Pod — каждый ЦОД выступает как под. Учитываются требования к масштабируемости по количеству коммутаторов и задержкам между подами (RTT по-малко от 50 мс). Принято решение не строить решение Multi-Site для облегчения управления (для Multi-Pod решения используется единый интерфейс управления, для Multi-Site потребовалось бы два интерфейса или мульти-сайтовый оркестратор), как и отсутствие необходимости в географическом резервировании площадок.

Относительно миграции сервисов из 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 поради допълнително оборудване излиза по-скъпо, но е готово решение без нужда от доработки, докато второто решение е по-сложно и скъпо по отношение на експлоатацията, но е по-евтино.

Ако искате да обсъдим колко може да струва внедряването на мрежова фабрика при различни доставчици и каква архитектура е необходима, можем да се срещнем и да поговорим. До чернова на архитектурата (с която можете да формирате бюджетите) ще ви насочим безплатно, детайлната обработка, разбира се, вече е платна.