Ацэніце звязкі ў сярэдняй частцы схемы. Ніжэй да іх вернемся
У нейкі момант вы можаце сутыкнуцца з тым, што вялікія складаныя сеткі на базе 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 за кошт дадатковага абсталявання выйшаў даражэй, але рашэнне гатовае без неабходнасці дапілоўвання, другое рашэнне больш складана і затратна з пункту гледжання эксплуатацыі, але танней.
Калі хочаце абмеркаваць, колькі можа каштаваць ўкараненне сеткавай фабрыкі на розных вендарах, і якая патрэбна архітэктура, - можна сустрэцца і пагутарыць. Да чарнавога накіда архітэктуры (з якім можна лічыць бюджэты) падкажам бясплатна, дэталёвая прапрацоўка, натуральна, ужо платная.
Уладзімір Клепчэ, карпаратыўныя сеткі.
Крыніца: habr.com