FA CENTRALIZZATO CONTROL PLANE SENSO?

Un mio amico mi ha inviato una domanda provocatoria:

Hai dichiarato un paio di volte che non favoriscono la versione di OpenFlow SDN causa di una serie di problemi come il ridimensionamento e la latenza. Quale modello / meccanismo ti piace? Hybrid? Qualcos'altro?

Prima di rispondere alla domanda, facciamo un passo indietro e chiedere un altro: " Facentralizzato piano di controllo, come evangelizzata dall'ONF ?, dare un senso "

Un po 'di storia

Come sempre, cominciamo con uno dei più grandi maestri: la storia. Abbiamo avuto architetture centralizzate per decenni, da SNA a varie tecnologie WAN (SDH / SONET, Frame Relay e ATM). Tutti condividono un problema comune: quando le partizioni di rete, i nodi tagliati fuori dalla fermata intelligenza centrale funzionante (in caso SNA) o rimangono in uno stato congelato (tecnologie WAN).

Si potrebbe essere tentati di concludere che la versione ONF di SDN non se la passeranno meglio rispetto alle tecnologie WAN commutate. La realtà è molto peggio:

Tecnologie WAN avevano poca interazione control-plane con il mondo esterno (esempio: Frame Relay LMI), e queste interazioni sono stati eseguiti dai dispositivi locali, non dal piano di controllo centralizzato;

Dispositivi WAN (multiplexer SONET / SDH o ATM e switch Frame Relay) hanno funzionalità OAM locale che ha permesso loro di rilevare collegamenti o nodi guasti e di reindirizzare intorno a loro con percorsi di backup preconfigurati. Si potrebbe sostenere che questi dispositivi avevano piano di controllo locale, anche se non è mai indipendente come piani di controllo utilizzati nei router di oggi.

È interessante notare che, MPLS-TP vuole reinventare il passato glorioso e re-introdurre una gestione centralizzata percorso, RFC 1925 sezione 2.11 ancora una volta dimostrando.

L'ultima architettura (che ricordo) che utilizzava piano di controllo davvero centralizzato era SNA, e se sei abbastanza vecchio si sa bene che si è conclusa.

Sarebbe piano di controllo centrale senso nelle distribuzioni limitate?

Piano di controllo centrale è ovviamente un single point of failure, e partizionamento di rete è un incubo se si dispone di un punto di controllo centrale. Implementazioni su larga scala di variante ONF di SDN sono quindi fuori discussione. Ma ha senso distribuire piano di controllo centralizzato in isole minori indipendenti (reti di campus, data center zone disponibilità)?

È interessante notare, numerose architetture di data center utilizzano già piano di controllo centralizzato, in modo che possiamo analizzare quanto bene essi svolgono:

• Juniper XRE può controllare fino a quattro switch EX8200, per un totale di 512 porte 10GE;
• Nexus 7700 può controllare 64 estensori del tessuto con 3.072 porte, oltre a qualche centinaio di porte 10GE direttamente collegate;
• HP IRF può legare insieme due 12916 interruttori per un totale di 1.536 porte 10GE;
• QFabric Network Node Gruppo potrebbe controllare otto nodi, per un totale di 384 porte 10GE.

NEC ProgrammableFlow sembra essere un outlier - possono controllare fino a 200 switch, per un totale di oltre 9000 porte GE (non 10GE) ... ma non eseguire qualsiasi protocollo di controllo-aereo (a parte ARP e l'apprendimento MAC dinamico) con il mondo esterno.No STP, LACP, LLDP, BFD o protocolli di routing.

Si potrebbe obiettare che potremmo ottenere un ordine di grandezza al di là di quei numeri se solo usavamo adeguato hardware piano di controllo (CPU Xeon, per esempio).Io non compro questo argomento finché non ho fatto vedere una distribuzione di produzione, e di non tenere a mente che NEC ProgrammableFlow Controller utilizza decente hardware basato su Intel. Sistemi distribuiti in tempo reale con anelli di retroazione veloci sono molto più complesso di quanto la maggior parte delle persone che cercano da realizzare al di fuori (vedi anche RFC 1925, paragrafo 2.4).

Fa piano di controllo centrale ha senso?

Lo fa in alcuni ambienti di piccole dimensioni (vedi sopra) ... fino a quando si può garantire connettività ridondata tra allora controller e dispositivi controllati o non importa quello che succede dopo la perdita di collegamento (vedi anche i punti di accesso senza fili ). Ha senso per generare un enorme trambusto mentre reinventare questa particolare ruota? Vorrei trascorrere le mie energie a fare qualcos'altro.

Sono assolutamente a capire perché NEC è andato giù questo percorso - hanno fatto qualcosa di straordinario per differenziarsi in un mercato molto affollato. Capisco anche il motivo per cui Google ha deciso di utilizzare questo approccio , e perché evangelizzo tanto quanto fanno. Sto solo dicendo che non ha molto senso per il resto di noi.

Infine, tenere a mente che tutto il mondo dell'IT si sta muovendo verso architetture di scale-out. Netflix & Co sono già lì, e il mondo dell'impresa sta a malincuore facendo i primi passi. Nel frattempo, evangelisti OpenFlow parlano i meriti rivoluzionari incommensurabile di scala-up architettura centralizzata. Essi devono essere vive su un altro pianeta.

Corso Cisco - Corso CCNA - Corso Security - Corso CCNA Security - Certificazione Cisco - CCNA 200-120