Vurder forbindelserne i den midterste del af kredsløbet. Vi vender tilbage til dem nedenfor.
På et tidspunkt kan du opleve, at store komplekse netværk baseret på L2 er uhelbredeligt syge. Først og fremmest problemer relateret til behandlingen af BUM-trafik og driften af STP-protokollen. I den anden - generelt, moralsk forældet arkitektur. Dette giver ubehagelige problemer i form af nedetid og besvær ved håndtering.
Vi havde to parallelle projekter, hvor kunder nøgternt vurderede alle fordele og ulemper ved mulighederne og valgte to forskellige overlejringsløsninger, og dem implementerede vi.
Det var muligt at sammenligne implementeringen. Ikke operation, det er værd at tale om det om to eller tre år.
Så hvad er et netværksstof med overlay-netværk og SDN?
Hvad skal man gøre med de ømme problemer med klassisk netværksarkitektur?
Nye teknologier og ideer dukker op hvert år. I praksis opstod det akutte behov for at genopbygge netværkene ikke i lang tid, for man kan også gøre alting i hånden efter de gode gamle bedstefar-metoder. Så hvad, hvad er det enogtyvende århundrede i gården? I sidste ende skal administratoren arbejde og ikke sidde på sit kontor.
Så begyndte et boom i opførelsen af store datacentre. Så blev det klart, at grænsen for udviklingen af klassisk arkitektur var nået, ikke kun med hensyn til ydeevne, fejltolerance, skalerbarhed. Og en af mulighederne for at løse disse problemer var ideen om at bygge overlejringsnetværk oven på en routbar backbone.
Derudover blev problemet med at styre sådanne fabrikker akut med stigningen i netværksskalaen, som et resultat af, at softwaredefinerede netværksløsninger begyndte at dukke op med evnen til at administrere hele netværksinfrastrukturen som helhed. Og når netværket styres fra et enkelt punkt, er det nemmere for andre komponenter i it-infrastrukturen at interagere med det, og sådanne interaktionsprocesser er nemmere at automatisere.
Næsten alle større producenter af ikke kun netværksudstyr, men også virtualisering, har muligheder for sådanne løsninger i sin portefølje.
Det er kun tilbage at finde ud af, hvad der passer til hvilke behov. For eksempel for især store virksomheder med et godt udviklings- og driftsteam, opfylder leverandørernes out-of-the-box løsninger ikke altid alle behov, og de tyr til at udvikle deres egne SD (software defined) løsninger. Det er for eksempel cloud-udbydere, der konstant udvider rækken af tjenester, der leveres til deres kunder, og boxed-løsninger er simpelthen ikke i stand til at følge med deres behov.
For mellemstore virksomheder er den funktionalitet, leverandøren tilbyder i form af en kasseløsning, nok i 99 procent af tilfældene.
Hvad er overlejringsnetværk
Hvad er ideen med overlejringsnetværk. Grundlæggende tager du et klassisk routet netværk og bygger endnu et netværk oven på det for at få flere funktioner. Oftest taler vi om den effektive fordeling af belastningen på udstyr og kommunikationslinjer, en betydelig stigning i skalerbarhedsgrænsen, øget pålidelighed og en masse sikkerhedsgodter (på grund af segmentering). Og SDN-løsninger muliggør derudover meget, meget, meget bekvem fleksibel administration og gør netværket mere gennemsigtigt for dets forbrugere.
Generelt, hvis lokale netværk blev opfundet i årene af 2010'erne, ville de se langt fra det, vi arvede fra militæret fra 1970'erne.
Med hensyn til teknologier til at bygge fabrikker ved hjælp af overlejringsnetværk er der i øjeblikket mange implementeringer af producenter og internet RFC-projekter (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve og andre). Ja, der er standarder, men implementeringen af disse standarder af forskellige producenter kan variere, så når du opretter sådanne fabrikker, er det stadig muligt helt at opgive leverandørlåsen kun i teorien på papir.
Med SD-løsningen er tingene endnu mere komplicerede, hver leverandør har sin egen vision. Der er helt åbne løsninger, som man i teorien kan gøre færdig på egen hånd, der er helt lukkede.
Cisco tilbyder sin egen version af SDN til datacentre - ACI. Der er naturligvis tale om en 100 % leverandørlåst løsning i forhold til valg af netværksudstyr, men samtidig er den fuldt integreret med virtualisering, containerisering, sikkerhed, orkestrering, load balancers osv. Men faktisk er det stadig en slags black box, uden mulighed for fuld adgang til alle interne processer. Ikke alle kunder er enige i denne mulighed, da du er fuldstændig afhængig af kvaliteten af den skrevne løsningskode og dens implementering, men på den anden side har producenten en af de bedste tekniske support i verden og har et dedikeret team, der beskæftiger sig med kun med denne løsning. Cisco ACI blev valgt som løsningen til det første projekt.
Til det andet projekt blev der valgt en Juniper-løsning. Producenten har også sit eget SDN til datacentret, men kunden besluttede ikke at implementere SDN. EVPN VXLAN fabrikken blev valgt som teknologien til at bygge netværket uden brug af centraliserede controllere.
Hvad har du brug for
Oprettelse af en fabrik giver dig mulighed for at bygge et let skalerbart, fejltolerant, pålideligt netværk. Arkitekturen (bladryg) tager højde for datacentres funktioner (trafikstier, minimering af forsinkelser og flaskehalse i netværket). SD-løsninger i datacentre gør det meget bekvemt, hurtigt, fleksibelt at administrere en sådan fabrik, integrere den i datacentrets økosystem.
Begge kunder skulle bygge redundante datacentre for at sikre fejltolerance, desuden skulle trafikken mellem datacentre krypteres.
Den første kunde overvejede allerede stofløse løsninger som en mulig standard for deres netværk, men i test havde de problemer med STP-kompatibilitet mellem flere hardwareleverandører. Der var nedetider, der forårsagede servicefald. Og for kunden var det kritisk.
Cisco var allerede kundens virksomhedsstandard, de så på ACI og andre muligheder og besluttede, at det var værd at tage netop denne løsning. Jeg kunne godt lide automatiseringen af kontrol fra én knap gennem en enkelt controller. Tjenester opsættes hurtigere, administreres hurtigere. Vi besluttede at levere trafikkryptering ved at køre MACSec mellem IPN- og SPINE-switcherne. Dermed var det muligt at undgå en flaskehals i form af en krypto-gateway, spare på dem og udnytte båndbredden maksimalt.
Den anden kunde valgte Junipers controllerløse løsning, fordi deres eksisterende datacenter allerede havde en lille installation med en EVPN VXLAN-stofimplementering. Men der var den ikke fejltolerant (en afbryder blev brugt). Vi besluttede at udvide infrastrukturen i hoveddatacentret og bygge en fabrik i backupdatacentret. Den eksisterende EVPN blev ikke udnyttet fuldt ud: VXLAN-indkapsling blev faktisk ikke brugt, da alle værter var forbundet til den samme switch, og alle MAC-adresser og /32 værtsadresser var lokale, den samme switch var gatewayen for dem, der var ingen andre enheder, hvor det var nødvendigt at bygge VXLAN-tunneler. De besluttede at levere trafikkryptering ved hjælp af IPSEC-teknologi mellem firewalls (ITU-ydelsen var tilstrækkelig).
De prøvede også ACI, men besluttede, at på grund af leverandørlåsen, ville de skulle købe for meget hardware, inklusive udskiftning af nyligt købt nyt udstyr, og det giver simpelthen ikke økonomisk mening. Ja, Cisco-stoffet integreres med alt, men kun dets enheder er muligt inde i selve stoffet.
På den anden side, som tidligere nævnt, kan du ikke bare blande en EVPN VXLAN-fabrik med enhver naboleverandør, fordi protokolimplementeringerne er anderledes. Det er som at krydse Cisco og Huawei i samme netværk – det ser ud til, at standarderne er fælles, kun du skal danse med en tamburin. Da dette er en bank, og kompatibilitetstests ville være meget lange, besluttede vi, at det var bedre at købe fra den samme leverandør nu og ikke rigtig lade sig rive med af funktionalitet ud over den grundlæggende.
Migrationsplan
To datacentre baseret på ACI:
Organisering af interaktion mellem datacentre. Der er valgt en Multi-Pod løsning - hvert datacenter er en pod. Kravene til skalering efter antallet af switches og forsinkelser mellem pods (RTT mindre end 50 ms) tages i betragtning. Det blev besluttet ikke at bygge en Multi-Site-løsning for at lette administrationen (en enkelt administrationsgrænseflade bruges til en Multi-Pod-løsning, for Multi-Site ville der være to grænseflader, eller en Multi-Site Orchestrator ville være påkrævet). og da der ikke var behov for geografisk reservation af steder.
Fra synspunktet om migrering af tjenester fra Legacy-netværket blev den mest gennemsigtige mulighed valgt, gradvist at overføre VLAN'er svarende til visse tjenester.
Til migrering blev der oprettet en tilsvarende EPG (End-point-group) for hvert VLAN på fabrikken. Først blev netværket strakt mellem det gamle netværk og fabrikken langs L2, derefter efter migreringen af alle værter blev gatewayen overført til fabrikken, og EPG'en interagerede med det eksisterende netværk gennem L3OUT, mens interaktionen mellem L3OUT og EPG blev beskrevet ved hjælp af kontrakter. Omtrentlig skema:
Den omtrentlige struktur for de fleste ACI-fabrikspolitikker er vist i figuren nedenfor. Hele indstillingen er baseret på politikker indlejret i andre politikker og så videre. I starten er det meget svært at finde ud af det, men gradvist, som praksis viser, vænner netværksadministratorer sig til en sådan struktur i løbet af cirka en måned, og derefter kommer først forståelsen af, hvor praktisk det er.
sammenligning
I Cisco ACI-løsningen skal du købe mere udstyr (separate switche til Inter-Pod-interaktion og APIC-controllere), hvorfor det viste sig at være dyrere. Junipers løsning krævede ikke indkøb af controllere og tilbehør; det viste sig delvist at bruge kundens allerede eksisterende udstyr.
Her er EVPN VXLAN-stofarkitekturen for de to datacentre i det andet projekt:
I ACI får du en færdig løsning - ingen grund til at plukke, ingen grund til at optimere. Ved kundens første bekendtskab med fabrikken er der ikke behov for udviklere, der er ikke behov for støttende folk til kode og automatisering. Enkel betjening er nok, mange indstillinger kan udføres generelt gennem en guide, hvilket ikke altid er et plus, især for folk, der er vant til kommandolinjen. Under alle omstændigheder tager det tid at genopbygge hjernen på nye spor, på de særlige forhold ved indstillinger gennem politikker og drift på en lang række indlejrede politikker. Udover dette er det yderst ønskeligt at have en klar struktur for navngivning af politikker og objekter. Hvis der er et problem i controllerens logik, kan det kun løses gennem teknisk support.
I EVPN, konsollen. Lide eller glæde sig. Velkendt interface til den gamle garde. Ja, der er en typisk konfiguration og guider. Du skal ryge mana. Forskellige designs, alt er klart og detaljeret.
Naturligvis er det i begge tilfælde bedre ikke at migrere de mest kritiske tjenester først, for eksempel testmiljøer, og først derefter, efter at have fanget alle fejlene, fortsætte til produktion. Og tune ikke ind fredag aften. Du skal ikke stole på leverandøren, at alt vil være ok, det er altid bedre at spille sikkert.
Du betaler mere på ACI, selvom Cisco i øjeblikket aktivt promoverer denne løsning og ofte giver gode rabatter for den, men du sparer på vedligeholdelsen. Administration og enhver form for automatisering af en EVPN-fabrik uden en controller kræver investeringer og regelmæssige omkostninger - overvågning, automatisering, implementering af nye tjenester. Samtidig tager den første lancering af ACI 30-40 procent længere. Dette skyldes, at det tager længere tid at oprette hele sæt af nødvendige profiler og politikker, som derefter vil blive brugt. Men efterhånden som netværket vokser, falder antallet af nødvendige konfigurationer. Du bruger allerede på forhånd oprettede politikker, profiler, objekter. Du kan fleksibelt konfigurere segmentering og sikkerhed, centralt administrere kontrakter, der er ansvarlige for at løse visse interaktioner mellem EPG - mængden af arbejde falder kraftigt.
I EVPN skal du konfigurere hver enhed fra fabrikken, sandsynligheden for fejl er større.
Hvis ACI er langsommere at implementere, tog EVPN næsten dobbelt så lang tid at fejlfinde. Hvis du i Ciscos tilfælde altid kan ringe til en supportingeniør og spørge om netværket som helhed (fordi det er dækket som en løsning), så køber du kun hardware fra Juniper Networks, og det er det, der er dækket. Pakker forladt enheden? Okay, så dine problemer. Men du kan åbne et spørgsmål om valg af løsning eller netværksdesign - og så vil de råde dig til at købe en professionel service, mod et ekstra gebyr.
ACI-understøttelse er meget cool, fordi den er adskilt: et separat team sidder kun for dette. Der er, herunder russisktalende specialister. Vejledningen er detaljeret, beslutningerne er forudbestemte. Se og råd. De validerer hurtigt designet, hvilket ofte er vigtigt. Juniper Networks gør det samme, men til tider langsommere (vi plejede at gøre det, nu skulle det ifølge rygterne være bedre), hvilket tvinger dig til at gøre alt selv, hvor en løsningsingeniør kunne rådgive.
Cisco ACI understøtter integration med virtualiserings- og containeriseringssystemer (VMware, Kubernetes, Hyper-V) og centraliseret administration. Der er netværkstjenester og sikkerhedstjenester - balancering, firewalls, WAF, IPS og mere... God mikrosegmentering ud af boksen. I den anden løsning sker integration med netværkstjenester med en tamburin, og det er bedre at ryge fora med dem, der gjorde dette på forhånd.
Total
For hvert konkret tilfælde er det nødvendigt at vælge en løsning, ikke kun baseret på omkostningerne til udstyr, men det er også nødvendigt at tage højde for yderligere driftsomkostninger og de vigtigste problemer, som kunden står over for nu, og hvad er planerne til udvikling af IT-infrastruktur.
ACI på grund af ekstra udstyr kom dyrere ud, men løsningen er klar uden behov for yderligere savning, den anden løsning er mere kompliceret og omkostningsfuld i forhold til drift, men billigere.
Hvis du vil diskutere, hvor meget det kan koste at implementere en netværksfabrik på forskellige leverandører, og hvilken slags arkitektur der er behov for, kan du mødes og chatte. Før den grove skitse af arkitekturen (med hvilken du kan beregne budgetterne), giver vi dig et gratis tip, en detaljeret undersøgelse er selvfølgelig allerede betalt.
Vladimir Klepche, virksomhedsnetværk.
Kilde: www.habr.com