È l’ora delle Software Defined Networks. Con le reti virtuali e i dispositivi programmabili il modello Infrastructure-as-a-Service si fa Network-as-Code.
Acronimi come NFV (Network Function Virtualization) e SDN (Software Defined Networks) sono sempre utilizzati da chi si occupa di infrastrutture nella prospettiva del DevOps. Il concetto di Software Defined Networks si sviluppa del contesto di processi di virtualizzazione sempre più spinti che mirano a minimizzare e ottimizzare l’installazione di reti fisiche, e possibilmente portare tutte le funzionalità di rete 1 a girare su software invece che hardware dedicato. In questo senso l’espressione Software Defined Networks è direttamente connessa al concetto di Infrastructure-as-a-Service (IaaS).
Nel 2012 Fail Toad di Packet Pushers diceva
“Software Defined Networks is a nonsense term”,
e
“As networking adapts and these concepts evolve and become clearly defined, Software Defined Networks will fade. The apocalypse is not coming”.
Previsione che suonava un po’ simile a quella di Bill Gates su internet del 1996: internet è una realtà da tempo, e “l’apocalisse” (anche se con qualche anno di ritardo) sta arrivando.
In effetti Software Defined Networks, insieme a Network Function Virtualization, si sta imponendo come un modello sempre più concreto. Con l’esplosione dei Big Data e la necessità di reti sempre più capaci e grandi, che richiedono processi di manutenzione sempre più vasti e impegnativi, le Software Defined Networks stanno diventando più una necessità che una opportunità.
In principio erano cavi e device
Uno dei problemi maggiori con la gestione delle reti oggi è la fragilità delle stesse: anche semplici modifiche possono risultare in conseguenze inattese, il che ha generato un intero processo attorno al Change Control.
Non è raro avere strette finestre temporali dedicate a questo processo, dove solo modifiche specificamente approvate sono permesse. L’anacronismo appare particolarmente stridente se viene confrontato con le moderne metodologie agile, dove gli sviluppatori sono in grado di tradurre requisiti in codice funzionante e ‘installarlo’ in pochi giorni.
Sarebbe quindi desiderabile poter sfruttare almeno parte dell’ecosistema disponibile ai DevOps, ma la difficoltà era che le funzionalità di rete erano legate a dispositivi fisici proprietari.
Di conseguenza era spesso necessario installare fisicamente reti multiple, a seconda delle funzioni o dei dipartimenti aziendali, con il risultato di installazioni non semplici da gestire, e che richiedevano periodi di fermo per poter effettuare eventuali modifiche.
Ma tutti questi dispositivi di fatto espletano le loro funzioni tramite applicazioni software installate sull’hardware dedicato. Quindi perché non trovare il modo di disaccoppiare la funzionalità dall’infrastruttura?
Appunto da questa considerazione nasce il concetto di Infrastructure as Code, ponendo particolare enfasi sulla parte network dell’infrastruttura. L’idea alla base è che qualsiasi funzione di rete può essere considerata come software, e come tale può beneficiare degli strumenti di DevOps, quali Collaboration, CI/CD (Continuous Integration / Continuous Development), Virtualizzazione.
La rivoluzione di SDN e NFV
Nelle reti convenzionali Control Plane e Data Plane sono di fatto nello stesso dispositivo, mentre con SDN i due layer vengono separati, lasciando nello switch solo la parte a basso livello.
La funzione fondamentale di SDN (Software Defined Networking) è quella di separarare la rete in Data Plane (il substrato fisico della rete, ovvero il modo in cui “spostiamo” i dati dal punto A al punto B) e Control Plane, che costituisce lo strato di management della rete.
Il control plane è gestito da quello che viene definito SDN controller, il “cervello” della rete. Il vantaggio principale rispetto alle reti tradizionali è che con SDN è possibile utilizzare ad esempio switch generici al posto dei costosi switch proprietari, dal momento che le funzionalità vengono gestite appunto dal controller SDN.
I controller SDN oggi sono prevalentemente basati su OpenDaylight, la piattaforma open source ormai di riferimento, e la comunicazione tra controller SDN e Data Plane viene effettuata tramite API proprietarie, o via OpenFlow, un protocollo di comunicazione che sta guadagnando rapidamente popolarità, adottata anche da Google.
NFV
Come già detto, uno dei vantaggi di SDN è che gli switch nel Data Plane possono essere “white box” (dispositivi generici senza hardware proprietario, quindi economici). Ciò non toglie che anch’essi possono essere virtualizzati e implementati totalmente via software, come nel caso di Open vSwitch.
Lo switch virtuale è solo una delle numerose funzionalità associate a NFV. L’idea di Network Functions Virtualizations (NFV) consiste nello spostare tutte o quasi le funzionalità di rete su software, disaccoppiando così le funzioni dall’hardware.
Il concetto di NFV può essere suddiviso in due sottoaree:
- Infrastruttura (NFVI, Network Function Virtualization Infrastructure): L’insieme degli host di reti virtuali (VN)
- Funzioni (VNF, Virtual Network Function): le applicazioni software che espletano funzioni di rete, come switching, routing, firewall, analisi di traffico, etc.
Come già detto, nelle Software Defined Networks queste funzioni cono poi coordinate da un controller centralizzato, prevalentemente comunicando tramite OpenFlow, anche se ci sono le dovute eccezioni.
Service Orchestration
Nel contesto di SDN è possibile orchestrare il provisioning delle reti assieme a componenti IT come hardware e applicazioni. Il concetto chiave è che essendo le SDN automatizzate, il provisioning è possibile rapidamente e a chance di errore molto ridotte. ETSI (European Telecommunications Standards Institute) ha istituito in proposito NFV MANO (NFV MANagement and Organization), un apposito workgroup col compito di definire un’architettura di riferimento.
I tool di orchestrazione (OpenStack Neutron è uno dei tool open source più diffusi per l’orchestrazione, ma ce ne sono anche altri, come Contrail Service Orchestration di Juniper) svolgono il ruolo di automatizzare il processo di configurazione della rete partendo dallo stato desiderato della stessa, e andando a configurare i dispositivi in modo da ottenere il risultato voluto.
Possibili problemi di sicurezza SDN
Parliamo di architetture e componenti interamente basate su software, quindi con requisiti di sicurezza differenti dalle reti hardware.
La Open Networking Foundation (ONF), organo promotore del protocollo OpenFlow, ha recentemente pubblicato un articolo evidenziando due minacce principali dell’architettura:
- Il controller SDN è un “single point of attack failure”: essendo il componente centrale che fornisce “intelligenza” a tutta l’architettura, lo rende un target particolarmente appetibile ad eventuali attacchi.
- L’interfaccia southbound (quella che comunica con i device di rete), come lo stesso OpenFlow, è vulnerabile a minacce che potrebbero degradare la disponibilità e la performance della rete.
La programmabilità del controller SDN inoltre pone potenziali problemi tutti suoi: da un lato l’innegabile vantaggio per gli operatori della possibilità di installare applicazioni su di esso e applicare facilmente nuove policy di sicurezza, dall’altro considerando che questi controller sono in grado di riconfigurare l’intera rete, l’eventualità che vengano installate applicazioni compromesse apre a nuove problematiche e rischi.
5G
I provider wireless hanno tre obiettivi primari per 5G: aumentare la capacità, aumentare la velocità e abbassare la latenza. Chiaramente avere una velocità 100 volte superiore ad oggi, con una latenza inferiore al millisecondo significa che non sarà sufficiente limitarsi ad aggiornare hardware e software alle ultime tecnologie.
Tra i possibili benefici che SDN porterà a 5G si segnalano:
- L’abilità di fornire flussi di dati più efficienti, tramite il reindirizzamento automatico del traffico.
- La possibilità di avere cache distribuita per i contenuti richiesti di frequente.
- La scalabilità unita al provisioning dinamico riducendo drasticamente lo sforzo necessario per espandere le reti.
Intelligenza artificiale
Pur essendo il dettaglio delle opportunità di impiego di AI nelle SDN al di fuori dallo scope di questo articolo, si possono già ora immaginare scenari in cui si risponde ai problemi di sicurezza tramite machine learning: per esempio, si potrebbero analizzare i pacchetti in arrivo cercando di fare “apprendere” al controller pattern che identifichino attacchi maliziosi in modo da difendersi da solo.
Inoltre tutti gli automatismi indirizzati da SDN (routing dinamico, assegnazione di banda on-demand, etc) richiederanno giocoforza analytics per fornire il supporto decisionale richiesto.
Le automobili self-driven sono una realtà, è giunta l’ora anche per le reti self-driven?
Una citazione (per ora) merita il concetto di rete self-driven, in special modo promossa da Juniper.
L’idea è di andare oltre il fornire agli operatori strumenti per la configurazione e il provisioning, ma fare in modo che la rete scopra da sola i nodi, li configuri per funzionare assieme, sia in grado di monitorare il traffico e lo stato di “salute” dei componenti, e in ultima analisi di funzionare ed eventualmente anche modificarsi autonomamente.
Inoltre, almeno sulla carta le reti autonome dovrebbero essere in gradi di abilitare il design-by-intent, ovvero permettere all’operatore di effettuare modifiche funzionali dichiarando lo stato desiderato, senza preoccuparsi dei dettagli operativi che sottintendono l’operazione.
Conclusione
Network Function Virtualization e Software Defined Networks stanno già cambiando il modo di fare networking di gran parte delle Telco, siamo ancora agli inizi e ci saranno sicuramente molti aspetti da limare nel percorso, ma in ultima analisi le reti software sembrano essere qui per restare.
Il machine learning ha cambiato il modo in cui vediamo il software, probabilmente dovremo cambiare anche il modo in cui vediamo le reti.
Questo articolo è stato originariamente pubblicato su Spindox.it: Software Defined Networks: la via per DevOps passa dalla virtualizzazione
Note:
1. Es: switch, firewall, routing…
Links
SDN
It’s the End of Network Automation as We Know It (and I Feel Fine)
Achieving Infrastructure as Code
Industry recognizes imperative of transforming the network architecture
SDN 101: What It Is, Why It Matters, and How to Do It
Software Defined Networking is critical in big software
Self-Driving Networks
Are Self Driving Networks Set to Disrupt the Enterprise Networking World?
NFV
NFV: Network Functions Virtualization
What is NFV – Network Function Virtualization?
Virtualized Network Functions VNF
What is the difference between SDN and NFV?
NFV MANO: NFV MANagement Organization
Andrea lavora nel campo dell’IT da quasi 20 anni coprendo un po’ tutto, da sviluppo a business analysis, alla gestione di progetti.
Oggi possiamo dire che è uno gnomo spensierato, appassionato di Neuroscienze, Intelligenza Artificiale e fotografia.
