Puncte:2

echilibrare a sarcinii pe un singur NIC pentru a depăși limita pe conexiune

drapel ru

Am o configurație ciudată în care ISP-ul oferă o conexiune foarte rapidă (10 Gbps), dar limitează fiecare conexiune la 50 Mbps. Acest lucru este în regulă pentru aplicațiile cu mai multe fire în care pot doar să măresc numărul de fire. Dar aș dori să rezolv această problemă și pentru aplicațiile cu un singur thread.Rulez Linux și acesta este tot traficul TCP (trebuie să fie) - simt că există o modalitate bună de a face asta folosind iptables, dar aceasta este puțin din profunzimea mea. Sunt limitat la o singură placă NIC pe dispozitiv. Există o modalitate de a realiza un echilibrator de încărcare care să creeze mai multe conexiuni pe aceeași NIC și apoi să împartă pachetele? (Practic, fac deja acest lucru în software pentru aplicații multithreaded.. dar vreau să o fac la nivel de sistem de operare).

problema rezolvata ceea ce s-a întâmplat nu a fost deloc limitat de ISP. Încercam să mă conectez la dispozitive care au o dimensiune fixă ​​a ferestrei TCP. schimbarea acelor dispozitive la dimensiunea ferestrei TCP dinamice a crescut debitul per conexiune la maximum. mai multe aici:

https://en.wikipedia.org/wiki/Bandwidth-delay_product

Nonny Moose avatar
drapel gb
Au spus de ce au făcut asta?
drapel ru
Acesta este un mediu găzduit - vă puteți accesa serverele prin internetul public pentru relativ ieftin. Dar organizația noastră a optat pentru fibre întunecate. De fapt, plătim pentru 10 Gbps. Deci pot obține 10 Gbps... cu un miliard de fire. Cred că ISP-ul nu și-a dat seama câți oameni ar opta pentru fibră întunecată, așa că au subprovizionat-o foarte mult... iar acum trebuie să limiteze viteza oamenilor pe bază de conexiune (fără a încălca limita de viteză totală pentru care am plătit-o. . asta este în contract). Toată chestia asta este foarte scumpă.. încercând să ne câștigăm banii :)
Puncte:2
drapel ru

Nu cred că are rost.

Desigur, puteți utiliza mai multe IP-uri sursă (fie de la mai multe gazde, mai multe NIC-uri sau chiar o singură NIC), dar din nou, probabil că le-ați NAT pe toate la adresa IPv4 publică pe care o aveți - deci nu există nicio diferență față de exteriorul. Poți la fel de bine să folosești mai multe fire.

Dar, evident, puteți încerca să legați mai multe adrese IP surse la un singur NIC, nu prea mult.

drapel ru
Mulțumesc pentru răspunsul rapid - voi încerca să creez o grămadă de IP-uri pe gazda mea (același NIC), apoi folosesc iptables pentru a le rotunji robin.. și apoi NAT la celălalt capăt (toate pe aceeași gazdă). Poate că acest lucru va păcăli cumva sistemul să creadă că sunt conexiuni separate. Nu sunt sigur CUM urmăresc.. dar poate fi exact aceeași sursă și exact aceeași destinație.. atâta timp cât este într-un fir diferit, are propria lățime de bandă!
Zac67 avatar
drapel ru
Probabil, mai multe filete / conexiuni prize sunt tot ceea ce aveți nevoie. Introducerea diferitelor adrese IP * înainte de * NAT nu poate face cu adevărat o diferență (cu excepția cazului în care acestea sunt necesare pentru ca aplicația să folosească ECMP).
Puncte:1
drapel br

Există două moduri în care acest lucru a fost limitat - pe bază de VM sau pe bază de vNIC. Dacă este pe o bază per VM, nu poți face nimic în afară de a amenința să te muți la un alt furnizor sau să muți efectiv furnizorii, evident că primul ar putea să nu funcționeze. Dacă este pe o bază de vNIC, atunci puteți fie să adăugați mai multe dvs., dacă este posibil, fie să cereți din nou furnizorului să le adauge și, din nou, dacă refuză, amenință cu plecarea.

În cele din urmă, aveți o nevoie de afaceri care pare că nu este satisfăcută de furnizorul dvs., așa că fiți pregătit să plătiți puțin mai mult pentru a obține ceea ce aveți nevoie.

drapel ru
Mulțumesc mult pentru răspunsul rapid - cu siguranță este chiar ciudat. Ei urmăresc cumva fiecare conexiune și apoi o limitează - dar nu le pasă dacă sursa și destinația sunt complet identice. Codul meu multi-threaded face literalmente același lucru în paralel (aceeași sursă, aceeași destinație - în acest caz prin HTTPS, dar am încercat altele și nu contează). Cred că mă întreb dacă există o modalitate de a abstractiza acest lucru la nivelul sistemului de operare, astfel încât fiecare conexiune TCP să se transforme în... să zicem... 50 dintre ele... spre deosebire de a trebui să reutilizeze fiecare bucată de software pentru a face asta. intern.
drapel ru
Spuse diferit.. nu este pe o bază per VM sau pe o bază de vNIC... cu siguranță este pe o bază per conexiune... Nu sunt sigur CUM este urmărit acest lucru și dacă există o modalitate elegantă de a ocolește-l : ) Ne este garantată o anumită viteză (este fibră întunecată).. vezi comentariul meu la celălalt poster de mai sus.. dar ne limitează viteza pe conexiune cred că pentru a evita aglomerația. Am testat exact aceeași configurație cu un ISP diferit care nu limitează firele (avem ISP redundanți.. centre de date redundante..etc) și este de 50 de ori mai rapid pe fir.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.