Оценете връзките в средната част на схемата. По-долу ще се върнем към тях.
В определен момент можете да се сблъскате с проблема, че големи сложни мрежи на базата на 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 между firewall-ите (възможностите на МСЕ бяха достатъчни).
Също така разгледаха ACI, но решиха, че заради вендор-локализацията ще трябва да закупят прекалено много оборудване, включително да заменят наскоро купеното ново, и това просто няма икономическия смисъл. Да, фабриката на Cisco интегрира всичко, но вътре в самата фабрика е възможно само нейното оборудване.
От друга страна, както беше споменато по-рано, фабрика EVPN VXLAN с какъвто и да е съседен вендор не може да се комбинира просто така, защото реализациите на протокола се различават. Това е като да смесваш Cisco и Huawei в една мрежа — сякаш стандартите са общи, само че с бубон трябва да подскачаш. Тъй като това е банка и тестовете за съвместимост биха били много дълги, решиха, че е по-добре да се снабдят с оборудване от същия вендор сега и да не се увлекат много с функционалността извън базовото.
План на миграцията
Два ЦОД-а на база ACI:
Организиране на взаимодействието между ЦОД-овете. Избрано е решение Multi-Pod — всеки ЦОД представлява под. Учили са изискванията за мащабиране по брой комутатори и закъснения между подовете (RTT под 50 ms). Решено е да не се изгражда решение Multi-Site за удобство на управлението (за решението Multi-Pod се използва един интерфейс за управление, докато за Multi-Site биха били необходими два интерфейса или Multi-Site Orchestrator), и тъй като географското резервиране на площадките не е било необходимо.
От гледна точка на миграцията на услугите от Legacy мрежата, избран е най-прозрачният вариант, да се пренасят постепенно VLAN-ите, съответстващи на определени услуги.
За миграцията на всеки VLAN е създаден съответстващ EPG (End-point-group) на фабриката. Първоначално мрежата се разширява между старата мрежа и фабриката по L2, след което, след миграцията на всички хостове, шлюзът се премества на фабриката, а взаимодействието на EPG с съществуващата мрежа се осъществява чрез L3OUT, като взаимодействието между L3OUT и EPG е описано с контракти. Примерна схема:
Примерната структура на повечето политики на фабриката ACI е показана на следващата рисунка. Цялата настройка се основава на политики, вложени в други политики и така нататък. Поначало е много трудно да се разбере, но постепенно, както показва практиката, мрежовите администратори свикват с такава структура за около месец, а след това идва и разбирането колко удобно е то.
Сравнение
При решението Cisco ACI е необходимо да се закупи повече оборудване (отделни комутатори за взаимодействие между подовете и APIC контролери), поради което то стана по-скъпо. Решението на Juniper не изискваше закупуване на контролери и допълнително оборудване; частично се използваше вече съществуващото оборудване на клиента.
Ето архитектурата на EVPN VXLAN фабриката за двата ЦОД-а от втория проект:
В ACI получавате готово решение — не е нужно да разкривате, не е нужно да оптимизирате. При първоначалното запознаване на клиента с фабриката не са нужни разработчици, не са нужни поддържащи хора за код и автоматизация. Достатъчно е само да го експлоатирате, много настройки могат да се правят дори чрез в Wizard, което не винаги е плюс, особено за хора, свикнали с командния ред. Във всеки случай е нужно време, за да се преобърне мисленето към нови релси, за особеностите на настройките чрез политики и управление на много вложени помежду си политики. Много е желателно, освен това, да имате ясна структура на именуването на политиките и обектите. При възникване на какъвто и да е проблем в логиката на работа на контролера, той може да бъде решен само чрез техническа поддръжка.
В 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, поради допълнителното оборудване, излиза по-скъпо, но решението е готово без необходимост от допълнителна настройка, второто решение е по-сложно и скъпо от гледна точка на експлоатация, но по-евтино.
Ако искате да обсъдите колко може да струва внедряването на мрежова фабрика при различни доставчици и каква архитектура е необходима — можем да се срещнем и да поговорим. До черновото на архитектурата (с която можете да считате бюджетите) ще ви посъветваме безплатно, детайлната разработка, естествено, вече е платена.
Владимир Клепче, корпоративни мрежи.
Източник: habr.com
