TL;DR Negocierea automată a fost dezactivată pe comutatorul meu și avea setări recomandate de producător pentru o conexiune 40G. Activarea negocierii automate a rezolvat problema.
Vreau să-mi răspund la întrebarea mea cu detalii din aventura mea pe această cale de a obține configurarea rețelei mele de 40 gigabit. În acest fel oricine altcineva care încearcă acest lucru în viitor are câteva puncte de referință.
Cred că este important să rețineți că am folosit NIC 40G în modul Ethernet, nu Infiniband. Driverele Ethernet păreau să funcționeze, dar am terminat cu driverele OFED pentru că a funcționat, nu am vrut să mă mai încurc cu ele. Dacă intenționați să obțineți o astfel de configurație, a te asigura cardul dvs. este capabil de modul Ethernet!
Ce am încercat
Odată ce am primit comutatorul, NIC-urile și cablurile, am instalat driverele/software-ul OFED (OpenFabrics Enterprise Distribution) furnizate de Mellanox/Nvidia. Odată ce aceștia nu au reușit să stabilească o legătură, am folosit instrumentele încorporate în software pentru a-și actualiza firmware-ul. A fost destul de simplu, singura problemă pe care am avut-o a fost să găsesc cel mai recent fișier firmware .bin pentru cardurile mele specifice. Firmware-ul pe care l-am folosit a fost 2.33.5000, încă destul de vechi, dar mai nou decât ceea ce era pe carduri.
După ce a eșuat, am presupus că cablurile/transceiver-urile (o unitate) sunt vinovați. Am schimbat cablurile primite inițial cu o pereche (56G 10m AOC + 56G 2m DAC > 40G 11m AOC + 40G 1m DAC) de cabluri personalizate care au fost proiectate pentru comutatorul Mikrotik specific pe care îl cumpărasem. Deoarece acestea au fost personalizate, au durat o lună să ajungă. Odată ce acestea au sosit și nu au funcționat, am rămas nedumerit și am început să caut ajutor pe diferite forumuri. În scurt timp mi s-a sugerat cumpara un instrument de la FS.com, care mi-ar permite să recodesc furnizorul pe transceiver-uri pentru a păcăli NIC-ul să funcționeze.
Deoarece cablurile au fost personalizate pentru comutator, am presupus că NIC-ul nu a cooperat. Setarea transceiver-ului fie la IBM sau Mellanox nu a funcționat.După ce au căutat asistență suplimentară, câțiva oameni mi-au sugerat să găsesc documentație despre NIC-urile și să găsesc cabluri/transceiver compatibile. Am găsit un PDF (deși nu este furnizat sau realizat de IBM/Mellanox) care enumera câteva numere de piese compatibile pe care FS.com le-a furnizat. Așa că am achiziționat IBM 49Y7890 1m DAC de la FS.com.
Odată ce a ajuns, am descoperit că nici aceasta nu era soluția. Din disperare, am găsit câteva fire de oameni care și-au trimis cardurile la firmware-ul Mellanox adevărat. Am decis să-mi încerc mâna. După câteva depanări privind funcționarea programului de actualizare, am actualizat cu succes versiunea de firmware 2.42.5000 cu noul PSID MT_1100120019 (consultați „Acesta nu a fost sfârșitul” paragraful 4 pentru detalii despre cum acest lucru poate încurca lucrurile. Vezi aici cum să încrucișezi blițul). După ce această încercare a eșuat, au avut loc discuții suplimentare pe această temă și, în cele din urmă, au ajuns la concluzia că ar trebui să testez NIC-urile conectate direct între ele. Odată ce am conectat NIC-urile și le-am configurat subrețeaua, am văzut viteze de 36,5 GBit/s folosind mai multe teste iperf (deoarece iperf și iperf3 sunt cu un singur thread, va trebui să configurați mai multe pentru aceste viteze. Am configurat 16 pentru fiecare set pentru a utiliza 10 fire). Odată ce am eliminat NIC-urile din lista de vinovați, am început să mă întreb dacă setarea de auto-negociere de pe comutator ar fi fost o problemă. Pornind-o din nou, am văzut imediat „link ok”.
Acesta nu a fost sfârșitul
Am pus configurarea să funcționeze, s-a dovedit că nu a existat nicio problemă de compatibilitate și probabil că nu am avut niciodată nevoie să-mi schimb cablurile sau să-l cumpăr pe cel IBM. Eram extaziat, dar asta era departe de a se termina. Intenționam să rulez această configurare cu Proxmox pe serverul meu și Windows ca mașină client. Ambele sisteme ar fi echipate cu 40G.
Din moment ce știam că voi da peste cap instalarea Proxmox de mai multe ori, am făcut mai întâi o copie de rezervă pe o altă unitate. Odată terminat, am procedat la instalarea driverelor Mellanox OFED pe Proxmox.Există câteva probleme în încercarea acestui lucru, driverele OFED încearcă să elimine pachetele foarte critice din Proxmox, deoarece „interferează” cu driverele (nu o fac). Așa că am editat scriptul mlnxofedinstaller și am comentat toate apelurile la funcția „remove_old_packages”. Acest lucru a împiedicat instalatorul să facă Proxmox o lobotomie.
În acest moment, majoritatea lucrurilor au funcționat, singura problemă pe care o aveam a fost trimiterea datelor către server. Nu accepta mai mult de câțiva megaocteți pe secundă, cu mult mai puțin decât ar trebui să primesc. Am încercat multe versiuni diferite ale software-ului, încercând Ubuntu 20.04, 19.XX nu a funcționat din cauza dependențelor pe care Proxmox nu le are, dar cele două instalări au. Am fost forțat să instalez drivere Ubuntu 18.04, deoarece acestea erau cele mai recente drivere fără probleme de dependență. Instalarea driverelor de obicei nu a rezolvat problema vitezei. Așa că am încercat să instalez pachetele kernel numai folosind --doar kernel flag pe programul de instalare. La un moment dat am obținut vitezele pe care le căutam, dar asta a fost o întâmplare, deoarece nu am putut să le reproduc mai târziu. Am decis să încerc câteva variante ale driverelor Debian 10, am avut viteze ceva mai bune la 20 MB/s. După ceva timp, am dat idei de la altcineva, am încercat să setez rețeaua 40G la 9000 MTU. Acest lucru a dus la niște rezultate foarte ciudate. Viteze de abia 1 gigabit, chiar dacă întreaga configurație avea MTU de 9000. L-am trecut înapoi la 1500 pentru a face teste suplimentare pe Ubuntu în loc de Proxmox, deoarece aveam viteze bune pe Ubuntu. Acest lucru nu a reușit să treacă, testele de viteză pe care le-am făcut inițial trebuie să fi fost o întâmplare.
Am decis să schimb NIC-urile din sisteme, etichetându-le cu 1 și 2 după ce le-am scos, astfel încât să nu le încurc. După ce au efectuat mai multe teste de viteză, sa dovedit că cardul din sistemul Proxmox a fost problema. Am reușit să trimit la viteză maximă, dar nu am putut să primesc la viteză maximă. Mi-am amintit driverele care actualizau firmware-ul pe acel NIC și nu m-am gândit prea mult la asta, deoarece foloseam cea mai recentă versiune.Așa că am re-flashed versiunea încrucișată pe care o instalasem inițial. După teste suplimentare, am ajuns la concluzia că vitezele limitate de 22 GBit/s în sus și 11 GBit/s în jos au fost rezultatul diferitelor gâturi de sticlă între sisteme. Testând în mod specific pe discuri RAM cu un fișier de 30 de gibibyte, am ajuns la concluzia că serverul cu DIMM-uri de două ori populate a putut scrie cu o viteză de două ori mai mare. Încercarea de a utiliza NVMe cu un sistem de fișiere NTFS pe sistemul de testare a funcționat prost din cauza stratului de compatibilitate cu un singur fir. După ce au mai rulat o duzină de teste iperf, totul a funcționat fără probleme, chiar și cu serverul care rula Proxmox.
O avertizare când utilizați driverele OFED, veți pierde capacitatea de a vă conecta la partajări de rețea CIFS. Driverele OFED descarcă acest modul până când driverul nu mai rulează. Driverele Ethernet funcționează, dar poate fi necesar să treceți flash cu firmware-ul mellanox.
Traseul înainte
Deoarece aveam un buget de aproximativ 1.500 de dolari, a trebuit să merg cu unele dintre cele mai ieftine echipamente pe care le-am putut găsi. De aici și cardurile de rețea de 60 USD. Când am găsit acest comutator Mikrotik nou pentru 500 USD, am fost încântat. Avea tot ce aveam nevoie la cel mai bun preț pe care l-am putut găsi, chiar depășind unele unități uzate. Nu avea licență de port și a venit cu una dintre licențele software de nivel superior. A fost într-adevăr o afacere greu de învins. Desigur, totul vine cu compromisuri.
Chiar dacă nu intenționam să folosesc porturile 10G SFP+, le doream pentru extinderea viitoare. Am primit un adaptor SFP+ la RJ45 și un NIC 10G, așa că aveam ceva de testat în timp ce echipamentul 40G era în livrare. Am putut primi un total de 2 gigabiți pe secundă pe NIC 10G. Acestea erau toate datele pe care le puteam alimenta între conexiunea mea la internet de 1 gigabit și serverul meu echipat cu 1 gigabit. Dar încercarea de a rula o încărcare gigabit pe internet de pe cardul 10G, rezultând viteze mult mai mici decât mă așteptam. Obțineam doar aproximativ 300 Mbps, în ciuda faptului că puteam atinge 900 Mbps în mod destul de fiabil.Am continuat să întreb și teoria comutatorului care nu are dimensiunea tamponului pentru a reduce 10G la 1G a fost concluzia. Această teorie este promovată prin comutarea legăturii în sus 1G a routerului meu la portul 10G și încercarea de a încărca la gigabit dintr-un sistem 40G (doar o scădere de 4x, în loc de 10x) a scăzut vitezele la ~ 1mbps. Ceea ce sugerează că cele 48 de porturi 1G au un buffer partajat.
Aceasta nu este cu adevărat o problemă pentru computerul meu Windows, deoarece oricum nu încărc niciodată la acele viteze. Dar pentru serverul meu, aceasta este o afacere destul de mare. Dacă lățimea de bandă de încărcare este redusă la o treime, ar putea ajunge să fie o problemă reală. După ce am săpat în jurul unora, am descoperit că aș putea folosi valorile de rutare pentru a forța traficul fie prin NIC 40G, fie prin NIC 1G, în funcție de unde merge. Deși această soluție nu este 100% perfectă, încă funcționează destul de bine.
Folosind traseul -n comandă Pot să văd traseele mele curente. Scopul este de a modifica rutele, astfel încât 40G să fie preferat pentru conexiunile locale și 1G pentru conexiunile la internet. Cu cât este mai mare metrica pe traseu, cu atât este mai costisitor de utilizat, astfel încât sistemul va folosi ruta mai puțin costisitoare.
Proxmox este livrat cu ifupdown în mod implicit, este mai stabil și are mai multe funcții. Netplan poate adăuga rute, dar nu le poate elimina sau modifica. De asemenea, nu vă permite să rulați comenzi înainte, la sau după pornirea interfeței. Tu poate sa utilizați netplan, dar ar trebui să configurați un serviciu separat pentru a elimina/modifica rute suplimentare.
Acesta este curentul meu /etc/network/interfaces config, a trebuit să adaug comenzile post-up la NIC-urile mele pentru a adăuga rutele în;
auto ens18 # 1 Gigabit NIC
iface ens18 inet static
...
post-up /usr/sbin/route add -net 192.168.0.0/24 metric 1000 ens18
auto ens19 # 40 Gigabit NIC
iface ens19 inet static
...
post-up /usr/sbin/route add -net 0.0.0.0/0 gw 192.168.0.1 metric 1000 ens19
post-up /usr/sbin/route add -net 192.168.0.0/24 metric 1 ens19
post-up /usr/sbin/route del -net 192.168.0.0/24 metric 0 ens19
Rutele dvs. ar trebui să arate ca;
Tabelul de rutare IP kernel
Destination Gateway Genmask Flags Metric Ref Utilizare Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 1 0 0 ens18
0.0.0.0 192.168.0.1 0.0.0.0 UG 1000 0 0 ens19
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 ens19
192.168.0.0 0.0.0.0 255.255.255.0 U 1000 0 0 ens18
Evident, aceste interfețe vor trebui să fie pe IP-uri locale diferite, sugerez să utilizați IP-ul setat la NIC 40G pentru orice local. Dacă ceva trebuie să fie redirecționat, utilizați NIC-ul gigabit. Ar trebui să fie în regulă să utilizați NIC gigabit la nivel local, atâta timp cât nu trimiteți mai mult de 100 MB odată. Această rutare poate funcționa dacă trimiteți date locale de 40 gigabiți/s către IP-ul legat de portul gigabit, însă nu este întotdeauna consecvent.
Este important să rețineți că, dacă modificați o rută, ar trebui să adăugați versiunea modificată înainte de a elimina versiunea veche.
De asemenea, este important să rețineți că este posibil ca configurația dvs. să nu aibă nevoie de același lucru pe care l-am postat mai sus. De exemplu, instalarea mea Proxmox adaugă deja o rută pentru ens18, așa că ar trebui să o elimin după ce am adăugat cea dorită.
Si asta e! În sfârșit, mi-am finalizat configurarea cu vitezele pe care mi le-am dorit. Pot transfera pe serverul meu la aproximativ 1,7 GB/s și de la aproximativ 1 GB/s (limitarea fiind fie NTFS, fie unul dintre SSD-uri).
