White paper
Principi dell'infrastruttura basata sulle applicazioni
(ACI)
Panoramica
Una delle principali innovazioni dell'infrastruttura basata sulle applicazioni (ACI) è l'introduzione di un'interfaccia a
elevato livello di astrazione che consente di esprimere la connettività delle componenti applicative unitamente alle
policy di alto livello che la disciplinano. Il modello è stato progettato per essere di semplice utilizzo per gli
sviluppatori di applicazioni e al tempo stesso per migliorare l'automazione e la sicurezza.
Teoria delle policy ACI
Il modello di policy ACI è un modello orientato agli oggetti, basato sulla teoria della promessa. La teoria della
promessa si basa sul controllo scalabile di oggetti intelligenti, anziché su modelli impositivi più tradizionali,
concepibili come un sistema di gestione top-down. In questo sistema, il Central Manager deve conoscere sia i
comandi di comunicazione degli oggetti sottostanti che lo stato corrente di tali oggetti.
La teoria della promessa si basa invece sulla gestione, da parte degli oggetti sottostanti, dei cambiamenti di stato
della configurazione avviati direttamente dal sistema di controllo, come "cambiamenti di stato desiderati". Gli
oggetti sono quindi responsabili per la ritrasmissione delle eccezioni o dei guasti al sistema di controllo. Questo
approccio riduce il carico e la complessità del sistema di controllo e consente una maggiore scalabilità. Il sistema
risulta ulteriormente scalabile consentendo ai metodi degli oggetti sottostanti di richiedere i cambiamenti di stato
reciproci e agli oggetti di livello inferiore (figura 1).
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 1 di 8
Figura 1.
Approccio basato sulla teoria della promessa al controllo dei sistemi su larga scala
All'interno di questo modello teorico ACI costruisce un modello a oggetti per l'implementazione delle applicazioni,
che rappresentano l'elemento centrale del sistema. In genere i limiti alle applicazioni derivano dalla capacità della
rete e da requisiti volti a impedire l'uso improprio dei costrutti per attuare le policy. Concetti come indirizzamento,
VLAN e sicurezza sono stati raggruppati, limitando la portata e la mobilità dell'applicazione. Nel momento in cui le
applicazioni vengono riprogettate per la mobilità e l'ambito Web, questo approccio tradizionale ne ostacola
un'implementazione rapida e coerente.
Il modello di policy ACI non impone requisiti relativi alla struttura della rete sottostante. Tuttavia, come previsto
dalla teoria della promessa, richiede che un qualche tipo di elemento edge, o iLeaf, gestisca le connessioni ai vari
dispositivi.
Modello a oggetti
Al livello superiore il modello a oggetti ACI si basa su un gruppo di uno o più tenant, consentendo l'isolamento
dell'amministrazione dell'infrastruttura della rete e dei flussi di dati. I tenant possono essere usati per clienti, unità
aziendali o gruppi in base alle esigenze dell'azienda. Un'azienda, ad esempio, può utilizzare un tenant per l'intera
struttura, mentre un provider di servizi cloud può avere clienti che utilizzano uno o più tenant per rappresentare le
proprie aziende.
I tenant possono essere ulteriormente suddivisi in contesti, che si riferiscono direttamente alle istanze di routing e
inoltro virtuale (VRF) o a spazi IP separati. A ogni tenant possono essere associati uno o più contesti, a seconda
delle esigenze di business del tenant in questione. I contesti rappresentano un modo per separare ulteriormente i
requisiti organizzativi e di inoltro per un dato tenant. Visto che i contesti utilizzano istanze di inoltro separate,
l'indirizzamento IP può essere duplicato in contesti separati a scopo di multitenancy.
All'interno del contesto il modello fornisce una serie di oggetti che definiscono l'applicazione. Questi oggetti sono
costituiti da endpoint (EP) e gruppi di endpoint (EPG), e dalle policy che ne definiscono il rapporto (figura 2). Si noti
che le policy in questo caso sono più di un semplice insieme di elenco di controllo degli accessi (ACL), e
comprendono una raccolta di: filtri in ingresso e in uscita, impostazioni relative alla qualità del traffico, regole di
marcatura e regole di reindirizzamento.
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 2 di 8
Figura 2.
Modello a oggetti logico
La figura 2 mostra un tenant con due contesti e le applicazioni che li compongono. Gli EPG raffigurati sono gruppi
di endpoint che compongono un livello applicativo o un altro raggruppamento applicativo logico. Ad esempio,
l'Applicazione B, espansa sul lato destro della figura, può consistere di un livello Web (blu), di un livello applicativo
(rosso) e di un livello database (arancione). La combinazione tra EPG e di policy che ne definiscono l'interazione
rappresenta un profilo di rete dell'applicazione (ANP, Application Network Profile) nel modello ACI.
Gruppi di endpoint
Gli EPG sono un insieme di endpoint simili che rappresentano un livello applicativo o un gruppo di servizi;
forniscono un raggruppamento logico di oggetti che richiedono una policy simile. Un EPG, ad esempio, potrebbe
essere il gruppo di componenti che costituiscono il livello Web di un'applicazione. Gli endpoint sono definiti
utilizzando la scheda di interfaccia di rete (NIC), NIC virtuale (vNIC), indirizzo IP o DNS (Domain Name System),
con l'estensibilità per supportare i metodi futuri di identificazione dei componenti dell'applicazione.
Gli EPG sono utilizzati anche per rappresentare entità come reti esterne, servizi di rete, dispositivi di protezione e
archiviazione in rete. Gli EPG sono insiemi di uno o più endpoint che svolgono una funzione simile. Rappresentano
un raggruppamento logico con una varietà di opzioni di utilizzo, a seconda del modello in uso per
l'implementazione delle applicazioni (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.
Relazioni tra i gruppi di endpoint
Gli EPG sono progettati per fornire flessibilità, consentendo di personalizzarne l'utilizzo in base a uno o più modelli
di implementazione a scelta del cliente. Gli EPG vengono quindi utilizzati per definire gli elementi ai quali si applica
la policy. All'interno del fabric di rete la policy viene applicata tra EPG, definendone quindi la modalità di
comunicazione reciproca. Questo approccio è stato concepito per poter essere esteso, in una prospettiva futura,
all'applicazione delle policy all'interno degli EPG.
Ecco alcuni esempi di utilizzo degli EPG:
●
EPG definito da VLAN di rete tradizionali: tutti gli endpoint connessi a una determinata VLAN collocati in un
EPG
●
EPG definito da Virtual Extensible LAN (VXLAN): come per le VLAN, ma utilizzando una VXLAN
●
EPG mappato a un gruppo di porte VMware
●
EPG definito da IP o subnet: ad esempio, 172.168.10.10 oppure 172.168.10
●
EPG definito da nomi o intervalli DNS: ad esempio, example.foo.com o *.web.foo.com
L'utilizzo degli EPG è al contempo flessibile ed estensibile. Il modello è pensato per fornire gli strumenti necessari
a costruire un modello di rete applicativo che rispecchi il modello di implementazione dell'ambiente reale. Anche la
definizione degli endpoint è estendibile, e fornisce cosìsupporto per miglioramenti di prodotto ed esigenze di
settore future.
Il modello EPG offre una serie di vantaggi a livello di gestione: fornisce infatti un singolo oggetto con policy
uniforme per strumenti di automazione e di orchestrazione di livello superiore. Gli strumenti non devono
necessariamente operare su singoli endpoint per modificare le policy. Inoltre, agevola la coerenza tra endpoint
nello stesso gruppo indipendentemente dalla loro collocazione nella rete.
Applicazione della policy
Il rapporto tra EPG e policy può essere pensato come una matrice con un asse che rappresenta l'EPG di origine
(sEPG) e l'altro che rappresenta l'EPG di destinazione (dEPG.) Una o più policy vengono collocate all'intersezione
di specifici sEPG e dEPG. Nella maggior parte dei casi la matrice è scarsamente popolata, dato che molti EPG non
hanno l'esigenza di comunicare (figura 4).
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 4 di 8
Figura 4.
Matrice di applicazione della policy
Le policy sono divise per filtri sulla qualità del servizio (QoS), controllo degli accessi, inserimento dei servizi e così
via. I filtri sono regole specifiche per la policy tra due EPG. I filtri sono costituiti da regole in entrata e in uscita:
consenti, rifiuta, reindirizza, registra, copia e contrassegna. Le policy rendono possibili funzioni wildcard all'interno
delle definizioni (figura 5). L'applicazione della policy utilizza in genere un approccio "most-specific-match-first",
che attribuisce la priorità in base al livello di specificità.
Figura 5.
Regole di applicazione wildcard
Profili di rete delle applicazioni
Un profilo di rete dell'applicazione è un raccolta di EPG, delle loro connessioni e delle policy che definiscono
queste ultime. I profili di rete delle applicazioni sono la rappresentazione logica di un'applicazione e delle sue
interdipendenze sul fabric di rete.
I profili di rete delle applicazioni sono progettati per essere modellati in modo logico, corrispondente alle modalità di
progettazione e implementazione delle applicazioni medesime. La configurazione e l'applicazione delle policy e la
connettività vengono gestite dal sistema anziché manualmente dall'amministratore. La figura 6 mostra un esempio
di profilo di accesso.
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 5 di 8
Figura 6.
Profili di rete delle applicazioni
Questi passaggi generali sono necessari per creare un profilo di rete dell'applicazione:
1.
Creare gli EPG (come discusso in precedenza).
2.
Creare le policy che definiscono la connettività, con queste regole:
3.
●
Consenti
●
Rifiuta
●
Log
●
Contrassegna
●
Reindirizza
●
Copia
Creare punti di connessione tra gli EPG utilizzando i costrutti di policy noti come contratti.
Contratti
I contratti definiscono permessi di entrata e in uscita, rifiuti e regole e policy QoS, come il reindirizzamento. I
contratti consentono la definizione sia semplice che complessa del modo in cui un EPG comunica con gli altri a
seconda dei requisiti dell'ambiente. Anche se i contratti vengono applicati tra EPG, sono collegati a questi ultimi
mediante relazioni fornitore-consumatore. In sostanza, un EPG fornisce un contratto, e gli altri EPG ne fanno uso.
Il modello fornitore-consumatore è utile per diversi scopi. Offre un modo naturale per associare uno "scudo" o
"membrana" a un livello applicativo, che determina il modo in cui tale livello interagisce con altre parti di
un'applicazione. Ad esempio, un server Web potrà fornire HTTP e HTTPS, e gli verrà applicato un contratto che
consenta solo questi servizi. Inoltre, il modello di contratto fornitore-consumatore promuove la sicurezza,
consentendo aggiornamenti di policy semplici e coerenti di un singolo oggetto policy, anziché dei link multipli che
un contratto può rappresentare. I contratti forniscono semplicità anche consentendo di definire le policy una sola
volta, per poi riutilizzarle (figura 7).
© 2013 Cisco e/o i relativi affiliati. Tutti i diritti riservati. Il presente documento contiene informazioni pubbliche di Cisco.
Pagina 6 di 8
Figura 7.
Contratti
La figura 8 mostra la relazione tra i tre livelli di un'applicazione Web definiti dalla connettività EPG e dai contratti
che ne definiscono la comunicazione. La somma di queste parti costituisce un profilo di rete dell'applicazione. I
contratti prevedono anche la riutilizzabilità e la coerenza delle policy per i servizi che generalmente comunicano
con più EPG.
Figura 8.
Profilo di rete dell'applicazione completo
Conclusioni
Questo documento si limita a fornire un'introduzione al modello di policy ACI, illustrando il concetto di ACI e il modo
in cui il relativo modello di policy può essere utilizzato. Presuppone anche una serie di altri costrutti e oggetti che,
per semplicità, non sono stati trattati in questa sede.
Per ulteriori informazioni
Collegarsi all'indirizzo 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-729906-00
11/13
Pagina 8 di 8