Оценете връзките в средната част на веригата. Ще се върнем към тях по-долу.
В даден момент може да откриете, че големи сложни мрежи, базирани на L2, са неизлечимо болни. На първо място, проблеми, свързани с обработката на BUM трафик и работата на STP протокола. Във втория - като цяло, морално остаряла архитектура. Това причинява неприятни проблеми под формата на престой и неудобство при работа.
Имахме два паралелни проекта, при които клиентите трезво прецениха всички плюсове и минуси на опциите и избраха две различни наслагващи решения, които ние внедрихме.
Беше възможно да се сравни изпълнението. Не операция, струва си да говорим за това след две или три години.
И така, какво е мрежова структура с насложени мрежи и SDN?
Какво да правим с наболелите проблеми на класическата мрежова архитектура?
Всяка година се появяват нови технологии и идеи. На практика спешната необходимост от възстановяване на мрежите не възникна дълго време, защото можете да направите всичко и на ръка, като използвате добрите стари методи на дядо. И какво, какво е двадесет и първи век в двора? В крайна сметка администраторът трябва да работи, а не да седи в кабинета си.
Тогава започва бум в изграждането на мащабни центрове за данни. Тогава стана ясно, че пределът на развитието на класическата архитектура е достигнат, не само по отношение на производителност, отказоустойчивост, скалируемост. И една от възможностите за решаване на тези проблеми беше идеята за изграждане на мрежи с наслагване върху маршрутизиран гръбнак.
В допълнение, с увеличаването на мащаба на мрежите, проблемът с управлението на такива фабрики стана остър, в резултат на което започнаха да се появяват софтуерно дефинирани мрежови решения с възможност за управление на цялата мрежова инфраструктура като цяло. И когато мрежата се управлява от една точка, е по-лесно за други компоненти на ИТ инфраструктурата да взаимодействат с нея и такива процеси на взаимодействие са по-лесни за автоматизиране.
Почти всеки голям производител не само на мрежово оборудване, но и на виртуализация, има опции за такива решения в своето портфолио.
Остава само да разберем какво е подходящо за какви нужди. Например, за особено големи компании с добър екип за разработка и експлоатация, готовите решения на доставчиците не винаги задоволяват всички нужди и те прибягват до разработването на свои собствени SD (софтуерно дефинирани) решения. Например, това са облачни доставчици, които непрекъснато разширяват набора от услуги, предоставяни на своите клиенти, а кутийните решения просто не са в състояние да се справят с техните нужди.
За средни компании функционалността, предлагана от доставчика под формата на решение в кутия, е достатъчна в 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 между защитните стени (производителността на ITU беше достатъчна).
Те също опитаха ACI, но решиха, че поради блокирането на доставчика ще трябва да купуват твърде много хардуер, включително замяна на наскоро закупено ново оборудване, и това просто няма икономически смисъл. Да, платът на Cisco се интегрира с всичко, но само неговите устройства са възможни вътре в самия плат.
От друга страна, както споменахме по-рано, не можете просто да смесите EVPN VXLAN фабрика с всеки съседен доставчик, тъй като реализациите на протокола са различни. Това е като да пресечеш Cisco и Huawei в една и съща мрежа - изглежда, че стандартите са общи, само трябва да танцуваш с тамбура. Тъй като това е банка и тестовете за съвместимост ще бъдат много дълги, решихме, че е по-добре да купим от същия доставчик сега и да не се увличаме с функционалност извън базовата.
План за миграция
Два центъра за данни, базирани на ACI:
Организация на взаимодействието между центровете за данни. Избрано е Multi-Pod решение – всеки център за данни е pod. Взети са под внимание изискванията за мащабиране чрез броя на превключванията и закъсненията между модулите (RTT по-малко от 50 ms). Беше решено да не се изгражда Multi-Site решение за по-лесно управление (използва се един интерфейс за управление за Multi-Pod решение, за Multi-Site ще има два интерфейса или ще се изисква Multi-Site Orchestrator), и тъй като не е необходимо географско резервиране на обекти.
От гледна точка на миграцията на услуги от наследената мрежа беше избран най-прозрачният вариант, постепенно прехвърляне на VLAN, съответстващи на определени услуги.
За миграция е създаден съответен EPG (End-point-group) за всяка VLAN фабрично. Първо, мрежата беше опъната между старата мрежа и фабриката по 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 поради допълнително оборудване излезе по-скъпо, но решението е готово без необходимост от допълнително рязане, второто решение е по-сложно и скъпо по отношение на експлоатацията, но по-евтино.
Ако искате да обсъдите колко може да струва внедряването на мрежова фабрика на различни доставчици и какъв вид архитектура е необходима, можете да се срещнете и да поговорите. Преди грубата скица на архитектурата (с която можете да изчислите бюджетите), ние ще ви дадем безплатен съвет, подробното проучване, разбира се, вече е платено.
Владимир Клепче, корпоративни мрежи.
Източник: www.habr.com