Bloguri AntiCisco - Arhiva blog - Nexus 1000v
bloguri de tehnologie și hardware Cisco de la instructori
Nexus 1000v
Postat de Minorioo pe 7 mai 2014
În conversația de astăzi cu dvs., vom vorbi despre comutatorul virtual Cisco, care servește ca înlocuitor pentru VMware dSwitch - Nexus1Kv.
N1K este o mașină virtuală care poate rula sub toți cei mai importanți supraveghetori de astăzi: ESX/ESXi, Hyper-V, Xen.
Componentele comutatoare
Comutatorul este format din două componente principale:
— Modulul de supraveghere virtuală (VSM)
— Modulul Ethernet virtual (VEM)
VSM oferă funcții ale planului de control și management, în timp ce VEM oferă plan de date.
Pentru a înțelege pe deplin cum funcționează comutatorul, mai întâi trebuie să fiți familiarizați cu arhitectura VmWare.
Infrastructura de bază de rețea VMware
O rețea virtuală VmWare constă din interfețe de rețea virtuală (vNIC-uri), plăci de rețea fizice (pNIC-uri sau doar NIC-uri) și switch-uri virtuale pentru a le conecta între ele.
Fiecare mașină virtuală are unul sau mai multe vNIC-uri (asta vedeți în conexiunile de rețea). Aceste vNIC-uri sunt conectate la un comutator virtual (vSwitch - de exemplu, Cisco Nexus 1000v). Conexiunea este implementată printr-un mecanism cunoscut sub numele de Port Group. Fiecare portgroup definește un vlan sau un set de vlan-uri care vor fi disponibile pentru vNIC. De asemenea, puteți defini parametri suplimentari în grupul de porturi, cum ar fi limitarea ratei, securitatea porturilor, QoS. Portgroup-ul este legat de mașina virtuală în stadiul creării sale (cel mai adesea).
Figurile de mai jos arată cum arată adăugarea unui grup de porturi la o mașină virtuală în interfața vSphere și logica conexiunii.
Arhitectură Nexus 1000v
Modul de supraveghere virtuală
După cum sa menționat deja, VSM oferă funcții ale planului de management. Tratați VSM-ul în același mod în care ați face un supervizor normal într-un comutator fizic (de exemplu, 2T pe Catalyst6500). Singura diferență este faptul că funcțiile de supraveghere N7K/Cat6K sunt codificate în hardware, dar aici VSM este fie o mașină virtuală separată, fie un blade virtual pe platforma hardware Cisco Nexus 1010. Sub ESX, VSM este instalat ca o mașină virtuală obișnuită, cel mai adesea folosind OVF (Open Virtualization Format) sau un fișier ISO. După instalarea N1K, veți vedea interfața familiară a lui NX-OS J
Pentru funcționarea normală, VSM necesită trei vNIC-uri, fiecare dintre ele va îndeplini o funcție specifică.
Notă. vNIC necesită driver Intel E1000 pentru a funcționa
Interfață de gestionare
Interfața de gestionare este vizibilă pe comutator ca portul mgmt0. Folosit pentru a stabili comunicarea între VSM și VMware vCenter. Interfața este numerotată ca „Network Adapter 2” în proprietățile mașinii virtuale.
Interfață de control
Interfața de control este folosită pentru a comunica cu modulele VEM în modul L2 al comutatorului (ce este și cum diferă de L3 va fi discutat mai târziu). Interfața este folosită și pentru VSM High-Availability. Interfața este numerotată ca „Adaptor de rețea 1”.
Interfață de pachete
Interfața Packet este folosită pentru a transporta pachete care trebuie procesate de VSM. Practic, există două tipuri de pachete: CDP și IGMP.
ID domeniu
Un comutator fizic clasic trece informațiile planului de control de la portul ASIC de pe CPU prin magistrala internă. Acest autobuz este izolat de lumea exterioară în mod implicit. În cazul infrastructurii virtuale, pachetele de plan de control de la VEM la VSMtransmise pe mediile fizice. Teoretic, s-ar putea întâmpla ca, din cauza unei erori de administrator, VEM-ul să primească un cadru de control de la VSM care se referă la un comutator complet diferit de 1000v. Dacă VEM răspunde la un astfel de pachet, atunci nu îl va putea procesa corect. Pentru a preveni un astfel de scenariu, este utilizat parametrul Domain ID. Fiecare comandă trimisă de VSM este etichetată cu acest ID. Dacă VSM și VEM partajează același ID de domeniu, atunci VEM va accepta această comandă. În caz contrar, va fi aruncat.
Modul Ethernet virtual
VEM este analog cu o placă de linie într-un comutator fizic. Cu toate acestea, în același timp, fiecare VEM este un comutator separat în ceea ce privește comutarea traficului.
VEM are o integrare foarte profundă cu ESXi: este instalat ca componentă a nucleului. Resursele care sunt alocate sub VEM nu sunt gestionate - în funcție de configurație, RAM este alocată dinamic. Într-o implementare tipică, intervalul de utilizare a RAM este între 10 și 50 MB (limită superioară absolută de 150 MB). Numărul maxim de VEM pentru o pereche de VSM de failover este 64.
Comutați interfețele
Nexus 1000v acceptă mai multe tipuri de interfețe: Ethernet virtual (vEth), Ethernet (Eth) și Port-Channel (Po). Dacă totul ar trebui să fie clar cu Eth și Po clasice, atunci ne vom opri asupra vEth mai detaliat.
vEth este un port care se conectează la vNIC-ul mașinii virtuale. Aș dori să mă opresc puțin asupra schemei de denumire pentru interfețele virtuale. Tu și cu mine suntem obișnuiți cu faptul că interfețele arată ca FaX / Y, unde X este numărul slotului switch-ului și Y este numărul portului. Interfețele vEth sunt marcate ca vEthZ, unde Z este un număr de serie care nu depinde de undeVEM localizat fizic. Acest lucru a fost făcut pentru o integrare transparentă cu VMware VMotion.
Fiecare vEth este asociat static cu un anumit vNIC și există doar atâta timp cât există mașina virtuală corespunzătoare.
Transferul cadrului și protecția buclei
De asemenea, Nexus 1000v nu acceptă Spanning-Tree. Pentru a preveni buclele, se folosește un algoritm ușor diferit. Și anume: fiecare cadru de intrare este verificat pe interfața fizică Eth. Dacă sursa MAC este intern VEM, atunci cadrul este abandonat. Dacă MAC-ul de destinație este extern, atunci cadrul este abandonat.
Interacțiunea dintre VEM și VSM
Transferul de date între VEM și VSM poate avea loc fie pe L2, fie pe L3. Modul recomandat este L3.
În cazul modului de operare L3, interacțiunea dintre VEM și VSM poate avea loc fie prin interfața de control, fie prin management. Pentru a configura, introduceți comanda(config-svs-domain)#svs mode interfață L3 [mgmt0control0]
După aplicarea acestei comenzi, toate cadrele de control încep să fie încapsulate în UDP.
De ce se recomandă implementarea modului L3? L3 este mult mai ușor de depanat în cazul oricăror probleme (la fel cum este mai ușor pentru noi să depanăm IGP decât orice problemă L2) datorită aplicațiilor standard precum ping, traceroute etc. De asemenea, în cazul L2, toate VEM-urile și VSM-urile trebuie să fie în același vlan, ceea ce nu este întotdeauna convenabil.
Notă. Dar, în orice caz, indiferent de metoda de comunicare între modulele comutatoare, Nexus 1000v este configurat ca un dispozitiv NX-OS obișnuit.
Pentru a monitoriza VEM-urile, bătăile auzului sunt utilizate cu o frecvență de 1 secundă și un timp de reținere de 6 secunde. Toate comunicațiile dintre ele sunt criptate folosind AES-128.
Configurare
Aici suntNu voi da nicio setare de tehnologie anume. Aș vrea să mă opresc asupra altceva. Într-o situație standard (când avem un comutator fizic), folosim setări bazate pe porturi. De asemenea, folosește o tehnologie numită profile port. Profilurile sunt create pe VSM și apoi distribuite către vCenter ca grupuri de porturi. După ce profilul ajunge la vCenter, administratorul îl poate atribui vNIC-ului mașinii virtuale. Fii atent, pentru că Există două tipuri de profiluri: Ethernet și vEthernet. Pentru aplicare pe link-uri fizice sau virtuale, respectiv.
Mai jos voi da un exemplu de configurare a profilului și o descriere a ceea ce face:
Rămâne să ne ocupăm de diverse considerații de design, dar aceasta este o cu totul altă poveste.