<< Torna agli Approfondimenti Tematici

Premessa

Da qualche tempo, parlando con ingegneri, studenti, project e account manager, mi sono fatto l’idea che la moda del momento sia chiedersi se il networking come lo conosciamo oggi sia arrivato al capolinea.

Fino ad oggi abbiamo dovuto risolvere con MPLS TE complessi problemi di ingegneria del traffico, garantire le risorse con tecniche di qualità del servizio puntuali: alcuni con uno sottofondo di inquietudine si chiedono se le conoscenze di rete possedute oggi e dominate con grande fatica, saranno presto considerate ingenue ed obsolete; altri con fare entusiasta e consapevole affermano che siamo all’anno zero dell’ingegneria di rete, che finalmente renderà applicazioni e rete un tutt’uno, evocando scenari degni dell’Architetto di Matrix Revolution.

Con aspettative e con copetenze diverse, in molti guardano ormai ad una rete controllata centralmente che rende le applicazioni padrone ancora una volta della scena, dove perl, pyton, c++ e java prenderanno il posto di Cisco IOS, Junos e così via. Il futuro potrebbe essere SDN Software Defined Networking!

Se volete sapere come andrà a finire, potete trovare la risposta a questa domanda facilmente in rete e nelle conferenze di mezzo mondo. Peccato che le risposte siano il più delle volte contrastanti, opinioni che si dividono tra oracoli che già sanno cosa accadrà tra dieci anni con stupefacente lucidità e scettici che tendono a minimizzare l’impatto di quella che è una nuova filosofia che propone innegabili innovazioni interessanti.

Purtroppo come network engineer non so prevedere il futuro, e credo che per farlo sarebbe necessaria una profonda conoscenza delle tecnologie SDN che credo al momento abbiano coloro che stanno sviluppando protocolli e prodotti e i pionieri che si cimentano nello studio della materia. Mancando un’ampia gamma di casi studio è difficile fare valutazioni economiche e strategiche per trarre delle conclusioni ragionate e consapevoli.

Quello che cercherò di fare in questo articolo è invece partire dalle motivazioni, presentare una panoramica di funzionamento e quali sono gli spunti più interessanti, non solo da un punto di vista tecnologico ma anche dare uno sguardo alle nuove figure professionali innovative, che potrebbero essere richieste per progettare ed implementare una SDN. Al termine dell’articolo riporto le fonti che ho considerato ed alcune risorse per approfondire gli argomenti qui trattati.

Le origini

Fino a relativamente poco tempo fa, lo storage, il computing e la rete erano considerate entità separate. Questo perché nella maggior parte delle aziende l’IT ha sempre preferito considerarle tali, per motivi meramente organizzativi: basando gruppi di supporto ed ingegneria su competenze più specifiche ed anche in nome della sicurezza che sarebbe stata più solida segmentando le funzionalità.

Storicamente si è sempre preferito far combaciare un box con un servizio in nome della stabilità, e quindi server dedicati di posta, domain controller, server radius, server web e così via. Questo approccio ha reso semplice per molto tempo una certa divisione tra i dipartimenti, dove un server poteva essere considerato sotto il controllo e la responsabilità esclusiva di un certo gruppo all’interno dell’organizzazione.

Le cose con il tempo sono andate cambiando, lentamente e inesorabilmente, da server distribuiti a data center centralizzati, da box dedicati sui quali potevamo installare Windows Server o Linux Red Hat a box condivisi tra più servizi, grazie a tecnologie hypervisor e qundi virtualizzazione. Una grande potenza computazionale a basso costo ha portato molte aziende a riconsiderare il rapporto box-sistema operativo richiedendo il consolidamento, e quindi la virtualizzazione e quello che viene chiamato “elastic computing”.

Una delle prime realtà a rendersi conto del problema delle “troppe scatole” fu Amazon, con la sua crescita vertiginosa, nella quale raddoppiava le proprie necessità ogni sei mesi, e dovendo quindi scalare per forza di cose orizzontalmente, si trovava sempre più spesso ad occupare spazio nei propri data center e dover pagare l’alimentazione della propria attrezzatura anche se questa non era ancora utilizzata.

Il decrescere del costo computazionale ha certamente dato lo slancio a tecnologie di virtualizzazione come WMWare, tuttavia ci si è trovati nell’ultimo decennio a non avere una sostanziale diminuzione del costo degli apparati di rete intelligenti in nome della complessità di control plane crescente: i dispositivi devono supportare molteplici tecnologie che aumentano di numero rapidamente garantendone in molti casi la coesistenza.

Intorno al 2008, queste considerazioni portarono alla nascita, nelle università di Berkeley e Stanford, della visione della Software Defined Network, una rete composta da apparati di rete controllati da un controller centrale ed alla conseguente proposta di un protocollo di comunicazione standard tra il controller e gli apparati: OpenFlow. Oggi con le dovute differenze molti vendor hanno deciso di supportare e promuovere l’approccio SDN. Juniper sembra aggredire più il mercato data center, mentre Cisco sembra interessata a più architetture come enterprise, service provider, collaboration; ad ogni modo si direbbbe che sia Juniper che Cisco stiano ponendo enfasi sulle ASIC più che sulla parte software, secondo molti scelta strategica che certamente dipende dal core business che è quello di produrre apparati di rete e non esclusivamente pacchetti software. Non è irrilevante sottolineare che questo nuovo approccio possa essere strategicamente problematico per aziende che hanno sempre fatto dell’hardware il loro cavallo di battaglia, ma è anche vero che ad esempio Cisco da lungo tempo ha proposto soluzioni come OER (Optimazed Edge Routing) e successivamente PfR (Performance Routing) che potremmo considerare una sorta di SDN versione 0.1. Oggi Cisco con il suo ONE (Open Network Environment) lavora su un approccio ibrido che rende possibile l’inserimento SDN in una rete tradizionale. Tuttavia è innegabile che la SDN ponga alcuni nodi da sciogliere e si presenti come una rivoluzione copernicana nell’ingegneria di rete, vediamo quindi quali sono gli aspetti principali di questa tecnologia.

Come funziona

Essenzialmente si parte dall’idea di suddividere control plane e data plane tra dispositivi differenti e scissi, in contrasto con quanto accade nelle reti attuali dove un router si occupa di popolare con algoritmi e protocolli delle strutture dati, che verranno poi utilizzate per l’inoltro dei pacchetti dallo stesso router.

Una problematica nata contestualmente alla virtualizzazione e quindi propria dei data center, è la necessità di molteplici VLAN per segregare il traffico tra macchine virtuali, comunicazioni Server-Server che possono essere dinamiche e complesse, implementazioni di regole di qualità del servizio puntuali, tutto nel rispetto di policy di sicurezza sempre più stringenti. Problematiche queste risolvibili con le tecnologie attuali ma che presentano indubbie problematiche di gestione essendo le logiche di queste soluzioni confinate sui singoli switch di rete. Visto da questo punto di vista lo stato attuale delle cose è assimilabile alla situazione della passata era mainframe, nella quale, hardware e software erano un tutt’uno, cotrol plane e data plane in un solo monolito monovendor.

Da diversi anni ormai il mercato è cambiato proponendo, hardware, sistemi operativi e API in grado di produrre un mercato vario, concorrenziale e rapido nell’innovazione, SDN si propone lo stesso traguardo con protocolli aperti e fruibili come Open Flow, disaccoppiando hardware e software, rendendo il control plane ancora una volta una parte software indipendente e interfacciabile con qualunque hardware. In questa visione gli apparati di rete perdono il loro ruolo centrale diventando meri esecutori delle indicazioni ricevute dal controller.

L’architettura SDN prevede tre livelli, dei quali il centrale, il controller è quello che governa la rete controllando se un flusso può essere immesso in rete e quali debbano essere le sue caratteristiche di trasporto. Il controller popola le strutture dati, tabelle di routing, policy di firewalling, lunghezza e algoritmi di gestione delle code. L’aspetto più interessante e innovativo sta nel fatto che con questo disaccoppiamento le applicazioni possono vedere la rete come una entità singola con la quale si può comunicare con delle API indipendenti dall’hardware.

Questo approccio a singolo controller pone certamente problemi di disponibilità, privacy e scalabilità che possono essere risolti implementando un protocollo di comunicazione intercontroller. Tale protocollo deve consentire oltre alla scalabilità anche un trattamento diverso della rete per singolo dominio, eventualmente anche differenziando policy di sicurezza e di qualità del servizio. Una soluzione a molte di queste problematiche è il protocollo SDNi proposto nella RFC informational SDNi: A Message Exchange Protocol for Software Defined Networks (SDNS).

Per implementare SDN è necessaria una architettura logica comune tra gli apparati di rete oltre ad un modo standard per comunicare con loro, OpenFlow è la risposta ad entrambe le esigenze, ma attualmente non è l’unico protocollo esistente, di grande rilievo è il protocollo OpenDaylight il progetto open source per SDN.

Per chi volesse approfondire l’argomento da un punto di vista tecnico consiglio la lettura di SDN: Software Defined Networks (Thomas D. Nadeau; Ken Gray - O'Reilly Media, Inc.) uno dei pochi testi ad oggi davvero completi che cerca di dare una visione a 360° delle attuali implementazioni e prospettive di sviluppo.

Figure professionali emergenti

Se da una parte SDN dovrebbe ridurre le risorse necessarie per l’esercizio di rete automatizzando molte delle configurazioni richieste, la complessità della rete probabilmente crescerà congiuntamente alle nuove possibilità offerte da questa architettura, rendendo necessari network designer molto preparati e trasversali oltre a richiedere importanti competenze di programmazione necessarie per rendere le applicazioni protagoniste della SDN.

In questo senso Cisco ha lanciato una prima versione di curriculum e certificazioni, che verranno rilasciate completamente entro Settembre 2014 per soddisfare le esigenze future del mercato:

Business Application Engineer (nessun prerequisito): figura professionale che sviluppa applicazioni per il business utilizzando le nuove possibilità di programmazione dell’ambiente di rete. Questa figura sarà quindi esperta di API.

Network Application Developer (prerequisito qualunque CCNA): responsabile per lo sviluppo di applicazioni di rete nel nuovo ambiente. Questa figura professionale deve avere una conoscenza di uno o più linguaggi di programmazione come Python, C o altri.

Network Proframmability Designer (prerequisito qualunque CCNP): questa figura professionale raccoglie le esigenze del cliente e grazie alla conoscenza delle capacità del nuovo ambiente di rete può tradurre le esigenze cliente in applicazioni, fornendo le specifiche funzionali al Network Application Developer.

Network Programmability Support (prerequisito qualunque CCNP): questa figura professionale si occupa della messa in servizio delle applicazioni. Dopo aver ricevuto i dettagli di progetto e l’applicazione dal Network Programmability Designer, si occupa di installarle e renderle operative effettuando eventualmente traoubleshooting.

E’ interessante come le nuove figure siano tutte concentrate sulla progettazione, sviluppo e messa in servizio delle applicazioni, ma sia richiesto un background sulla filosofia IOS (CCNA o CCNP), a dimostrazione che SDN dal punto di vista del trasporto, sarà una filosofia diversa per ottenere gli stessi risultato ottenibili con IOS ma customizzabile per applicazione. Appare evidente anche come le figure professionali di network engineer e programmer o network designer e software architect potrebbero non essere più così distanti, proponendo invece figure con una conoscenza trasversale di altissimo valore sul mercato.

Conclusioni

Concordo fondamentalmente con chi afferma che in generale SDN non renderà le reti meno costose. Diminuirà le spese di implementazione e messa in servizio, tuttavia non è inverosimile che aumentino costi operativi, che verranno riallocati sulla creazione di applicazioni che sono coscienti della rete, questo costo ulteriore consentirà però di ottenere prestazioni e funzionalità oggi difficilmente ottenibili. Probabilmente la soluzione controller con SDN può essere interessante per applicazioni Big Data e per quelle aziende come Google e Facebook che affrontano la gestione di data center enormi e soprattutto dinamici; non sono altrettanto certo che questa potrà essere una soluzione adatta a realtà di medie dimensioni o che non abbiano effettiva esigenza di applicazioni dinamiche e molto performanti.

Non nego di apprezzare l’approccio ibrido seguito da Cisco con ONE , non ritenendo realistico che OSPF, MPLS e BGP verranno spenti per lasciare spazio ad OpenFlow o OpenDaylight; credo invece che per molto molto tempo assisteremo a sistemi ibridi dove verrà valutato di volta in volta cosa deputare ai controller e cosa invece dovrà restare dominio di scelta dei protocolli tradizionalmente intesi. Tutto sommato si può essere certi solamente di una cosa: è davvero un periodo sfidante per lavorare come network engineer, il futuro proporrà opportunità veramente interessanti e di valore per chi vorrà coglierle!

Fonti e approfondimenti

SDN: Software Defined Networks (Thomas D. Nadeau; Ken Gray - O'Reilly Media, Inc.)
SDNi: A Message Exchange Protocol for Software Defined Networks (SDNS)
Software Defined Network and OpenFlow
Cisco Open Network Environment
Open Daylight
OpenFlow might lower CapEx while SDN will increase OpEx
Cisco Network Programmability Training