Softwaredefineret netværk (SDN): historie, arkitektur og anvendelser

Informatic Digital » Recursos » Softwaredefineret netværk (SDN): historie, arkitektur og anvendelser

Softwaredefineret netværk (SDN) har fuldstændig ændret den måde, kommunikationsinfrastrukturer designes, implementeres og administreres på . Det, der engang var en rigid ramme af fysisk udstyr og manuelle konfigurationer, kan nu administreres næsten som kode med meget større hastighed, fleksibilitet og indsigt i, hvad der sker i alle hjørner af netværket.

Denne nye tilgang opstod ikke ud af ingenting: den er resultatet af årtiers forskning og adskillige teknologiske milepæle , fra de aktive netværk i 90'erne til standardiseringen af ​​OpenFlow og skabelsen af ​​et komplet økosystem af controllere, API'er og applikationer. Lad os se trin for trin på, hvordan vi er nået hertil, hvilke problemer SDN løser, hvordan det fungerer internt, og i hvilke virkelige scenarier det bruges i dag.

Oprindelse og historie for softwaredefinerede netværk (SDN)

Historien om SDN begynder for omkring 20 år siden, ved det kommercielle internets begyndelse , da det globale netværks succes gjorde det klart, at kommunikationsinfrastrukturer skulle kunne modificeres og udvikles meget lettere. Fra da af kan der skelnes mellem tre hovedfaser, der banede vejen for det, vi nu kalder SDN.

Det første trin svarer til aktive netværk (ca. 1995-2000) . Ideen var at åbne netværket for programmering, svarende til hvordan en pc programmeres, men anvendt på hver kommunikationsnode. For at opnå dette blev der defineret en API i netværksenhederne , der eksponerede ressourcer såsom computerkraft, lagerplads, pakkekøer og behandlingsfunktioner, hvilket gjorde det muligt at indlæse kode, der anvendte brugerdefinerede adfærdsmønstre til specifikke trafikstrømme.

Denne tilgang var i modstrid med synspunktet hos dem, der argumenterede for, at den eneste måde, hvorpå internettet kunne skaleres og forblive funktionelt, var at holde netværket så simpelt som muligt. Alligevel ansporede det aktive netværksprogram vigtige fremskridt: reducerede beregningsomkostninger, forbedringer i programmeringssprog, fremkomsten af ​​virtuelle maskiner og frem for alt ideen om, at netværket kunne behandles som en programmerbar platform og ikke blot en samling af lukkede kasser.

En vigtig katalysator i den æra var støtten fra agenturer som DARPA, der lancerede Active Networks Program , som var aktivt fra midten af ​​90'erne til begyndelsen af ​​2000'erne. Selvom aktive netværk aldrig opnåede masseudrulning, såede de koncepter, der senere skulle blive fundamentale for SDN: programmerbare funktioner i netværket, ressourcevirtualisering og en samlet visning af forskellige enheder (firewalls, IDS, NAT osv.).

Med årtiskiftet og den eksplosive vækst i trafik begyndte den anden fase, der fokuserede på adskillelsen af ​​kontrolplanet og dataplanet (2001-2007) . Traditionelle routere og switche kombinerede kontrollogik (rutevalg, routingprotokoller) og dataplanet (selve pakkevideresendelse) i den samme enhed, hvilket gjorde det meget vanskeligt at debugge fejl, justere trafikteknik eller introducere nye tjenester.

For at håndtere dette scenarie begyndte operatørerne at implementere pakkevideresendelse på specialiseret hardware , mens kontrollen forblev mere adskilt, og samtidig søgte de måder at administrere stadig større og mere komplekse netværk med tjenester som VPN'er og andre avancerede funktioner. Ud fra dette opstod to innovationslinjer: på den ene side åbne grænseflader mellem kontrol og videresendelse, såsom ForCES (IETF) eller Netlink på Linux; på den anden side arkitekturer med centraliseret logisk kontrol, såsom RCP, SoftRouter eller PCE-protokollen, som gjorde det muligt at træffe routingbeslutninger med et globalt overblik.

Den tredje fase kom med Project 4D og den efterfølgende Ethane , som krystalliserede ideen om en central logikcontroller med fire klart definerede planer: data (pakkebehandling i henhold til regler), discovery (indsamling af topologisk og trafikinformation), dissemination (installation af behandlingsregler) og decision (globale politikker oversat til specifikke regler). Ethane, implementeret i virkelige miljøer som Stanford University, bidrog med et ekstremt simpelt switchdesign, der skulle blive grundlaget for det, vi nu kender som OpenFlow.

I mellemtiden udviklede eksperimenteringsøkosystemet sig også: infrastrukturer som PlanetLab og Emulab, projekter som GENI og det europæiske FIRE-program, og Stanfords Clean Slate-program fremmede storstilet testning af alternative netværksarkitekturer. Det var i dette miljø, at OpenFlow opstod som en praktisk måde at eksponere switch-videresendelsesfunktioner til en ekstern controller ved hjælp af en standard API.

En betydelig milepæl i branchen var Avayas demonstration i 2014 , som kombinerede Shortest Path Bridging med OpenStack for at bygge softwaredefinerede netværk med minimal manuel konfiguration. Og gradvist, takket være simple firmwareopdateringer, begyndte mange kommercielle switche at understøtte OpenFlow uden at kræve hardwareændringer.

Problemer med traditionelle netværk, som SDN løser

Konventionelle netværk, der næsten udelukkende er baseret på individuelt konfigureret fysisk udstyr , når deres grænser i lyset af de nuværende behov fra virksomheder, tjenesteudbydere og slutbrugere. Deres primære akilleshæl er den kompleksitet, der er akkumuleret gennem årene.

For at dække alle mulige scenarier har industrien tilføjet stadig mere specifikke netværksprotokoller , der løser bestemte problemer (sikkerhed, effektivitet, redundans osv.), men disse er normalt designet isoleret. Resultatet er et virvar af mekanismer, der skal koordineres manuelt, uden et fælles abstraktionslag for at forenkle helheden.

Når en organisation ønsker at håndhæve ensartede politikker på tværs af hele sit netværk – for eksempel at bestemme, hvem der kan få adgang til hvilke ressourcer – skal administratorer ændre hundredvis eller tusindvis af enheder . Noget så simpelt som at tilføje en ny virtuel maskine kan involvere ændringer af adskillige adgangskontrollister (ACL'er) spredt over hele miljøet, med risiko for menneskelige fejl og forsinkelser på flere timer.

Manglende skalerbarhed er et andet alvorligt problem. Fremkomsten af ​​datacentre, brugervækst og øget trafik nødvendiggør tilføjelse af flere og flere enheder. Hvert ekstra stykke udstyr betyder mere konfiguration, mere administration og flere potentielle fejlpunkter. At holde alt dette i overensstemmelse med forretningsbehov bliver en herkulisk opgave.

Fra et økonomisk synspunkt lider organisationer under en stærk afhængighed af producenternes produktcyklusser . Hvis der er behov for ny netværksfunktionalitet, er det ofte ikke nok blot at opdatere softwaren: organisationer skal vente på, at leverandøren frigiver den relevante model, at interne certificeringer gennemføres, at udstyret anskaffes, og at implementeringen finder sted – en proces, der kan tage år og hæmme innovation.

For at gøre tingene værre komplicerer de seneste tendenser billedet yderligere: Der dukker langt mere heterogene trafikmønstre op med maskine-til-maskine-strømme, distribuerede databaser, mikrotjenester og brugere, der opretter forbindelse fra hvor som helst med mobiltelefoner, tablets og bærbare computere. Arbejdsbyrden for administratorer stiger, da de forsøger at beskytte følsomme data, mens den traditionelle netværksperimeter stort set forsvinder.

Dertil kommer væksten af ​​cloud-tjenester (SaaS, IaaS, PaaS) , som kræver hurtig provisionering, dynamisk skalering af databehandling, lagring og netværk samt mere sofistikerede sikkerhedskrav. Fremkomsten af ​​big data kræver massiv båndbredde og transportkapacitet på tværs af tusindvis af servere, som traditionelle netværk ikke altid kan følge med.

Hvad er SDN egentlig, og hvordan løser det problemet?

SDN fremstår som en ny arkitektur designet til at give fleksibilitet, centraliseret kontrol og programmerbarhed til netværket, flytte kompleksiteten til softwaren og fjerne den fra hardwaren. Det handler ikke længere om at administrere hver enhed individuelt, men om at definere den ønskede netværksadfærd fra et højere logisk lag.

Hovedprincippet er adskillelsen af ​​kontrolplanet og dataplanet . Dataplanet er ansvarligt for at flytte pakker med høj hastighed mellem endepunkter; kontrolplanet bestemmer, hvordan og hvor disse pakker skal bevæge sig hen, og anvender politikker, ruter og regler. I SDN er disse planer afkoblet, og kontrollen er koncentreret i en eller flere logiske controllere.

En veldefineret grænseflade etableres mellem de to, normalt gennem en standardprotokol som OpenFlow . Takket være denne grænseflade kan controlleren installere, ændre eller slette videresendelsesregler på switche og routere, som derefter opfører sig som programmerbare enheder snarere end lukkede systemer. OpenFlow er ikke den eneste mulige protokol, men den er den mest udbredte og er blevet de facto-standarden.

Over controllerne bruger SDN-applikationer nordgående API'er til at udtrykke, hvilken adfærd de har brug for fra netværket : prioritering af bestemt trafik, segmentering af afdelinger, load balancing, forbedring af servicekvaliteten, reaktion på et denial-of-service-angreb osv. Controlleren oversætter disse anmodninger på højt niveau til konkrete videresendelsesregler, der anvendes i dataplanet.

Med andre ord transformerer SDN netværket til en platform, hvor applikationer og tjenester kan udvikles, som om de var ren software , uden hensyntagen til detaljerne i hver udstyrsmodel eller lavniveauprotokol. Denne abstraktion letter automatisering, reducerer fejl og giver mulighed for meget hurtigere tilpasning til ændringer i efterspørgslen.

SDN-arkitektur: Controllere, API'er og nøglekomponenter

Et typisk SDN-netværk er struktureret i flere logiske lag og veldifferentierede komponenter. I hjertet er SDN-controlleren , der fungerer som netværkets hjerne, indsamler information fra dataplanet og implementerer applikationsbeslutninger.

Controlleren opretholder et abstrakt overblik over netværket: topologi, hver enheds funktioner, trafikstatistik, linktilstande osv. Med disse oplysninger og baseret på plugin-moduler, der kan aktiveres eller deaktiveres (lagerstyring, statistikindsamling, sikkerhedsmoduler, load balancing osv.), træffer den beslutninger og kommunikerer dem til enhederne via den sydgående API, normalt OpenFlow eller andre protokoller såsom OVSDB eller Cisco OpFlex.

Dataplanenheder – fysiske switche, virtuelle switche, routere – implementerer det, som ONF kalder en SDN-datasti : et sæt videresendelsesmotorer og trafikbehandlingsfunktioner, der er logisk eksponeret. Inden for hver datasti er der en Control Interface Processing Agent (CDPI-agent), der modtager instruktioner fra controlleren og oversætter dem til regler i flowtabeller eller specifikke hardwarehandlinger.

Øverst i arkitekturen finder man SDN-applikationerne . Disse er programmer, der kommunikerer med controlleren via Northbound API'er (NBI'er) og udtrykker forretningsmæssige eller tekniske behov: IP-adressestyring (IPAM), serviceorkestrering, kontrol af servicekvalitet (QoS), DoS-angrebsforsvarssystemer, avancerede analyseværktøjer osv. Hver applikation indeholder sin egen logik og en eller flere NBI'er til at interagere med controlleren.

Mellem disse blokke ligger Control-to-Data Plane Interface (CDPI) , som er ansvarlig for at levere programmerbarhed over videresendelse, annoncere enhedsfunktioner, eksponere statistik og underrette hændelser. Controllere implementerer drivere til denne grænseflade, og enheder implementerer agenter, så hvert driver/agent-par etablerer et specifikt forhold mellem den fysiske infrastruktur og applikationerne.

Ud over disse tre hovedlag identificerer ONF et styrings- og administrationslag , der dækker mere statiske opgaver: ressourceallokering til klienter, grundlæggende konfiguration af fysisk udstyr, administration af legitimationsoplysninger og tilknytninger mellem logiske og fysiske enheder. Disse opgaver administreres typisk uden for den dynamiske trafikstyringscyklus.

Nord- og sydgrænseflader og flowprogrammeringsmodeller

Den sydgående API forbinder controlleren til hardwaren eller datastierne . OpenFlow var den første bredt anvendte grænseflade: den definerer, hvordan controlleren installerer poster i switchenes flowtabeller, hvordan den indsamler statistik, hvordan hændelser som f.eks. uoverensstemmende pakker rapporteres osv. Andre alternativer, såsom Cisco OpFlex, foreslår andre modeller, men med den samme grundlæggende idé om at tillade et centralt element at påvirke enhedens adfærd.

Den nordgående API giver applikationer mulighed for at kommunikere med controlleren og modtage et abstrakt overblik over netværket. Der er ikke en standard, der er så etableret som OpenFlow her: der er mange forslag og biblioteker placeret på forskellige lag af stakken (REST, gRPC, specifikke SDK'er, intentbaserede modeller osv.), og det er netop på grund af denne mangfoldighed, at ONF har lagt stor vægt på at definere bedste praksis og konvergere mod kompatible tilgange.

På operationelt niveau kan controllere følge en proaktiv, reaktiv eller hybrid model til at implementere flowregler på enheder. I den reaktive tilgang forespørger switchen controlleren, når den modtager en pakke, der ikke matcher nogen post i dens tabel; controlleren svarer med instruktioner og opretter om nødvendigt en ny regel for lignende fremtidige pakker.

I den proaktive model forudinstallerer controlleren regler for forventede trafikstrømme , svarende til hvordan traditionelle routingtabeller udfyldes. Dette minimerer forespørgsler i realtid og reducerer latenstiden for den indledende kommunikation. Mange implementeringer i den virkelige verden kombinerer begge modeller, idet de er reaktive over for uforudsigelig trafik og proaktive over for velkendte strømme.

SDN's sande styrke ligger i den programmerbarhed, som disse åbne API'er giver . Takket være dem er det muligt dynamisk at justere ruter baseret på belastning, prioritere kritisk trafik, automatisere reaktion på fejl eller sikkerhedshændelser og endda tillade applikationer selv at forhandle de betingelser, de har brug for, med netværket (båndbredde, maksimal latenstid, redundansniveau osv.).

Anvendelseseksempler for programmerbarhed i SDN

For at illustrere konceptet netværksprogrammerbarhed diskuteres ofte tre vigtige anvendelsesscenarier for at demonstrere, hvordan SDN udnyttes i praksis . Den første er finjustering af trafikstrømme: med protokoller som OpenFlow kan controlleren næsten øjeblikkeligt beslutte, hvilke stier bestemte typer trafik skal følge, afbalancere belastningen på tværs af links, undgå overbelastning eller anvende strengere sikkerhedspolitikker, hvor det er nødvendigt.

Det andet store tilfælde ligger i avanceret applikationssupport . I stedet for at netværket er blindt for, hvad applikationer laver, kan de eksponere deres krav (f.eks. lav latenstid for tale eller video, høj båndbredde for visse overførsler, streng isolation mellem klienter), og controlleren tilpasser konfigurationen for at imødekomme dem. Desuden muliggør automatiserede implementeringer - især i cloud- og massive virtualiseringsmiljøer - hurtig implementering af nye tjenester uden at en administrator manuelt skal ændre parametre.

Det tredje nøgleelement er automatisering af netværksdrift . I et veldesignet SDN-scenarie kan netværket reagere autonomt på mange hændelser: Hvis et link fejler, genberegnes ruter; hvis et mistænkeligt trafikmønster opstår, anvendes blokeringsregler eller omdirigering til analysesystemer; hvis en ny applikation lanceres, allokerer netværket automatisk ressourcer. Administratorens rolle skifter fra blot at "ændre kommandoer" til at definere politikker på overordnet niveau og sikre overholdelse.

Fordele ved SDN for organisationer

SDN's værditilbud udmønter sig i en række meget klare fordele for virksomheder og tjenesteudbydere . En af de mest bemærkelsesværdige er centraliseret styring: Fra controlleren kan adgangspolitikker, sikkerhedsregler, trafikprioriteter og tjenestelevering defineres for hele netværket, uden at man skal administrere hver enhed individuelt eller være afhængig af hver producents specifikke grænseflade.

Med hensyn til skalerbarhed tilbyder SDN enorm fleksibilitet. Administratorer kan tilføje eller fjerne virtuelle enheder, segmentere netværk, forbinde filialer eller datacentre og justere ruter i næsten realtid, ofte integreret med cloud-orkestreringsplatforme. Alt dette opnås med minimal påvirkning af den underliggende fysiske infrastruktur, som forbliver et relativt stabilt substrat.

En anden vigtig fordel er den omfattende indsigt i netværksadfærd . Ved at centralisere information i controlleren eller et domæne af koordinerede controllere opnås et komplet billede af ydeevne, flaskehalse, aktive flows og potentielle trusler. Denne indsigt letter ikke kun den daglige drift, men også kapacitetsplanlægning og tidlig problemdetektering.

Fra et økonomisk perspektiv hjælper SDN med at reducere både CAPEX og OPEX. På den ene side muliggør det genbrug af meget af den eksisterende hardware , da mange switche kan aktivere SDN-funktioner med simple firmwareopdateringer. På den anden side reducerer automatisering den tid, personalet bruger på gentagne konfigurationsopgaver, reducerer menneskelige fejl og forenkler vedligeholdelse og opgraderinger.

Det sidste store sæt fordele vedrører innovation og responshastighed . Ved at afkoble hardware og software kan organisationer skabe nye tjenester, eksperimentere med forskellige forretningsmodeller eller tilpasse netværket til nye krav (hybrid cloud, IoT, edge computing, big data) uden at være bundet til en bestemt producents produktlanceringsplan.

Ulemper og udfordringer ved SDN-netværk

SDN er ikke et universalmiddel og medfører også udfordringer, der skal huskes på, når man designer og driver denne type netværk. En af de hyppigst nævnte er controllerens potentielle sårbarhed: ved at koncentrere så meget logik og beslutningstagning bliver den et kritisk punkt, hvis fejl eller kompromittering kan bringe hele systemet ned.

Dette nødvendiggør implementering af mekanismer for høj tilgængelighed, redundans og failover , samt meget strenge adgangskontroller. Denial-of-service (DDoS)-angreb mod controlleren skal for eksempel afbødes med tilstrækkelig kapacitet til at forhindre, at netværket bliver "blindt" for kritiske hændelser.

En anden udfordring er den potentielle stigning i latenstid og kompleksitet, efterhånden som antallet af enheder og flows vokser. Hvis controlleren skal håndtere for mange interaktioner med dataplanet, kan den blive overbelastet. En veldesignet SDN-arkitektur bør distribuere funktioner, opretholde en vis kontrol i de distribuerede elementer, når det giver mening (for eksempel til hurtig gendannelse fra lokale fejl), og skalere controllere horisontalt.

Med hensyn til sikkerhed tilbyder SDN forbedret synlighed, men det mangler også nogle mekanismer, der tidligere var integreret i traditionelle routere, switche eller fysiske firewalls. Det er vigtigt at beskytte kommunikationen mellem controllere, applikationer og enheder, sikre autenticitet og integritet og designe et robust politikmiljø, der muliggør verifikation af, at politikker anvendes præcis som tilsigtet.

Derudover er det afgørende at etablere processer for netværksforensik : detaljeret hændelseslogning, sporbarhed af ændringer og evnen til at rekonstruere, hvad der skete i tilfælde af en hændelse. Alt dette skal sameksistere med SDN's iboende dynamik, forhindre sikkerhed i at blive en flaskehals, samtidig med at det sikres, at der ikke forbliver sårbarheder.

ONF's og andre aktørers roller i SDN-økosystemet

Open Networking Foundation (ONF) spiller en fundamental rolle i udviklingen af ​​SDN. Det er en organisation drevet af slutbrugere (operatører, store virksomheder) med det mål at fremme implementeringen af ​​softwaredefinerede netværk gennem åbne standarder og samarbejdsprocesser.

ONF har været ansvarlig for at definere, vedligeholde og udvikle OpenFlow-standarden , som var den første anerkendte SDN-standard og fortsat er et kerneelement i mange arkitekturer. Men dens arbejde går ud over det: den leder arbejdsgrupper, der analyserer krav til kommercielle implementeringer, foreslår nye grænseflader, datamodeller og terminologi og fremmer et økosystem med flere leverandører.

Parallelt har teknologivirksomheder og udstyrsproducenter udviklet deres egne SDN-platforme og hybride tilgange. Nogle, såsom løsninger baseret på logisk centraliserede controllere som Cienas Blue Planet, kombinerer centraliserede funktioner (end-to-end synlighed, politikker, båndbredde) med distribuerede funktioner på tværs af netværkselementer til fejlretning, lokal overvågning eller sikkerhed.

Denne hybride tilgang afspejler en praktisk realitet: ikke al kontrol behøver at ligge hos den centrale styreenhed, og det er bekvemt, at visse hurtige reaktionsmekanismer forbliver tæt på trafikken, mens den mere komplekse intelligens og orkestrering styres på en centraliseret og programmerbar måde.

SDN, netværksvirtualisering og brugsscenarier i den virkelige verden

I mange organisationer anvendes SDN i forbindelse med netværksvirtualiseringsteknikker for at oprette overlay-netværk oven på den eksisterende fysiske infrastruktur. Disse virtuelle netværk kan segmentere forskellige miljøer (produktion, udvikling, forskellige kunder) ved at udnytte den samme underliggende hardware, eller de kan forbinde flere fysiske netværk, som om de var én logisk enhed.

Denne tilgang er især effektiv, når den integreres med cloud computing-tjenester som SaaS, IaaS og PaaS . Det softwaredefinerede netværk koordineres med orkestreringsplatforme, så hele provisioneringscyklussen - virtuelle maskiner, lagring, netværk, sikkerhed - udføres konsekvent, hurtigt og automatisk, ofte via API'er.

I store virksomheder og operatører bruges SDN til at bygge smartere virksomheds-WAN'er , hvor trafikken mellem hovedkvarter, datacentre og offentlige clouds styres omhyggeligt. Google har for eksempel brugt SDN i årevis til at sammenkoble sine globale datacentre og har samarbejdet med ONF om at definere nye kontrolgrænseflader ud over OpenFlow.

I datacentermiljøet er SDN en nøglekomponent til at opnå hurtig og effektiv skalering : det gør det muligt for et nyt datacenter at blive operationelt på få timer og netværksressourcer at blive klargjort på få minutter. Det letter også implementeringen af ​​store IoT-miljøer og administrerer tusindvis af distribuerede enheder og sensorer uden overvældende kompleksitet.

Endelig er SDN en del af en bredere tendens mod softwaredefineret infrastruktur , hvor ikke kun netværket, men også lager (SDS) og andre ressourcer styres fra logiske kontrolplaner, uafhængigt af den specifikke hardware. Dette giver organisationer større portabilitet, fleksibilitet og muligheden for at flytte arbejdsbyrder mellem skyen og on-premises efter behov.

Med al denne historiske, tekniske og praktiske baggrund konsoliderer SDN sig som en anderledes måde at forstå netværk på: tættere på softwarens verden, fokuseret på automatisering og programmerbarhed, og i stand til at reagere på udfordringen med trafikvækst, skyen, big data og IoT uden at tvinge en uendelig multiplikation af hardware eller driftskompleksitet frem.