{"id":33050,"date":"2019-10-31T21:50:27","date_gmt":"2019-10-31T18:50:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu\/"},"modified":"2019-10-31T21:50:27","modified_gmt":"2019-10-31T18:50:27","slug":"application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Application Centric Infrastructure. L'architettura della rete del futuro \u2014 dalle riflessioni all'azione","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Negli ultimi anni, Cisco ha attivamente promosso una nuova architettura per la costruzione delle reti di trasmissione dati nei data center \u2014 Application Centric Infrastructure (o ACI)<\/b>. Alcuni ne sono gi\u00e0 a conoscenza. Altri sono persino riusciti a implementarla nelle loro aziende, anche in Russia. Tuttavia, per la maggior parte dei professionisti IT e dei dirigenti IT, l'ACI rimane ancora un'abbreviazione poco chiara o solo una speculazione sul futuro.
\nIn questo articolo cercheremo di avvicinare questo futuro. A tal fine, parleremo dei principali componenti architettonici dell'ACI e illustreremo il modo in cui pu\u00f2 essere applicata nella pratica. Inoltre, nei prossimi giorni organizzeremo una dimostrazione visiva del funzionamento dell'ACI, alla quale pu\u00f2 iscriversi ogni professionista IT interessato.
\n<\/a><\/noindex>
\nPotr\u00e0 scoprire di pi\u00f9 sulla nuova architettura di costruzione della rete a San Pietroburgo a maggio 2019. Tutti i dettagli \u2013 a link<\/a><\/noindex>. Iscriviti!<\/p>\n

Antefatti<\/b>
\nIl modello di rete tradizionale e pi\u00f9 popolare \u00e8 il modello gerarchico a tre livelli: core -> distribuzione (aggregazione) -> accesso. Per molti anni questo modello \u00e8 stato un riferimento, e i produttori hanno realizzato vari dispositivi di rete in base a questa logica.
\nIn passato, quando le tecnologie informatiche erano una sorta di accessorio necessario (e, diciamolo, non sempre desiderato) per le imprese, questo modello era comodo, piuttosto statico e affidabile. Tuttavia, ora che l'IT \u00e8 uno dei motori di sviluppo del business, e in molti casi lo \u00e8 esso stesso, la staticit\u00e0 di questo modello ha portato a grandi problemi.<\/p>\n

Il business moderno genera una grande quantit\u00e0 di diverse e complesse esigenze per l'infrastruttura di rete. Il successo del business dipende direttamente dalle tempistiche di realizzazione di queste esigenze. In tali condizioni, i ritardi sono inaccettabili, e il modello classico di costruzione della rete spesso non consente di soddisfare tempestivamente tutte le necessit\u00e0 aziendali. <\/p>\n

Ad esempio, l'emergere di una nuova e complessa applicazione aziendale implica che gli amministratori di rete eseguano un gran numero di operazioni routinarie simili su un gran numero di diversi dispositivi di rete a vari livelli. Oltre a richiedere molto tempo, ci\u00f2 aumenta anche il rischio di commettere errori, che possono portare a significative interruzioni dei servizi IT e, di conseguenza, a danni finanziari.<\/p>\n

La radice del problema non risiede nemmeno nelle scadenze o nella complessit\u00e0 dei requisiti. Il punto \u00e8 che questi requisiti devono essere \"tradotti\" dal linguaggio delle applicazioni aziendali al linguaggio dell'infrastruttura di rete. Come \u00e8 ben noto, qualsiasi traduzione comporta sempre una parziale perdita di significato. Quando il proprietario dell'applicazione parla della logica di funzionamento della propria applicazione, l'amministratore di rete comprende un insieme di VLAN e access list su decine di dispositivi che devono essere mantenuti, aggiornati e documentati.<\/p>\n

L'esperienza accumulata e la costante comunicazione con i clienti hanno permesso a Cisco di progettare e implementare nuovi principi per la costruzione di una rete di dati nei centri di elaborazione, che rispondono alle tendenze moderne e si basano, prima di tutto, sulla logica delle applicazioni aziendali. Da qui il nome \u2014 Application Centric Infrastructure.<\/p>\n

Architettura ACI.<\/b>
\nL'architettura ACI dovrebbe essere considerata correttamente non dal punto di vista fisico, ma logico. Essa si basa su un modello di politiche automatizzate, i cui oggetti possono essere suddivisi ai livelli superiori nei seguenti componenti:<\/p>\n

    \n
  1. Rete basata su switch Nexus.<\/li>\n
  2. Cluster di controller APIC;<\/li>\n
  3. Profili delle applicazioni;<\/li>\n<\/ol>\n

    \n\"Application
    \nEsaminiamo ogni livello pi\u00f9 in dettaglio, passando dal semplice al complesso.<\/p>\n

    Rete basata su switch Nexus<\/b>
    \nLa rete nella fabbrica ACI \u00e8 simile a un modello gerarchico tradizionale, ma viene costruita in modo significativamente pi\u00f9 semplice. Per organizzare la rete si utilizza il modello Leaf-Spine, che \u00e8 diventato l'approccio standard per l'implementazione delle reti di nuova generazione. Questo modello \u00e8 composto da due livelli: Spine e Leaf, rispettivamente.
    \n \"Application
    \nIl livello Spine \u00e8 responsabile solo delle prestazioni. La prestazione totale degli switch Spine \u00e8 pari alle prestazioni dell'intera fabbrica, quindi a questo livello \u00e8 necessario utilizzare switch con porte da 40G o superiori.
    \nGli Spine switch si collegano a tutti gli switch di livello successivo: gli switch Leaf, ai quali si collegano gli host finali. Il ruolo principale degli switch Leaf \u00e8 la capacit\u00e0 di porte. <\/p>\n

    In questo modo, \u00e8 facile affrontare le questioni di scalabilit\u00e0: se abbiamo bisogno di aumentare la capacit\u00e0 di banda della fabbrica, aggiungiamo switch Spine, mentre se necessitiamo di aumentare la capacit\u00e0 delle porte, utilizziamo switch Leaf.
    \nPer entrambi i livelli si utilizzano switch della serie Cisco Nexus 9000, che per Cisco sono lo strumento principale per la costruzione di reti di Data Center, indipendentemente dalla loro architettura. Per il livello Spine si usano switch Nexus 9300 o Nexus 9500, mentre per il livello Leaf solo Nexus 9300.
    \nLa gamma di switch Nexus, che vengono utilizzati nella fabbrica ACI, \u00e8 mostrata nell'immagine sottostante.
    \n \"Application<\/p>\n

    Cluster di controller APIC (Application Policy Infrastructure Controller) <\/b>
    \nI controller APIC sono server fisici specializzati, mentre per piccole implementazioni \u00e8 consentito utilizzare un cluster composto da un controller APIC fisico e due virtuali.
    \nI controller APIC svolgono funzioni di gestione e monitoraggio. \u00c8 importante notare che i controller non partecipano mai alla trasmissione dei dati; quindi, anche se tutti i controller del cluster dovessero guastarsi, la stabilit\u00e0 della rete non sarebbe assolutamente influenzata. \u00e8 necessario anche sottolineare che tramite gli APIC l'amministratore gestisce tutte le risorse fisiche e logiche della fabbrica e, per apportare modifiche, non \u00e8 pi\u00f9 necessario collegarsi a un dispositivo specifico, poich\u00e9 nell'ACI si utilizza un'unica point of control.
    \n \"Application<\/p>\n

    Ora passiamo a uno dei componenti principali dell'ACI: i profili delle applicazioni.<\/b>
    \nProfilo applicazione (Application Network Profile)<\/b> \u00e8 la base logica dell'ACI. I profili delle applicazioni definiscono le politiche di interazione tra tutti i segmenti di rete e descrivono i segmenti di rete stessi. L'ANP consente di astrarsi dal livello fisico e, in sostanza, di rappresentare come organizzare l'interazione tra i vari segmenti della rete dal punto di vista dell'applicazione. <\/p>\n

    Il profilo dell'applicazione \u00e8 composto da gruppi di connessioni (End-point groups \u2013 EPG). Un gruppo di connessioni \u00e8 un gruppo logico di host (macchine virtuali, server fisici, contenitori, ecc.) che si trovano nello stesso segmento di sicurezza (non di rete, ma di sicurezza specifica). Gli host finali che appartengono a un determinato EPG possono essere definiti secondo numerosi criteri. Di solito si utilizzano i seguenti: <\/p>\n