EVPN VXLAN ja Cisco ACI põhjal võrgufabrikate rakendamise kogemus ja väike võrrelda.

Hinnake diagrammi keskel olevate sidemete kvaliteeti. Naasen nende juurde allpool.

Mõnel hetkel võite avastada, et suured keerulised L2-võrgud on ravimatud. Esiteks probleemi BUM liikluse töötlemise ja STP protokolli tööga. Teiseks - moraalselt vananenud arhitektuuri. See toob kaasa ebameeldivaid probleeme, nagu seisakud ja halvad haldusvõimalused.

Meil oli kaks paralleelset projekti, kus tellijad tegid ratsionaalse otsuse võimaluste plusse ja miinuseid arvesse võttes ning valisid kaks erinevat overlay lahendust, mille me rakendasime.

Oli võimalus võrrelda just rakendust. Mitte kasutust, selle üle tasub rääkida kahe-kolme aasta pärast.

Nii et, mis on võrgufabrik, millel on overlay-võrgud ja SDN?

Mida teha klassikalise võrguarhitektuuri probleemidega?

Igal aastal ilmuvad uusi tehnoloogiaid ja ideid. Praktikas ei ole olnud suurt vajadust võrgusüsteemide uuendamiseks juba pikka aega, sest kõik käib ka vana hea meetodi järgi käsitsi. Ja mis siis, et on kakskümmend esimeses sajandis? Lõppude lõpuks peab adminn tööd tegema, mitte oma kabinetis istuma.

Siis algas suurte andmekeskuste ehitamise buum. Sel ajal sai selgeks, et klassikalise arhitektuuri areng piirdub mitte ainult töökuse, vaid ka talitlushäirete ja skaleeritavuse osas. Üks võimalikke lahendusi nende probleemide lahendamiseks oli ideede loomine overlay-võrkudest marsruutimise tõukereele.

Lisaks, koos võrkude suurendamisega, kerkis teravalt esile selliste tehaste haldamise probleem, mille tulemuseks oli programmiga määratletud võrkude lahenduste tekkimine, mis võimaldas hallata kogu võrguinfrastruktuuri kui tervikut. Kui võrk on hallatav ühest kohast, saavad teised IT-infrastruktuuri komponendid sellega lihtsamalt suhelda ja selliseid suhtlemisprotsesse on lihtsam automatiseerida.

Peaaegu iga suurem tootja, mitte ainult võrguseadmete, vaid ka virtualiseerimise vallas, omab oma portfellides selliseid lahendusi.

Jääb ainult selgeks teha, mis sobib milliste vajaduste jaoks. Näiteks, eriti suurte ettevõtete puhul, kellel on hea arendustiim ja operatiivmeeskond, ei rahulda tavaliselt pakkujate välja pakutavad lahendused kõiki vajadusi ning nad pöörduvad oma SD (tarkvaraliselt määratletud) lahenduste väljatöötamise poole. Näiteks on need pilveteenuse pakkujad, kes pidevalt laiendavad oma klientidele pakutavate teenuste valikut ning tavalised lahendused ei suuda lihtsalt järele jõuda nende vajadustele.

Keskmiste ettevõtete puhul piisab 99 protsendi juhtudest pakkujate poolt pakutavast funktsionaalsusest, mis on saadaval karbilahendustes.

Mis on overlay-ärivõrgud?

Overlay-ärivõrkude idee seisneb selles, et te võtate klassikalise marsruutimisvõrgu ja ehitate selle peale veel ühe võrgu, et saada rohkem funktsioone. Kõige sagedamini räägime efektiivsest koormuse jaotamisest seadmetele ja sidekanalitele, olulisest skaleeritavuse piiri tõstmisest, usaldusväärsuse paranemisest ja hulkate turvalisuse boonustest (segmendiseerimise kaudu). SDN lahendused pakuvad lisaks sellele ka väga, väga, väga mugavat ja paindlikku haldust ning teevad võrgu tarbijatele läbipaistvamaks.

Üldiselt, kui kohalikke võrgulahendusi oleks välja töötatud 2010. aastate paiku, siis näeksid nad kindlasti väga erinevad välja võrreldes sellega, mis meile sõjaväest 1970. aastatest on jäänud.

Tehnoloogiate seisukohalt, mis on seotud tehaste rajamisega, kasutades overlay-võrke, on praegu olemas palju tootjate ja Interneti-projektide RFC realiseerimisi (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve jne). Jah, standardsed lahendused eksisteerivad, kuid nende rakendamine erinevate tootjate poolt võib erineda, seega on selliste tehaste loomisel täielik loobumine tarnija sõltuvusest praegu vaid paberiteooria tasemel.

SD-lahendustega on olukord veel keerulisem, igal tarnijal on oma nägemus. On täiesti avatud lahendusi, mida teoreetiliselt saab ise arendada, ning täielikult suletud lahendusi.

Cisco pakub oma varianti SDN andmekeskustele — ACI. Loomulikult on see 100% tarnija-põhine lahendus võrguvarustuse valiku osas, kuid see integreerub täielikult virtualiseerimise, konteineriseerimise, turbe, orkestreerimise, koormuse tasakaalustamise ja muude süsteemidega. Kuid põhimõtteliselt on see ikkagi mingi must kast, ilma võimaluseta täielikult ligipääseda kõikidele sisemistele protsessidele. Kõik kliendid ei nõustu sellise lahendusega, kuna olete täielikult sõltuv lahenduse kirjutatud koodi ja selle rakendamise kvaliteedist, kuid teisest küljest on tootjal üks parimaid tehnilisi tugiteenuseid maailmas ning neil on eraldi meeskond, mis tegeleb ainult selle lahendusega. Esimese projekti lahenduseks valiti just Cisco ACI.

Teise projekti jaoks valiti Juniperi lahendus. Tootjal on samuti oma SDN andmekeskustele, kuid klient otsustas SDN-i rakendamisest loobuda. Võrgu ehitamise tehnoloogiana valiti EVPN VXLAN fabrik ilma tsentraliseeritud kontrollerite kasutamiseta.

Miks on see vajalik

Fabriku loomine võimaldab luua hõlpsasti skaleeritava, katkestustaluvuse ja usaldusväärse võrgu. Arhitektuur (leaf-spine) arvestab omadustega andmekeskuste riketest (andmete edastusrajad, viivituste ja kitsaskohtade minimeerimine võrgus). SD lahendused andmekeskustes võimaldavad väga mugavalt, kiiresti ja paindlikult hallata sellist fabrikut, integreerida see andmekeskuse ökosüsteemi.

Mõlemale kliendile oli vajalik ehitada varukoopiad andmekeskused tagamaks katkestustaluvust, lisaks pidi andmekeskuste vahel liikuv liiklus olema krüpteeritud.

Esimene klient oli juba kaalunud lahendusi ilma fabrikuta kui oma võrkude võimaliku standardina, kuid testide käigus esines neil ühilduvusprobleeme STP osas mitmete tarnijate riistvara vahel. Kerkisid seisakud, mis põhjustasid teenuste kokkuvarisemist. See oli kliendi jaoks kriitiline.

Cisco on juba olnud kliendi ettevõtte standard, nad vaatasid ACI ja teisi variante ning otsustasid, et see lahendus on sobivaim. Neil meeldis, et juhtimist saab automatiseerida ühe nupuvajutusega läbi ühe kontrolleri. Teenuste seadistamine on kiirem, haldamine on lihtsam. Andmevoo krüpteerimise otsustati tagada MACSeci käivitamisega IPN ja SPINE lülitite vahel. Nii õnnestus vältida kitsaskohti krüptoväravate näol, säästa nendelt ja maksimeerida ribalaiust.

Teine klient valis Juniperi lahenduse, mis ei kasuta kontrollerit, kuna nende olemasolevas andmekeskuses oli juba väike seadistus EVPN VXLAN tehase rakendusega. Kuid seal ei olnud see tõrketaluv (kasutati ühte lülitit). Otsustati laiendada põhiteenuste infrastruktuuri ja rajada reservandmekeskuses tehase. Olemasolevat EVPN-i ei kasutatud täielikult: VXLAN-i kapseldamine ei olnud tegelikult rakendatud, kuna kõik hostid olid ühendatud ühte lülitisse ja kõik MAC-aadressid ja /32 aadressid olid lokaalsed, selle samme väravaks oli see sama lüliti, ei olnud muid seadmeid, kuhu VXLAN tunnelid rajada. Andmevoo krüpteerimine otsustati tagada IPSEC tehnoloogia abil tulemüüride vahel (MSCE jõudlus oli piisav).

Samuti uuriti ACI-d, kuid otsustati, et tarnija lukustumise tõttu tuleb osta liiga palju riistvara, sealhulgas asendada hiljuti ostetud uus varustus, ja see lihtsalt ei ole majanduslikult mõistlik. Jah, Cisco tehas integreerub kõigega, kuid tehase sees on võimalused ainult selle seadmete jaoks.

Teisest küljest, nagu eelnevalt öeldi, ei saa EVPN VXLAN tehast lihtsalt niimoodi kokku segada ühegi naabertarnijaga, kuna protokollide rakendused erinevad. See on nagu Cisco ja Huawei segamine ühes võrgus — standardid on küll ühised, kuid seda on vaja teha keerukalt. Kuna tegemist on pangaga ja ühilduvustestid oleksid väga pikad, otsustati, et parem on praegu osta sama tarnijaga ja mitte lasta end põhifunktsionaalsusest üleliia kaasa tõmmata.

Migreerimise plaan

Kaks andmekeskust ACI-l põhinevas lahenduses:

Andmetevahe lülitamisel andmekeskuste vahel on valitud Multi-Pod lahendus — iga andmekeskus on pod. Arvesse on võetud vajadusi skaleeritavuse osas lülitite arvu ja viivituste vahel podide vahel (RTT alla 50 ms). Otsustati mitte rajada Multi-Site lahendust haldamise mugavuse tõttu (Multi-Pod lahenduse puhul kasutatakse ühte haldusliidest, samas kui Multi-Site jaoks oleks vajalik kaks liidest või Multi-Site Orkestreerija), ning kuna geograafiline varundamine asukohtade vahel ei olnud vajalik.

Teenuste migratsiooni seisukohalt Legacy võrgust oli valitud kõige läbipaistvam variant, et järk-järgult kanda üle VLAN-id, mis vastavad teatud teenustele.
Iga VLAN-i jaoks loodi migratsiooni käigus vastav EPG (Lõpp-punkti grupp) tehases. Esiteks laiendati võrk vana võrgu ja tehase vahel L2 kaudu; seejärel, pärast kõigi hostide migratsiooni, viidi lüüs üle tehasesse ning EPG ja olemasoleva võrgu vaheline suhtlus toimus L3OUT kaudu, samas kui L3OUT-i ja EPG vahelisi suhteid kirjeldati lepingute abil. Umbes selline skeem:

Alloleval joonisel on toodud ACI tehase enamik poliitikaid. Kogu seadistus põhineb poliitikatest, mis on söövitatud teiste poliitikate sisse ja nii edasi. Alguses on seda väga keeruline mõista, kuid järk-järgult, nagu praktika näitab, harjuvad võrguhaldurid selle struktuuriga umbes kuu ajaga, pärast mida tuleb ainult arusaamine, kui mugav see on.

Võrdlus

Cisco ACI lahenduses tuleb osta rohkem seadmeid (eraldi lülitid Inter-Pod suhtlemiseks ja APIC kontrollerid), mistõttu on see kallim. Juniperi lahendus ei nõudnud kontrollerite ja abiseadmete ostmist; saadi osaliselt kasutada juba olemasolevaid seadmeid kliendilt.

Siin on EVPN VXLAN tehase arhitektuur kahe andmekeskuse kohta teisel projektil:

ACI-s saad valmis lahendus — ei pea kaevama ega optimeerima. Klientide esmakordsel tutvumisel tehasega ei ole arendajad ega koodi ja automatiseerimise toetajad vajalikud. Piisab lihtsalt kasutamisest, paljusid seadistusi saab teha isegi wizard'i kaudu, mis ei ole alati pluss, eriti inimestele, kes on harjunud käsureaga. Igatahes on aega vaja, et oma mõtteviisi uutele rööpadele ümber ehitada, kohandada seadeid poliitikate kaudu ja hallata paljusid üksteise sisse keeratud poliitikaid. Soovitav on omada ka selget poliitikate ja objektide nimede struktuuri. Kui tekib mingeid probleeme kontrolleri toimimises, saab selle lahendada ainult tehnilise toe kaudu.

EVPN — konsool. Kas kannata või rõõmusta. Harjumuspärane liides vanale koolkonnale. Jah, on tüüpiline konfiguratsioon ja juhised. Pead lugema käsiraamatuid. Erinevad konstruktsioonid, kõik on selge ja detailne.

Muidugi, mõlemal juhul on parem migreerida esmalt mitte kõige kriitilisemaid teenuseid, näiteks testimise keskkondi, ja alles siis, kui kõik vead on kinni püütud, minna tootmisse. Ja ei tohi seadistada reede õhtul. Ei tasu uskuda müüjasse, et kõik läheb hästi, alati on parem ennast kindlustada.

ACI eest maksad rohkem, kuigi hetkel Cisco aktiivselt edendab seda lahendust ja sageli pakub sellele häid allahindlusi, kuid säästad hoolduskuludest. EVPN tehase juhtimine ja automatiseerimine ilma kontrollerita nõuab investeeringuid ja pidevaid kulutusi — jälgimine, automatiseerimine, uute teenuste juurutamine. Samal ajal võtab ACI esialgne käivitamine 30–40 protsenti kauem. See juhtub, kuna kogu vajalik profiilide ja poliitikate kogum, mida hiljem kasutatakse, luuakse kauem. Kuid võrgu kasvades väheneb vajalike konfiguratsioonide arv. Kasutad juba eelnevalt loodud poliitikaid, profiile, objekte. Saad paindlikult seadistada segmentatsiooni ja turvalisuse, hallata tsentraliseeritult lepinguid, mis vastutavad teatud EPG-de vaheliste interaktsioonide lubamise eest — töömaht langeb järsult.

EVPN-is tuleb iga seadme tehases konfigureerida, veaprobleemide tõenäosus on suurem.

Kui ACI rakendamine on aeglasem, siis EVPN-i tõrkeotsing kestab peaaegu kaks korda kauem. Kui Cisco puhul saab alati kutsuda tugitehniku ja küsida võrgu kohta laiemalt (sest see on lahendusena kaetud), siis Juniper Networks'is ostate te ainult riistvara, ja see on ainus asi, mis katab. Kas seadmetest on paketid läinud? Noh, olgu, järgmine probleem on teie. Kuid saate avada küsimuse lahenduse või võrgu disaini valiku kohta — ja siis soovitatakse osta professionaalne teenus, lisatasu eest.

ACI tugi on väga hea, kuna on eraldi: seal istub ainult sellele pühendatud meeskond. Seal on ka venekeelsed spetsialistid. Juhend on üksikasjalik, lahendused on eelnevalt määratud. Nad vaatavad ja soovitavad. Nad valideerivad kiiresti disaini, mis on tihti oluline. Juniper Networks teeb sama, kuid palju aeglasemalt (meil oli nii, nüüd peaks kuulujuttude kohaselt olema parem), mis sunnib teid iseseisvalt kõike tegema seal, kus saaks soovitada lahenduse insener.

Cisco ACI toetab virtualiseerimise ja konteinerite haldamise süsteemide (VMware, Kubernetes, Hyper-V) integreerimist ja keskset haldust. On ka võrguteenuseid ja turvateenuseid — koormuse tasakaalustus, tulemüürid, WAF, IPS ja muu... Hea mikrosegmentatsioon väljaoleval kujul. Teises lahenduses toimub integreerimine võrguteenustega keerukamalt, seetõttu on parem eelnevalt lugeda foorumeid, kus inimesed on seda teinud.

Kokkuvõte

Iga konkreetse juhtumi jaoks tuleb lahendus valida, mitte ainult arvestades seadmete hinda, vaid tuleb arvesse võtta ka edasisi hoolduskulusid ja peamisi probleeme, millega tellija praegu silmitsi seisab, ja millised on IT-infrastruktuuri arendamise plaanid.

ACI on lisaseadmete tõttu kallim, kuid lahendus on olemas ilma täiendavate muudatusteta, teine lahendus on keerulisem ja kulukam hoolduse seisukohalt, kuid odavam.

Kui soovite arutada, kui palju võib võrgufabriku rakendamine erinevates vendorites maksma minna, ja milline arhitektuur on vajalik — saame kohtuda ja rääkida. Eelprojekteeritud arhitektuuri (mille põhjal saab eelarveid arvutada) osas anname nõu tasuta, detailne välja töötamine on loomulikult tasuline.

Vladimir Kleptše, ettevõttevõrgud.

Allikas: habr.com