Hinnake skeemi keskmise osa seoseid. Kohtume nendega hiljem.
Mingil hetkel võite sattuda olukorda, kus suured keerulised L2 võrgud on ravimatult haiged. Esiteks probleemid, mis on seotud BUM liikluse töötlemise ja STP protokolli toimimisega. Teiseks – üldiselt moraalselt vananenud arhitektuuriga. See toob kaasa ebameeldivaid probleeme nagu seisakud ja halva haldamise mugavus.
Meil oli kaks paralleelset projekti, kus tellijad hindasid objektiivselt kõiki võimaluste plusse ja miinuseid ning valisid kaks erinevat overlay lahendust, mille me juurutame.
Oli võimalik võrrelda just teostust. Mitte kasutust, sellest tuleb rääkida paar aastat hiljem.
Nii et mis on overlay-võrk ja SDN?
Mis teha traditsioonilise võrguarhitektuuri põletavate probleemidega?
Igal aastal tekivad uued tehnoloogiad ja ideed. Praktikas pole olnud äraootavat vajadust võrguside ümberkorraldamiseks juba pikka aega, sest kõik on võimalik teha ka käsitsi vanade heade meetoditega. Ja mis siis, et on 21. sajand? Lõppude lõpuks peab adminn ju töötama, mitte istuma oma kabinetis.
Siis algas suur andmekeskuste ehitamise buum. Siis sai selgeks, et traditsioonilise arhitektuuri arengul on saavutatud piir mitte ainult töökindluse, talitluse ja skaaleerimise osas. Ükskõikne lahendus nende probleemide lahendamiseks oli idee luua overlay-võrgud marsruutimisvõrgu peale.
Lisaks sellele, kui võrgud suurenevad, kerkib äärmiselt terav probleem selliste tehaste haldamisega, mille tulemusena ilmnevad lahendused programmide määratud võrgus, mille kaudu on võimalik kogu võrguinfrastruktuuri hallata kui ühte tervikut. Ja kui võrk on hallatav ühes punktis, on muudel IT-infrastruktuuri komponentidel kergem temaga suhelda, ja selliseid suhtlemisprotsesse on lihtsam automatiseerida.
Praktiselt iga suur tootja mitte ainult võrguseadmete, vaid ka virtualiseerimise valdkonnas, omab oma portfellis sellise lahendusi.
Küsimus on, millised vajadused sobivad. Näiteks väga suurtele ettevõtetele, kellel on hea arendajate ja haldamise meeskond, ei rahulda alati müüjad pakutavad lahendused kõiki vajadusi, ja nad arendavad oma SD (tarkvara määratud) lahendusi. Näiteks on see pilveteenuste pakkujad, kes pidevalt laiendavad oma klientidele pakutavate teenuste valikut, ja valmis lahendused ei suuda lihtsalt nende nõudlustes järgi jõuda.
Keskmiste ettevõtete jaoks piisab enamikul juhtudel müüjate poolt pakutavatest lahendustest 99 protsendi ulatuses.
Mis on overlay-võrgud?
Milles seisneb overlay-võrkude idee? Sisuliselt võtate klassikalise marsruutimisvõrgu ja ehitate selle peale veel ühe võrgu, et saada rohkem omadusi. Tihti räägime seadmete ja sidekanalite koormuse tõhusast jaotusest, maksimaalsest laiendamisvõime suurendamisest, töökindluse suurendamisest ja mitmest turvalisuse eelise (segmenteerimise tõttu). SDN lahendused lisaks sellele annavad väga, väga paindlikud haldamisvõimalused ja muudavad võrgu oma tarbijatele läbipaistvamaks.
Kokkuvõttes, kui kohalikud võrgud oleksid välja töötatud umbes 2010. aastatel, ei näeks nad kindlasti välja nagu need, mis meile on jäänud 1970. aastate sõjaväelt.
Tehnoloogiate seisukohalt, mis on seotud overlay-võrkude tootmisega, on praegu käibel mitmed teostused tootjatelt ja Interneti projektide RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve jne). Jah, on standardid, kuid nende standardite rakendamine erinevate tootjate poolt võib varieeruda, seega overlay-võrkude loomisel oleks võimalik täielikult loobuda vendori lukust ainult teoorias esitatud paberil.
SD lahendused on veelgi keerulisemad, igal tootjal on oma nägemus. On täiesti avatud lahendusi, mida teoreetiliselt saab ise täiustada, ja on täiesti suletud lahendusi.
Cisco pakub oma lahendust SDN kohta andmekeskustes - ACI. Loomulikult on see 100% tarnijapoolne lahendus võrguseadmete valiku osas, kuid samas integreerub see täielikult virtualiseerimise, konteinerimise, turvalisuse, orkestreerimise, koormuse tasakaalustamise ja muude süsteemidega. Kuid sisuliselt on see ikkagi must kast, ilma võimaluseta täielikult kõiki sisemisi protsesse juurde pääseda. Mitte kõik tellijad ei ole sellise lahendusega nõus, kuna sõltud täielikult lahenduse koodi kvaliteedist ja selle rakendamisest, kuid teisest küljest on tootjal üks parimaid tehnilisi tugimeeskondi maailmas, mis tegeleb ainult selle lahendusega. Esimese projekti lahenduseks valiti just Cisco ACI.
Teiseks projektiks valiti lahendus Juniperilt. Tootjal on samuti oma SDN andmekeskustele, kuid tellija otsustas loobuda SDN rakendamisest. Võrgutehnoloogia ehitamiseks valiti EVPN VXLAN tehase lahendus ilma kesksete kontrolleriteta.
Miks on see vajalik
Tehase loomine võimaldab rajada kergesti skaleeritava, tõrgete suhtes vastupidava ja usaldusväärse võrgustruktuuri. Arhitektuur (leaf-spine) arvestab eriliste vajadustega andmekeskusi (andmete edastamise teed, viivituste ja kitsaskohtade minimeerimine võrgus). SD lahendused andmekeskustes võimaldavad väga mugavat, kiiret ja paindlikku sellise tehase haldamist ning selle integreerimist andmekeskuse ökosüsteemi.
Mõlemale tellijale oli vajalik ehitada varuandmekeskused tõrkejõulisuse tagamiseks, lisaks peab andmeside andmekeskuste vahel olema krüpteeritud.
Esimene tellija oli juba kaalunud lahendusi ilma tehaseta, kui võimalikku standardit oma võrkudes, kuid testide käigus esines neil ühilduvusprobleeme STP vahel mitmete tarnijate seadmetega. Ilmnesid seisakud, mis põhjustasid teenuste katkestusi. Ja see oli tellijale kriitilise tähtsusega.
Cisco oli juba tellija ettevõtte standardiks, nad uurisid ACI ja teisi variante ning otsustasid, et tuleks valida just see lahendus. Neile meeldis ühe nupu kaudu haldamise automatiseerimine, mis kiirendab teenuste seadistamist ja haldamist. Andmeside krüpteerimise tagamiseks otsustati kasutada MACSec'i IPN ja SPINE lülitite vahel. Nii saadi vältida kitsaskohta krüptotusvtlise seadmena, säästa nende pealt ja maksimeerida ribalaiust.
Teine tellija valis Juniperilt lahenduse ilma kontrollerita, kuna nende olemasolevas andmekeskuses oli juba väike installatsioon EVPN VXLAN tehase rakenduste osas. Kuid seal ei olnud see tõrke suhtes vastupidav (kasutati ühte lülitit). Otsustati laiendada peamise andmekeskuse infrastruktuuri ja rajada varuandmekeskusesse tehas. Olemasolevat EVPN ei kasutatud täielikult: VXLAN-i kapseldamine ei olnud praktiliselt kasutusel, kuna kõik hostid olid ühendatud ühe lülitiga ja kõik MAC-aadressid ning /32 aadressid olid lokaalsed, selle lüliti juhtimiseks oli see sama ja teisi seadmeid, kuhu oleks tulnud rajada VXLAN tunnelid, ei olnud.
Sama prooviti ka ACI-ga, kuid otsustati, et tarnijapoolne lukku seondub liiga palju seadmete ostmisest, sealhulgas hiljuti ostetud uue seadmega asendamisest, ja see ei ole lihtsalt majanduslikult mõttekas. Jah, Cisco tehase integreerub kõigega, kuid tehase sees on lubatud ainult selle seadmete kasutamine.
Teisest küljest, nagu varem öeldi, ei saa EVPN VXLAN tehast lihtsalt segada kohalike tarnijatega, sest protokollide rakendused erinevad. See on nagu proovida Cisco't ja Huawei't ühenduses - standartid on nagu ühesugused, kuid siiski tuleb veidi keerulisemalt vastata. Kuna see on pank ja ühilduvuse testid võtaksid liiga kaua aega, siis otsustati osta sama tarnijat nüüd ja mitte liialdada funktsionaalsusega väljaspool põhifunktsiooni.
Migratsiooniplaan
Kaks andmekeskust ACI baasil:
Kohtade vahelise suhtluse korraldamine. Valitud Multi-Pod lahendus - iga andmekeskus on pod. Arvesse on võetud nõudeid lülitite arvu ja hilinemise kohta podide vahel (RTT alla 50 ms). Otsustati mitte rajada Multi-Site lahendust lihtsama haldamise huvides (Multi-Pod lahenduse jaoks kasutatakse ühte haldusliidest, Multi-Site puhul oleks olnud vajadus kahe liidese või Multi-Site Orkestratori järele), kuna ei olnud vajalik geograafiline varukoopia kohtade reserveerimine.
Teenuste migreerimise osas Legacy võrgust valiti kõige läbipaistvam lahendus, et järk-järgult üle viia VLAN-id, mis vastavad teatud teenustele.
Iga VLAN migratsiooni jaoks loodi vastav EPG (End-point-group) tehases. Esiteks venitati võrk vana võrgu ja tehase vahel L2-s, seejärel, pärast kõigi hostide migratsiooni, viidi gateway tehasesse ning EPG interaktsioon olemasoleva võrgu jaoks toimus L3OUT kaudu, samal ajal kui L3OUT-i ja EPG vahelise suhtluse määratlemiseks kasutati lepinguid. Ligikaudne skeem:
Enamiku ACI tehase poliitikate umbkaudne struktuur on toodud alloleval joonisel. Kogu konfigureerimine põhineb poliitikatel, mis on üksteisesse liigitatud ja nii edasi. Alguses on keeruline arusaada, kuid järk-järgult, nagu praktika näitab, harjuvad võrguadministraatorid sellise struktuuriga umbes kuu jooksul ning seejärel tekib arusaam, kui mugav see on.
Võrdlus
Cisco ACI lahenduses tuleb osta rohkem riistvara (erinevad lülitid Inter-Pod suhtluseks ja APIC kontrollerid), mistõttu see osutus kallimaks. Juniperi lahendus ei nõudnud kontrollerite ja abiriistade ostmist; oli osaliselt võimalik kasutada juba olemasolevat seadmeid klientidel.
Siin on EVPN VXLAN tehase arhitektuur kahes andmekeskuses teises projektis:
ACI-s saad valmis lahenduse — ei pea näpuvahel ringi kaevama, ei pea optimeerima. Klientide esimese tutvustamise ajal tehasega ei ole arendajaid ega toetavaid inimesi koodi ja automatiseerimise jaoks vaja. Piisab lihtsalt kasutamisest, paljusid sätteid saab teha isegi lihtsalt wizard-i kaudu, mis ei ole alati pluss, eriti neile, kes on harjunud käsureaga. Igatahes on aega vajalik oma mõttelaadi ümber kujundamiseks uutele rööbastele, seoses poliitikate kaudu seadistamise iseloomu ja paljude omavahel seotud poliitikate haldamisega. Samuti on soovitatav omada selget poliitikate ja objektide nimetamise struktuuri. Iga probleemi korral kontrolleri tööloogikas saab lahendusi ainult tehnilisest toetusest.
EVPN — konsool. Aga piina või rõõmustada. Harjumuspärane liides vana garderoobi jaoks. Jah, on tüüpiline konfiguratsioon ja juhised. Pead läbi töötama käsiraamatud. Erinevad konstruktsioonid, kõik on selge ja detailselt.
Muidugi, mõlemal juhul on parem migratsiooni ajal kõigepealt migreerida mitte kõige kriitilisemad teenused, näiteks testkeskkonnad, ja alles seejärel, pärast kõikide tõrgete tabamist, liikuda tootmisse. Ja mitte seadistada reede õhtul. Ära usu müüjat, et kõik on hästi, alati on parem end kaitsta.
ACI eest maksad rohkem, kuigi hetkel Cisco aktiivselt edendab seda lahendust ja tihti pakub sellele häid allahindlusi, kuid kokkuhoid on hooldus- ja toetuskuludest. EVPN tehase haldamine ja automatiseerimine, ilma kontrollerita, nõuab investeeringuid ja regulaarseid kulusid — jälgimine, automatiseerimine, uute teenuste rakendamine. Samuti takeb ACI esialgne käivitamine 30–40% kauem aega. See on tingitud sellest, et kogu vajalikud profiilide ja poliitikate komplekti loomine kestab kauem, mis hiljem kasutatakse. Kuid võrgu suurenedes väheneb vajalike seadistuste arv. Sa kasutad juba eelnevalt loodud poliitikaid, profiile ja objekte. Sa saad paindlikult häälestada segmenteerimist ja turvalisust, keskelt hallata lepinguid, mis reguleerivad EPG vahelisi tehingute suhtlemisi — töö mahud langevad järsult.
EVPN-is peab iga seadme tehases konfigureerima, vea tõenäosus on suurem.
Kui ACI rakendatakse aeglasemalt, siis EVPN-i häälestamine kestab peaaegu kaks korda kauem. Kui Cisco puhul saab alati kutsuda toe inseneri, et küsida võrgu üldtöötamise kohta (sest see katab lahendust), siis Juniper Networks'i puhul ostad ainult riistvara, ja see katab vaid selle. Kas seadmest on pakett välja läinud? Noh, edasi on teie probleem. Kuid saate avada küsimuse lahenduse või võrgu disaini kohta — ja siis soovitatakse osta profesionaalne teenus, lisatasu eest.
ACI toetus on väga hea, sest see on eraldi: eraldi meeskond töötab vaid selle nimel. Sealhulgas on ka venekeelsed spetsialistid. Juhend on detailne, lahendused on ette määratud. Nad õpid ja nõuavad. Kiiresti valideerivad disaini, mis on sageli oluline. Juniper Networks teeb sama, kuid palju aeglasemalt (meil oli nii, praegu peaks kuulujuttude järgi olema parem), mis sunnib sind ise tegema kõike seal, kus sul oleks võinud soovitada lahenduste insener.
Cisco ACI toetab virtualiseerimise ja konteinerite süsteemide (VMware, Kubernetes, Hyper-V) integreerimist ning keskset haldust. Pakuvad võrguteenuseid ja turvateenuseid - laadimine, tulemüürid, WAF, IPS ja muud... Hea mikrosegmentatsioon kohe välja pakendatud. Teises lahenduses teenuste integreerimine käib keerulisemalt ja on parem, kui uurida foorumeid nende jaoks, kes seda juba teinud on.
Kokkuvõte
Iga konkreetse juhtumi puhul tuleb lahendus valida mitte ainult seadmete hindade põhjal, vaid arvesse tuleks võtta ka edasisi kulutusi hooldusele ja peamistele probleemidele, millega klient hetkel silmitsi seisab, ning IT-infrastruktuuri arengu plaane.
ACI, tänu täiendavatele seadmetele, osutus kallimaks, kuid lahendus on valmis ilma täiendavate kohandusteta, teine lahendus on keerulisem ja kulukam, kuid odavam.
Kui soovite arutada, kui palju võib maksta võrgu tehase rakendamine erinevatelt tarnijatelt ja milline arhitektuur on vajalik, - saame kokku ja rääkida. Ükski ettevalmistav arhitektuur (mille põhjal saame eelarveid planeerida) on tasuta, detailne töötlemine, loomulikult, on juba tasuline.
Vladimir Kleptš, ettevõttevõrgud.
Allikas: habr.com
