Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Transcript

1 White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric Infrastructure) di Cisco. Il modello di programmabilità di Cisco ACI consente un accesso completo a livello programmatico all'infrastruttura basata sulle applicazioni. Cisco ACI fornisce accesso in lettura e scrittura, attraverso API standard Representational State Transfer (REST), al modello a oggetti sottostante, che è una rappresentazione di ogni attributo fisico e logico nell'intero sistema. Grazie a questo accesso, i clienti possono integrare l'implementazione di rete in strumenti di gestione e di monitoraggio e implementare i nuovi carichi di lavoro a livello di programmazione. Sfide derivanti dagli attuali approcci alla programmabilità della rete La maggioranza delle reti attualmente in uso sono basate su hardware con software ad associazione rigida, destinato a essere gestito e amministrato tramite l'interfaccia della riga di comando (CLI). Questi sistemi erano adatti a un contesto caratterizzato da configurazioni di rete statiche, carichi di lavoro statici e modifiche più lente e prevedibili per lo scaling delle applicazioni. Con la virtualizzazione delle reti dei data center e l'avvio della transizione verso modelli IT agili e cloud, questo modello non funziona più. Pertanto, i fornitori si stanno adoperando per integrare la programmabilità nelle offerte e nei sistemi operativi dei dispositivi esistenti. Questo approccio aumenta le capacità, ma non è il metodo ideale per incorporare la programmabilità. Il modello aggiunge complessità gestionale introducendo un punto di gestione totalmente nuovo, di solito identificato in un controller di rete, che cerca di eseguire artificialmente il mapping tra policy di applicazioni e utenti e costrutti di rete non flessibili. Inoltre, questi controller di rete e i modelli che incorporano sono limitati alle funzioni di rete e non possono arrivare a supportare il resto dell'infrastruttura. La vera programmabilità deve essere integrata fin dalle basi, non applicata in un secondo momento. I componenti dell'infrastruttura e i costrutti che incorporano deve essere progettati all'insegna della programmabilità fin dalle basi, con un modello che gli sviluppatori possano comprendere e utilizzare rapidamente Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco. Pagina 1 di 8

2 Programmabilità di Cisco ACI con API REST e modello di dati orientato agli oggetti Con la soluzione Cisco ACI, Cisco ha adottato un approccio fondante alla creazione di un'infrastruttura della rete programmabile. Questa infrastruttura funziona come un unico sistema a livello di fabric, controllato da Cisco Application Policy Infrastructure Controller (APIC). Con tale approccio, la rete del data center nel suo insieme è collegata in modo coeso e gestita come un sistema di trasporto intelligente per le applicazioni che supportano l'azienda. Sui dispositivi di rete che fanno parte di questo fabric, il nucleo del sistema operativo è stato scritto per supportare questa visione sistemica e fornire un'architettura basata sulla programmabilità. Anziché aprire un sottoinsieme delle funzionalità della rete attraverso interfacce di programmazione, come le soluzioni SDN (Software Defined Networking) della generazione precedente, l'intera infrastruttura è aperta all'accesso programmatico. Questo risultato deriva dalla disponibilità dell'accesso al modello a oggetti di Cisco ACI, che rappresenta la configurazione completa e lo stato di runtime di ogni singolo componente hardware e software in tutta l'infrastruttura. Inoltre, il modello a oggetti è reso disponibile attraverso interfacce REST standard, facilitando l'accesso e la manipolazione del modello stesso e, di conseguenza, della configurazione e dello stato di runtime del sistema. Al livello superiore, il modello a oggetti di Cisco ACI si basa sulla teoria della promessa, che fornisce un'architettura di controllo scalabile, con oggetti autonomi incaricati di implementare le modifiche di stato desiderate fornite dal cluster controller. Questo approccio è maggiormente scalabile rispetto ai sistemi di gestione top-down tradizionali, che richiedono una conoscenza dettagliata delle configurazioni di basso livello e dello stato attuale. Con la teoria della promessa, le modifiche di stato desiderate vengono trasmesse e gli oggetti le implementano, restituendo errori quando necessario. Al di sotto di questo concetto di alto livello si trova il nucleo centrale della programmabilità di Cisco ACI: il modello a oggetti. Il modello può essere suddiviso in due componenti principali: logica e fisica. I framework basati su modelli forniscono un modo preciso per rappresentare i dati. Il modello di Cisco ACI fornisce accesso completo al modello di informazione sottostante, offrendo astrazione delle policy, modelli fisici e dati di debug e di implementazione. La figura 1 rappresenta il framework del modello di Cisco ACI. Il modello è accessibile tramite API REST, con conseguente apertura del sistema alla programmabilità. Figura 1. Modello di dati orientato agli oggetti e API REST di Cisco ACI 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco. Pagina 2 di 8

3 Come mostrato nella figura 1, il modello logico è l'interfaccia con il sistema. Gli amministratori o i sistemi di gestione cloud di alto livello interagiscono con il modello logico attraverso API, CLI o GUI. Le modifiche al modello logico vengono quindi trasmesse al modello fisico, che diventa in genere la configurazione hardware. Il modello logico è costituito a sua volta da oggetti, configurazione, policy e stato di runtime, che possono essere manipolati, e dagli attributi di tali oggetti. Nel framework di Cisco ACI questo modello è noto come struttura di gestione delle informazioni (MIT, Management Information Tree). Ogni nodo MIT rappresenta un oggetto o un gruppo di oggetti gestiti. Questi oggetti sono organizzati in modo gerarchico, creando contenitori di oggetti logici. La figura 2 illustra la gerarchia logica del modello a oggetti MIT. Figura 2. Struttura di gestione delle informazioni (MIT, Management Information Tree) Oggetti nella MIT Cisco ACI utilizza un'architettura basata sul modello informativo in cui il modello descrive tutte le informazioni che possono essere controllate da un processo di gestione. Alle istanze di oggetti viene fatto riferimento come oggetti gestiti (MO, Managed Object). Ogni oggetto gestito nel sistema può essere identificato mediante un nome distinto univoco (DN, Distinguished Name). Questo approccio consente di fare riferimento all'oggetto a livello globale. Oltre al suo nome distinto, ogni oggetto può essere identificato mediante il nome relativo (RN, Relative Name). Il nome relativo identifica un oggetto in relazione al suo oggetto padre. Il nome distinto di un dato oggetto è costituito dal suo nome relativo aggiunto in coda al nome distinto del relativo oggetto padre. I nomi distinti vengono mappati direttamente agli URL. Per accedere a un oggetto è possibile utilizzare il nome relativo o il nome distinto, in base alla posizione corrente nella MIT. La relazione tra oggetti gestiti, nomi relativi e nomi distinti è illustrata nella figura Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco. Pagina 3 di 8

4 Figura 3. Oggetti gestiti, nomi relativi e nomi distinti La figura 3 mostra il nome distinto, che rappresenta in modo univoco ogni istanza di oggetto gestito, e il nome relativo, che rappresenta l'oggetto a livello locale al di sotto del relativo oggetto gestito padre. Tutti gli oggetti nella struttura esistono al di sotto dell'oggetto principale. A causa della natura gerarchica della struttura e del sistema di attributi utilizzato per identificare le classi di oggetti, la struttura può essere interrogata in diversi modi per richiedere informazioni sull'oggetto gestito. Le query possono essere eseguite direttamente sull'oggetto tramite il suo nome distinto, su una classe di oggetti, ad esempio chassis switch, o a livello di struttura, per individuare tutti i membri di un oggetto. Nella figura 4 sono illustrate tre query a livello di struttura. Figura 4. Query a livello di struttura 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco. Pagina 4 di 8

5 La figura 4 mostra due chassis interrogati a livello di struttura. Entrambe le query restituiscono l'oggetto di riferimento e i relativi oggetti figlio. Questo approccio è utile per individuare i componenti di un sistema più ampio. L'esempio nella figura 4 individua le schede e le porte di un determinato chassis switch. La figura 5 mostra un altro tipo di query: la query a livello di classe. Figura 5. Query a livello di classe Come illustrato nella figura 5, le query a livello di classe restituiscono tutti gli oggetti di una determinata classe. Questo approccio è utile per individuare tutti gli oggetti di un certo tipo disponibili nella MIT. Nell'esempio, la classe utilizzata è Cards (schede), che restituisce tutti gli oggetti di tipo scheda. Il terzo tipo di query è la query a livello di oggetto. In una query a livello di oggetto viene utilizzato un nome distinto per restituire un oggetto specifico. La figura 6 mostra due query a livello di oggetto: una per il nodo 1 sullo chassis 2, e una per il nodo 1 sullo chassis 1, scheda 1, porta 2. Figura 6. Query a livello di classe Per tutte le query MIT, è possibile scegliere di restituire l'intera sottostruttura o una sottostruttura parziale. Inoltre, il meccanismo di controllo degli accessi basato sui ruoli (RBAC) nel sistema indica quali oggetti verranno restituiti; a essere restituiti saranno sempre e solo gli oggetti per i quali l'utente dispone dei diritti di visualizzazione Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco. Pagina 5 di 8

6 Proprietà degli oggetti gestiti Gli oggetti gestiti in Cisco ACI includono proprietà che definiscono l'oggetto gestito. Le proprietà in un oggetto gestito sono suddivise in blocchi, gestiti da processi determinati all'interno del sistema operativo. Per ogni oggetto possono essere presenti diversi processi che vi accedono. Tutte queste proprietà nel loro insieme vengono compilate in fase di runtime e presentate all'utente come un singolo oggetto. La figura 7 mostra un esempio di questa relazione. Figura 7. Proprietà degli oggetti gestiti Nella figura 7 per l'oggetto di esempio sono presenti tre processi che scrivono nei blocchi di proprietà nell'oggetto. Il motore di gestione dei dati (DME), che costituisce l'interfaccia tra Cisco APIC (quindi, l'utente) e l'oggetto, il Port Manager, che gestisce la configurazione delle porte, e lo Spanning Tree Protocol (STP) interagiscono tutti con blocchi di questo oggetto. L'oggetto stesso viene presentato all'utente tramite l'api come una singola entità compilata in fase di runtime. Accesso ai dati dell'oggetto tramite interfacce REST REST è uno stile di architettura software per sistemi distribuiti come il World Wide Web. Negli ultimi anni REST si è affermato come uno dei modelli predominanti di progettazione dei servizi Web. Grazie allo stile più semplice, REST si sta via via sostituendo ad altri modelli di progettazione come il protocollo SOAP (Simple Object Access Protocol) e WSDL (Web Services Description Language). Cisco APIC supporta le interfacce REST per l'accesso a livello di programmazione all'intera soluzione Cisco ACI. Il modello di informazione basato su oggetti di Cisco ACI lo rende particolarmente adatto alle interfacce REST: URL e URI vengono associati direttamente ai nomi distinti che identificano gli oggetti nella struttura, e tutti i dati della MIT possono essere descritti come un documento con struttura testuale strutturata autonoma, codificato in XML o annotazione oggetti JavaScript Object (JSON). Gli oggetti hanno relazioni padre-figlio identificate mediante nomi distinti e proprietà, che vengono letti e modificati da un insieme di operazioni create, read, update e delete (CRUD) Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco. Pagina 6 di 8

7 Gli oggetti sono accessibili al rispettivo indirizzo definito, i relativi URL REST, utilizzando comandi HTTP standard per il recupero e la manipolazione dei dati degli oggetti Cisco APIC. Il formato URL utilizzato può essere rappresentato come segue: <sistema>/api/[mo classe]/[nd classe][:metodo].[xml json]?{opzioni} I vari componenti fondamentali di tale URL sono i seguenti: sistema: identificatore di sistema; un indirizzo IP o un nome host risolvibile tramite DNS mo classe: indica se si tratta di una query a livello di oggetto gestito, struttura (MIT) o classe classe: classe di oggetto gestito (come specificato nel modello di informazione) degli oggetti interrogati; il nome della classe è rappresentato come <nomepacchetto><nomeclasseoggettogestito> dn: nome distinto (nome gerarchico univoco dell'oggetto nella struttura MIT) dell'oggetto interrogato metodo: indicazione facoltativa del metodo richiamato sull'oggetto; si applica solo alle query HTTP POST xml json: formato di codifica opzioni: opzioni, filtri e argomenti della query La capacità di fare riferimento e accedere a un singolo oggetto o a una classe di oggetti con l'url REST consente di ottenere accesso completo a livello di programmazione all'intera struttura di oggetti e, quindi, all'intero sistema. Software development kit per ambienti di programmazione Le API REST per Cisco ACI integrano facilmente qualsiasi ambiente di programmazione a prescindere dalla metodologia di sviluppo e dal linguaggio utilizzati. Per accelerare ulteriormente lo sviluppo negli ambienti di programmazione più diffusi, saranno resi disponibili software development kit (SDK) per Cisco ACI. Cisco ACIpysdk, un SDK basato su Python, è uno di questi SDK per ambienti di programmazione Python. Le librerie Python e le API che fanno parte dell'sdk eseguono l'astrazione delle chiamate alle API REST sottostanti e forniscono una facile e rapida integrazione nelle suite software basate su Python. Conclusioni Il modello di dati orientato agli oggetti di Cisco APIC è progettato fin dalle basi per la programmabilità della rete. A livello di dispositivo, il sistema operativo è stato riscritto come sistema operativo di switch completamente basato su oggetti per Cisco ACI. I componenti di Cisco ACI sono gestiti da Cisco APIC, che fornisce API REST totalmente funzionali. Al di sopra di questa API sono presenti una CLI e una GUI per l'amministrazione ordinaria. Il modello a oggetti consente fluidità della programmazione e accesso completo ai componenti sottostanti dell'infrastruttura utilizzando le API REST. Gli oggetti sono organizzati logicamente in un modello gerarchico e memorizzati nella MIT. Questo approccio fornisce un framework per il controllo e la programmabilità della rete, con un livello di apertura non disponibile in altri sistemi. Per ulteriori informazioni Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco. Pagina 7 di 8

8 Stampato negli Stati Uniti C / Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco. Pagina 8 di 8