Vurdere bånd i midten af diagrammet. Vi vil vende tilbage til dem senere.
På et tidspunkt kan du støde på, at store komplekse netværk baseret på L2 er uhelbredeligt syge. Først og fremmest på grund af problemer relateret til behandling af BUM-trafik og med STP-protokollen. For det andet på grund af en generelt forældet arkitektur. Dette skaber ubehagelige problemer i form af nedetid og vanskeligheder med administration.
Vi havde to parallelle projekter, hvor kunderne realistisk vurderede alle fordele og ulemper ved mulighederne og valgte to forskellige overlay-løsninger, som vi implementerede.
Der var mulighed for at sammenligne netop implementeringen. Ikke driften, det kan vi vurdere om to til tre år.
Så hvad er et netværksfabrikationssystem med overlay-netværk og SDN?
Hvad skal der gøres med de velkendte problemer i klassisk netværksarkitektur?
Hvert år dukker der nye teknologier og ideer op. I praksis har der længe ikke været et presserende behov for at omstrukturere netværk, fordi man stadig kan gøre alt manuelt med gamle, pålidelige metoder. Og hvad så, hvis vi er i det 21. århundrede? I sidste ende skal administratoren arbejde og ikke sidde i sit kontor.
Så begyndte boomet med konstruktionen af store datacentre. Dengang blev det klart, at grænsen for udviklingen af klassisk arkitektur var nået, ikke kun hvad angår funktionalitet, fejltolerance og skalerbarhed. Og en af løsningerne på disse problemer blev ideen om at bygge overlay-netværk oven på en routbar backbone.
Derudover opstod problematikken omkring administration af sådanne fabrikker, når netværkene blev større, hvilket resulterede i fremkomsten af løsninger for softwaredefinerede netværk med mulighed for at administrere hele netværksinfrastrukturen som en enhed. Når netværket administreres som en helhed, bliver det lettere for andre komponenter i IT-infrastrukturen at interagere med det, og sådanne interaktionsprocesser er lettere at automatisere.
Næsten hver større producent, ikke kun af netværksudstyr, men også af virtualisering, har sådanne løsninger i deres portefølje.
Det handler kun om at finde ud af, hvad der passer til hvilke behov. For eksempel, for meget store virksomheder med et godt udviklingsteam og driftsafdeling tilfredsstiller de færdige løsninger fra leverandører ikke altid alle behov, og de tyr til at udvikle deres egne SD (software defined) løsninger. For eksempel er dette cloud-udbydere, der konstant udvider deres sortiment af tjenester til deres kunder, og færdige løsninger kan simpelthen ikke følge med deres behov.
For mellemstore virksomheder er de funktioner, som leverandøren tilbyder i form af en færdig løsning, tilstrækkelige i 99 procent af tilfældene.
Hvad er overlay-netværk?
Hvad er idéen bag overlay-netværk? I det væsentlige tager du et klassisk routet netværk og bygger et yderligere netværk ovenpå for at få flere funktioner. Oftest handler det om effektiv fordeling af belastningen på udstyr og kommunikationslinjer, betydelig stigning i skalerbarhed, forbedring af pålidelighed og en masse fordele inden for sikkerhed (gennem segmentering). Og SDN-løsninger giver desuden mulighed for meget, meget, meget fleksibel administration, hvilket gør netværket mere gennemsigtigt for dets brugere.
Generelt hvis lokale netværk var blevet opfundet i omkring 2010'erne, ville de se helt anderledes ud end det, vi har arvet fra militæret i 1970'erne.
Set fra et teknologisk perspektiv for opbygning af fabrikker ved hjælp af overlay-netværk, findes der i øjeblikket mange implementeringer fra producenter og internetprojekter RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve og andre). Ja, der er standarder, men implementeringen af disse standarder fra forskellige producenter kan variere, så det er kun i teorien muligt at undgå leverandørlåsning fuldstændigt på papir, når sådanne fabrikker oprettes.
Sagerne med SD-løsninger er endnu mere komplekse, hver leverandør har sin egen opfattelse. Der er helt åbne løsninger, som i teorien kan tilpasses af dig selv, og der er helt lukkede løsninger.
Cisco tilbyder sin version af SDN til datacentre - ACI. Det er selvfølgelig en 100 % leverandør-specifik løsning med hensyn til valg af netværksudstyr, men det integreres fuldt ud med virtualiserings-, containeriserings-, sikkerheds-, orkestreringssystemer, load balancere mv. Men i bund og grund er det stadig en form for sort boks, uden mulighed for fuld adgang til alle interne processer. Ikke alle kunder er enige i denne løsning, da man er fuldstændig afhængig af kvaliteten af den kode, der er skrevet til løsningen, og dens implementering. På den anden side har producenten en af de bedste tekniske supportløsninger i verden og en dedikeret gruppe, der kun arbejder med denne løsning. Cisco ACI blev valgt som løsning til det første projekt.
Til det andet projekt blev der valgt en løsning fra Juniper. Producenten har også sin egen SDN til datacentre, men kunden besluttede at afvise implementeringen af SDN. EVPN VXLAN-fabrikken blev valgt som netværksteknologi uden brug af centraliserede controllere.
Hvad er det nødvendigt til
Oprettelsen af en fabrik gør det muligt at bygge et let skalerbart, fejlresistent og pålideligt netværk. Arkitekturen (leaf-spine) tager højde for særegenhederne datacentre (trafikveje, minimalisering af forsinkelser og flaskehalse i netværket). SD-løsninger i datacentre tillader meget bekvemt, hurtigt og fleksibelt at administrere en sådan fabrik og integrere den i datacentrets økosystem.
Begge kunder havde behov for at opbygge backup datacentre for at sikre fejltolerance, og derudover skulle trafikken mellem datacentrene krypteres.
Den første kunde overvejede allerede løsninger uden fabrikken som en mulig standard for deres netværk, men under testene oplevede de problemer med kompatibilitet af STP mellem flere leverandører af hardware. Der opstod nedetider, der forårsagede servicefald. Og for kunden var dette kritisk.
Cisco har allerede været kundens virksomhedsstandard, de kiggede på ACI og andre muligheder og besluttede, at det var værd at vælge denne løsning. De kunne godt lide automatiseringen af styringen med et enkelt klik gennem en samlet controller. Tjenesterne konfigureres hurtigere, og administrationen går hurtigere. De besluttede at sikre trafikkryptering ved at implementere MACSec mellem IPN- og SPINE-svitsjerne. På denne måde kunne de undgå en flaskehals i form af en krypteringsgateway, spare penge på den og maksimere båndbredden.
Den anden kunde valgte en løsning uden controller fra Juniper, da der allerede var en lille installation med implementering af EVPN VXLAN i deres eksisterende datacenter. Men det var ikke redundante (kun én switch blev brugt). Der blev truffet beslutning om at udvide infrastrukturen i hoveddatacentret og opbygge en fabrik i det backup-datacenter. Den eksisterende EVPN blev ikke udnyttet fuldt ud: VXLAN-inkapsling blev faktisk ikke anvendt, da alle værter var tilsluttet en switch, og alle MAC-adresser og /32 adresser for værter var lokale, og gatewayen for dem var den samme switch, der var ingen andre enheder, hvor VXLAN-tunneler skulle opbygges. De besluttede at sikre trafikkryptering ved hjælp af IPSEC-teknologi mellem firewalls (MSA-ydeevnen var tilstrækkelig).
De kiggede også på ACI, men besluttede, at på grund af leverandørbindingen ville de være nødt til at købe for meget hardware, herunder erstatte nyindkøbt udstyr, og det giver ikke økonomisk mening. Ja, Cisco-fabrikken integreres med alt, men inden for selve fabrikken er kun dens egne enheder mulige.
På den anden side, som nævnt tidligere, kan man ikke bare blande en EVPN VXLAN-fabrik med enhver naboleverandør, fordi implementeringerne af protokollen adskiller sig. Det er som at blande Cisco og Huawei i et netværk — standarderne er tilsyneladende fælles, men man må danse med tamburinerne. Da dette er en bank, og kompatibilitetstestene ville være meget lange, besluttede de, at det var bedre at investere i den samme leverandør nu og ikke blive for optaget af funktionalitet uden for det grundlæggende.
Migrationsplan
To datacentre baseret på ACI:
Organisering af interaktionen mellem datacentre. Multi-Pod-løsningen blev valgt - hvert datacenter fungerer som en pod. Kravene til skalering med hensyn til antal switches og latensen mellem podene (RTT under 50 ms) er taget i betragtning. Beslutningen om ikke at bygge en Multi-Site-løsning blev taget for at forenkle administrationen (for Multi-Pod-løsningen anvendes et enkelt administrationsinterface, for Multi-Site ville der være brug for to grænseflader eller en Multi-Site Orchestrator), og da der ikke var behov for geografisk redundans mellem sites.
Fra et migrationsperspektiv af tjenester fra Legacy-netværket blev den mest gennemsigtige mulighed valgt, nemlig at overføre VLAN’er gradvist, der svarer til bestemte tjenester.
For migration blev der oprettet et tilsvarende EPG (End-point-group) for hvert VLAN på fabrikken. Først blev netværket strakt mellem det gamle netværk og fabrikken via L2, derefter, efter migrationen af alle værter, blev gatewayen flyttet til fabrikken, og interaktionen mellem EPG og det eksisterende netværk fandt sted via L3OUT, samtidig blev interaktionen mellem L3OUT og EPG beskrevet ved hjælp af kontrakter. Principskema:
Principskemaet for de fleste politikker i ACI-fabrikken ses på billedet nedenfor. Hele opsætningen er baseret på politikker, der er indlejret i andre politikker og så videre. I starten er det meget vanskelig at forstå, men gradvist, som praksis viser, vænner netværksadministratorerne sig til denne struktur på cirka en måned, og kun da får de en forståelse af, hvor bekvemt det er.
Sammenligning
I Cisco ACI-løsningen skal der købes mere udstyr (separate switches til inter-Pod-interaktion og APIC-controllere), hvilket gør det dyrere. Juniper-løsningen krævede ikke køb af controllere og hjælpesystemer; det var muligt at delvist bruge det eksisterende udstyr, som kunden allerede havde.
Her er arkitekturen for EVPN VXLAN-fabrikken for de to datacentre fra det andet projekt:
I ACI får du en færdig løsning — du behøver ikke at rode rundt, og du skal ikke optimere. Ved den indledende introduktion af kunden til fabrikken kræves der ikke udviklere eller supportpersonale til kode og automatisering. Det er tilstrækkeligt med simpel drift, mange indstillinger kan gøres via en wizard, hvilket ikke altid er en fordel, især for folk der er vant til kommandolinjen. På ethvert tidspunkt er der brug for tid til at omstille sindet til nye metoder, til den særlige indstilling via politikker og håndtering af mange indbyrdes indviklede politikker. Det er meget ønskeligt, derudover, at have en klar struktur for navngivning af politikker og objekter. Hvis der opstår problemer i controllerens logik, kan dette kun løses gennem teknisk support.
I EVPN — konsollen. Lid eller glæd dig. Den velkendte grænseflade for den gamle garde. Ja, der er en typisk konfiguration og vejledninger. Du bliver nødt til at gennemgå manualerne. Forskellige konstruktioner, alt er klart og detaljeret.
Naturligvis er det i begge tilfælde bedst at migrere de mindst kritiske tjenester først, for eksempel testmiljøer, og først derefter, efter at alle fejl er fanget, gå i gang med produktionen. Og undgå at konfigurere om fredagen aften. Det er ikke klogt at tro på, at leverandøren siger, at alt vil være i orden; det er altid bedre at tage sine forholdsregler.
På ACI betaler du mere, selvom Cisco i øjeblikket aktivt promoverer denne løsning og ofte giver gode rabatter på den, men du sparer på service og vedligeholdelse. Styring og enhver form for automatisering af EVPN-fabrikken uden controller kræver investeringer og regelmæssige udgifter — overvågning, automatisering, implementering af nye tjenester. Samtidig tager den primære opsætning i ACI længere tid, cirka 30-40 procent længere. Dette sker, fordi det tager længere tid at oprette det nødvendige sæt profiler og politikker, som senere vil blive anvendt. Men efterhånden som netværket vokser, reduceres antallet af nødvendige konfigurationer. Du bruger allerede forudskabte politikker, profiler og objekter. Du kan fleksibelt justere segmentering og sikkerhed og centralt styre de kontrakter, der bestemmer interaktionerne mellem EPG'er — arbejdsbyrden falder drastisk.
I EVPN skal hvert enhed i fabrikken konfigureres, hvilket øger risikoen for fejl.
Hvis ACI implementeres langsommere, så tager EVPN næsten dobbelt så lang tid at fejlfinde. I tilfælde af Cisco kan man altid tilkalde en supportingeniør og spørge om netværket generelt (fordi det dækkes som en løsning), mens du hos Juniper Networks kun køber hardwaren, og det er kun den, der dækkes. Er pakkerne sendt fra enheden? Nå, godt, så er det jeres problem. Men man kan stille spørgsmål om valg af løsning eller netværksdesign - og så vil de anbefale at købe professionel service for et ekstra gebyr.
ACI-supporten er rigtig god, fordi den er særskilt: et separat team sidder kun til dette formål. Der er også russisktalende specialister. Guiden er detaljeret, løsningerne er foruddefinerede. De ser og rådgiver. De validerer hurtigt design, hvilket ofte er vigtigt. Juniper Networks gør det samme, men meget langsommere (det har været vores oplevelse, men nu skulle det efter rygterne være bedre), hvilket tvinger dig til selv at gøre alt der, hvor du kunne have fået råd fra en solutionsingeniør.
Cisco ACI understøtter integration med virtualiserings- og containeriseringssystemer (VMware, Kubernetes, Hyper-V) og centraliseret administration. Der er netværkstjenester og sikkerhedstjenester - belastningsbalancering, firewalls, WAF, IPS og meget mere… God mikrosegmentering direkte fra kassen. I den anden løsning er integrationen med netværkstjenester mere kompliceret, og det er bedst at undersøge fora med dem, der har gjort det før.
Resultat
For hver enkelt sag skal der vælges en løsning, ikke kun baseret på prisen på udstyret, men man skal også tage højde for de fremtidige driftsomkostninger og de hovedproblemer, kunden står overfor nu, samt hvilke planer der er for udvikling af IT-infrastrukturen.
ACI blev dyrere på grund af ekstra udstyr, men det er en klar løsning uden behov for tilpasning, mens den anden løsning er mere kompleks og kostbar med hensyn til drift, men er billigere.
Hvis du ønsker at diskutere, hvad implementeringen af et netværksfabrik kan koste hos forskellige leverandører, og hvilket arkitektur der er nødvendig, kan vi mødes og tale. Indtil et skitseudkast af arkitekturen (som man kan basere budgetterne på) kan vi give gratis rådgivning, en detaljeret bearbejdning er selvfølgelig allerede betalende.
Vladimir Klepche, virksomhedsnetsværk.
Kilde: habr.com
