mercoledì 4 giugno 2014

FCOE E NEXUS 1000V QOS

Uno dei miei lettori volevano implementare FCoE su UCS in combinazione con Nexus 1000V e chiese come FCoE impatto del traffico QoS su Nexus 1000v. Ha scritto:
Diciamo che voglio 4Gb per FCoE. Devo aggiungere azioni di banda fino al 60% nel nesso 1000v CBWFQ config in modo che il 40% sono nel default-classe come 1kv non è a conoscenza del traffico FCoE? O aggiungere fino al 100% con l'assunzione che la 1kv sa che c'è solo 6Gb canali via rete? Inoltre, sarà il Nexus 1000v in grado di rilevare contesa in uplink, anche se non vede il traffico FCoE?
Come sempre, le cose non sono così semplici come sembrano.

Background: adattatore FEX e FCoE

Gli adattatori Ethernet UCS implementare FCoE in hardware - il sistema operativo non lo sa si tratta di un singolo adattatore fisico con un unico set di uplink 10GE. Ogni adattatore 10GE ​​fisico appare come (almeno) due adattatori PCI: un 10GE ​​Ethernet NIC e un host Fibre Channel Bus Adapter (HBA).
Ogni adattatore 10GE attuazione FCoE in hardware è dotato di funzionalità NIC + HBA. Carte di Cisco adattatore (P81E o VIC1225) o adattatori di terze parti che supportano la tecnologia Cisco proprietaria VNTag (esempio: Broadcom BCM57810) consentono di fare un passo avanti e creare numerosi adattatori Ethernet dalla stessa scheda di rete fisica.
L'allocazione della larghezza di banda e la coda in uplink 10GE ​​fisica è nascosto dalle NIC presentati al sistema operativo. Il sistema operativo pensa che si tratta di interfacce multiple in piena regola 10GE/FC, e succede solo che le interfacce trasmettono pacchetti dall'hardware TX-ring più lento di quanto ci si aspetterebbe ... ma poi si potrebbe ottenere gli stessi risultati utilizzando frame PAUSE (o PFC ) su un'interfaccia 10GE ​​dedicato.

Uscita in coda su Nexus 1000v

Uscita in coda su Nexus 1000v funziona allo stesso modo di qualsiasi altra applicazione in uscita in coda: il driver di interfaccia accoda i pacchetti in uscita in hardware TX-ring fino a quando il TX-ring raggiunge una lunghezza prefissata, a questo punto il software di accodamento (CBWFQ) avvia.
Il driver di interfaccia non ha bisogno di conoscere l'esatta banda dell'interfaccia, tutto ciò che deve sapere è quando l'anello TX è inferiore al limite minimo (a cui i pacchetti dei punti sono levati dalla coda dalle code CBWFQ e spostate l'anello TX). Le percentuali banda specificata nel CBWFQ influenzano la relativa quantità di dati trasferiti da ciascuna coda singola classe; funzionano altrettanto bene indipendentemente dalla velocità di interfaccia fisica o il flusso effettivo.

Nessun commento:

Posta un commento

Nota. Solo i membri di questo blog possono postare un commento.