Disponiamo di 2 switch Nexus 5010 (SW-A e SW-B) e due fabric extender Nexus 2148T (FEX-A e FEX-B). Attualmente, FEX-A è collegato a SW-A e FEX-B a SW-B. L'obiettivo è di collegare quasi tutti i server o dispositivi di storage a un FEX su un diverso switch Nexus 5000 per la ridondanza dei percorsi.
Ho guardato attraverso "Cisco Nexus 2000 Guida alla configurazione del software FEX Series Fabric Extender, versione 4.1", in particolare la sezione "Aggiornamento del Fabric Extender in una topologia vPC" alle pagine 21-22 per provare a scoprire cosa succede se un FEX è dual-homed su più switch.
Capisco che se uno o più FEX sono collegati a un singolo switch, quando il firmware di quello switch viene aggiornato, tutti i FEX collegati si riavvieranno insieme allo switch. Quello che non riesco a determinare con certezza è se eseguo il dual-home di entrambi i FEX su entrambi gli switch Nexus 5010: è possibile aggiornare/riavviare uno switch alla volta senza riavviare tutti i FEX contemporaneamente? Se il dual-home dei FEX significa che tutti i FEX si riavvieranno contemporaneamente, questo vanifica l'utilità di percorsi di rete multipli verso i server collegati.
Rispondi Discussione
Ci sono due considerazioni importanti da tenere a mente quando si scollega o si esegue il dual-homing di un singolo N2K FEX su N5K distinti per garantire resilienza: in primo luogo, è possibile supportare un massimo di 12 FEX. Pertanto, la connettività dipende dal progetto Top-Of-Rack e dall'effettiva densità di porte che si desidera ottenere. Ad esempio, se ciascuno dei 12 N2K è collegato a due N5K distinti, il limite è di sole 12 * 48 porte (poiché ogni N5K è associato a 12 N2K, anche se si tratta in realtà dello stesso switch).
La resilienza dipende dalla funzionalità dell'host, dalla sua configurazione attiva/attiva o attiva/standby, poiché questo determinerà in ultima analisi la topologia della rete. Esistono essenzialmente due scenari di distribuzione, uno per ciascuna modalità di host finale:
L'immagine sopra illustra lo scenario di distribuzione in cui è richiesto un protocollo active-active per l'host finale. Questa progettazione offre due vantaggi: il primo è che ogni N5K può supportare 12 N2K (576 porte) in quanto completamente indipendenti, fatta eccezione per il fatto che l'host finale è configurato all'interno della stessa vPC per ottenere il protocollo active-active sull'host, che rappresenta il secondo vantaggio. Sebbene gli N2K non siano collegati in modo ridondante agli altri N5K, ogni N2K può essere connesso con un massimo di 4 interfacce da 10 Gb in un singolo Port-Channel e, anche se l'intero PO e la connettività venissero persi dall'N2K in quel caso, l'host finale sarebbe comunque connesso e inoltrerebbe tramite la NIC connessa all'altro N2K, che a sua volta è connesso a un diverso Peer-Switch N5K.
La nota importante qui è che la modalità attivo-attivo non è supportata quando ogni N2K sarebbe connesso all'altro Peer-Switch N5K come illustrato di seguito:
In questo scenario, l'host finale è configurato per active-standby e ogni N2K può essere in dual-home con l'altro N5K. Pertanto, è necessario considerare come si intende distribuire gli host finali e il design Top-Of-Rack. Sì, l'active-standby offre resilienza in caso di perdita di un uplink verso uno switch peer N5K, tuttavia questo non costituirebbe un problema se fossero configurati all'interno di un Port-Channel. Se si perdesse tutto l'uplink, l'N2K si disattiverebbe e la NIC di standby dovrebbe quindi inoltrare in caso di guasto del collegamento dell'attivo. Lo svantaggio in questo caso è che si limita la connessione di soli 12 N2K in totale su entrambi gli N5K e si è inoltre tenuti a configurare le interfacce active e standby su entrambi gli N5K. Mi spiego: l'interfaccia active è su Eth100/1/1, questa interfaccia esisterebbe effettivamente su entrambi gli N5K, quindi se si modificassero le caratteristiche di una porta, si dovrebbero modificare su entrambi gli N5K; se fossero diverse, l'interfaccia rimarrebbe inattiva.
In risposta alla tua domanda, se i tuoi N2K sono dual-homed come sopra, in sostanza, quando NX-OS viene aggiornato sull'N5K, ogni N2K connesso verrà effettivamente aggiornato di conseguenza. Questo è particolarmente difficile da gestire se sono connessi all'interno di una vPC in cui entrambi gli uplink sono un canale logico; senza vPC è necessario STP. In questa situazione, qualsiasi N5K che lo scopra, l'N2K assume per primo il controllo e l'interfaccia è disponibile; tuttavia, l'altro N5K non sarebbe in grado di gestire queste interfacce finché l'uplink verso l'altro N5K non viene perso. Quindi è possibile isolare l'N2K, ma non è consigliabile, e poiché vPC è diventato disponibile nella versione 4.1.3, si consiglia di aggregare i link ed evitare STP.
Per ridurre al minimo i tempi di inattività durante un aggiornamento, la modalità attivo-attivo consentirà di aggiornare un singolo N5K e di influire solo sugli N2K connessi localmente. La connettività verrà comunque garantita tramite l'interfaccia attiva rimanente sull'host, tramite l'altro N5K.
Informazioni da https://supportforums.cisco.com/t5/lan-switching-and-routing/nexus-5000-switches-nexus-2000-fex-and-multiple-links/td-p/1407824
Più correlati
Caratteristiche dei modelli Cisco Nexus 5500 e Nexus 5600
Opzioni di licenza per Cisco Nexus 5500 e Nexus 5600
Licenze basate sulle funzionalità per le serie Cisco Nexus 5000, Nexus 5500 e Nexus 5600