Utvärdera anslutningarna i mitten av diagrammet. Vi återkommer till dem nedan
Vid något tillfälle kan du upptäcka att stora, komplexa L2-baserade nätverk är dödligt sjuka. Först och främst problem associerade med bearbetning av BUM-trafik och driften av STP-protokollet. För det andra är arkitekturen i allmänhet föråldrad. Detta orsakar obehagliga problem i form av stillestånd och obekväm hantering.
Vi hade två parallella projekt, där kunderna nyktert bedömde alla för- och nackdelar med alternativen och valde två olika överläggslösningar och vi implementerade dem.
Det fanns möjlighet att jämföra genomförandet. Inte exploatering, vi borde prata om det om två eller tre år.
Så, vad är ett nätverkstyg med överläggsnätverk och SDN?
Vad ska man göra med de akuta problemen med klassisk nätverksarkitektur?
Varje år dyker nya tekniker och idéer upp. I praktiken har det akuta behovet av att bygga om nätverk inte uppstått på ganska länge, för att göra allt för hand med de gamla goda metoderna är också möjligt. Så vad händer om det är det tjugoförsta århundradet? En administratör ska ju jobba och inte sitta på sitt kontor.
Sedan började en boom i byggandet av storskaliga datacenter. Då stod det klart att den klassiska arkitekturens utvecklingsgräns hade nåtts, inte bara vad gäller prestanda, feltolerans och skalbarhet. Och ett av alternativen för att lösa dessa problem var idén om att bygga överläggsnätverk ovanpå ett rutat stamnät.
Dessutom, med ökningen av omfattningen av nätverk, har problemet med att hantera sådana fabriker blivit akut, som ett resultat av vilket mjukvarudefinierade nätverkslösningar började dyka upp med förmågan att hantera hela nätverksinfrastrukturen som en helhet. 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.
Allt som återstår är att ta reda på vad som passar för vilka behov. Till exempel, för särskilt stora företag med ett bra utvecklings- och driftteam, tillfredsställer inte alltid paketerade lösningar från leverantörer alla behov, och de tar till att utveckla sina egna SD-lösningar (programvarudefinierade). Det är till exempel molnleverantörer som ständigt utökar utbudet av tjänster som tillhandahålls sina kunder, och paketerade lösningar klarar helt enkelt inte av att hänga med deras behov.
För medelstora företag är den funktionalitet som leverantören erbjuder i form av en boxad lösning tillräcklig i 99 procent av fallen.
Vad är överläggsnätverk?
Vad är tanken bakom överläggsnätverk? I huvudsak tar du ett klassiskt dirigerat nätverk och bygger ett annat nätverk ovanpå det för att få fler funktioner. Oftast pratar vi om att effektivt fördela belastningen på utrustning och kommunikationslinjer, avsevärt öka skalbarhetsgränsen, öka tillförlitligheten och en massa säkerhetsgodis (på grund av segmentering). Och SDN-lösningar ger utöver detta möjlighet till väldigt, väldigt, väldigt bekväm flexibel administration och gör nätet mer transparent för sina konsumenter.
I allmänhet, om lokala nätverk hade uppfunnits på 2010-talet, skulle de ha sett mycket annorlunda ut än vad vi ärvde från militären på 1970-talet.
När det gäller teknologier för att bygga tyger med överlagringsnätverk finns det för närvarande många leverantörsimplementeringar och Internet RFC-projekt (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve och andra). 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 fortfarande möjligt att helt överge leverantörslåset endast i teorin på papper.
Med en SD-lösning är saker och ting ännu mer förvirrande, varje leverantör har sin egen vision. Det finns helt öppna lösningar som man i teorin kan komplettera själv, och det finns helt slutna.
Cisco erbjuder sin version av SDN för datacenter - ACI. Naturligtvis är detta en 100 % leverantörslåst lösning vad gäller val av nätverksutrustning, men samtidigt är den helt integrerad med virtualiseringssystem, containerisering, säkerhet, orkestrering, lastbalanserare etc. Men i huvudsak är det fortfarande en sorts svart låda, utan möjlighet till full tillgång till alla interna processer. Inte alla kunder accepterar detta alternativ, eftersom du är helt beroende av kvaliteten på den skriftliga lösningskoden och dess implementering, men å andra sidan har tillverkaren en av de bästa tekniska supporterna i världen och har ett dedikerat team som endast är dedikerat till denna lösning. Cisco ACI valdes som lösningen för det första projektet.
För det andra projektet valdes en Juniper-lösning. Tillverkaren har även ett eget SDN för datacentret, men kunden valde att inte implementera SDN. Ett EVPN VXLAN-tyg utan användning av centraliserade styrenheter valdes som nätverkskonstruktionsteknik.
Vad är det för?
Genom att skapa en fabrik kan du bygga ett enkelt skalbart, feltolerant, pålitligt nätverk. Arkitekturen (bladryggen) tar hänsyn till egenskaperna hos datacenter (trafikvägar, minimering av förseningar och flaskhalsar i nätverket). SD-lösningar i datacenter låter dig mycket bekvämt, snabbt och flexibelt hantera en sådan fabrik och integrera den i datacentrets ekosystem.
Båda kunderna behövde bygga redundanta datacenter för att säkerställa feltolerans, och dessutom måste trafiken mellan datacenterna krypteras.
Den första kunden övervägde redan tyglösa lösningar som en möjlig standard för sina nätverk, men i tester hade de problem med STP-kompatibilitet mellan flera hårdvaruleverantörer. Det fanns driftstopp som fick tjänsterna att krascha. Och för kunden var detta avgörande.
Cisco var redan kundens företagsstandard, de tittade på ACI och andra alternativ och beslutade att det var värt att ta den här lösningen. Jag gillade automatiseringen av kontroll från en knapp genom en enda kontroller. Tjänsterna konfigureras snabbare och hanteras snabbare. Vi bestämde oss för att säkerställa trafikkryptering genom att köra MACSec mellan IPN- och SPINE-switcharna. Därmed lyckades vi undvika flaskhalsen i form av en krypto-gateway, spara på dem och använda maximal bandbredd.
Den andra kunden valde en styrlös lösning från Juniper eftersom deras befintliga datacenter redan hade en liten installation som implementerade ett EVPN VXLAN-tyg. Men där var den inte feltålig (en strömbrytare användes). Vi beslutade att utöka infrastrukturen för huvuddatacentret och bygga en fabrik i backupdatacentret. Den befintliga EVPN användes inte fullt ut: VXLAN-inkapsling användes faktiskt inte, eftersom alla värdar var anslutna till en switch och alla MAC-adresser och /32 värdadresser var lokala, gatewayen för dem var samma switch, det fanns inga andra enheter , där det var nödvändigt att bygga VXLAN-tunnlar. De bestämde sig för att säkerställa trafikkryptering med IPSEC-teknik mellan brandväggar (brandväggens prestanda var tillräcklig).
De provade också ACI, men bestämde sig för att på grund av leverantörslåset skulle de behöva köpa för mycket hårdvara, inklusive att byta ut nyligen inköpt ny utrustning, och det var helt enkelt inte ekonomiskt vettigt. Ja, Cisco-tyget integreras med allt, men bara dess enheter är möjliga i själva tyget.
Å andra sidan, som vi sa tidigare, kan du inte bara blanda ett EVPN VXLAN-tyg med någon närliggande leverantör, eftersom protokollimplementeringarna är olika. Det är som att korsa Cisco och Huawei i ett nätverk - det verkar som om standarderna är vanliga, men du måste dansa med en tamburin. Eftersom det här är en bank, och kompatibilitetstester skulle vara mycket långa, bestämde vi oss för att det var bättre att köpa från samma leverantör nu och inte bli för hänförd av funktionalitet utöver de grundläggande.
Migrationsplan
Två ACI-baserade datacenter:
Organisering av interaktion mellan datacenter. Multi-Pod-lösningen valdes – varje datacenter är en pod. Kraven på skalning efter antal switchar och fördröjningar mellan pods (RTT mindre än 50 ms) beaktas. Det beslutades att inte bygga en Multi-Site-lösning för att underlätta hanteringen (en Multi-Pod-lösning använder ett enda hanteringsgränssnitt, en Multi-Site skulle ha två gränssnitt eller skulle kräva en Multi-Site Orchestrator), och eftersom ingen geografisk reservation av webbplatser krävdes.
Med tanke på att migrera tjänster från Legacy-nätverket valdes det mest transparenta alternativet, som gradvis överförde VLAN som motsvarar vissa tjänster.
För migrering skapades en motsvarande EPG (End-point-group) för varje VLAN på fabriken. Först sträcktes nätverket mellan det gamla nätverket och strukturen över L2, sedan efter att alla värdar migrerats flyttades gatewayen till strukturen och EPG interagerade med det befintliga nätverket genom L3OUT, medan interaktionen mellan L3OUT och EPG beskrevs med hjälp av kontrakt. Ungefärligt diagram:
Ett exempel på struktur för de flesta ACI-fabrikspolicyer visas i figuren nedan. Hela installationen är baserad på policyer som är kapslade i andra policyer och så vidare. Till en början är det väldigt svårt att ta reda på det, men gradvis, som praxis visar, vänjer sig nätverksadministratörer vid denna struktur på ungefär en månad, och sedan börjar de först förstå hur bekvämt det är.
jämförelse
I Cisco ACI-lösningen behöver du köpa mer utrustning (separata switchar för Inter-Pod-interaktion och APIC-kontroller), vilket gör det dyrare. Junipers lösning krävde inte inköp av kontroller eller tillbehör; Det var möjligt att delvis använda kundens befintliga utrustning.
Här är EVPN VXLAN-tygarkitekturen för två datacenter i det andra projektet:
Med ACI får du en färdig lösning - inget behov av att mixtra, inget behov av att optimera. Under kundens första bekantskap med fabriken behövs inga utvecklare, inga stödjande personer behövs för kod och automatisering. Det är ganska lätt att använda; många inställningar kan göras genom guiden, vilket inte alltid är ett plus, särskilt för personer som är vana vid kommandoraden. Hur som helst, det tar tid att bygga upp hjärnan på nya spår, till särdragen med inställningar genom policyer och att arbeta med många kapslade policyer. Utöver detta är det mycket önskvärt att ha en tydlig struktur för namngivning av policyer och objekt. Om något problem uppstår i styrenhetens logik kan det endast lösas genom teknisk support.
I EVPN - konsol. Lida eller glädjas. Ett välbekant gränssnitt för det gamla gardet. Ja, det finns en standardkonfiguration och guider. Du måste röka mana. Olika design, allt är tydligt och detaljerat.
Naturligtvis, i båda fallen, när du migrerar, är det bättre att först migrera inte de mest kritiska tjänsterna, till exempel testmiljöer, och först sedan, efter att ha fångat alla buggar, gå vidare till produktionen. Och lyssna inte på fredag kväll. Du ska inte lita på leverantören att allt kommer att ordna sig, det är alltid bättre att spela säkert.
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ållet. Hantering och all automatisering av en EVPN-fabrik utan styrenhet kräver investeringar och regelbundna kostnader - övervakning, automatisering, implementering av nya tjänster. Samtidigt tar den första lanseringen på ACI 30–40 procent längre tid. Detta händer eftersom det tar längre tid att skapa hela uppsättningen av nödvändiga profiler och policyer som sedan kommer att användas. Men när 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 är ansvariga för att tillåta viss interaktion mellan EPG:er – mängden arbete minskar kraftigt.
I EVPN måste du konfigurera varje enhet i fabriken, sannolikheten för fel är större.
Medan ACI var långsammare att implementera, tog EVPN nästan dubbelt så lång tid att felsöka. Om du i Ciscos fall alltid kan ringa en supportingenjör och fråga om nätverket som helhet (eftersom det täcks som en lösning), så köper du från Juniper Networks bara hårdvara, och det är det som täcks. Har paketen lämnat enheten? Okej, då dina problem. Men du kan öppna en fråga angående val 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-stöd är väldigt coolt, eftersom det är separat: ett separat team sitter bara för detta. Det finns också 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 här, 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 containeriseringssystem (VMware, Kubernetes, Hyper-V) och centraliserad hantering. Finns med nätverks- och säkerhetstjänster - balansering, brandväggar, WAF, IPS, etc... Bra mikrosegmentering ur lådan. I den andra lösningen är integration med nätverkstjänster en bris, och det är bättre att diskutera forum i förväg med dem som har gjort detta.
Totalt
För varje specifikt fall är det nödvändigt att välja en lösning, inte bara baserat på kostnaden för utrustningen, utan det är också nödvändigt att ta hänsyn till ytterligare driftskostnader och de huvudsakliga problemen som kunden för närvarande står inför, och vilka planer där är för utveckling av IT-infrastrukturen.
ACI, på grund av extra utrustning, var dyrare, men lösningen är färdiggjord utan behov av ytterligare efterbehandling; den andra lösningen är mer komplex och kostsam när det gäller drift, men billigare.
Om du vill diskutera hur mycket det kan kosta att implementera ett nätverkstyg på olika leverantörer, och vilken typ av arkitektur som behövs, kan du träffas och chatta. Vi ger dig råd utan kostnad tills du får en grov skiss på arkitekturen (med vilken du kan beräkna budgetar), detaljerad bearbetning är naturligtvis redan betald.
Vladimir Klepche, företagsnätverk.
Källa: will.com