Erfarenhet av att implementera nätverksstrukturer baserade på EVPN VXLAN och Cisco ACI och en kort jämförelse

Utvärdera kopplingarna i diagrammets mitt. Vi återkommer till dem nedan.

Vid någon tidpunkt kan man stöta på det faktum att stora komplexa L2-baserade nätverk är obotligt sjuka. Först och främst, med problem relaterade till BUM-trafikbehandling och driften av STP-protokollet. För det andra, med en överlag moraliskt föråldrad arkitektur. Detta orsakar obehagliga problem i form av driftstopp och besvär med kontrollerbarhet.

Vi hade två parallella projekt, där kunderna nyktert bedömde alla för- och nackdelar med alternativen och valde två olika överlappande lösningar, och vi implementerade dem.

Det fanns en möjlighet att jämföra genomförandet, inte driften, vilket är värt att prata om om två eller tre år.

Så vad är en nätverksstruktur med overlay-nätverk och SDN?

Vad ska man göra med de akuta problemen med klassisk nätverksarkitektur?

Varje år dyker nya teknologier och idéer upp. I praktiken uppstod det inte på länge att det akuta behovet av att bygga om nätverk, eftersom det också är möjligt att göra allt manuellt med hjälp av gamla goda farfars metoder. Så tänk om det är tjugoförsta århundradet? Administratören ska ju trots allt arbeta, inte sitta på sitt kontor.

Sedan började boomet av att bygga storskaliga datacenter. Då blev det tydligt att gränsen för utvecklingen av klassisk arkitektur hade nåtts, inte bara vad gäller driftsäkerhet, feltolerans och skalbarhet. Och ett av alternativen för att lösa dessa problem var idén att bygga overlay-nätverk ovanpå en routad stamnätverk.

Dessutom, i takt med att nätverken blir allt större, har problemet med att hantera sådana fabriker blivit akut, vilket har lett till att programvarudefinierade nätverkslösningar med möjlighet att hantera hela nätverksinfrastrukturen som en enda enhet har börjat dyka upp. Och när nätverket hanteras från en enda punkt är det lättare för andra komponenter i IT-infrastrukturen att interagera med det, och sådana interaktionsprocesser är lättare att automatisera.

Nästan alla större tillverkare av inte bara nätverksutrustning, utan även virtualisering, har alternativ för sådana lösningar i sin portfölj.

Det återstår bara att lista ut vad som passar vilka behov. Till exempel, för särskilt stora företag med ett bra team av utvecklare och operatörer, uppfyller inte leverantörernas färdiga lösningar alltid alla behov, och de tar till att utveckla sina egna SD-lösningar (software defined). Det handlar till exempel om molnleverantörer som ständigt utökar utbudet av tjänster som erbjuds sina kunder, och färdiga lösningar kan helt enkelt inte hålla jämna steg med deras behov.

För medelstora företag är funktionaliteten som leverantören erbjuder som en komplett lösning tillräcklig i 99 procent av fallen.

Vad är overlay-nätverk?

Vad är idén bakom overlay-nätverk? I grund och botten tar man ett klassiskt routat nätverk och bygger ett annat nätverk ovanpå det för att få fler funktioner. Oftast talar vi om effektiv lastfördelning på utrustning och kommunikationslinjer, en betydande ökning av skalbarhetsgränser, ökad tillförlitlighet och en massa säkerhetsfördelar (på grund av segmentering). Och SDN-lösningar utöver detta ger möjlighet till mycket, mycket, mycket bekväm flexibel administration och gör nätverket mer transparent för sina konsumenter.

Generellt sett, om lokala nätverk hade uppfunnits på 2010-talet, skulle de ha sett helt annorlunda ut än vad vi ärvde från militären på 1970-talet.

När det gäller tekniker för att bygga fabriker med hjälp av overlay-nätverk finns det för närvarande många implementeringar av tillverkare och Internet RFC-projekt (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve med flera). Ja, det finns standarder, men implementeringen av dessa standarder av olika tillverkare kan skilja sig åt, så när man skapar sådana fabriker är det bara möjligt i teorin på pappret att helt överge leverantörslåsningen.

Med SD-lösningar är det ännu mer komplicerat, varje leverantör har sin egen vision. Det finns helt öppna lösningar, som i teorin kan färdigställas av dig själv, och det finns helt slutna.

Cisco erbjuder sin egen version av SDN för datacenter – ACI. Naturligtvis är detta en 100 % leverantörslåst lösning när det gäller val av nätverksutrustning, men samtidigt är den helt integrerad med virtualisering, containerisering, säkerhet, orkestreringssystem, lastbalanserare etc. Men i grund och botten är det fortfarande en sorts svart låda, utan möjlighet att få full åtkomst till alla interna processer. Inte alla kunder är överens om detta alternativ, eftersom man är helt beroende av kvaliteten på den skrivna lösningskoden och dess implementering, men å andra sidan har tillverkaren en av de bästa tekniska supporterna i världen och ett dedikerat team som endast arbetar med denna lösning. Cisco ACI valdes som lösning för det första projektet.

För det andra projektet valdes en Juniper-lösning. Tillverkaren har också ett eget SDN för datacentret, men kunden beslutade att överge implementeringen av SDN. EVPN VXLAN-struktur utan användning av centraliserade styrenheter valdes som teknik för att bygga nätverket.

Vad är det till för?

Skapandet av en väv möjliggör konstruktionen av ett lätt skalbart, feltolerant och tillförlitligt nätverk. Leaf-spine-arkitekturen tar hänsyn till specifika egenskaper. центров обработки данных (trafikvägar, minimering av latens och flaskhalsar i nätverket). SD-lösningar i datacenter möjliggör mycket bekväm, snabb och flexibel hantering av en sådan fabrik och integrerar den i datacentrets ekosystem.

Båda kunderna behövde bygga backup-datacenter för att säkerställa feltolerans, och dessutom var trafiken mellan datacenter tvungen att krypteras.

Den första kunden hade redan övervägt fabric-fria lösningar som en möjlig standard för sina nätverk, men under tester hade de problem med STP-kompatibilitet mellan flera hårdvaruleverantörer. Driftstopp uppstod, vilket orsakade serviceavbrott. Och för kunden var detta avgörande.

Cisco var redan kundens företagsstandard, de tittade på ACI och andra alternativ och bestämde sig för att det var värt att välja den här lösningen. De gillade automatiseringen av styrning från en knapp genom en enda kontroller. Tjänster konfigureras snabbare och hanteras snabbare. De bestämde sig för att tillhandahålla trafikkryptering genom att köra MACSec mellan IPN- och SPINE-switchar. På så sätt lyckades de undvika en flaskhals i form av en kryptogateway, spara pengar och använda maximal bandbredd.

Den andra kunden valde en kontrollerlös lösning från Juniper, eftersom deras befintliga datacenter redan hade en liten installation med implementeringen av EVPN VXLAN-strukturen. Men den var inte feltolerant där (en switch användes). De beslutade att utöka infrastrukturen i huvuddatacentret och bygga en struktur i backup-datacentret. Den befintliga EVPN:n användes inte fullt ut: VXLAN-inkapsling användes inte i själva verket, eftersom alla värdar var anslutna till en switch, och alla MAC-adresser och /32-adresser för värdarna var lokala, samma switch var deras gateway, det fanns inga andra enheter där det var nödvändigt att bygga VXLAN-tunnlar. De beslutade att tillhandahålla trafikkryptering med IPSEC-teknik mellan brandväggar (brandväggens prestanda var tillräcklig).

Vi provade även ACI, men bestämde oss för att på grund av leverantörslåset skulle vi behöva köpa för mycket hårdvara, inklusive att ersätta nyinköpt utrustning, och det är helt enkelt inte ekonomiskt vettigt. Ja, Cisco-fabriken integrerar med allt, men bara dess enheter är möjliga inuti själva fabriken.

Å andra sidan, som de sa tidigare, kan man inte bara blanda EVPN VXLAN-fabriken med någon närliggande leverantör, eftersom protokollimplementeringarna är olika. Det är som att korsa Cisco och Huawei i ett nätverk – standarderna verkar vara desamma, men man får dansa med en tamburin. Eftersom det här är en bank, och kompatibilitetstester skulle ta lång tid, bestämde vi oss för att det skulle vara bättre att köpa samma leverantör nu, och inte bli för uppslukade av funktionalitet utöver grunderna.

Migrationsplan

Två ACI-baserade datacenter:

Organisering av interaktion mellan datacenter. Multi-Pod-lösningen valdes – varje datacenter är en pod. Kraven på skalning med antalet switchar och fördröjningar mellan poddar (RTT mindre än 50 ms) togs med i beräkningen. Det beslutades att inte bygga en Multi-Site-lösning för enkel hantering (ett enda hanteringsgränssnitt används för Multi-Pod-lösningen, för Multi-Site skulle det finnas två gränssnitt, eller så skulle Multi-Site Orchestrator krävas), och eftersom geografisk redundans för anläggningar inte krävdes.

Ur synvinkel av migrering av tjänster från Legacy-nätverket valdes det mest transparenta alternativet, att gradvis överföra VLAN motsvarande vissa tjänster.
För migreringen skapades en motsvarande EPG (End-point-group) för varje VLAN på infrastrukturen. Först sträcktes nätverket ut mellan det gamla nätverket och infrastrukturen via L2, sedan, efter att alla värdar hade migrerat, flyttades gatewayen till infrastrukturen, och EPG:n interagerade med det befintliga nätverket via L3OUT, medan interaktionen mellan L3OUT och EPG beskrevs med hjälp av kontrakt. Ungefärligt diagram:

Den ungefärliga strukturen för de flesta ACI-strukturpolicyer visas i figuren nedan. Hela upplägget är baserat på policyer som är inbäddade i andra policyer, och så vidare. Till en början är det mycket svårt att förstå, men gradvis, som praktiken visar, vänjer sig nätverksadministratörer vid en sådan struktur på ungefär en månad, och först då kommer en förståelse för hur bekväm den är.

jämförelse

Cisco ACI-lösningen kräver inköp av mer utrustning (separata switchar för Inter-Pod-interaktion och APIC-styrenheter), vilket gör den dyrare. Juniper-lösningen krävde inte inköp av styrenheter och hjälputrustning; det var möjligt att delvis använda kundens befintliga utrustning.

Här är arkitekturen för EVPN VXLAN-strukturen för två datacenter i det andra projektet:

I ACI får du en färdig lösning – inget behov av att välja, inget behov av att optimera. När kunden först bekantar sig med fabriken behövs inga utvecklare, ingen supportpersonal för koden och automatisering behövs. Driften är enkel nog, många inställningar kan göras via guiden, vilket inte alltid är ett plus, särskilt för personer som är vana vid kommandoraden. I vilket fall som helst tar det tid att bygga upp hjärnan på nya räls, på inställningarnas säregenhet genom policyer och att hantera en mängd kapslade policyer. Utöver detta är det mycket önskvärt att ha en tydlig struktur för att namnge policyer och objekt. Om något problem uppstår i styrenhetens logik kan det bara lösas genom teknisk support.

I EVPN — konsol. Lida eller glädjas. Bekant gränssnitt för den gamla garden. Ja, det finns en standardkonfiguration och guider. Du kommer att behöva röka mana. Olika designer, allt är tydligt och detaljerat.

Naturligtvis är det i båda fallen bättre att migrera de minst kritiska tjänsterna först, såsom testmiljöer, och först sedan, efter att ha upptäckt alla buggar, gå vidare till produktion. Och konfigurera inte på fredag ​​kväll. Lita inte på leverantören att allt kommer att gå bra, det är alltid bättre att vara på den säkra sidan.

Du betalar mer för ACI, även om Cisco för närvarande aktivt marknadsför denna lösning och ofta ger bra rabatter på den, men du sparar på underhåll och support. Hantering och all automatisering av en EVPN-struktur utan en styrenhet kräver investeringar och regelbundna kostnader - övervakning, automatisering, implementering av nya tjänster. Samtidigt tar den initiala lanseringen av ACI 30-40 procent längre tid. Detta händer eftersom det tar längre tid att skapa hela uppsättningen nödvändiga profiler och policyer som sedan ska användas. Men allt eftersom nätverket växer minskar antalet nödvändiga konfigurationer. Du använder förskapade policyer, profiler, objekt. Du kan flexibelt konfigurera segmentering och säkerhet, centralt hantera kontrakt som ansvarar för att tillåta vissa interaktioner mellan EPG:er - mängden arbete minskar kraftigt.

I EVPN måste du konfigurera varje enhet i fabriken, sannolikheten för fel är högre.

Om ACI är långsammare att implementera, tog det nästan dubbelt så lång tid att felsöka EVPN. Om du i Ciscos fall alltid kan ringa en supporttekniker och fråga om nätverket som helhet (eftersom det täcks som en lösning), så köper du med Juniper Networks bara hårdvara, och den täcks specifikt. Har paket från enheten försvunnit? Ja, okej, då är det ditt problem. Men du kan öppna en fråga om valet av lösning eller nätverksdesign – och då kommer de att råda dig att köpa en professionell tjänst, mot en extra avgift.

ACI-supporten är väldigt cool, eftersom den är separat: ett separat team sitter bara för detta. Det finns, inklusive rysktalande specialister. Guiden är detaljerad, lösningarna är förutbestämda. De tittar och ger råd. De validerar snabbt designen, vilket ofta är viktigt. Juniper Networks gör samma sak, men mycket långsammare (vi hade det så, nu borde det vara bättre enligt rykten), vilket tvingar dig att göra allt själv där en lösningsingenjör kan ge råd.

Cisco ACI stöder integration med virtualiserings- och containersystem (VMware, Kubernetes, Hyper-V) och centraliserad hantering. Det finns nätverkstjänster och säkerhetstjänster - balansering, brandväggar, WAF, IPS, etc. Bra mikrosegmentering direkt ur lådan. I den andra lösningen sker integration med nätverkstjänster med en tamburin, och det är bättre att läsa forum med de som har gjort detta i förväg.

Totalt

För varje specifikt fall är det nödvändigt att välja en lösning baserad inte bara på kostnaden för utrustningen, utan också att ta hänsyn till ytterligare driftskostnader och de huvudsakliga problem som kunden står inför för närvarande, samt vilka planer som finns för utveckling av IT-infrastrukturen.

ACI är dyrare på grund av extra utrustning, men lösningen är färdig utan behov av ytterligare modifieringar; den andra lösningen är mer komplex och dyrare i drift, men billigare.

Om ni vill diskutera hur mycket det kan kosta att implementera en nätverksstruktur hos olika leverantörer, och vilken arkitektur som behövs, kan vi träffas och prata. Vi ger er kostnadsfri rådgivning om arkitekturutkastet (med vilket ni kan beräkna budgetar), detaljerad utveckling är givetvis betald.

Vladimir Klepche, företagsnätverk.

Källa: will.com