🥇Erfarenhet av att implementera nätverksfabriker med EVPN VXLAN och Cisco ACI samt en kort jämförelse

Utvärdera länkarna i mitten av schemat. Vi kommer tillbaka till dem snart.

Vid något tillfälle kan du stöta på att stora komplexa nätverk baserade på L2 är obotligt sjuka. Främst handlar det om problem relaterade till hantering av BUM-trafik och STP-protokollet. För det andra, den generellt föråldrade arkitekturen. Detta orsakar obehagliga problem i form av driftstopp och svårigheter med hanteringen.

Vi hade två parallella projekt där kunderna realistiskt bedömde alla fördelar och nackdelar med alternativen och valde två olika överliggande lösningar, som vi implementerade.

Det fanns möjlighet att jämföra just implementeringen. Inte driften, den bör man diskutera först efter två till tre år.

Så vad är ett nätverksfabriken med överlagda nätverk och SDN?

Vad ska man göra med de plågsamma problemen i klassisk nätverksarkitektur?

Nya teknologier och idéer dyker upp varje år. I praktiken har det länge varit en brådskande nödvändighet att omstrukturera nätverk, eftersom det också går att göra allt för hand med de gamla hederliga metoderna. Vad spelar det för roll att det är tjugoförsta århundradet? Slutligen, administratören ska ju arbeta, inte bara sitta på sitt kontor.

Sedan började boomen av storskaliga datacenter. Det blev då tydligt att den klassiska arkitekturen hade nått sin utvecklingsgräns, inte bara när det gäller funktionalitet, redundans och skalbarhet. En av lösningarna på dessa problem blev idén att bygga överlagda nätverk ovanför ett routat ryggrad.

Dessutom, med större nätverksstordomar, uppstod akuta problem med att hantera sådana fabriker, vilket ledde till lösningar för programvarudefinierade nätverk som möjliggör hantering av hela nätverksinfrastrukturen som en enhet. När nätverket styrs från en central punkt blir det enklare för andra IT-komponenter att interagera med det, och sådana interaktionsprocesser blir lättare att automatisera.

Nästan varje stor tillverkare, inte bara av nätverksutrustning utan även av virtualisering, har sådana lösningar i sin portfölj.

Det handlar bara om att förstå vad som passar olika behov. Till exempel, för mycket stora företag som har ett bra team av utvecklare och drift, är det inte alltid färdiga lösningar från leverantörer som uppfyller alla behov, och de tar till att utveckla sina egna SD (software defined) lösningar. Till exempel är detta molnleverantörer som hela tiden utökar sitt utbud 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äcker funktionen som erbjuds av leverantören i form av en färdig lösning i 99 procent av fallen.

Vad är overlay-nätverk?

Vad handlar idén med overlay-nätverk om? I grunden tar du ett klassiskt routat nätverk och bygger ett till nätverk ovanpå det för att få fler funktioner. Oftast handlar det om effektiv belastningsfördelning på utrustning och kommunikationslinjer, ett betydande ökat skalbarhetsgräns, ökad tillförlitlighet och en massa fördelar när det kommer till säkerhet (genom segmentering). SDN-lösningar ger dessutom en möjlighet till mycket, mycket, mycket bekväm och flexibel administration och gör nätverket mer transparent för sina användare.

Generellt sett, om lokala nätverk skulle ha uppfunnits kring 2010-talet, skulle de se mycket annorlunda ut än det vi har ärvt från militären under 1970-talet.

När det gäller teknologier för att bygga fabriksliknande nätverk med overlay-nätverk, finns det för närvarande många implementationer från olika tillverkare och internetprojekt RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve och andra). Ja, det finns standarder, men implementationen av dessa standarder kan variera mellan olika tillverkare, så det är teoretiskt möjligt att helt avstå från leverantörslåsningar vid skapandet av sådana fabriker, men det är fortfarande mest en pappersfråga.

Med SD-lösningar är läget ännu mer komplicerat, varje leverantör har sin egen syn. Det finns helt öppna lösningar som teoretiskt sett kan modifieras av användaren, och det finns helt stängda losningar.

Cisco erbjuder sin egen SDN-lösning för datacenter — ACI. Det är självklart en 100 % leverantörsspecifik lösning när det kommer till val av nätverksutrustning, men det integreras fullt ut med virtualiseringssystem, containerlösningar, säkerhet, orkestrering, belastningsbalanserare och mer. Men i grunden är det fortfarande en slags svart låda, utan möjlighet till full tillgång till alla interna processer. Inte alla kunder går med på en sådan lösning, eftersom du helt beror på kvaliteten på den skrivna koden och dess implementering. Å andra sidan har tillverkaren en av världens bästa tekniska support och en dedikerad team som bara arbetar med denna lösning. Cisco ACI valdes som lösning för det första projektet.

För det andra projektet valdes en lösning baserad på Juniper. Tillverkaren har också sin egen SDN för datacenter, men kunden beslutade att avstå från att implementera SDN. Som nätverksteknologi valdes en EVPN VXLAN-fabrik utan centrala kontroller.

Vad behövs

Att skapa en fabrik möjliggör en lätt skalbar, felfri och pålitlig nätverksstruktur. Arkitekturen (leaf-spine) tar hänsyn till egenskaperna datacenter (trafikvägar, minimering av fördröjningar och flaskhalsar i nätverket). SD-lösningar i datacenter gör det möjligt att enkelt, snabbt och flexibelt hantera en sådan fabrik, integrera den i datacenter-ekosystemet.

Båda kunderna behövde bygga reservdatacenter för att säkerställa felfri drift, förutom att trafiken mellan datacenter skulle krypteras.

Den första kunden hade redan övervägt lösningar utan fabrik som en möjlig standard för sina nätverk, men under testerna stötte de på kompatibilitetsproblem med STP mellan flera leverantörers hårdvara. Det uppstod driftstopp som orsakade serviceavbrott. Och för kunden var detta kritiskt.

Cisco har redan varit kundens företagsstandard, de har tittat på ACI och andra alternativ och beslutat att gå med denna lösning. De gillade automatiseringen av hantering med en knapp genom en enhetlig kontroller. Tjänsterna ställs in snabbare och hanteras snabbare. De beslutade att säkerställa kryptering av trafiken genom att starta MACSec mellan IPN- och SPINE-switcharna. På så sätt kunde de undvika flaskhalsar i form av en kryptogateway, spara kostnader och maximera bandbredden.

Den andra kunden valde en lösning utan kontroller från Juniper, eftersom de redan hade en liten installation i deras befintliga datacenter med en implementering av EVPN VXLAN-fabriken. Men där var den inte redundanta (en switch användes). De beslutade att utöka infrastrukturen i huvuddatacentret och bygga fabriken i det reservdatacentret. Den befintliga EVPN användes inte fullt ut: VXLAN-inkapslingen användes faktiskt inte, eftersom alla värdar var anslutna till en switch, och alla MAC-adresser och /32 adresser för värdar var lokala, där switche blev gateway, det fanns inga andra enheter som krävde byggnad av VXLAN-tunnlar. De beslutade att säkerställa kryptering av trafiken med hjälp av IPSEC-teknologi mellan brandväggarna (prestandan i MSÄ var tillräcklig).

De tittade också på ACI, men beslutade att på grund av leverantörslåsningen skulle de behöva köpa för mycket hårdvara, inklusive att byta ut nyligen inköpt ny utrustning, vilket helt enkelt inte hade någon ekonomisk mening. Ja, Cisco-fabriken integreras med allt, men endast dess enheter är möjliga inom fabrikens interna struktur.

Å andra sidan, som tidigare nämnts, kan du inte enkelt blanda EVPN VXLAN-fabriken med vilken grannes leverantör som helst, eftersom implementeringarna av protokollet skiljer sig. Det är som att korsa Cisco och Huawei inom samma nätverk — standards kan vara gemensamma, men du måste dansa med tamburen. Eftersom detta är en bank, och kompatibilitetstester skulle ta väldigt lång tid, beslutade de att bättre köpa från samma leverantör nu, och inte gå för långt utanför grundläggande funktionalitet.

Migrationsplan

Två datacenter baserade på ACI:

Organisation av interaktionen mellan datacenter. Multi-Pod-lösningen har valts — varje datacenter fungerar som en pod. Kraven på skalbarhet för antalet switchar och för fördröjningen mellan poddar (RTT mindre än 50 ms) har beaktats. Beslutet togs att inte bygga en Multi-Site-lösning för att underlätta hanteringen (för Multi-Pod-lösningen används ett gemensamt hanteringsgränssnitt, för Multi-Site skulle det behövas två gränssnitt eller en Multi-Site Orchestrator), och eftersom geografisk redundans på platserna inte var nödvändig.

När det gäller migrationen av tjänster från det äldre nätverket, valdes det mest transparenta alternativet, att gradvis flytta VLAN som motsvarar specifika tjänster.
För migreringen skapades ett motsvarande EPG (End-point-group) för varje VLAN i fabriken. Först sträcktes nätverket ut mellan det gamla nätverket och fabriken över L2, och efter att alla värdar migrerats flyttades gatewayen till fabriken, och interaktionen mellan EPG och det befintliga nätverket utfördes via L3OUT, där interaktionen mellan L3OUT och EPG beskrevs med hjälp av kontrakt. En ungefärlig skiss:

Den ungefärliga strukturen för de flesta policys i ACI-fabriken visas i bilden nedan. All konfiguration bygger på policys som är insatta i andra policys och så vidare. I början är det mycket svårt att förstå, men så småningom, som erfarenheten visar, vänjer sig nätverksadministratörer vid en sådan struktur på ungefär en månad, och då kommer förståelsen för hur praktisk den är.

Jämförelse

I Cisco ACI-lösningen krävs det att köpa mer utrustning (separata switchar för Inter-Pod-interaktion och APIC-kontroller), vilket har gjort den dyrare. Juniper-lösningen krävde inte köp av kontroller och hjälputrustning; det blev möjligt att delvis använda kundens redan befintliga utrustning.

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

Med ACI får du en färdig lösning – ingen nødvendig att pilla med, ingen nødvendig att optimera. Vid den första introduktionen av kunden till fabriken behövs ingen utvecklare, ingen supportperson för kod och automatisering. Det räcker med att bara köra, många inställningar kan göras helt genom en wizard, vilket inte alltid är en fördel, särskilt för dem som är vana vid kommandoraden. I vilket fall som helst krävs det tid för att omprogrammera hjärnan för att anpassa sig till nya spår, till egenskaperna hos inställningar genom policys och hantering av många inbäddade policys. Det är mycket önskvärt att utöver detta ha en tydlig struktur för namngivning av policys och objekt. Vid uppkomsten av något problem i logiken av kontrollerarens arbete kan det endast lösas genom supporten.

I EVPN – konsolen. Lida eller glädjas. Den vanliga gränssnittet för den gamla gardet. Ja, det finns standardkonfiguration och guider. Du kommer att behöva läsa manualer. Olika konstruktioner, allt är klart och detaljerat.

Självklart, i båda fallen är det bättre vid migration att först migrera de minst kritiska tjänsterna, till exempel testmiljöer, och först efter att ha fångat alla buggar gå över till produktion. Och gör inga inställningar på fredag kväll. Det är inte värt att tro på leverantören att allt kommer att vara okej, det är alltid bättre att vara på den säkra sidan.

Med ACI betalar du mer, ä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 – support. Hantering och någon form av automatisering av EVPN-fabriken utan kontroller kräver investeringar och löpande kostnader – övervakning, automatisering, implementering av nya tjänster. Samtidigt tar den första lanseringen av ACI längre tid med 30–40 procent. Detta beror på att hela uppsättningen nödvändiga profiler och policys tar längre tid att skapa, vilka sedan kommer att användas. Men med nätverkets tillväxt minskar antalet nödvändiga konfigurationer. Du kan använda redan förut skapade policys, profiler, objekt. Du kan flexibelt anpassa segmentering och säkerhet, centralt hantera kontrakt som ansvarar för tillståndet av olika interaktioner mellan EPG – arbetsbelastningen minskar avsevärt.

I EVPN måste varje enhet i fabriken konfigureras, vilket ökar sannolikheten för fel.

Om ACI implementeras långsammare, så har EVPN nästan dubbelt så lång tid för avstämning. I fallet med Cisco kan man alltid kalla på en supportingenjör och fråga om nätverket i stort (eftersom det täcks som en lösning), medan hos Juniper Networks köper du bara hårdvaran, och det är endast den som täcks. Har paketen skickats från enheten? Okej, det är era problem nu. Men du kan ställa en fråga om valet av lösning eller nätverksdesign — och då rekommenderar de att köpa professionell service mot en extra kostnad.

ACI-supporten är verkligen fantastisk, eftersom den är separat: ett eget team sitter bara för detta. Det finns också rysktalande specialister. Guiden är detaljerad, lösningarna är fördefinierade. De granskar och ger råd. Designen valideras snabbt, vilket ofta är viktigt. Juniper Networks gör samma sak, men mycket långsammare (det var så för oss, nu ska det vara bättre enligt rykten), vilket tvingar dig att göra allt själv där en lösningsingenjör skulle kunna ge råd.

Cisco ACI stöder integration med virtualiserings- och containerplattformar (VMware, Kubernetes, Hyper-V) och centraliserad hantering. Det finns nätverkstjänster och säkerhetstjänster — lastbalansering, brandväggar, WAF, IPS med mera… Bra mikrosegregering från början. I den andra lösningen är integrationen med nätverkstjänster mer komplicerad, och det är bättre att i förväg kolla forum med dem som har gjort det.

Resultat

För varje specifikt fall måste en lösning väljas, inte bara med hänsyn till kostnaden för utrustningen, utan också med tanke på de framtida driftkostnaderna och de grundläggande problem som kunden brottas med just nu, samt vilka planer som finns för utvecklingen av IT-infrastrukturen.

ACI blev dyrare på grund av ytterligare utrustning, men lösningen är färdig utan behov av ytterligare modifieringar, den andra lösningen är mer komplex och kostsam ur driftssynpunkt, men billigare.

Om ni vill diskutera vad implementeringen av en nätverksfabrik kan kosta hos olika leverantörer, och vilken arkitektur som behövs, — vi kan träffas och prata. Vi hjälper gärna till till ett grovt utkast av arkitekturen (som man kan räkna budgeter med) gratis, en detaljerad bearbetning kostar naturligtvis.