[section_title title=SDN vs infrastrutture convergenti]
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.
