Įvertinkite vidurinėje diagramos dalyje esančius ryšius. Prie jų grįšime toliau
Tam tikru momentu galite pastebėti, kad dideli, sudėtingi L2 pagrindu veikiantys tinklai yra nepagydomi. Visų pirma, problemos, susijusios su BUM srauto apdorojimu ir STP protokolo veikimu. Antra, architektūra paprastai yra pasenusi. Tai sukelia nemalonių problemų, pasireiškiančių prastovomis ir nepatogiu valdymu.
Turėjome du lygiagrečius projektus, kur užsakovai blaiviai įvertino visus variantų pliusus ir minusus ir pasirinko du skirtingus perdangos sprendimus, o mes juos įgyvendinome.
Buvo galimybė palyginti įgyvendinimą. Ne išnaudojimas; apie tai turėtume kalbėti po dvejų ar trejų metų.
Taigi, kas yra tinklo audinys su perdangos tinklais ir SDN?
Ką daryti su aktualiomis klasikinės tinklo architektūros problemomis?
Kiekvienais metais atsiranda naujų technologijų ir idėjų. Praktiškai skubus poreikis atstatyti tinklus nekilo gana ilgai, nes galima ir viską daryti rankomis, naudojant senus gerus metodus. O kas, jei tai dvidešimt pirmas amžius? Juk administratorius turi dirbti, o ne sėdėti savo kabinete.
Tada prasidėjo didelio masto duomenų centrų statybos bumas. Tada tapo aišku, kad pasiekta klasikinės architektūros raidos riba ne tik našumo, atsparumo gedimams ir mastelio atžvilgiu. Ir vienas iš šių problemų sprendimo variantų buvo idėja sukurti perdangos tinklus ant nukreipto pagrindo.
Be to, didėjant tinklų mastui, išryškėjo tokių gamyklų valdymo problema, dėl kurios pradėjo atsirasti programinės įrangos apibrėžtų tinklo sprendimų, galinčių valdyti visą tinklo infrastruktūrą kaip vieną visumą. O kai tinklas valdomas iš vieno taško, kitiems IT infrastruktūros komponentams su juo lengviau sąveikauti, o tokius sąveikos procesus lengviau automatizuoti.
Tokių sprendimų variantų savo portfelyje turi beveik kiekvienas didesnis ne tik tinklo įrangos, bet ir virtualizacijos gamintojas.
Belieka išsiaiškinti, kas kokiems poreikiams tinka. Pavyzdžiui, ypač didelėms įmonėms, turinčioms gerą kūrimo ir eksploatavimo komandą, tiekėjų supakuoti sprendimai ne visada patenkina visus poreikius, todėl jos imasi kurti savo SD (programinės įrangos apibrėžtus) sprendimus. Pavyzdžiui, tai debesų tiekėjai, kurie nuolat plečia savo klientams teikiamų paslaugų spektrą, o supakuoti sprendimai tiesiog nepajėgia neatsilikti nuo jų poreikių.
Vidutinėms įmonėms pardavėjo siūlomo funkcionalumo dėžutės pavidalu pakanka 99 proc.
Kas yra perdangos tinklai?
Kokia yra perdangos tinklų idėja? Iš esmės pasirenkate klasikinį nukreiptą tinklą ir sukuriate kitą tinklą, kad gautumėte daugiau funkcijų. Dažniausiai kalbame apie efektyvų įrangos ir ryšio linijų apkrovos paskirstymą, ženkliai padidinamą mastelio ribą, padidiname patikimumą ir krūvą saugumo gėrybių (dėl segmentavimo). O SDN sprendimai, be to, suteikia galimybę labai, labai, labai patogiai lanksčiai administruoti ir padaryti tinklą skaidresnį jo vartotojams.
Apskritai, jei vietiniai tinklai būtų buvę išrasti 2010-aisiais, jie atrodytų gerokai kitaip, nei paveldėjome iš kariuomenės aštuntajame dešimtmetyje.
Kalbant apie audinių kūrimo technologijas naudojant perdangos tinklus, šiuo metu yra daug tiekėjų diegimų ir interneto RFC projektų (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve ir kt.). Taip, standartai yra, tačiau skirtingų gamintojų šių standartų įgyvendinimas gali skirtis, todėl kuriant tokias gamyklas, visiškai atsisakyti pardavėjo spynos dar galima tik teoriškai popieriuje.
Naudojant SD sprendimą, viskas yra dar painiau; kiekvienas pardavėjas turi savo viziją. Yra visiškai atvirų sprendimų, kuriuos teoriškai galite užbaigti patys, ir yra visiškai uždarų.
„Cisco“ siūlo savo SDN versiją duomenų centrams – ACI. Natūralu, kad tai yra 100% pardavėjo užrakintas sprendimas renkantis tinklo įrangą, tačiau tuo pat metu jis yra visiškai integruotas su virtualizacijos sistemomis, konteinerizavimu, apsauga, orkestravimu, apkrovos balansavimo įrenginiais ir kt. Tačiau iš esmės tai vis tiek yra juodosios dėžės rūšis, be galimybės visapusiškai pasiekti visus vidinius procesus. Ne visi klientai sutinka su šia galimybe, nes esate visiškai priklausomi nuo parašyto sprendimo kodo kokybės ir jo įgyvendinimo, tačiau, kita vertus, gamintojas turi vieną geriausių techninių paslaugų pasaulyje ir turi tik specialią komandą. prie šio sprendimo. Pirmojo projekto sprendimu buvo pasirinktas „Cisco ACI“.
Antram projektui buvo pasirinktas „Kadagys“ sprendimas. Gamintojas taip pat turi savo SDN duomenų centrui, tačiau klientas nusprendė neįdiegti SDN. Kaip tinklo konstravimo technologija buvo pasirinktas EVPN VXLAN audinys, nenaudojant centralizuotų valdiklių.
Kam tai
Sukūrę gamyklą galėsite sukurti lengvai keičiamą, gedimams atsparų ir patikimą tinklą. Architektūra (lapas-stuburas) atsižvelgia į duomenų centrų ypatybes (srauto kelius, sumažina vėlavimą ir tinklo kliūtis). SD sprendimai duomenų centruose leidžia labai patogiai, greitai ir lanksčiai valdyti tokią gamyklą bei integruoti į duomenų centro ekosistemą.
Abiem klientams reikėjo sukurti perteklinius duomenų centrus, kad būtų užtikrintas atsparumas gedimams, be to, srautas tarp duomenų centrų turėjo būti užšifruotas.
Pirmasis klientas jau svarstė be audinių sprendimus kaip galimą savo tinklų standartą, tačiau atliekant bandymus jiems kilo problemų dėl kelių techninės įrangos pardavėjų suderinamumo su STP. Buvo prastovų, dėl kurių paslaugos nutrūko. Ir klientui tai buvo labai svarbu.
„Cisco“ jau buvo kliento įmonės standartas, jie peržiūrėjo ACI ir kitas galimybes ir nusprendė, kad verta imtis šio sprendimo. Man patiko valdymo automatizavimas nuo vieno mygtuko per vieną valdiklį. Paslaugos sukonfigūruojamos greičiau ir valdomos greičiau. Nusprendėme užtikrinti srauto šifravimą paleisdami MACSec tarp IPN ir SPINE jungiklių. Taigi mums pavyko išvengti kliūties kriptovaliutų formoje, sutaupyti jų ir išnaudoti maksimalų pralaidumą.
Antrasis klientas pasirinko Juniper sprendimą be valdiklio, nes jų esamame duomenų centre jau buvo įdiegta nedidelė EVPN VXLAN audinys. Bet ten jis nebuvo atsparus gedimams (buvo naudojamas vienas jungiklis). Nusprendėme išplėsti pagrindinio duomenų centro infrastruktūrą ir atsarginiame duomenų centre pastatyti gamyklą. Esamas EVPN nebuvo pilnai panaudotas: VXLAN inkapsuliacija faktiškai nenaudota, nes visi kompiuteriai buvo prijungti prie vieno komutatoriaus, o visi MAC adresai ir /32 pagrindinio kompiuterio adresai buvo vietiniai, šliuzai jiems buvo tas pats jungiklis, nebuvo kitų įrenginių. , kur reikėjo statyti VXLAN tunelius. Jie nusprendė užtikrinti srauto šifravimą naudojant IPSEC technologiją tarp ugniasienės (užkardos našumas buvo pakankamas).
Jie taip pat bandė ACI, bet nusprendė, kad dėl pardavėjo užrakto jiems teks pirkti per daug techninės įrangos, įskaitant neseniai įsigytos naujos įrangos keitimą, ir tai tiesiog nebuvo ekonomiškai prasminga. Taip, „Cisco“ audinys sujungiamas su viskuo, tačiau pačiame audinyje galimi tik jo įrenginiai.
Kita vertus, kaip minėjome anksčiau, jūs negalite tiesiog maišyti EVPN VXLAN audinio su bet kuriuo kaimyniniu pardavėju, nes protokolo diegimas skiriasi. Tai tarsi „Cisco“ ir „Huawei“ kirtimas viename tinkle – atrodo, kad standartai yra įprasti, bet teks šokti su tamburinu. Kadangi tai yra bankas, o suderinamumo testai būtų labai ilgi, nusprendėme, kad dabar geriau pirkti iš to paties pardavėjo ir per daug nesijaudinti dėl funkcionalumo, išskyrus pagrindinius.
Migracijos planas
Du ACI pagrįsti duomenų centrai:
Duomenų centrų sąveikos organizavimas. Pasirinktas Multi-Pod sprendimas – kiekvienas duomenų centras yra podas. Atsižvelgiama į mastelio keitimo pagal jungiklių skaičių ir delsas tarp modulių (RTT mažiau nei 50 ms) reikalavimus. Buvo nuspręsta nekurti kelių svetainių sprendimo, kad būtų lengviau valdyti (Multi-Pod sprendimas naudoja vieną valdymo sąsają, kelių svetainių sprendimas turėtų dvi sąsajas arba jam reikės kelių svetainių orkestruotojo), ir kadangi nėra geografinio reikėjo rezervuoti aikšteles.
Paslaugų perkėlimo iš „Legacy“ tinklo požiūriu buvo pasirinktas skaidriausias variantas, palaipsniui perkeliant tam tikras paslaugas atitinkančius VLAN.
Perkėlimui gamykloje kiekvienam VLAN buvo sukurta atitinkama EPG (End-point-group). Pirma, tinklas buvo ištemptas tarp senojo tinklo ir audinio per L2, tada perkėlus visus pagrindinius kompiuterius, vartai buvo perkelti į audinį, o EPG sąveikavo su esamu tinklu per L3OUT, o sąveika tarp L3OUT ir EPG. buvo aprašyta naudojant sutartis. Apytikslė diagrama:
Daugumos ACI gamyklos politikos pavyzdinė struktūra parodyta toliau esančiame paveikslėlyje. Visa sąranka pagrįsta politika, įdėta į kitas strategijas ir pan. Iš pradžių labai sunku tai išsiaiškinti, bet palaipsniui, kaip rodo praktika, tinklo administratoriai maždaug per mėnesį pripranta prie šios struktūros, o tik tada pradeda suprasti, kaip tai patogu.
Palyginimas
„Cisco ACI“ sprendime reikia įsigyti daugiau įrangos (atskiri jungikliai Inter-Pod sąveikai ir APIC valdikliai), todėl jis brangsta. „Juniper“ sprendimui nereikėjo pirkti valdiklių ar priedų; Buvo galima iš dalies panaudoti kliento turimą įrangą.
Štai dviejų antrojo projekto duomenų centrų EVPN VXLAN audinio architektūra:
Naudodami ACI gausite paruoštą sprendimą – nereikia dirbti, nereikia optimizuoti. Pirminės kliento supažindinimo su gamykla metu nereikia jokių kūrėjų, nereikia pagalbinių žmonių kodui ir automatizavimui. Tai gana paprasta naudoti; daug nustatymų galima atlikti naudojant vedlį, o tai ne visada yra pliusas, ypač žmonėms, pripratusiems prie komandinės eilutės. Bet kokiu atveju prireikia laiko, kad smegenys atsirastų naujomis kryptimis, atsižvelgiant į nustatymų ypatumus, taikant politiką ir dirbant su daugybe įdėtų strategijų. Be to, labai pageidautina turėti aiškią strategijų ir objektų pavadinimų struktūrą. Jei valdiklio logikoje iškyla kokių nors problemų, ją galima išspręsti tik pasitelkus techninę pagalbą.
EVPN - konsolė. Kankinkitės arba džiaukitės. Pažįstama sąsaja senajai gvardijai. Taip, yra standartinė konfigūracija ir vadovai. Teks parūkyti maną. Skirtingi dizainai, viskas aišku ir detalu.
Natūralu, kad abiem atvejais migruojant geriau iš pradžių migruoti ne pačias kritiškiausias paslaugas, pavyzdžiui, testavimo aplinkas ir tik tada, sugavus visas klaidas, pereiti prie gamybos. Ir neprisijunk penktadienio vakarą. Jūs neturėtumėte pasitikėti pardavėju, kad viskas bus gerai, visada geriau žaisti saugiai.
Jūs mokate daugiau už ACI, nors Cisco šiuo metu aktyviai reklamuoja šį sprendimą ir dažnai jam suteikia gerų nuolaidų, tačiau sutaupote priežiūrai. Valdymas ir bet koks EVPN gamyklos automatizavimas be valdiklio reikalauja investicijų ir reguliarių išlaidų – stebėjimo, automatizavimo, naujų paslaugų diegimo. Tuo pačiu metu pradinis paleidimas ACI užtrunka 30–40 procentų ilgiau. Taip nutinka todėl, kad užtrunka ilgiau sukurti visą būtinų profilių ir strategijų rinkinį, kuris vėliau bus naudojamas. Tačiau augant tinklui reikalingų konfigūracijų skaičius mažėja. Naudojate iš anksto sukurtas strategijas, profilius, objektus. Galite lanksčiai konfigūruoti segmentavimą ir saugumą, centralizuotai valdyti sutartis, kurios yra atsakingos už tam tikros sąveikos tarp EPG leidimą – darbo kiekis smarkiai sumažėja.
EVPN kiekvieną įrenginį turite sukonfigūruoti gamykloje, klaidų tikimybė yra didesnė.
Nors ACI diegiamas lėčiau, EVPN derinimas užtruko beveik dvigubai ilgiau. Jei Cisco atveju visada galite paskambinti pagalbos inžinieriui ir pasiteirauti apie visą tinklą (nes jis yra padengtas kaip sprendimas), tai iš Juniper Networks perkate tik techninę įrangą, ir tai yra padengta. Ar pakuotės paliko įrenginį? Na, gerai, tada tavo problemos. Bet jūs galite atsakyti į klausimą dėl sprendimo ar tinklo dizaino pasirinkimo - tada jie jums patars įsigyti profesionalią paslaugą už papildomą mokestį.
ACI palaikymas yra labai šaunus, nes jis yra atskiras: tik tam sėdi atskira komanda. Yra ir rusakalbių specialistų. Vadovas yra išsamus, sprendimai numatyti iš anksto. Jie žiūri ir pataria. Jie greitai patvirtina dizainą, o tai dažnai yra svarbu. Juniper Networks daro tą patį, tik daug lėčiau (turėjome tokį, dabar pagal gandus turėtų būti geriau), o tai verčia patiems daryti viską, kur galėtų patarti sprendimų inžinierius.
Cisco ACI palaiko integraciją su virtualizacijos ir konteinerių sistemomis (VMware, Kubernetes, Hyper-V) ir centralizuotu valdymu. Galima su tinklo ir apsaugos paslaugomis - balansavimas, ugniasienės, WAF, IPS ir tt... Geras mikrosegmentavimas iš dėžutės. Antrajame sprendime integracija su tinklo paslaugomis yra paprasta, todėl geriau iš anksto aptarti forumus su tais, kurie tai padarė.
Visas
Kiekvienu konkrečiu atveju reikia parinkti sprendimą, ne tik atsižvelgiant į įrangos kainą, bet ir į tolimesnes eksploatacijos išlaidas bei pagrindines problemas, su kuriomis šiuo metu susiduria klientas, ir kokie ten planai. yra skirti IT infrastruktūros plėtrai.
ACI dėl papildomos įrangos kainavo brangiau, tačiau sprendimas yra paruoštas be papildomos apdailos, antrasis sprendimas yra sudėtingesnis ir eksploataciniu požiūriu brangesnis, bet pigesnis.
Jei norite aptarti, kiek gali kainuoti tinklo audinio įdiegimas įvairiems tiekėjams ir kokios architektūros reikia, galite susitikti ir pabendrauti. Patarsime nemokamai, kol gausite apytikslį architektūros eskizą (su juo galėsite skaičiuoti biudžetus), detalus apdirbimas, žinoma, jau mokamas.
Vladimiras Klepche, įmonių tinklai.
Šaltinis: www.habr.com