SDN e infrastrutture convergenti: due tendenze in conflitto?

Emanuel Monticelli

Se dovessimo individuare il fattore di cambiamento principale che al giorno d’oggi è di spinta per la trasformazione del business – e che a sua volta è il motore dell’innovazione tecnologica che si sviluppa – io sarei pronto a proporre il concetto di flessibilità. Le aziende hanno più che mai bisogno di essere flessibili, e tutta l’innovazione tecnologica segue proprio questa direzione: offrire alle imprese gli strumenti per poter rendere più flessibili i propri processi produttivi.

 

Oggi le imprese necessitano di tecnologie che possano fornire loro una buona flessiblità, ossia la capacità di adattarsi rapidamente ai cambiamenti, per essere in grado di convertire, aggiungere, eliminare e aggiustare rapidamente servizi o applicazioni per il mercato. Necessitano anche di individuare quali parti dell’infrastruttura tecnologica siano strategiche per potervi investire, e di disporre di strutture abbastanza dinamiche da modificare il mix “in house”-outsourcing/cloud a seconda delle esigenze dell’azienda.

 

Se si parla di flessibilità in materia di infrastrutture IT e di rete, è chiaro che la tecnologia SDN risulta avere un ruolo chiave. Prendendo in esame i diversi approcci del mercato, e mettendo da parte quelli chiusi e privati, che a mio parere non alimentano l’innovazione e si adattano male a questa ricerca di soluzioni flessibili, ci possiamo concentrare su quegli approcci basati su standard e open source.

 

In questo ambito tuttavia ci sono anche alcune controversie riguardo alle reti SDN, soprattutto riguardo a dove si debba effettuare questa “separazione” di implementazioni nella rete per poter usufruire delle proprietà SDN, o quali sviluppi dell’architettura siano quelli che effettivamente favoriscono apertura e programmabilità.

 

SDN vs Infrastrutture convergenti

Uno dei grandi temi di discussione riguardo alla tecnologia SDN è se l’ “astrazione” dell’intelligenza di rete sia efficace in tutte le situazioni e fino a che livello possa spingersi. A quei produttori che scommettono per l’astrazione totale sarebbe da chiedere per quale motivo talvolta si registra un crescente interesse per le infrastrutture convergenti, che rispondono ad una filosofia apparentemente contraria a quella della tecnologia SDN, nel senso che si cerca in questo caso di aggiungere componenti- parliamo di ambiente di rete del data center – al posto di scomporre o astrarre l’intelligenza dell’infrastruttura.

 

Esaminiamo più in dettaglio le due soluzioni:

 

a) Infrastruttura Convergente. Questo approccio parte dal presupposto che si possa eliminare una certa complessità del data center, se si è in grado di astrarre la configurazione dell’intero ambiente mediante la precedente integrazione di tutti gli elementi che lo compongono: rete, server e storage, in modo che al cliente venga offerta una specie di data center “in-a-box”. Indubbiamente questo approccio consente di esternalizzare la complessità verso il fornitore, e di ridurre il tempo necessario ad implementare o ad ampliare il data center. L’inconveniente è che ci si trova però di fronte ad una soluzione chiusa. Io credo invece che si possano sfruttare i benefici di un’infrastruttura convergente senza che essa debba per forza essere una soluzione chiusa.

 

b) Software Defined Networking (SDN). Dall’altra parte abbiamo l’ SDN, che di base separa l’hardware di rete dall’intelligenza di rete, creando strati intermedi che favoriscono flessibilità, controllo e automazione. Molti produttori, incluse molte nuove aziende che offrono software SDN, adottano questa separazione dei livelli nella parte inferiore dell’architettura, e ciò è noto come “southbound API”. Tuttavia, a mio parere, le capacità di programmazione di rete che apporta la tecnologia SDN, vanno ben oltre questo livello, salendo in alto, verso i piani di applicazione. Ad esempio, possiamo programmare il modo in cui le applicazioni comunicano con la rete – chiedendo più risorse, fornendo informazioni di come l’utente utilizza un’applicazione, oppure quando questa applicazione utilizza nuove porte TCP. Tutto questo è ciò che in termini SDN si definisce “northbound API”.

 

Ma esiste realmente un conflitto tra queste due soluzioni? A prima vista, possono sembrare due impostazioni contrastanti: integrare e assemblare componenti da un lato, disgregare e mantenere più elementi intercambiabili nell’infrastruttura dall’altro. In ogni caso entrambi gli approcci tentano di eliminare la complessità o almeno di ottenere maggiore flessibilità all’interno dell’infrastruttura. Coloro che hanno molta fretta di ristrutturare il proprio data center possono optare per la soluzione convergente “in-a-box”, mentre coloro che sono interessati a reti aperte e dinamiche, più orientati verso l’innovazione a lungo termine, possono usufruire della tecnologia SDN.

 

La verità è che non si tratta di una scelta tra tutto o niente, non sono soluzioni che si escludono reciprocamente, sempre che si opti per tecnologie aperte. Dopotutto a cosa serve la tecnologia SDN se le componenti non funzionano bene insieme? Molti sono alla ricerca di soluzioni SDN testate e con un alto tasso di integrazione all’interno di un ecosistema più elevato. Grazie al crescente numero di iniziative open source come OpenDaylight, Open Networking Lab o ON.Lab si ha un impulso crescente di soluzioni aperte, e grazie alle architetture di riferimento come VSPEX e a driver come OpenDaylight, i vantaggi di ciascun  approccio possono essere personalizzati a seconda della rete.

Emanuel Monticelli

System Engineer North Italy Extreme Networks