Software Defined Networks: la via per DevOps passa dalla virtualizzazione

È 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.

reti
Quando regnavano i cavi…

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.

disposiviti di rete
Tipici dispositivi di rete

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.

software defined networks
Modello di architettura SDN

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.

software defined networks - strati logici
Esempio semplificato di layer di rete logica programmato sopra la la rete fisica

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.

openmano
Disegnare una rete via software e implementarla sarà la stessa cosa

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.

Architettura NCS

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.

Architettura di riferimento NFV MANO

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.

Fasi per il passaggio a reti self-driven

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)

The Network as Code

Achieving Infrastructure as Code

What is OpenStack Networking?

What is OpenStack Neutron?

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

What is Self-Driving Network?

Are Self Driving Networks Set to Disrupt the Enterprise Networking World?

NFV

What is an NFV OpenStack?

NFV: Network Functions Virtualization

What is NFV – Network Function Virtualization?

Virtualized Network Functions VNF

What is the difference between SDN and NFV?

NFVI, NFV Infrastructure

NFV MANO: NFV MANagement Organization

ETSI NFV MANO on IETF

 

Informazioni sull'autore

Rispondi

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.

%d blogger hanno fatto clic su Mi Piace per questo: