I TOPI, ELEFANTI E SWITCH VIRTUALI

I topi ed elefanti è un QoS tradizionali favola - traffico in tempo reale sensibile alla latenza (o protocollo di richiesta-risposta come HTTP) bloccato nella stessa coda dietro megabyte di trasferimento di file (o di backup o iSCSI) il traffico.

La soluzione è anche ben noto - colorare il elefanti rosa (aka DSCP) e ordinarli in una coda diversa - fino a quando la realtà interviene.

Sembra oh-così-impossibile capire quali applicazioni possono generare flussi di elefante e segnare di conseguenza sul server di origine; non c'è altro modo per spiegare la necessità di classificazione del traffico e la marcatura sull'interruttore ingresso, e altri aggeggi MacGyver la squadra messa in rete utilizza per assicurarsi che "non è colpa della rete" invece di dire " noi siamo un programma di utilità - che stai ricevendo esattamente quello che hai chiesto. "

TCP e UDP numeri di porta sul server di corrispondenza (perché le sessioni FTP tendono ad essere più elefantiaco di richieste DNS) e impostare valori DSCP dei pacchetti in uscitaè anche, ovviamente, una missione impossibile per alcune persone; è modo più facile far finta che il problema non esiste e la colpa la rete per mancanza di una corretta classificazione del traffico.

Bisogna chiedersi quanto bene la recente ondata di soluzione di networking application-aware passeranno se le squadre di server / applicazione non può essere preso la briga di raccontare la rete che tipo di traffico è di fronte impostando un valore a un byte semplice in ogni pacchetto, ma cerchiamo di non andare lì.

In ogni caso, la situazione peggiora in ambienti con traffico davvero inclassificabile (come l'abominio ultimo immaginare una soluzione che fa i backup su HTTP), dove è impossibile elefante separato dai topi in base ai loro numeri di porta TCP / UDP.

Se, tuttavia, si avrebbe spaccato buffer TCP del sistema operativo, o misurare la frequenza per-flow, si potrebbe essere in grado di capire che scorre esporre le tendenze in sovrappeso - e questo è esattamente ciò che il team di Open switch virtuale (OVS) ha fatto .

Inoltre, OVS appare come un offload con capacità TCP NIC alle macchine virtuali e le applicazioni di massa felicemente discarica segmenti TCP megabyte di dimensioni direttamente nella coda di uscita del VM NIC, dove è facile per il software hypervisor sottostante (OVS) per individuarli e contrassegnarli con un valore DSCP diversa (questa idea è contrassegnato come sospeso nella presentazione di Martin Casado).

I risultati ( documentati in una presentazione ) non dovrebbe essere sorprendente - sappiamo ping non è influenzato da un trasferimento FTP in corso se capita di essere in diverse code fin dai tempi di Fred Baker orgogliosamente presentato i primi risultati di misurazione del poi-rivoluzionaria Weighted meccanismo Fair Queuing ( questa è l'unica presentazione che ho trovato, ma WFQ esisteva già alla fine del 1995 ), a un certo metà degli anni '90 incarnazione di Cisco Live (probabilmente anche prima dei giorni di Cisco Live è stato chiamato Networkers).

L'identificazione elefante basato OVS è una bella idea, anche se ci si deve chiedere come funziona in pratica se misura la portata di ogni flusso che passa attraverso uno switch virtuale (vedi anche OVS scala guai ).

Dire alla gente come impressionante è che gli interruttori Cumulus-powered reagiscono ai flussi di elefanti in hardware è puro marketing - ogni interruttore funziona bene quando di fronte a pacchetti adeguatamente segnalati. Chiamare marcatura "integrazione overlay-to-underlay" DSCP è anche fesserie (no, non voglio link alla fonte); abbiamo usato DSCP per decenni senza bisogno di nomi di fantasia.

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