Programmabilità di rete con l`infrastruttura Cisco basata sulle

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.
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 1 di 8
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
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 3.
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 3 di 8
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
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.
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 5 di 8
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).
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 6 di 8
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
http://www.cisco.com/go/aci.
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 7 di 8
Stampato negli Stati Uniti
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
C11-729999-00
11/13
Pagina 8 di 8