Vurder forbindelsene i den midtre delen av diagrammet. Vi kommer tilbake til dem nedenfor
På et tidspunkt kan du oppdage at store, komplekse L2-baserte nettverk er dødelig syke. Først av alt, problemer knyttet til behandling av BUM-trafikk og driften av STP-protokollen. For det andre er arkitekturen generelt foreldet. Dette gir ubehagelige problemer i form av driftsstans og upraktisk håndtering.
Vi hadde to parallelle prosjekter, hvor kundene nøkternt vurderte alle fordeler og ulemper med alternativene og valgte to ulike overleggsløsninger, og vi implementerte dem.
Det var anledning til å sammenligne gjennomføringen. Ikke utnyttelse, vi bør snakke om det om to eller tre år.
Så, hva er et nettverksstoff med overleggsnettverk og SDN?
Hva skal man gjøre med de presserende problemene med klassisk nettverksarkitektur?
Hvert år dukker det opp nye teknologier og ideer. I praksis oppsto ikke det påtrengende behovet for å gjenoppbygge nettverk på lenge, for å gjøre alt for hånd med de gode gammeldagse metodene er også mulig. Så hva om det er det tjueførste århundre? Tross alt skal en administrator jobbe, og ikke sitte på kontoret sitt.
Så begynte en boom i byggingen av store datasentre. Da ble det klart at utviklingsgrensen for klassisk arkitektur var nådd, ikke bare når det gjelder ytelse, feiltoleranse og skalerbarhet. Og et av alternativene for å løse disse problemene var ideen om å bygge overleggsnettverk på toppen av en rutet ryggrad.
I tillegg, med økningen i omfanget av nettverk, har problemet med å administrere slike fabrikker blitt akutt, som et resultat av at programvaredefinerte nettverksløsninger begynte å dukke opp med muligheten til å administrere hele nettverksinfrastrukturen som en helhet. Og når nettverket administreres fra ett enkelt punkt, er det lettere for andre komponenter i IT-infrastrukturen å samhandle med det, og slike interaksjonsprosesser er lettere å automatisere.
Nesten alle store produsenter av ikke bare nettverksutstyr, men også virtualisering, har alternativer for slike løsninger i sin portefølje.
Det gjenstår bare å finne ut hva som passer til hvilke behov. For eksempel, for spesielt store bedrifter med et godt utviklings- og driftsteam, tilfredsstiller ikke alltid pakkede løsninger fra leverandører alle behov, og de tyr til å utvikle egne SD (software defined) løsninger. Dette er for eksempel skyleverandører som stadig utvider spekteret av tjenester som tilbys til sine kunder, og pakkeløsninger klarer rett og slett ikke å holde tritt med deres behov.
For mellomstore bedrifter er funksjonaliteten som tilbys av leverandøren i form av en boksløsning tilstrekkelig i 99 prosent av tilfellene.
Hva er overleggsnettverk?
Hva er ideen bak overleggsnettverk? I hovedsak tar du et klassisk rutet nettverk og bygger et annet nettverk på toppen av det for å få flere funksjoner. Oftest snakker vi om å effektivt fordele belastningen på utstyr og kommunikasjonslinjer, øke skalerbarhetsgrensen betydelig, øke påliteligheten og en haug med sikkerhetsgodbiter (på grunn av segmentering). Og SDN-løsninger, i tillegg til dette, gir mulighet for veldig, veldig, veldig praktisk fleksibel administrasjon og gjør nettverket mer transparent for sine forbrukere.
Generelt, hvis lokale nettverk hadde blitt oppfunnet på 2010-tallet, ville de sett langt annerledes ut enn det vi arvet fra militæret på 1970-tallet.
Når det gjelder teknologier for å bygge tekstiler ved bruk av overleggsnettverk, er det for tiden mange leverandørimplementeringer og Internett RFC-prosjekter (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve og andre). Ja, det er standarder, men implementeringen av disse standardene av forskjellige produsenter kan variere, så når du oppretter slike fabrikker, er det fortsatt mulig å forlate leverandørlåsen fullstendig bare i teorien på papir.
Med en SD-løsning er ting enda mer forvirrende; hver leverandør har sin egen visjon. Det er helt åpne løsninger som du i teorien kan fullføre selv, og det er helt lukkede.
Cisco tilbyr sin versjon av SDN for datasentre – ACI. Naturligvis er dette en 100 % leverandørlåst løsning med tanke på valg av nettverksutstyr, men samtidig er den fullt integrert med virtualiseringssystemer, containerisering, sikkerhet, orkestrering, lastbalansere osv. Men i hovedsak er det fortsatt en slags svart boks, uten mulighet for full tilgang til alle interne prosesser. Ikke alle kunder godtar dette alternativet, siden du er helt avhengig av kvaliteten på den skrevne løsningskoden og implementeringen av den, men på den annen side har produsenten en av de beste tekniske støttene i verden og har et dedikert team som kun er dedikert til denne løsningen. Cisco ACI ble valgt som løsning for det første prosjektet.
For det andre prosjektet ble en Juniper-løsning valgt. Produsenten har også eget SDN for datasenteret, men kunden valgte å ikke implementere SDN. Et EVPN VXLAN-stoff uten bruk av sentraliserte kontrollere ble valgt som nettverkskonstruksjonsteknologi.
Hva er den til?
Ved å opprette en fabrikk kan du bygge et enkelt skalerbart, feiltolerant og pålitelig nettverk. Arkitekturen (bladrygg) tar hensyn til egenskapene til datasentre (trafikkveier, minimerer forsinkelser og flaskehalser i nettverket). SD-løsninger i datasentre lar deg meget praktisk, raskt og fleksibelt administrere en slik fabrikk og integrere den i datasenterets økosystem.
Begge kundene måtte bygge redundante datasentre for å sikre feiltoleranse, og i tillegg måtte trafikken mellom datasentrene krypteres.
Den første kunden vurderte allerede stoffløse løsninger som en mulig standard for nettverkene sine, men i tester fikk de problemer med STP-kompatibilitet mellom flere maskinvareleverandører. Det var nedetider som førte til at tjenester krasjet. Og for kunden var dette kritisk.
Cisco var allerede kundens bedriftsstandard, de så på ACI og andre alternativer og bestemte at det var verdt å ta denne løsningen. Jeg likte automatiseringen av kontroll fra én knapp gjennom en enkelt kontroller. Tjenester konfigureres raskere og administreres raskere. Vi bestemte oss for å sikre trafikkkryptering ved å kjøre MACSec mellom IPN- og SPINE-svitsjene. Dermed klarte vi å unngå flaskehalsen i form av en kryptogateway, spare på dem og bruke maksimal båndbredde.
Den andre kunden valgte en kontrollerløs løsning fra Juniper fordi deres eksisterende datasenter allerede hadde en liten installasjon som implementerte et EVPN VXLAN-stoff. Men der var den ikke feiltolerant (en bryter ble brukt). Vi bestemte oss for å utvide infrastrukturen til hoveddatasenteret og bygge en fabrikk i backupdatasenteret. Den eksisterende EVPN ble ikke brukt fullt ut: VXLAN-innkapsling ble faktisk ikke brukt, siden alle verter var koblet til én svitsj, og alle MAC-adresser og /32 vertsadresser var lokale, gatewayen for dem var den samme svitsjen, det var ingen andre enheter , hvor det var nødvendig å bygge VXLAN-tunneler. De bestemte seg for å sikre trafikkkryptering ved hjelp av IPSEC-teknologi mellom brannmurer (ytelsen til brannmuren var tilstrekkelig).
De prøvde også ACI, men bestemte seg for at på grunn av leverandørlåsen måtte de kjøpe for mye maskinvare, inkludert å erstatte nylig kjøpt nytt utstyr, og det var rett og slett ikke økonomisk fornuftig. Ja, Cisco-stoffet integreres med alt, men bare enhetene er mulig i selve stoffet.
På den annen side, som vi sa tidligere, kan du ikke bare blande et EVPN VXLAN-stoff med en hvilken som helst naboleverandør, fordi protokollimplementeringene er forskjellige. Det er som å krysse Cisco og Huawei i ett nettverk - det virker som standardene er vanlige, men du må danse med en tamburin. Siden dette er en bank, og kompatibilitetstester ville være veldig lange, bestemte vi oss for at det var bedre å kjøpe fra samme leverandør nå, og ikke bli for revet med funksjonalitet utover de grunnleggende.
Migrasjonsplan
To ACI-baserte datasentre:
Organisering av samhandling mellom datasentre. Multi-Pod-løsningen ble valgt – hvert datasenter er en pod. Kravene til skalering etter antall brytere og forsinkelser mellom pods (RTT mindre enn 50 ms) er tatt i betraktning. Det ble besluttet å ikke bygge en Multi-Site-løsning for enkel administrasjon (en Multi-Pod-løsning bruker et enkelt administrasjonsgrensesnitt, en Multi-Site ville ha to grensesnitt, eller ville kreve en Multi-Site Orchestrator), og siden ingen geografisk reservasjon av nettsteder var nødvendig.
Fra synspunktet om å migrere tjenester fra Legacy-nettverket, ble det mest transparente alternativet valgt, og gradvis overføre VLAN-er som tilsvarer visse tjenester.
For migrering ble det opprettet en tilsvarende EPG (End-point-group) for hvert VLAN på fabrikken. Først ble nettverket strukket mellom det gamle nettverket og strukturen over L2, så etter at alle vertene var migrert, ble gatewayen flyttet til strukturen, og EPG samhandlet med det eksisterende nettverket gjennom L3OUT, mens interaksjonen mellom L3OUT og EPG ble beskrevet ved bruk av kontrakter. Omtrentlig diagram:
En eksempelstruktur for de fleste ACI-fabrikkpolicyer er vist i figuren nedenfor. Hele oppsettet er basert på policyer som er nestet i andre policyer og så videre. Til å begynne med er det veldig vanskelig å finne ut av det, men gradvis, som praksis viser, blir nettverksadministratorer vant til denne strukturen i løpet av omtrent en måned, og så begynner de først å forstå hvor praktisk det er.
sammenligning
I Cisco ACI-løsningen må du kjøpe mer utstyr (separate brytere for Inter-Pod-interaksjon og APIC-kontrollere), noe som gjør det dyrere. Junipers løsning krevde ikke kjøp av kontroller eller tilbehør; Det var mulig å delvis bruke kundens eksisterende utstyr.
Her er EVPN VXLAN-stoffarkitekturen for to datasentre i det andre prosjektet:
Med ACI får du en ferdig løsning - ingen grunn til å tukle, ingen behov for å optimalisere. Under den første bekjentskapen til kunden med fabrikken, trengs ingen utviklere, ingen støttepersoner er nødvendig for kode og automatisering. Det er ganske enkelt å bruke; mange innstillinger kan gjøres gjennom veiviseren, noe som ikke alltid er et pluss, spesielt for folk som er vant til kommandolinjen. Uansett tar det tid å gjenoppbygge hjernen på nye spor, til særegenhetene ved innstillinger gjennom policyer og drift med mange nestede policyer. I tillegg til dette er det svært ønskelig med en tydelig struktur for navngivning av policyer og objekter. Hvis det oppstår et problem i logikken til kontrolleren, kan det bare løses gjennom teknisk støtte.
I EVPN - konsoll. Lid eller glede deg. Et kjent grensesnitt for den gamle garde. Ja, det er en standard konfigurasjon og guider. Du må røyke mana. Ulike design, alt er klart og detaljert.
Naturligvis, i begge tilfeller, når du migrerer, er det bedre å først migrere ikke de mest kritiske tjenestene, for eksempel testmiljøer, og først deretter, etter å ha fanget alle feilene, fortsette til produksjonen. Og ikke still inn på fredag kveld. Du bør ikke stole på leverandøren om at alt vil være i orden, det er alltid bedre å spille det trygt.
Du betaler mer for ACI, selv om Cisco for tiden aktivt promoterer denne løsningen og ofte gir gode rabatter på den, men du sparer på vedlikehold. Administrasjon og all automatisering av en EVPN-fabrikk uten kontroller krever investeringer og vanlige kostnader - overvåking, automatisering, implementering av nye tjenester. Samtidig tar den første lanseringen på ACI 30–40 prosent lengre tid. Dette skjer fordi det tar lengre tid å lage hele settet med nødvendige profiler og policyer som deretter skal brukes. Men etter hvert som nettverket vokser, reduseres antallet nødvendige konfigurasjoner. Du bruker forhåndslagrede policyer, profiler, objekter. Du kan fleksibelt konfigurere segmentering og sikkerhet, sentralt administrere kontrakter som er ansvarlige for å tillate visse interaksjoner mellom EPG-er - mengden arbeid synker kraftig.
I EVPN må du konfigurere hver enhet på fabrikken, det er større sjanse for feil.
Mens ACI var tregere å implementere, tok EVPN nesten dobbelt så lang tid å feilsøke. Hvis du i tilfellet med Cisco alltid kan ringe en supportingeniør og spørre om nettverket som helhet (fordi det dekkes som en løsning), så kjøper du fra Juniper Networks kun maskinvare, og det er det som dekkes. Har pakkene forlatt enheten? Vel, ok, da dine problemer. Men du kan åpne et spørsmål angående valg av løsning eller nettverksdesign - og så vil de råde deg til å kjøpe en profesjonell tjeneste, mot en ekstra avgift.
ACI-støtte er veldig kul, fordi den er separat: et eget team sitter bare for dette. Det er også russisktalende spesialister. Veiledningen er detaljert, løsningene er forhåndsbestemt. De ser og gir råd. De validerer raskt designet, noe som ofte er viktig. Juniper Networks gjør det samme, men mye tregere (vi hadde dette, nå skulle det være bedre ifølge ryktene), noe som tvinger deg til å gjøre alt selv der en løsningsingeniør kan gi råd.
Cisco ACI støtter integrasjon med virtualiserings- og containeriseringssystemer (VMware, Kubernetes, Hyper-V) og sentralisert administrasjon. Tilgjengelig med nettverks- og sikkerhetstjenester - balansering, brannmurer, WAF, IPS osv... God mikrosegmentering ut av esken. I den andre løsningen er integrasjon med nettverkstjenester en lek, og det er bedre å diskutere fora på forhånd med de som har gjort dette.
Total
For hvert enkelt tilfelle er det nødvendig å velge en løsning, ikke bare basert på kostnadene for utstyret, men det er også nødvendig å ta hensyn til ytterligere driftskostnader og hovedproblemene som kunden står overfor, og hvilke planer der. er for utvikling av IT-infrastrukturen.
ACI, på grunn av tilleggsutstyr, var dyrere, men løsningen er ferdiglaget uten behov for ytterligere etterbehandling; den andre løsningen er mer kompleks og kostbar med tanke på drift, men billigere.
Hvis du vil diskutere hvor mye det kan koste å implementere et nettverksstoff på forskjellige leverandører, og hva slags arkitektur som trengs, kan du møtes og chatte. Vi vil gi deg gratis råd til du får en grov skisse av arkitekturen (som du kan beregne budsjetter med), detaljert utdypning er selvfølgelig allerede betalt.
Vladimir Klepche, bedriftsnettverk.
Kilde: www.habr.com