Hinnake diagrammi keskosas olevaid ühendusi. Nende juurde tuleme allpool tagasi
Mingil hetkel võite avastada, et suured keerulised L2-põhised võrgud on lõplikult haiged. Esiteks probleemid, mis on seotud BUM-liikluse töötlemise ja STP-protokolli toimimisega. Teiseks on arhitektuur üldiselt vananenud. See põhjustab ebameeldivaid probleeme seisakute ja ebamugava käsitsemise näol.
Meil oli kaks paralleelset projekti, kus kliendid hindasid kainelt kõiki variantide poolt- ja vastuargumente ning valisid kaks erinevat kattelahendust ning me need ellu viisime.
Teostust oli võimalus võrrelda. Mitte ekspluateerimine, me peaksime sellest rääkima kahe või kolme aasta pärast.
Niisiis, mis on ülekattevõrkude ja SDN-iga võrgukangas?
Mida teha klassikalise võrguarhitektuuri pakiliste probleemidega?
Igal aastal ilmuvad uued tehnoloogiad ja ideed. Praktikas ei tekkinud kiiret vajadust võrkude ümberehitamiseks päris pikka aega, sest võimalik on ka kõike käsitsi teha vanade heade meetoditega. Mis siis, kui käes on kahekümne esimene sajand? Administraator peaks ju töötama, mitte oma kontoris istuma.
Seejärel algas suuremahuliste andmekeskuste ehitamise buum. Siis sai selgeks, et klassikalise arhitektuuri arengupiir on saavutatud, mitte ainult jõudluse, veataluvuse ja skaleeritavuse osas. Ja üks nende probleemide lahendamise võimalustest oli idee ehitada ülekattevõrgud marsruuditud magistraalvõrgu peale.
Lisaks on võrkude mastaabi suurenedes teravaks muutunud selliste tehaste haldamise probleem, mille tulemusena hakkasid tekkima tarkvarapõhised võrgulahendused, mis võimaldavad hallata kogu võrgutaristut ühtse tervikuna. Ja kui võrku hallatakse ühest punktist, on IT-taristu teistel komponentidel lihtsam sellega suhelda ning selliseid interaktsiooniprotsesse on lihtsam automatiseerida.
Peaaegu kõigil suurematel mitte ainult võrguseadmete, vaid ka virtualiseerimise tootjatel on selliste lahenduste portfellis valikud.
Jääb üle vaid välja mõelda, mis millistele vajadustele sobib. Näiteks eriti suurte ettevõtete jaoks, kellel on hea arendus- ja operatiivmeeskond, ei rahulda tarnijate pakitud lahendused alati kõiki vajadusi ja nad kasutavad oma SD (tarkvaraga määratletud) lahendusi. Näiteks on tegemist pilveteenuse pakkujatega, kes oma klientidele pakutavate teenuste valikut pidevalt laiendavad ning pakettlahendused lihtsalt ei suuda nende vajadustega sammu pidada.
Keskmise suurusega ettevõtetele piisab 99 protsendil juhtudest müüja pakutavast funktsionaalsusest kastilahenduse näol.
Mis on ülekattevõrgud?
Mis on ülekattevõrkude idee? Põhimõtteliselt võtate klassikalise marsruudiga võrgu ja ehitate selle peale veel ühe võrgu, et saada rohkem funktsioone. Kõige sagedamini räägime seadmete ja sideliinide koormuse tõhusast jaotusest, skaleeritavuse piiri olulisest suurendamisest, töökindluse suurendamisest ja hunnikust turvalisusest (segmenteerimise tõttu). Ja SDN lahendused annavad lisaks sellele võimaluse väga-väga-väga mugavaks paindlikuks asjaajamiseks ning muudavad võrgu selle tarbijate jaoks läbipaistvamaks.
Üldiselt, kui kohalikud võrgud oleks leiutatud 2010. aastatel, oleksid need palju teistsugused kui 1970. aastatel sõjaväelt päritud.
Ülekattevõrke kasutades kangaste ehitamise tehnoloogiate osas on praegu palju tarnijate rakendusi ja Interneti-RFC-projekte (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve ja teised). Jah, standardid on olemas, kuid nende standardite rakendamine erinevate tootjate poolt võib erineda, nii et selliste tehaste loomisel on siiski võimalik müüja lukust täielikult loobuda ainult teoreetiliselt paberil.
SD-lahendusega on asjad veelgi segasemad; igal müüjal on oma nägemus. On täiesti avatud lahendusi, mida teoreetiliselt saate ise täiendada, ja on täiesti suletud lahendusi.
Cisco pakub andmekeskuste jaoks oma SDN-i versiooni – ACI. Loomulikult on see võrguseadmete valiku osas 100% müüja lukustatud lahendus, kuid samal ajal on see täielikult integreeritud virtualiseerimissüsteemide, konteinerite, turvalisuse, orkestratsiooni, koormuse tasakaalustajatega jne. Kuid sisuliselt on see siiski omamoodi must kast, millel puudub täielik juurdepääs kõikidele sisemistele protsessidele. Mitte kõik kliendid ei nõustu selle valikuga, kuna olete täielikult sõltuv kirjaliku lahenduskoodi kvaliteedist ja selle rakendamisest, kuid teisest küljest on tootjal üks maailma parimaid tehnilisi tugiteenuseid ja tal on ainult pühendunud meeskond. sellele lahendusele. Esimese projekti lahenduseks valiti Cisco ACI.
Teiseks projektiks valiti Kadakas lahendus. Tootjal on andmekeskuse jaoks ka oma SDN, kuid klient otsustas SDN-i mitte juurutada. Võrgu ehitamise tehnoloogiaks valiti EVPN VXLAN kangas ilma tsentraliseeritud kontrollereid kasutamata.
Milleks see mõeldud on
Tehase loomine võimaldab ehitada kergesti skaleeritava, tõrketaluva ja töökindla võrgu. Arhitektuur (leaf-spine) võtab arvesse andmekeskuste omadusi (liiklusteed, viivituste ja kitsaskohtade minimeerimine võrgus). SD-lahendused andmekeskustes võimaldavad sellist tehast väga mugavalt, kiiresti ja paindlikult hallata ning integreerida andmekeskuse ökosüsteemi.
Mõlemal kliendil oli tõrketaluvuse tagamiseks vaja ehitada üleliigsed andmekeskused ning lisaks tuli andmekeskuste vaheline liiklus krüpteerida.
Esimene klient kaalus juba kangata lahendusi oma võrkude võimaliku standardina, kuid testides tekkis neil probleeme mitme riistvaramüüja STP ühilduvusega. Esinesid seisakud, mis põhjustasid teenuste krahhi. Ja kliendi jaoks oli see kriitiline.
Cisco oli juba kliendi ettevõtte standard, nad vaatasid ACI ja muid võimalusi ning otsustasid, et tasub seda lahendust kasutada. Mulle meeldis juhtimise automatiseerimine ühest nupust ühe kontrolleri kaudu. Teenused konfigureeritakse kiiremini ja hallatakse kiiremini. Otsustasime tagada liikluse krüptimise, käivitades IPN-i ja SPINE-lülitite vahel MACSec. Seega õnnestus meil vältida krüptovärava näol tekkivat kitsaskohta, säästa nende pealt ja kasutada maksimaalset ribalaiust.
Teine klient valis Juniperi kontrollerita lahenduse, kuna nende olemasolevas andmekeskuses oli juba väike installatsioon, mis rakendas EVPN VXLAN kangast. Aga seal ei olnud see tõrketaluv (kasutati ühte lülitit). Otsustasime laiendada peamise andmekeskuse infrastruktuuri ja rajada varuandmekeskusesse tehase. Olemasolevat EVPN-i ei kasutatud täielikult: VXLAN-i kapseldamist ei kasutatud, kuna kõik hostid olid ühendatud ühe lülitiga ning kõik MAC-aadressid ja /32 hostiaadressid olid kohalikud, nende lüüsiks oli sama lüliti, muid seadmeid polnud , kuhu oli vaja ehitada VXLAN tunnelid. Nad otsustasid tagada tulemüüridevahelise IPSEC-tehnoloogia abil liikluse krüptimise (tulemüüri jõudlus oli piisav).
Nad proovisid ka ACI-d, kuid otsustasid, et müüja lukustuse tõttu peavad nad ostma liiga palju riistvara, sealhulgas hiljuti ostetud uusi seadmeid välja vahetama, ja see polnud lihtsalt majanduslikult mõttekas. Jah, Cisco kangas integreerub kõigega, kuid kangas endas on võimalikud ainult selle seadmed.
Teisest küljest, nagu me varem ütlesime, ei saa te lihtsalt segada EVPN VXLAN-kangast ühegi naabermüüjaga, kuna protokolli rakendused on erinevad. See on nagu Cisco ja Huawei ristumine ühes võrgus – näib, et standardid on tavalised, kuid peate tantsima tamburiiniga. Kuna tegemist on pangaga ja ühilduvustestid veniksid väga pikaks, siis otsustasime, et parem on osta kohe samalt müüjalt ja mitte lasta end liigselt kaasa funktsionaalsusele peale põhifunktsioonide.
Rändeplaan
Kaks ACI-põhist andmekeskust:
Andmekeskuste vahelise suhtluse korraldamine. Valituks sai lahendus Multi-Pod – iga andmekeskus on pod. Arvesse on võetud nõudeid skaleerimisele lülitite arvu ja podide vaheliste viivituste järgi (RTT alla 50 ms). Otsustati mitte ehitada Multi-Site lahendust haldamise hõlbustamiseks (Multi-Podi lahendus kasutab ühte haldusliidest, Multi-Site oleks kahe liidesega või vajaks Multi-Site Orchestratorit) ja kuna puudub geograafiline saite oli vaja broneerida.
Legacy võrgust teenuste migreerimise seisukohalt valiti kõige läbipaistvam variant, kandes järk-järgult üle teatud teenustele vastavad VLAN-id.
Migratsiooni jaoks loodi tehases iga VLAN-i jaoks vastav EPG (End-point-group). Esiteks venitati võrk vana võrgu ja kanga vahel üle L2, seejärel pärast kõigi hostide migreerimist viidi lüüs kangasse ja EPG suhtles olemasoleva võrguga L3OUT kaudu, samal ajal kui L3OUT ja EPG vaheline interaktsioon. kirjeldati lepingute abil. Ligikaudne diagramm:
Enamiku ACI tehasepoliitikate näidisstruktuur on näidatud alloleval joonisel. Kogu seadistus põhineb teistes poliitikates sisalduvatel poliitikatel ja nii edasi. Alguses on seda väga raske välja mõelda, kuid järk-järgult, nagu praktika näitab, harjuvad võrguadministraatorid selle struktuuriga umbes kuuga ja alles siis hakkavad nad aru saama, kui mugav see on.
Võrdlus
Cisco ACI lahenduses tuleb juurde osta seadmeid (eraldi lülitid Inter-Pod interaktsiooni ja APIC kontrollerite jaoks), mis teeb selle kallimaks. Juniperi lahendus ei nõudnud kontrollerite ega tarvikute ostmist; Osaliselt oli võimalik kasutada kliendi olemasolevat tehnikat.
Siin on teise projekti kahe andmekeskuse EVPN VXLAN kangaarhitektuur:
ACI-ga saate valmis lahenduse – pole vaja nokitseda, pole vaja optimeerida. Kliendi esmase tehasega tutvumise ajal pole vaja arendajaid, pole vaja toetavaid inimesi koodi ja automatiseerimise jaoks. Seda on üsna lihtne kasutada; viisardi kaudu saab teha palju sätteid, mis pole alati pluss, eriti käsureaga harjunud inimeste jaoks. Igal juhul võtab aju ümberehitamine uutele radadele, seadete iseärasustele läbi poliitikate ja paljude pesastatud poliitikatega töötamise aega. Lisaks sellele on väga soovitav selge struktuur poliitikate ja objektide nimetamiseks. Kui kontrolleri loogikas tekib mõni probleem, saab seda lahendada ainult tehnilise toe kaudu.
EVPN-is - konsool. Kannatage või rõõmustage. Vanale kaardiväele tuttav liides. Jah, on olemas standardkonfiguratsioon ja juhendid. Sa pead mana suitsetama. Erinevad kujundused, kõik on selge ja detailne.
Loomulikult on mõlemal juhul migreerimisel parem migreerida esmalt mitte kõige kriitilisemad teenused, näiteks testkeskkonnad, ja alles seejärel, pärast kõigi vigade tuvastamist, asuda tootmisse. Ja ärge hääletage reede õhtul. Te ei tohiks müüjat usaldada, et kõik läheb hästi, alati on parem tegutseda.
Maksate ACI eest rohkem, kuigi Cisco propageerib praegu aktiivselt seda lahendust ja annab sellele sageli häid allahindlusi, kuid säästate hoolduselt. Ilma kontrollerita EVPN-i tehase juhtimine ja igasugune automatiseerimine nõuab investeeringuid ja regulaarseid kulusid - jälgimist, automatiseerimist, uute teenuste juurutamist. Samal ajal võtab esialgne käivitamine ACI-s 30–40 protsenti kauem aega. See juhtub seetõttu, et kogu vajalike profiilide ja poliitikate komplekti loomine, mida seejärel kasutatakse, võtab kauem aega. Kuid võrgu kasvades väheneb vajalike konfiguratsioonide arv. Kasutate eelnevalt loodud poliitikaid, profiile, objekte. Saate paindlikult konfigureerida segmenteerimist ja turvalisust, hallata keskselt lepinguid, mis vastutavad teatud interaktsioonide võimaldamise eest EPG-de vahel – töömaht väheneb järsult.
EVPN-is peate iga seadme tehases konfigureerima, vigade tõenäosus on suurem.
Kui ACI juurutamine oli aeglasem, kulus EVPN-i silumiseks peaaegu kaks korda kauem. Kui Cisco puhul saab alati helistada tugiinsenerile ja küsida võrgu kui terviku kohta (sest see on lahendusena kaetud), siis Juniper Networksist ostad ainult riistvara ja see on see, mis on kaetud. Kas pakid on seadmest lahkunud? Olgu, siis teie probleemid. Kuid võite avada küsimuse lahenduse või võrgukujunduse valiku kohta - ja siis soovitatakse teil osta lisatasu eest professionaalne teenus.
ACI tugi on väga lahe, sest see on eraldi: selleks istub eraldi meeskond. On ka vene keelt kõnelevaid spetsialiste. Juhend on üksikasjalik, lahendused on ette määratud. Vaatavad ja annavad nõu. Nad kinnitavad disaini kiiresti, mis on sageli oluline. Juniper Networks teeb sama asja, aga palju aeglasemalt (meil oli selline, nüüd peaks kuulujuttude järgi parem olema), mis sunnib kõike ise tegema, kus lahendusinsener nõu oskaks anda.
Cisco ACI toetab integreerimist virtualiseerimis- ja konteinersüsteemidega (VMware, Kubernetes, Hyper-V) ja tsentraliseeritud haldusega. Saadaval koos võrgu- ja turvateenustega - tasakaalustamine, tulemüürid, WAF, IPS jne... Hea mikrosegmentatsioon karbist välja. Teise lahenduse puhul on võrguteenustega integreerimine imelihtne ja parem on foorumid eelnevalt läbi arutada nendega, kes on seda teinud.
Summaarne
Igaks konkreetseks juhtumiks on vaja valida lahendus, mitte ainult seadmete maksumuse põhjal, vaid tuleb arvestada ka edasiste tegevuskuludega ja peamiste probleemidega, millega klient parasjagu silmitsi seisab, ja sellega kaasnevaid plaane. on IT infrastruktuuri arendamiseks.
ACI oli lisavarustuse tõttu kallim, kuid lahendus on valmis ilma täiendava viimistluseta, teine lahendus on keerulisem ja ekspluatatsioonilt kulukam, kuid odavam.
Kui soovite arutada, kui palju võib võrgukanga juurutamine erinevatel tarnijatel maksma minna ja millist arhitektuuri on vaja, võite kohtuda ja vestelda. Nõustame teid tasuta, kuni saate umbkaudse arhitektuurivisandi (mille abil saate eelarveid arvutada), detailne väljatöötamine on muidugi juba tasuline.
Vladimir Klepche, ettevõtete võrgud.
Allikas: www.habr.com