• Traducere

Măsurarea blocajelor de transfer prin timpul de trecere dublă a pachetelor

Din toate punctele de vedere, internetul de astăzi nu poate muta datele atât de repede cum ar trebui. Majoritatea utilizatorilor celulari din lume se confruntă cu întârzieri de la câteva secunde la câteva minute: publice Puncte WiFi este și mai rău la aeroporturi și conferințe. Fizicienii și climatologii trebuie să facă schimb de petabiți de date cu colegii din întreaga lume, dar constată că infrastructura lor elaborată multi-gigabit împinge adesea doar câțiva megabiți pe secundă pe legături transcontinentale.

Aceste probleme au apărut din alegerea arhitecturii care a fost făcută în timpul creării controlului congestiei TCP în anii 80 - atunci pierderea pachetelor a fost decisă ca interpretată ca „congestie”. Echivalența acestor concepte era adevărată pentru acea vreme, dar numai din cauza limitărilor tehnologiei, și nu prin definiție. Când NIC-urile (controlerele de interfață de rețea) au fost actualizate de la megabit la gigabit și cipurile de memorie de la kiloocteți la gigaocteți, relația dintre pierderea de pachete și congestie a devenit mai puțin evidentă.

În TCP modern, controlul congestiei pierderii de pachete - chiar și în cea mai avansată tehnologie de acest gen, CUBIC - este cauza principală a acestor probleme. Dacă tampoanele de blocaj sunt prea mari, controlul congestionării pierderii de pachete le menține pline, provocând tamponarea rețelei inutile. Dacă bufferele sunt prea mici, controlul congestionării pierderii de pachete va interpreta greșit pierderea de pachete ca un semnal de congestie, ducând la un debit redus. Rezolvarea acestor probleme necesită o alternativă la limitarea pierderii de pachete. Pentru a găsi această alternativă, trebuie să înțelegeți unde și cum apare congestia.

Congestie și blocaj

Există o singură legătură mai lentă pe o conexiune TCP (full duplex) la un moment dat sau blocajîn toate direcțiile. Blocajul este important din următoarele motive:

• Determină rata maximă de transfer de date pe conexiune. Aceasta este principala proprietate a unui flux de date necomprimat (de exemplu, imaginați-vă o autostradă cu șase benzi în timpul orei de vârf, dacă un accident face ca o mică porțiune a drumului să fie limitată la o singură bandă. Traficul din fața locului accidentului va nu vă deplasați mai repede decât traficul pe banda respectivă.
• Acesta este locul în care se formează în mod constant cozi. Acestea scad numai dacă intensitatea fluxului de ieșire din gâtul de sticlă depășește intensitatea fluxului de intrare. Pentru conexiunile care funcționează la cea mai mare rată de biți, toate fluxurile de ieșire către gâtul de sticlă au întotdeauna o rată de ieșire mai mare, astfel încât cozile se mută în gâtul de sticlă.

Indiferent de câte legături există în conexiune și care sunt vitezele lor individuale, din punctul de vedere al TCP, o rută arbitrar complexă este reprezentată ca o singură conexiune cu aceeași RTT (timpul de trecere dublă a pachetului, adică timp dus-întors) și lățimea de bandă a blocajului ... Două limitări fizice RTprop(timpul de propagare dus-întors) și BtlBw(lățimea de bandă a blocajului) afectează performanța transmisiei. (Dacă calea rețelei ar fi o conductă materială, RTprop ar fi lungimea conductei, iar BtlBw ar fi diametrul acesteia).

Figura 1 prezintă diferitele combinații de RTT și rata de biți cu cantitatea de date. în zbor, adică sub zbor (date trimise, dar fără confirmarea livrării). Liniile albastre arată limita RTprop, liniile verzi arată limita BtlBw, iar liniile roșii arată tamponul de blocaj. Operațiile în zonele gri nu sunt posibile, deoarece contrazic cel puțin o restricție. Tranzițiile dintre restricții au condus la formarea a trei regiuni (aplicație limitată, lățime de bandă limitată și tampon limitată) cu un comportament calitativ diferit.

Imaginea 1

Atunci când nu există suficiente date în zbor pentru a umple conducta, RTprop determină comportamentul; în caz contrar, BtlBw domină. Liniile limitative se intersectează într-un punct, care este și conducta BDP (produs de întârziere a lățimii de bandă, derivatul lățimii de bandă și întârziere). Deoarece conducta este plină după acest punct, excesul creează o coadă până la gâtuire, rezultând o relație liniară între datele RTT și datele de zbor, prezentate în graficul de sus. Pachetele sunt aruncate atunci când surplusul depășește capacitatea tamponului. Congestionare este doar o locație continuă în dreapta liniei BDP și controlul congestiei- un fel de schemă pentru stabilirea unei limite în ceea ce privește media transferului de date în dreapta liniei BDP.

Controlul congestiei pierderilor funcționează la marginea dreaptă a zonei cu lățime de bandă limitată, oferind lățime de bandă completă, în detrimentul latenței ridicate și a pierderii frecvente a pachetelor. În vremurile în care memoria era scumpă, dimensiunile bufferului erau doar puțin mai mari decât BDP, ceea ce minimiza latența excesivă a controlului congestiei cu pierderi. Reducerile ulterioare ale prețului memoriei au dus la o creștere a bufferului de rețea în exces și la o creștere a RTT la secunde în loc de milisecunde.

Există un punct de operare mai bun la marginea stângă a zonei cu capacitate limitată decât la dreapta. În 1979, Leonard Kleinrock a arătat că acest punct de operare este optim, maximizează debitul real minimizând în același timp latența și pierderile, atât pentru conexiunile individuale, cât și pentru rețea în ansamblu. Din păcate, în același timp, Jeffrey Yaffe a dovedit că este imposibil să se creeze un algoritm distribuit care converge în acest punct de operare. Această constatare a schimbat direcția cercetării. În loc să caute un algoritm distribuit care să caute punctul de operare Kleinrock optim, cercetătorii au început să exploreze abordări alternative de control al congestiei.

Grupul nostru de la Google petrece ore în fiecare zi examinând jurnalele de interceptare a antetului TCP din întreaga lume, înțelegând anomaliile și patologiile comportamentului. De obicei, primul lucru pe care îl căutăm este caracteristicile cheie ale traseului, RTprop și BtlBw. Faptul că pot fi deduse din urmele rețelei sugerează că concluzia lui Jaffe ar putea să nu fie la fel de neechivocă pe cât părea odată. Concluzia sa se bazează pe incertitudinea fundamentală de măsurare (de exemplu, dacă creșterea măsurată a RTT se datorează unei modificări a lungimii traseului, unei scăderi a capacității de blocare sau a unei creșteri a latenței cozii datorită traficului de la o altă conexiune). Deși este imposibil să se elimine incertitudinea fiecărei măsurători particulare, comportamentul compusului în timp oferă o imagine mai clară, sugerând posibilitatea aplicării unor strategii de măsurare concepute pentru a elimina incertitudinea.

Combinând aceste măsurători cu o buclă de urmărire fiabilă și aplicând cele mai recente progrese în sistemele de control, speranța este de a dezvolta un protocol de control al congestiei distribuite care să răspundă la congestia reală, mai degrabă decât pierderea pachetelor sau întârzierile scurte la coadă. Și va converge cu o probabilitate ridicată la punctul optim de operare Kleinrock. Astfel, a început proiectul nostru de trei ani de dezvoltare a unui sistem de gestionare a congestiei bazat pe măsurarea a doi parametri care caracterizează o rută: capacitatea de blocaj și timpul de trecere dublă a pachetelor sau BBR.

Caracteristica gâtului de sticlă

Conexiunea funcționează cu lățime de bandă maximă și latență minimă atunci când (echilibrul vitezei) rata de sosire a pachetelor la blocaj este BtlBw și (canal complet) cantitatea totală de date în zbor este egală cu BDP ().

Prima condiție asigură utilizarea blocajului 100%. Al doilea ne asigură că avem suficiente date pentru a preveni un blocaj simplu, dar nu pentru a revărsa canalul. Echilibrul vitezei în sine nu garantează că nu există coadă, ci doar dimensiunea sa neschimbată (de exemplu, dacă o conexiune începe cu trimiterea unei ferestre inițiale de 10 pachete către un BDP cu cinci pachete, atunci funcționează exact la aceeași viteză de blocaj, apoi cinci din zece pachete inițiale va umple canalul, iar surplusul va forma o coadă permanentă într-un loc îngust care nu se poate dizolva). La fel, o condiție de canal complet nu garantează că nu există coadă (de exemplu, o conexiune trimite BDP în rafale peste BDP / 2 și profită din plin de blocaj, dar coada medie este BDP / 4). Singura modalitate de a minimiza coada la blocaj și pe întregul canal este de a îndeplini ambele condiții în același timp.

Valorile BtlBw și RTprop se schimbă pe durata de viață a conexiunii, deci ar trebui să fie evaluate continuu. În prezent, TCP monitorizează RTT (intervalul de timp dintre trimiterea unui pachet de date către mesajul că a fost livrat), deoarece este necesar pentru a determina pierderea. La orice oră,

unde este „zgomotul” din cozile de-a lungul traseului, strategia destinatarului cu întârziere a confirmărilor, acumularea de confirmări și așa mai departe. RTprop este caracteristica fizică a legăturii și se schimbă numai atunci când canalul în sine se schimbă. Deoarece schimbările de canal au loc pe o scară de timp ≥ RTprop, atunci va fi o evaluare imparțială și eficientă a timpului
adică lansați într-o fereastră de timp (care este de obicei de zeci de secunde până la minute).

Spre deosebire de RTT, nimic din specificațiile TCP nu necesită o implementare pentru a urmări debitul de blocaj, dar o estimare bună a acestui lucru poate fi obținută din urmărirea ratelor de livrare. Când confirmarea de livrare a unui pachet este returnată expeditorului, acesta arată RTT-ul pachetului și anunță livrarea datelor în zbor la ieșirea pachetului. Viteza medie de livrare între trimiterea unui pachet și primirea unei confirmări este raportul dintre datele livrate și timpul scurs :. Această viteză trebuie să fie mai mică sau egală cu debitul blocajului (cantitatea la sosire este cunoscută exact, deci întreaga incertitudine constă în care trebuie să fie mai mare sau egală cu intervalul real de sosire; prin urmare, raportul trebuie să fie mai mic decât sau egală cu viteza reală de livrare, care, în coada sa, limitată de sus de capacitatea blocajului). Prin urmare, fereastra ratei maxime de livrare este o estimare eficientă, neparticulară a BtlBw:

unde fereastra de timp este de obicei de șase până la zece RTT-uri.

TCP trebuie să înregistreze ora la care a fost trimis fiecare pachet pentru a calcula RTT. BBR completează aceste înregistrări cu cantitatea totală de date livrate, astfel încât sosirea fiecărei confirmări să raporteze atât măsurarea RTT, cât și măsurarea ratei de livrare, pe care filtrele le traduc în estimările RTprop și BtlBw.

Rețineți că aceste valori sunt complet independente: RTprop se poate schimba (de exemplu, când se schimbă ruta), dar are același blocaj, sau BtlBw se poate schimba (de exemplu, când se schimbă lățimea de bandă fără fir) fără a schimba ruta. (Independența ambelor constrângeri este motivul pentru care acestea trebuie cunoscute pentru a asocia comportamentul de expediere cu ruta de livrare). Întrucât RTprop este vizibil numai pe partea stângă a BDP, iar BtlBw este vizibil doar pe partea dreaptă în Figura 1, ei respectă principiul incertitudinii: ori de câte ori una dintre cele două poate fi măsurată, cealaltă nu poate fi măsurată. Intuitiv, acest lucru poate fi înțeles după cum urmează: pentru a determina capacitatea unui canal, acesta trebuie supraumplut, ceea ce creează o coadă care nu face posibilă măsurarea lungimii canalului. De exemplu, o aplicație cu un protocol de solicitare / răspuns nu poate trimite niciodată suficiente date pentru a umple canalul și a observa BtlBw. Multe ore de transfer al unei cantități mari de date își pot petrece tot timpul într-o zonă cu lățime de bandă limitată și pot primi doar un singur eșantion RTprop de la RTT din primul pachet. Principiul inerent al incertitudinii înseamnă că, pe lângă estimările pentru reconstrucția celor doi parametri ai rutei, trebuie să existe stări care sunt urmărite simultan și ce pot fi învățate la punctul de operare curent și, pe măsură ce informațiile își pierd prospețimea, cum să mergeți la operație punctul în care poate fi obținut.date mai recente.

Potrivirea unui flux de pachete cu o cale de livrare

Algoritmul principal BBR are două părți:

Când primim confirmare (ack)

Fiecare confirmare oferă un nou RTT și măsurători ale ratei medii de livrare care actualizează estimările RTprop și BtlBw:

Funcție onAck (pachet) rtt = acum - packet.sendtime update_min_filter (RTpropFilter, rtt) livrat + = packet.size livrat timp = acum deliveryRate = (livrat - packet.delivered) / (livrat_time - packet.delivered_time) dacă (deliveryRate> BtlBwFilter. currentMax ||! packet.app_limited) update_max_filter (BtlBwFilter, deliveryRate) if (app_limited_until> 0) app_limited_until = app_limited_until - packet.size
Verificarea dacă este necesară din cauza problemei de ambiguitate discutată în ultimul paragraf: expeditorii pot fi restricționați de aplicație, adică aplicația poate rămâne fără date pentru a umple rețeaua. Aceasta este o situație destul de comună din cauza traficului de solicitare / răspuns. Când există posibilitatea de a trimite, dar nu sunt trimise date, BBR marchează mostrele de lățime de bandă corespunzătoare ca „aplicație limitată”, adică app_limited (vezi pseudocodul send ()). Acest cod determină ce tipare să includă în modelul lățimii de bandă, deci reflectă limitele rețelei, nu limitele aplicației. BtlBw este o limită superioară ridicată a ratei de livrare, deci o rată de livrare măsurată mai mare decât estimarea curentă a BtlBw ar trebui să însemne o estimare BtlBw subestimată, indiferent dacă eșantionul a fost sau nu restricționat la aplicare. În caz contrar, tiparele restricționate de aplicație sunt eliminate. (Figura 1 arată că în regiunea cu restricția aplicației deliveryRate, parametrul BtlBw este subestimat). Aceste verificări împiedică filtrul BtlBw să se umple cu valori subestimate, ceea ce ar putea încetini transmiterea datelor.

Când sunt trimise date

Pentru a corela rata de sosire a pachetelor cu rata de plecare de la blocaj, BBR monitorizează fiecare pachet de date. (BBR trebuie să se potrivească rată blocaj: Aceasta înseamnă că urmărirea este o parte integrantă a arhitecturii și o parte fundamentală a jobului - prin urmare ritm_impuls este principalul parametru de control. Parametru auxiliar cwnd_gain conectează zborul cu un set mic de BDP-uri pentru a gestiona patologiile tipice ale rețelei și destinatarilor (a se vedea capitolul despre confirmările întârziate și extinse de mai jos). Conceptual, o procedură de trimitere TCP arată ca următorul cod. (Pe Linux, trimiterea de date folosește o coadă de FQ / stimulare eficientă, ceea ce oferă BBR performanța liniară a unei singure conexiuni pe legături multi-gigabit și gestionează mii de conexiuni mai lente cu un procesor neglijabil.)

Funcția trimite (pachet) bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin if (inflight> = cwnd_gain × bdp) // așteptați ack sau retransmiterea expirarea returnării if (now> = nextSendTime) packet = nextPacketToSend () if (! Packet) app_limited_unt = return return packet.app_limited = (app_limited_until> 0) packet.sendtime = acum packet.delivered = livrat packet.delivered_time = livrat_ timp livrare (pachet) nextSendTime = acum + packet.size / (pacing_gain × BtlBwFilter.currentMax) timerCall nextSendTime)
Comportamentul stării de echilibru

Viteza și cantitatea de date trimise prin BBR depinde doar de BtlBw și RTprop, astfel încât filtrele controlează nu numai estimările de constrângere a blocajului, ci și aplicarea acestora. Aceasta creează o buclă de control personalizată descrisă în Figura 2, care arată RTT (albastru), zbor de zbor (verde) și rata de livrare (roșu) peste 700 ms pentru un flux de 10Mbit 40ms. Linia gri îngroșată deasupra ratei de livrare este starea filtrului BtlBw max. Formele triunghiulare se obțin aplicând ciclic coeficientul de stimulare_bain în BBR pentru a determina creșterea BtlBw. Câștigul din fiecare parte a ciclului este prezentat în aliniere în timp cu datele pe care le-a afectat. Acest factor a funcționat la RTT mai devreme când au fost trimise date. Acest lucru este demonstrat de nereguli orizontale în descrierea succesiunii evenimentelor din partea stângă.

Imaginea 2

BBR minimizează latența deoarece majoritatea timpului trece cu același BDP în acțiune. Datorită acestui fapt, blocajul se mută către expeditor, astfel încât creșterea BtlBw să devină invizibilă. Prin urmare, BBR petrece periodic intervalul RTprop la pacing_gain> 1, ceea ce crește viteza de trimitere și cantitatea de date trimise fără confirmarea livrării (zbor). Dacă BtlBw nu se modifică, atunci coada este creată în fața blocajului, mărind RTT, care menține livrarea constantă. (Coada poate fi eliminată prin trimiterea de date cu o valoare offset pacing_gain< 1 для следующего RTprop). Если BtlBw увеличивается, то скорость deliveryRate тоже увеличивается, а новое максимальное значение фильтра немедленно увеличивает базовую скорость отслеживания (ritm_impuls). Din acest motiv, BBR se adaptează rapid la noua dimensiune a blocajului. Figura 3 arată acest efect pe un flux de 10 Mbps 40 ms, pe care BtlBw îl crește brusc până la 20 Mbps după 20 de secunde de funcționare constantă (în partea stângă a graficului), apoi scade la 10 Mbps după alte 20 de secunde de funcționare susținută de 20 Mbps (partea dreaptă a graficului).

Figura 3

(Practic, BBR este un exemplu simplu de sistem de control „max-plus”, o nouă abordare a sistemelor de control bazate pe algebră non-standard max-plus. Această abordare permite adaptarea vitezei [controlată de raportul de transmisie) max] indiferent de creșterea cozii [controlată de raportul de transmisie in medie]. Aplicat problemei noastre, se reduce la o buclă de control simplă, necondiționată, în care adaptarea la modificările constrângerilor fizice se realizează automat prin schimbarea filtrelor care exprimă aceste constrângeri. Un sistem tradițional ar necesita crearea multor bucle de control combinate într-o mașină de stare complexă pentru a obține acest rezultat.)

Comportament la pornirea unui singur fir BBR

Implementările moderne gestionează evenimente precum pornirea, oprirea și recuperarea pierderilor cu algoritmi de „eveniment” cu o mulțime de linii de cod. BBR folosește codul de mai sus (în capitolul anterior „Potrivirea unui flux de pachete cu o cale de livrare”) pentru orice. Tratarea evenimentelor are loc prin parcurgerea unei secvențe de „stări”. „Stările” în sine sunt definite de un tabel cu una sau mai multe valori fixe ale coeficienților și criteriilor de ieșire. Majoritatea timpului este petrecut în starea ProbeBW, care este descrisă în capitolul Comportament de stare stabilă. Stările Startup și Drain sunt utilizate la pornirea conexiunii (Figura 4). Pentru a gestiona o conexiune în care randamentul crește cu 12 ordine de mărime, starea Startup implementează un algoritm de căutare binară pentru BtlBw, care folosește un factor de transmisie pentru a dubla rata de transmisie atunci când rata de livrare crește. Aceasta definește BtlBw în RTT, dar în același timp creează o coadă inutilă înainte. De îndată ce Startup-ul găsește BtlBw, sistemul BBR intră în starea Drain, care folosește rapoartele de transmisie inversă ale Startup-ului pentru a scăpa de coada excesivă și apoi în starea ProbeBW de îndată ce avionul coboară pe linia BDP.

Figura 4

Figura 4 prezintă prima secundă a unui flux BBR de 10Mbit 40ms. Graficul de sus arată ora și succesiunea evenimentelor, precum și progresul expeditorului (verde) și al destinatarului (albastru): cantitatea de date trimise și primite. Linia roșie arată performanța expeditorului folosind tehnologia CUBIC în aceleași condiții. Liniile verticale gri indică timpii de tranziție între stările BBR. Graficul de jos arată schimbarea timpului dus-întors (RTT) al ambelor conexiuni. Vă rugăm să rețineți că calendarul pentru acest program corespunde cu momentul primirii confirmării sosirii (ack). Prin urmare, poate părea că graficele par a fi schimbate în timp, dar de fapt evenimentele de mai jos corespund acelor momente în care sistemul BBR află despre aceste evenimente și reacționează.

Graficul de jos din Figura 4 compară BBR și CUBIC. La început, comportamentul lor este aproape același, dar BBR goleste complet coada formată la începutul conexiunii, iar CUBIC nu poate face acest lucru. Nu are un model de urmărire care să vă spună cât de multe dintre datele trimise sunt redundante. Prin urmare, CUBIC crește mai puțin agresiv transmiterea datelor fără confirmarea livrării, dar această creștere continuă până când bufferul de blocaj deversează și începe să scadă pachete sau până când receptorul atinge limita pentru datele trimise fără confirmare (fereastra de recepție TCP).

Figura 5 arată comportamentul RTT în primele opt secunde ale conexiunii descrise în Figura 4. Tehnologia CUBIC (în roșu) umple întregul buffer disponibil, apoi se rotește între 70% și 100% la fiecare câteva secunde. După ce conexiunea este pornită, BBR (verde) funcționează aproape fără a crea o coadă.

Figura 5

Comportament atunci când mai multe fluxuri BBR se întâlnesc într-un blocaj

Figura 6 arată cum debitul fluxurilor BBR multiple converge într-o secțiune onestă a unui blocaj de 100 megabiți / 10 milisecunde. Structurile triunghiulare orientate în jos sunt stări ale conexiunilor ProbeRTT în care autosincronizarea accelerează convergența finală.

Figura 6

Ciclurile de câștig ProbeBW (Figura 2) stimulează fluxuri mai mari pentru a oferi lățime de bandă fluxurilor mai mici, ca urmare a cărora fiecare flux își înțelege starea onestă. Acest lucru se întâmplă destul de repede (mai multe cicluri ProbeBW), deși nedreptatea poate persista dacă firele târzii la începutul redistribuirii supraestimează RTprop din cauza faptului că firele care au început mai devreme (temporar) creează o coadă.

Pentru a afla adevăratul RTProp, fluxul se deplasează spre stânga liniei BDP folosind starea ProbeRTT: dacă estimarea RTProp nu este actualizată (adică prin măsurarea unui RTT mai mic) timp de mai multe secunde, atunci BBR intră în starea ProbeRTT , reducând cantitatea de date trimise (zbor) la patru pachete pentru cel puțin o trecere dublă, și apoi revine la starea anterioară. Când fluxurile mari intră în starea ProbeRTT, multe pachete sunt eliminate din coadă, astfel încât mai multe fluxuri să vadă noua valoare RTprop (nou RTT minim) simultan. Datorită acestui fapt, estimările lor RTprop sunt resetate la zero în același timp, astfel încât să intre cu toții împreună în starea ProbeRTT - și coada scade și mai mult, ca urmare a faptului că și mai multe thread-uri văd noua valoare RTprop și așa mai departe . Această coordonare distribuită este un factor cheie atât în ​​corectitudinea lățimii de bandă, cât și în stabilitate.

BBR sincronizează fire în jurul evenimentului dorit, care este o coadă goală într-un blocaj. Spre deosebire de această abordare, limitarea congestiei pierderii de pachete sincronizează fluxurile în jurul evenimentelor nedorite, cum ar fi creșterea periodică a cozii și depășirile de tampon, ceea ce crește latența și pierderea de pachete.

Experiența implementării B4 WAN în Google

Google B4 este o rețea WAN de mare viteză (rețea de zonă largă) construită pe comutatoare convenționale, cu costuri reduse. Pierderile acestor comutatoare tampon de mică adâncime se datorează în principal creșterii ocazionale a unor mici explozii de trafic. În 2015, Google a început să mute traficul de la CUBIC la BBR. Nu au fost raportate probleme sau regresii și, din 2016, tot traficul B4 TCP folosește BBR. Figura 7 ilustrează un motiv pentru aceasta: debitul BBR este în mod constant de 2-25 ori mai mare decât CUBIC. Am văzut o îmbunătățire chiar mai mare, dar am constatat că 75% din conexiunile BBR sunt limitate de buffer-ul de recepție TCP în nucleu, pe care personalul operațiunilor de rețea l-a setat în mod deliberat la o valoare scăzută (8 MB) pentru a preveni inundarea rețelei de către CUBIC cu megabyți de trafic în exces fără confirmarea livrării (dacă împărțiți 8 MB la 200 ms de RTT intercontinental, obțineți maxim 335 Mbps). Creșterea manuală a bufferului de recepție pe o rută SUA-Europa a crescut instantaneu rata de date BBR la 2 Gbps, în timp ce CUBIC a rămas la 15 Mbps - o creștere relativă de 133 de ori a randamentului prevăzută de Matis și colegii din munca Science în 1997.

Figura 7

Figura 7 prezintă îmbunătățirea relativă a BBR față de CUBIC; inset - funcții de distribuție cumulative (CDF) pentru transfer. Măsurătorile au fost efectuate folosind serviciul de detectare activă, care deschide conexiuni permanente BBR și CUBIC către centre de date la distanță, apoi transferă 8 MB de date în fiecare minut. Sondele explorează multe rute B4 între America de Nord, Europa și Asia.

Îmbunătățirea uriașă este o consecință directă a BBR nu folosește pierderea de pachete ca indicator de congestie. Pentru a obține un randament complet, tehnicile existente de control al congestiei pierderilor de pachete necesită ca rata de pierdere să fie mai mică decât pătratul invers al BDP (de exemplu, mai puțin de o pierdere la 30 de milioane de pachete pentru o conexiune de 10 Gbps / 100 ms). Figura 8 compară debitul utilizabil măsurat la diferite niveluri de pierdere a pachetelor. În CUBIC, toleranța la pierderea pachetelor este o proprietate structurală a algoritmului, iar în BBR este un parametru de configurare. Pe măsură ce nivelul pierderii BBR se apropie de câștigul maxim de ProbeBW, probabilitatea de a măsura rata de livrare a BtlBw real scade brusc, ceea ce duce la o subestimare din partea filtrului max.

Figura 8

Figura 8 compară lățimea de bandă utilizabilă a BBR și CUBIC într-un flux de 60 de secunde pe o legătură de 100 Mbps și 100 ms cu pierderi aleatorii cuprinse între 0,001% și 50%. Debitul CUBIC este redus de 10 ori la o pierdere de 0,1% și se blochează complet cu mai mult de 1%. Lățimea de bandă maximă este fracția lățimii de bandă minus pierderea pachetului (). BBR se menține la acest nivel până la nivelul pierderilor de 5% și aproape de acesta până la 15%.

Experiență în implementarea YouTube Edge

BBR este implementat pe serverele video YouTube și Google.com. Google efectuează un mic experiment în care un procent mic de utilizatori sunt transferați accidental către BBR sau CUBIC. Redarea video BBR arată o îmbunătățire semnificativă a tuturor evaluărilor utilizatorilor pentru calitatea serviciilor. Poate pentru că comportamentul BBR este mai consistent și mai previzibil. BBR îmbunătățește ușor lățimea de bandă a conexiunii, deoarece YouTube adaptează deja rata de streaming la mult sub BtlBw pentru a minimiza tamponarea și re-tamponarea inutile a rețelei. Dar chiar și aici, BBR reduce mediana RTT cu 53% la nivel global și mai mult de 80% în țările în curs de dezvoltare.

Figura 9 arată îmbunătățirea mediană a RTT față de BBR și CUBIC peste 200 de milioane de vizionări video YouTube măsurate pe cinci continente pe parcursul unei săptămâni. Mai mult de jumătate din cele 7 miliarde de conexiuni mobile din lume sunt de 2,5G la 8Kbps până la 114Kbps, cu probleme bine documentate cu tehnicile de control al congestiei pierderii de pachete care tind să depășească tampoanele. Blocajul în aceste sisteme este de obicei între SGSN (Serving GPRS Support Node) și dispozitivul mobil. Software-ul SGSN rulează pe o platformă PC standard cu o memorie RAM amplă, adesea cu megabyți de tampon între internet și dispozitivul mobil. Figura 10 compară latența SGSN (emulată) între internet și mobil pentru BBR și CUBIC. Liniile orizontale marchează una dintre cele mai grave consecințe: TCP se adaptează la întârzierile RTT lungi, cu excepția pachetului SYN care inițiază conexiunea, care are un timeout fix, în funcție de sistemul de operare. Când un dispozitiv mobil primește o cantitate mare de date (de exemplu, de la actualizare automata software) prin SGSN cu un buffer mare, dispozitivul nu poate stabili nicio conexiune la Internet până când coada nu este gratuită (SYN ACK este întârziat mai mult decât expirarea SYN fixă).

Figura 9

Figura 10 prezintă modificările medii RTT la starea de echilibru și față de dimensiunea bufferului pe o conexiune de 128Kbps și 40ms cu opt fluxuri BBR (verde) sau CUBIC (roșu). BBR menține coada la valori minime, indiferent de dimensiunea bufferului de blocaj și de numărul de fire active. Fluxurile CUBIC umple întotdeauna bufferul, deci latența crește liniar cu dimensiunea bufferului.

Figura 10

Bandă adaptivă în telefonul mobil celular

Sistemele celulare adaptează lățimea de bandă pentru fiecare utilizator în parte pe baza previziunii cererii, care ia în considerare coada de pachete destinată acelui utilizator. Primele versiuni ale BBR au fost reglate pentru a crea cozi foarte mici, cauzând blocarea conexiunilor viteze mici... Creșterea valorii maxime a ritmului pentru ProbeBW și creșterea cozilor au dus la mai puține conexiuni blocate. Acest lucru arată o mare adaptabilitate pentru unele rețele. Cu valoarea curentă a câștigului de vârf, nu există degradare în nicio rețea în comparație cu CUBIC.

Pachete ack întârziate și întinse

Rețelele celulare, WiFi și de bandă largă întârzie și acumulează pachete ACK. Când zborul este limitat la un singur BDP, acesta provoacă tarabe, reducând lățimea de bandă. Creșterea factorului cwnd_gain ProbeBW la doi a permis transmiterea lină să continue la rata de livrare prevăzută, chiar și atunci când pachetele ack au fost întârziate cu până la un RTT. Acest lucru previne în mare măsură defecțiunile.

Limitatori de cupă curenți

Lansarea inițială a BBR către YouTube a arătat că majoritatea furnizorilor de servicii Internet din lume înclină traficul cu limitatoarele actuale ale ratei cupei. Bucket-ul este de obicei plin la începutul conexiunii, deci BBR recunoaște parametrul BtlBw pentru rețeaua de bază. Dar de îndată ce cupa este goală, toate pachetele trimise mai repede decât rata de umplere a cupei (mult mai mică decât BtlBw) sunt eliminate. BBR află în cele din urmă această nouă rată de livrare, dar cu ajutorul câștigului ProbeBW rezultă pierderi constante moderate. Pentru a minimiza pierderea lățimii de bandă în amonte și creșterea latenței aplicației din această pierdere, am adăugat un detector de tăiere dedicat și un model de tăiere explicit în BBR. De asemenea, explorăm în mod activ cele mai bune modalități de a elimina prejudiciul din limitatoarele de viteză.

Concurând cu metodele de control al congestiei pierderii de pachete

BBR se reduce la o partajare echitabilă a blocajului lățimii de bandă, indiferent dacă este în competiție cu alte fluxuri BBR sau fluxuri determinate de tehnici de control al congestiei pierderii de pachete. Chiar și atunci când acesta din urmă umple tamponul disponibil, ProbeBW înclină în mod fiabil estimarea BtlBw către o împărțire echitabilă, iar ProbeRTT consideră estimarea RTProp suficient de mare pentru a converti tit pentru tat în împărțire echitabilă. Cu toate acestea, tampoanele de router neadministrate care depășesc unele BDP-uri forțează concurenții de control al congestiei moștenite să umfle coada și să preia mai mult decât partea lor echitabilă. Eliminarea acestui lucru este un alt domeniu de cercetare activă.

Concluzie

Regândirea gestionării congestiei este un beneficiu imens. În loc să utilizeze evenimente precum pierderile de tampon sau confiscările de tampon care se corelează doar slab cu congestia, BBR începe cu modelul formal de congestie al lui Kleinrock și punctul de operare optim asociat. Concluzia enervantă că este „imposibil” să se determine simultan latența critică și lățimea de bandă este ocolită observând că acestea pot fi prezise simultan. Apoi, cele mai recente progrese în sistemele de control și teoria estimării sunt aplicate pentru a crea o buclă de control distribuită simplă care se apropie de optim, utilizând pe deplin rețeaua, menținând în același timp o coadă mică. Implementarea BBR de la Google este disponibilă în kernel-ul Linux open source și este detaliată în apendicele la acest articol.

Tehnologia BBR este utilizată pe coloana vertebrală Google B4, îmbunătățind semnificativ randamentul față de CUBIC. De asemenea, este implementat pe serverele web Google și YouTube, reducând semnificativ latența pe toate cele cinci continente testate până în prezent și deosebit de puternică în țările în curs de dezvoltare. Tehnologia BBR funcționează exclusiv pe partea expeditorului și nu necesită modificări ale protocolului, receptorului sau rețelei, ceea ce îi permite să fie implementat treptat. Depinde doar de notificările RTT și de livrare a pachetelor, deci poate fi utilizat în majoritatea protocoalelor de transport pe Internet.

Mulțumiri

Autorii sunt recunoscători lui Len Kleinrock pentru îndrumări cu privire la modul de gestionare adecvată a congestiei. Suntem datori lui Larry Brakmo pentru munca de pionierat la sistemele de gestionare a congestiei Vegas și New Vegas care anticipau multe dintre elementele BBR și pentru sfaturile și îndrumările sale în timpul dezvoltării timpurii a BBR. De asemenea, dorim să mulțumim lui Eric Dumazet, Nandita Dukkipati, Jana Iyengar, Ian Swett, M. Fitz Nowlan, David Wetherall, Leonid Leonidas Kontothanassis, Amin Vahdat și echipei Google BwE și YouTube Infrastructure pentru ajutorul și sprijinul lor neprețuit.

Anexă - descriere detaliată

Mașină de stat pentru sondare secvențială

Pacing_gain controlează cât de repede sunt trimise pachetele în raport cu BtlBw, iar aceasta este cheia funcției BBR inteligente. Când pacing_gain este mai mare decât unul, zborul crește și decalajul dintre pachete scade, ceea ce mută legătura spre partea dreaptă din Figura 1. Când pacing_gain este mai puțin de unul, are loc efectul opus, link-ul se deplasează spre stânga.

BBR folosește pacing_gain pentru a implementa o mașină simplă de detectare a stării secvențiale care alternează între testarea pentru mai multă lățime de bandă și testarea pentru mai puțini timpi de dublă trecere. (Nu este necesar să testați pentru o lățime de bandă mai mică, deoarece este gestionată automat de filtrul msx BtlBw: noile măsurători reflectă scăderea, astfel încât BtlBw se va corecta de îndată ce ultimele modificări vechi sunt eliminate din filtru prin timeout. Filtrul min RTprop gestionează o creștere a căii de livrare în același mod) ...

Dacă lățimea de bandă a blocajului crește, BBR trebuie să trimită date mai repede pentru a le detecta. La fel, dacă timpul real de trecere dublu al pachetului se modifică, acest lucru modifică BDP și, prin urmare, BDP trebuie să trimită date mai lent pentru a menține zborul sub BDP pentru a măsura noul RTprop. De aceea singura cale detectați aceste modificări - experimentați, trimiteți mai repede pentru a verifica creșterea BtlBw sau trimiteți mai lent pentru a verifica o scădere a RTprop. Frecvența, domeniul de aplicare, durata și structura acestor experimente diferă în funcție de ceea ce este deja cunoscut (începutul conexiunii sau starea stabilă) și de comportamentul aplicației care trimite date (intermitente sau persistente).

Stare echilibrată

Fluxurile BBR își petrec cea mai mare parte a timpului în starea ProbeBW, sondând seria folosind o metodă numită câștigă ciclismul care ajută fluxurile BBR să obțină un randament ridicat, o latență scăzută la coadă și o convergență echitabilă. Folosind câștigă ciclismul BBR încearcă ciclic o serie de valori pentru câștig pacing_gain... Opt faze de ciclu sunt utilizate cu următoarele valori: 5/4, 3/4, 1, 1, 1, 1, 1, 1. Fiecare fază durează de obicei pentru RTprop-ul prevăzut. Acest design permite buclei de coeficient să testeze mai întâi canalul pentru o lățime de bandă mai mare cu o valoare pacing_gain mai mare de 1.0 și apoi răspândiți orice coadă rezultată cu pacing_gain cu aceeași cantitate mai mică de 1,0, apoi deplasați-vă la viteza de croazieră cu o scurtă explozie de coeficienți de exact 1,0. Câștigul mediu pentru toate fazele este de 1,0, deoarece ProbeBW tinde să medieze pentru a egaliza lățimea de bandă disponibilă și, prin urmare, pentru a menține o utilizare a lățimii de bandă ridicată fără a crește coada. Rețineți că, deși ciclurile raportului se schimbă pacing_gain dar valoarea cwnd_gain rămâne întotdeauna egal cu două, deoarece pachetele ack întârziate și extinse pot apărea oricând (consultați capitolul despre pachetele ack întârziate și extinse).

Mai mult, pentru a îmbunătăți amestecarea fluxurilor și diviziunea echitabilă a lățimii de bandă și pentru a reduce cozile atunci când mai multe fluxuri BBR au un blocaj, BBR la întâmplare modifică fazele ciclului ProbeBW, alegând aleatoriu prima fază din toate valorile, cu excepția 3/4. De ce ciclul nu începe la 3/4? Scopul principal al acestei valori a raportului este de a dispersa orice coadă care se poate forma în timpul aplicării raportului 5/4, atunci când canalul este deja plin. Când un proces părăsește starea Drain sau ProbeRTT și intră în ProbeBW, nu există coadă, deci factorul 3/4 nu își face treaba. Utilizarea 3/4 într-un astfel de context are doar un efect negativ: umplerea canalului în această fază va fi 3/4 și nu 1. Astfel, începutul ciclului de la 3/4 are doar un efect negativ , dar nu are niciun efect pozitiv și, deoarece intrarea în statul ProbeBW durează destul de mult la începutul oricărei conexiuni, atunci BBR folosește această mică optimizare.

Firele BBR funcționează împreună pentru a goli periodic coada de blocaje folosind o stare numită ProbeRTT. În orice altă stare decât ProbeRTT în sine, dacă estimarea RTProp nu a fost actualizată (de exemplu, măsurând un RTT inferior) timp de mai mult de 10 secunde, atunci BBR intră în starea ProbeRTT și scade cwnd la o valoare foarte mică (patru pachete ). Păstrând un astfel de număr minim de pachete în zbor de cel puțin 200 ms și pentru un timp de trecere dublă, BBR părăsește starea ProbeRTT și intră fie în Startup, fie în ProbeBW, în funcție de faptul dacă canalul este deja plin.

BBR este proiectat să funcționeze de cele mai multe ori (aproximativ 98%) în starea ProbeBW și în restul timpului în ProbeRTT, pe baza unui set de compromisuri. Starea ProbeRTT durează suficient (cel puțin 200 ms) pentru a permite firelor cu RTT diferite să aibă stări simultane ProbeRTT, dar în același timp durează un timp suficient de scurt pentru a limita degradarea performanței la aproximativ două procente (200 ms / 10 secunde). Fereastra de filtrare RTprop (10 secunde) este suficient de mică pentru a se potrivi rapid modificărilor nivelurilor de trafic sau redirecționare, dar suficient de mare pentru aplicațiile interactive. Astfel de aplicații (de exemplu, pagini web, apeluri de proceduri la distanță, clipuri video) prezintă adesea perioade naturale de tăcere sau activitate scăzută în ferestrele acestei ferestre, unde debitul este suficient de lent sau suficient de lung pentru a dispersa coada într-un blocaj. Filtrul RTprop ajustează apoi aceste măsurători RTprop în mod oportunist, iar RTProp este actualizat fără a fi nevoie să utilizați ProbeRTT. Astfel, fluxurile de obicei trebuie să sacrifice 2% din lățimea de bandă dacă mai multe fluxuri umple abundent canalul pe o întreagă fereastră RTProp.

Comportament la pornire

Când pornește un fir BBR, acesta efectuează primul (și cel mai rapid) proces de sondare / golire a cozii secvențiale. Lățimea de bandă a rețelei variază în intervalul de 10 12 - de la câțiva biți la 100 de gigați pe secundă. Pentru a afla valoarea BtlBw pentru o astfel de schimbare gigantică, BBR efectuează o căutare binară în spațiul de viteză. El găsește foarte repede BtlBw (treceri duble de pachete), dar în detrimentul creării unei cozi în 2BDP în ultima etapă a căutării. Căutarea se efectuează în starea Startup în BBR, iar golirea cozii create se efectuează în starea Drain.

În primul rând, pornirea crește exponențial viteza de trimitere a datelor, dublându-le la fiecare rundă. Pentru a obține o detectare atât de rapidă în modul cel mai relaxat, atunci când începeți valorile de câștig pacing_gainși cwnd_gain sunt setate la, la valoarea minimă care vă permite să dublați viteza de încărcare pentru fiecare rundă. De îndată ce canalul este plin, coeficientul cwnd_gain limitează dimensiunea cozii la o valoare.

În starea de pornire a conexiunii, BBR judecă dacă canalul este plin, căutând un platou în estimarea BtlBw. Dacă se constată că au trecut mai multe (trei) runde, în care încercările de a dubla viteza de livrare nu dau cu adevărat o creștere mare a vitezei (mai puțin de 25%), atunci consideră că a ajuns la BtlBw, așa că iese din Startup starea și intră în starea de scurgere. BBR așteaptă trei runde pentru a obține dovezi convingătoare că platoul observat al expeditorului nu este un efect tranzitoriu din cauza ferestrei de primire. Așteptarea a trei runde oferă suficient timp pentru reglare automată pe partea destinatarului, pentru a deschide fereastra de primire și pentru expeditor să detecteze necesitatea creșterii BtlBw prin BBR: în prima rundă, algoritmul pentru ajustarea automată a ferestrei de primire mărește fereastra de primire; în a doua rundă, expeditorul completează fereastra de recepție mărită; în a treia rundă, expeditorul primește probe cu o viteză de livrare crescută. Această limită de trei runde s-a dovedit în implementarea YouTube.

În starea Drain, algoritmul BBR caută să golească rapid coada care s-a format în starea de pornire a conexiunii prin trecerea la pacing_gain cu valori opuse decât cele utilizate în starea Startup. Când numărul de pachete în zbor se potrivește cu estimarea BDP, înseamnă că BBR consideră că coada este complet goală, dar canalul este încă plin. Apoi BBR părăsește starea Drain și intră în ProbeBW.

Rețineți că o pornire a conexiunii BBR și o pornire lentă CUBIC ambele învață debitul de blocaj exponențial, dublând rata de trimitere pe fiecare rundă. Cu toate acestea, acestea sunt fundamental diferite. În primul rând, BBR este mai fiabil în determinarea lățimii de bandă disponibile, deoarece nu încetează căutarea în caz de pierdere de pachete sau (cum ar fi Hystart-ul CUBIC) de latență. În al doilea rând, BBR crește treptat viteza de trimitere, în timp ce CUBIC are o explozie de pachete pe fiecare rundă (chiar și cu ritm) și apoi o perioadă de tăcere. Figura 4 arată numărul de pachete în zbor și observă RTT pentru fiecare mesaj de confirmare de la BBR și CUBIC.

Răspunsul la situații tranzitorii

Calea rețelei și fluxul de trafic prin aceasta pot experimenta schimbări dramatice bruste. Pentru a se adapta ușor și fiabil la acestea, precum și pentru a reduce pierderea de pachete în aceste situații, BBR folosește o serie de strategii pentru a-și implementa modelul de bază. În primul rând, BBR consideră ca obiectivul spre care curentul cwnd se apropie cu prudență de jos, crescând cwnd de fiecare dată nu mai mult decât cantitatea de date pentru care a fost primită confirmarea de livrare. În al doilea rând, cu un timeout de retransmisie, ceea ce înseamnă că expeditorul consideră că toate pachetele în zbor sunt pierdute, BBR reduce în mod conservator cwnd până la un pachet și trimite un singur pachet (la fel ca algoritmii de control al congestiei pierderii de pachete, cum ar fi CUBIC). La urma urmei, atunci când expeditorul observă că s-a pierdut un pachet, dar există încă pachete în zbor, în primul pas al procesului de recuperare a pierderilor, BBR reduce temporar rata de expediere la nivelul ratei actuale de livrare; în cea de-a doua rundă și următoarele runde de recuperare a pierderilor, verifică faptul că rata de expediere nu depășește niciodată rata actuală de livrare cu mai mult de dublu. Acest lucru reduce foarte mult pierderile tranzitorii atunci când BBR întâlnește limitatoare de rată sau concurează cu alte fluxuri într-un buffer de dimensiunea BDP.

Link-uri

1. Abrahamsson, M. 2015. Suprimarea TCP ACK. Lista de corespondență IETF AQM;

În acest articol, vom prezenta câteva concepte pe care trebuie să le folosiți atunci când alegeți un ventilator pentru carcasă și vă vom spune despre caracteristicile tipice pentru diferite tipuri de ventilatoare. În plus, vom testa ventilatorul akasa Amber AK-183-L2B de 120 mm, care servește ca element activ al sistemului de răcire a procesorului Thermaltake Sonic Tower de mai bine de un an acum, care este utilizat la testarea procesoarelor și a plăcilor video . Și trebuie remarcat faptul că a meritat pe deplin dreptul de a deveni primul erou dintr-o serie de recenzii dedicate fanilor despre resursa noastră.

Întrebările la care vom încerca să răspundem vor fi ...

Care sunt cerințele pentru un ventilator de carcasă?

1. Nivel de performanță.
2. Nivel de zgomot.
3. Aspect (prezența și tipul de iluminare).
4. Funcții suplimentare (suport pentru sursa de alimentare PWM, prezența unui regulator de viteză, complet cu montaj anti-vibrații).

Care sunt principalele diferențe între fanii carcasei?

1. Dimensiuni- dimensiunea rotorului.

Pentru a crea ventilație internă în carcasă, în majoritatea cazurilor, se folosesc ventilatoare cu o dimensiune standard egală cu 80 mm, 92 mm sau 120 mm, deoarece orificiile de montare sunt prevăzute inițial pentru instalarea lor în carcasă. Este destul de clar că cu cât este mai mare dimensiunea rotorului ventilatorului, cu atât este mai mare capacitatea sa de a pompa fluxul de aer. Prin urmare, un ventilator mai mic va trebui să se rotească mai mult de de mare vitezăși, în consecință, face mult mai mult zgomot. Din acest motiv, ventilatoarele mari de 120 mm sunt populare.

Pentru a ilustra aceste proprietăți, puteți compara caracteristicile modelelor de ventilatoare din aceeași serie a Xinruilian Science & Technology Co. având dimensiuni diferite:

Dimensiune, mm
Viteza rpm
CFM de flux de aer
Nivel de zgomot, dB
Presiune, mm H 2 0

Judecând după caracteristicile date ale modelelor, putem concluziona că la aceeași viteză de rotație de 92 mm, ventilatorul va fi de 1,65 ori mai eficient decât cel de 80 mm, iar ventilatorul de 120 mm va fi de două ori mai eficient decât modelul de 92 mm, ținând cont că toți fanii au un singur tip de rotor.

Pe lângă diferitele diametre ale rotorului, dimensiunea profilului sau adâncimea ventilatorului sunt, de asemenea, la fel de importante. Profilul de 25 mm este „clasic” pentru carcasele convenționale. Fanii cu un profil mai mic sunt numiți cu profil redus și cu un profil mai mare, cu profil înalt. Forța de curgere a aerului depinde direct de dimensiunea profilului, care se caracterizează în specificație prin valoarea presiunii maxime.

De exemplu, să comparăm caracteristicile a două modele de 120 mm - cu un profil regulat și un profil înalt, care funcționează la aceeași viteză de rotație.

Dimensiune, mm
Viteza rpm
CFM de flux de aer
Nivel de zgomot, dB
Presiune, mm H20

Din tabel se poate observa că ventilatorul cu profil înalt diferă doar în cel mai bun indicator al presiunii maxime a debitului de aer. În obișnuit sisteme informatice nu este nevoie să se acumuleze suprapresiune, prin urmare aceste ventilatoare nu sunt utilizate în ele. În majoritatea cazurilor, ventilatoarele cu profil înalt sunt utilizate în servere, în plus, au o viteză de rotație crescută și, ca urmare, un zgomot de funcționare destul de ridicat.

2. Tipul rulmentului.

Există trei tipuri principale de rulmenți folosiți în ventilatoare: glisare simplă, combinată și rulare și doi rulmenți. În plus față de aceste tipuri de rulmenți, există semnificativ mai puține tipuri hidrodinamice, care sunt special dezvoltate separat de unii producători.

Cel mai adesea, tipul rulmentului poate fi determinat de prezența următorilor indici în numele modelului ventilatorului, deși este întotdeauna recomandabil să verificați cu specificația oficială:

S (mânecă) - rulment de manșon, care este în esență un manșon;
CU (combo) - un rulment cu bile și bucșă scurtă;
B (minge) sau 2B (2 mingi)- doi rulmenți cu bile.

Cel mai simplu și mai ieftin, dar, din păcate, nu deosebit de durabil, este rulmentul manșonului. Acest rulment are forma unei mici bucșe de cupru, în interiorul căreia arborele rotorului (tija) alunecă în timp ce se rotește. Un ventilator nou cu rulment de manșon lubrifiat poate fi complet silențios, dar această proprietate se poate pierde în timp. În absența unui nivel adecvat de lubrifiere, bucșa „se epuizează” destul de repede, ceea ce face ca ventilatorul să facă zgomot. În plus, în absența lubrifierii, lucrând într-o zonă cu temperatură ridicată, ventilatorul se poate bloca complet. Acest fapt este demonstrat în mod clar în special de cazurile cu surse de alimentare chinezești ieftine, în care au existat adesea cazuri de oprire a ventilatorului pe un rulment de manșon, care asigură răcirea elementelor semiconductoare de putere. Ca urmare, sursa de alimentare a eșuat.

Versiunea combinată a rulmentului are o durată de viață relativ mai mare.

Un rulment cu bile dublu este cea mai scumpă, dar și mai durabilă opțiune. Acest tip de rulment poate funcționa liber într-o zonă cu temperatură ridicată. Dar, în același timp, printre astfel de fani, puteți găsi adesea exemplare care emit un zgomot destul de puternic și neplăcut. O imagine similară este caracteristică în special ventilatoarelor ieftine, deoarece caracteristicile de zgomot ale întregii structuri depind în mod direct de calitatea fabricării unui rulment miniatural. Prin urmare, dacă alegeți un produs cu rulmenți cu bile, nu urmăriți în niciun fel ieftinitatea acestuia, deoarece modelele și mai scumpe sunt rareori silențioase.

3. Clasa motor.

Toate ventilatoarele de cutie sunt alimentate de motoare DC cu 4 poli. În ceea ce privește viteza, toate sunt clasificate în trei categorii: viteză mică până la 2000 rpm, viteză medie de la 2000 la 3000 rpm și viteză mare peste 3000 rpm. Puteți afla adesea clasa motorului ventilatorului după indexul din numele său, care este adesea indicat pe autocolant:

L (scăzut) - Mișcare înceată ( până în 2000 rpm);
M (mijloc) - in medie ( din 2000 până în 3000 rpm);
H (înalt) - de mare viteză ( peste 3000 rpm).

Care sunt caracteristicile datelor din specificațiile producătorului?

Viteza ventilatorului măsurat în numărul de rotații pe minut (RPM - rotații pe minut). Deoarece viteza ventilatorului în sine poate varia aproape proporțional direct cu tensiunea de alimentare, valoarea dată în specificație corespunde tensiunii nominale de alimentare. Cu cât viteza de rotație este mai mare, cu atât este mai eficient ventilatorul, dar, de asemenea, cu atât mai zgomotos.

Flux de aer poate fi specificat în CFM (picioare cubice pe minut, CFM) - picioare cubice pe minut sau în metri cubi pe oră (m 3 / h). În acest caz, 1 CFM ≈ 1,7 m 3 / h. Această valoare reflectă cantitatea de aer "pompat" pentru o anumită perioadă de timp, cu condiția să nu existe rezistență la fluxul de aer, adică cu o presiune egală a aerului pe ambele părți ale ventilatorului. Desigur, cu cât această valoare este mai mare, cu atât mai bine.

Presiunea statică a debitului de aer Ventilatorul este de obicei dat în mm de coloană de apă și caracterizează forța fluxului de aer pe care ventilatorul o poate genera.

Reamintim că presiunea este calculată prin formula P = F / S. Adică presiunea este raportul dintre forța fluxului de aer și zona pe care acționează. Specificațiile indică debitul maxim de aer pe care îl creează ventilatorul atunci când nu poate crea flux de aer din cauza rezistenței.

Întreaga caracteristică a ventilatorului poate fi văzută pe graficul „Curba de performanță”.

Curba de performanță reprezintă relația dintre debitul de aer și presiune. Punctul superior al curbei, situat pe axă, nu este altceva decât presiunea maximă care este dată în specificație. Punctul inferior al curbei, aflat pe cealaltă axă, corespunde debitului maxim de aer al ventilatorului atunci când acesta nu trebuie să acumuleze presiune. În condiții reale, și anume în caz, fluxul de aer trebuie să depășească o anumită rezistență. Fiecare corp are propriul său grad de rezistență individual. Rezistența sistemului va fi exprimată ca înclinată pe grafic, iar punctul de intersecție a liniei drepte și a curbei nu este altceva decât punctul de funcționare al ventilatorului din sistemul nostru condițional.

Resursa fanilor măsurat prin numărul de mii de ore în care ventilatorul trebuie să funcționeze și să furnizeze caracteristicile declarate. Autorul articolului nu este pe deplin conștient de condițiile de funcționare în care sunt atinse valorile citate, deoarece durata de viață depinde direct de condițiile de funcționare. Se presupune că ventilatorul poate funcționa pentru numărul specificat de ore fără a-și pierde calitățile de zgomot. Resursa depinde în mare măsură de tipul și calitatea rulmentului. Rulmenții simpli indică de obicei 30.000 de ore, rulmenții combinați 45.000 de ore și rulmenții cu bile duble au raportat valori de 60.000 de ore sau mai mult.

În majoritatea cazurilor, un ventilator pe un rulment de manșon poate funcționa destul de liniștit timp de aproximativ un an, deși producătorii susțin o cifră de 30 mii. Prin urmare, nu ar trebui să fiți părtinitor cu privire la aceste numere - sunt destul de relative. Și dacă săpați în jur, se dovedește că producătorul a însemnat și întreținerea periodică a ventilatoarelor, adică un lubrifiant pe care utilizatorii obișnuiți îl produc rar.

Acum să ne întoarcem la eroul recenziei noastre de fani. akasa AK-183-L2Bși uită-te la specificațiile sale:

	akasaAK-183-L2B
Dimensiune, mm
Viteza de rotație, rpm
CFM de flux de aer
Presiune, mm H20
Resursă, h
Tip rulment	două rulând
	Cu 3 pini
Nivel de zgomot, dB
Tensiunea de alimentare, V
Pagina web a produselor
prețul mediu

Ventilatorul akasa AK-183-L2B este ambalat într-o pungă de plastic transparentă. Ambalat cu partea din spate există o foaie de carton albastru care subliniază carcasa transparentă și rotorul translucid galben chihlimbar al ventilatorului. În general, totul este decorat în culoarea albastră-galbenă obișnuită a Grupului Akasa.

Există o foaie de specificații pe partea din spate a inserției de carton în cinci limbi diferite.

În plus față de ventilator, chiar în partea de jos a pachetului, există o cutie mică de carton negru cu o inscripție în traducere care sună ca „adaptor cu 3-4 pini”.

Prin urmare, nu este deloc surprinzător faptul că cutia conținea același adaptor care vă permite să conectați ventilatorul de la conectorii dispozitivelor periferice și, în plus, având în plus un conector cu 3 pini pentru controlul vitezei de rotație a ventilatorului. De asemenea, în cutia neagră mică se aflau patru șuruburi pentru instalarea ventilatorului în carcasă.

Carcasa ventilatorului akasa AK-183-L2B este fabricată din plastic transparent alb, iar rotorul său este din plastic translucid galben chihlimbar. De fapt, dacă luăm în considerare întreaga gamă de produse ale companiei akasa, atunci rareori întâlnește câteva soluții simple și standard, deoarece compania se angajează în distribuția de bunuri, în cea mai mare parte concepută special pentru modding. Dar acest lucru nu înseamnă deloc că, dacă nu aparțineți castei de moderi și sunteți obișnuiți să evaluați produsul doar din motive practice, atunci acest ventilator și restul produsului similar nu vă vor potrivi. De fapt, în producția de produse pentru așa-numiții utilizatori dificili, modders sau overlockers, o atenție sporită se referă întotdeauna, în primul rând, la calitatea manoperei și la proprietățile sale ceva mai ridicate. Prin urmare, nu este deloc surprinzător faptul că calitățile de consum ale acestor produse sunt aproape întotdeauna mai mari decât cele ale produselor simple.

În exterior, evantaiul, desigur, iese în evidență în primul rând pentru frumoasa combinație de galben și alb și se pare că un astfel de ventilator trebuie pur și simplu să aibă o lumină de fundal, dar de fapt nu este. Din punct de vedere aerodinamic, nu a fost implementată nicio inovație sau know-how în ventilator - un simplu rotor cu șapte palete.

Ventilatorul akasa AK-183-L2B aparține modelelor cu viteză redusă, viteza nominală de rotație este de 1400 rpm, în timp ce debitul maxim de aer poate atinge 44,8 CFM, iar presiunea statică este de 1,1 mm coloană de apă. Specificațiile nu sunt nici super-ridicate, nici destul de obișnuite, dar acest lucru nu este surprinzător, deoarece pentru fanii carcasei unui sistem de acasă, cerințele crescute pentru zgomot sunt plasate în primul rând.

Și în acest sens, specificațiile indică un nivel de zgomot destul de scăzut de 18 dB. Trebuie remarcat faptul că ventilatorul akasa AK-183-L2B se bazează pe doi rulmenți cu bile, iar resursa sa conform datelor producătorului este de 80.000 de ore. Valoarea obișnuită pentru rulmenții cu bile este de 60.000 de ore, deci o valoare ușor crescută oferă motive să sperăm într-o abordare mai bună a fabricării lor, deoarece așa cum am menționat deja, calitatea fabricării unui rulment cu bile este cea care determină caracteristicile sale de zgomot .

Ventilatorul este alimentat de un conector de alimentare cu 3 pini care nu acceptă surse de alimentare PWM.

Testarea

Partea practică a testului constă în două etape de testare a debitului de aer generat al ventilatorului la viteza nominală, precum și evaluarea intensității acestuia după ureche.

Testul numărul 1

În primul test, ventilatorul va acționa ca un element activ al răcitorului Thermalright SI-128. Testarea se efectuează într-o carcasă deschisă, iar principalul parametru controlat este temperatura de încălzire a procesorului overclockată la 2,8 GHz Intel core 2 Duo E6300 și temperatura plăcii de bază.

Testul numărul 2

În cel de-al doilea test, ventilatorul va fi utilizat pentru scopul propus ca ventilator de carcasă instalat pe panoul din spate și care funcționează pentru suflare. În timpul testului, carcasa va fi închisă și nu vor exista alți ventilatori aprinși. Principalul parametru controlabil va fi și temperatura de încălzire a procesorului Intel Core 2 Duo E6300, dar acum fără overclocking, pe care este instalat sistemul de răcire pasiv Thermaltake Sonic Tower (CL-P0071) și temperatura plăcii de bază. Rezultatul testului este înregistrat după o „alergare” de 10 minute a testului de stres al procesorului în aplicația Everest.

Configurația de testare a platformei procesorului Intel constă din următoarele componente:

Placă de bază	Gigabyte GA-965P-DS4 (Intel P965 Express)
CPU	Intel Core 2 Duo E6300 (LGA775, 1,86 GHz, L2 2 MB) @ 2,8 GHz
RAM	2 х DDR2-800 1024 MB Apacer PC6400
Placa video	EVGA GeForce 8600GTS 256 MB DDR3 PCI-E
HDD	Samsung HD080HJ 80GB SATA-300
Unitate optică	ASUS DRW-1814BLT SATA
Alimentare electrică	Ventilator Chieftec CFT-500-A12S 500W 120mm
	CODEGEN M603 MidiTower

Ventilatorul akasa AK-183-L2B demonstrează performanțe bune la fel ca alți concurenți. Putem confirma nivelul de zgomot declarat destul de scăzut de 18 dB numai prin opinia noastră subiectivă. Valoarea indicată este într-adevăr destul de consistentă cu nivelul real de zgomot - la viteza maximă emite un mic zumzet.

Concluzii.

Ventilatorul akasa AK-183-L2B nu este un decor frumos exclusiv, așa cum se poate gândi imediat cumpărătorul. Poate crea un flux de aer destul de mare și, cel mai important, emite suficient nivel scăzut zgomot. Dacă luăm în considerare costul său acceptabil ca pentru un model de înaltă calitate al unui ventilator cu rulmenți cu bile, atunci în această categorie de bunuri din punct de vedere al prețului / calităților consumatorului, acesta va fi unul dintre cele mai bune. Să repetăm ​​că în laboratorul nostru de testare, ventilatorul akasa AK-183-L2B funcționează de peste un an, iar calitățile sale de zgomot nu s-au schimbat practic în acest timp.

Avantaje:

• creează un flux mare de aer;
• nivel redus de zgomot;
• raport bun calitate / consumator.

Dezavantajele includ:

• lipsa suportului PWM.

Ne exprimăm recunoștința companiei PF Service LLC (Dnepropetrovsk) pentru echipamentele furnizate pentru testare.

Articol citit de 4669 de ori

Abonați-vă la canalele noastre

Software-ul open source a devenit un element de bază pentru unele dintre cele mai mari site-uri web. Odată cu creșterea acestor site-uri web, au apărut cele mai bune practici și linii directoare pentru arhitectura lor. Acest capitol își propune să acopere unele dintre problemele cheie care trebuie luate în considerare atunci când proiectăm site-uri web mari, precum și unele dintre componentele de bază utilizate pentru atingerea acestor obiective.

Accentul principal al acestui capitol este analiza sistemelor web, deși o parte din material poate fi extrapolată și la alte sisteme distribuite.

1.1 Principiile construirii sistemelor web distribuite

Ce înseamnă mai exact să creezi și să gestionezi un site web sau o aplicație scalabilă? La un nivel primitiv, este pur și simplu conectarea utilizatorilor la resurse la distanță prin Internet. Și resursele sau accesul la aceste resurse, care sunt dispersate pe mai multe servere și sunt link-ul care asigură scalabilitatea site-ului web.

La fel ca majoritatea lucrurilor din viață, a vă lua timp pentru a vă planifica în avans pentru a vă construi serviciul web vă poate ajuta în continuare; înțelegerea unora dintre considerațiile și compromisurile din spatele site-urilor web mari poate avea rezultate în decizii mai inteligente atunci când construiești site-uri web mai mici. Mai jos sunt câteva dintre principiile cheie care influențează proiectarea sistemelor web la scară largă:

• Disponibilitate: durată conditii de lucru un site web este esențial pentru reputația și funcționalitatea multor companii. Pentru unele dintre magazinele de vânzare cu amănuntul online mai mari, indisponibilitatea pentru câteva minute poate duce la pierderea veniturilor de mii sau milioane de dolari. Astfel, dezvoltarea sistemelor lor care sunt întotdeauna disponibile și rezistente la eșec este, de asemenea, o cerință fundamentală de afaceri și tehnologie. Disponibilitatea ridicată în sistemele distribuite necesită o analiză atentă a redundanței pentru componentele cheie, recuperarea rapidă după defecțiuni parțiale ale sistemului și reducerea redusă a nivelului atunci când apar probleme.
• Performanţă: Performanța site-ului web a devenit o valoare importantă pentru majoritatea site-urilor. Viteza site-ului web afectează experiența și satisfacția utilizatorilor, precum și clasamentele motoarelor de căutare - un factor care afectează direct păstrarea publicului și veniturile. Ca rezultat, cheia este crearea unui sistem care este optimizat pentru răspunsuri rapide și latență scăzută.
• Fiabilitate: sistemul trebuie să fie robust astfel încât o cerere specifică de date să returneze în mod constant date specifice. În cazul modificării sau actualizării datelor, aceeași interogare ar trebui să returneze date noi. Utilizatorii trebuie să știe dacă ceva este scris în sistem sau este stocat în el, apoi pot fi siguri că acesta va rămâne la locul său pentru posibilitatea recuperării datelor ulterior.
• Scalabilitate: Când vine vorba de orice sistem distribuit mare, dimensiunea este doar unul dintre multele lucruri de luat în considerare. La fel de importante sunt eforturile de creștere a debitului pentru a gestiona volume mari de sarcină de lucru, care este denumită în mod obișnuit scalabilitatea sistemului. Scalabilitatea se poate referi la diverși parametri ai unui sistem: cantitatea de trafic suplimentar pe care o poate gestiona, cât de ușor este să crească capacitatea de stocare sau cât de multe alte tranzacții pot fi procesate.
• Controlabilitate: Proiectarea unui sistem ușor de utilizat este un alt factor important. Gestionarea sistemului este echivalată cu scalabilitatea operațiunilor „întreținere” și „actualizări”. Pentru a asigura gestionabilitatea, este necesar să se ia în considerare problemele legate de ușurința diagnosticării și înțelegerea problemelor emergente, ușurința actualizării sau modificării, a sistemului capricios. în funcțiune. (Adică funcționează conform așteptărilor fără eșecuri sau excepții?)
• Preț: Costul este un factor important. Acest lucru poate include în mod evident costuri hardware și software, dar este, de asemenea, important să se ia în considerare alte aspecte necesare pentru implementarea și întreținerea sistemului. Cantitatea de timp necesară dezvoltatorului pentru a construi sistemul, cantitatea de efort operațional necesar pentru punerea în funcțiune a sistemului și chiar un nivel suficient de instruire ar trebui să fie prevăzute. Costul este costul total al proprietății.

Fiecare dintre aceste principii stă la baza luării deciziilor în proiectarea unei arhitecturi web distribuite. Cu toate acestea, ele pot intra și în conflict unul cu celălalt, deoarece atingerea obiectivelor unuia vine în detrimentul neglijării altora. Un exemplu simplu: alegerea de a adăuga pur și simplu mai multe servere ca soluție de performanță (scalabilitate) poate crește costurile de gestionare (trebuie să operați un server suplimentar) și achizițiile de server.

Atunci când dezvoltați orice fel de aplicație web, este important să luați în considerare aceste principii cheie, chiar dacă este vorba de confirmarea faptului că proiectul poate dona unul sau mai multe dintre ele.

1.2 Noțiuni de bază

Atunci când se ia în considerare arhitectura sistemului, există mai multe probleme care trebuie evidențiate, cum ar fi componentele care merită utilizate, modul în care se potrivesc împreună și ce compromisuri se pot face. Investirea banilor în scalare fără necesitatea evidentă a acestora nu poate fi considerată o decizie inteligentă de afaceri. Cu toate acestea, o anumită previziune în planificare poate economisi semnificativ timp și resurse în viitor.

Această secțiune se concentrează pe câțiva factori de bază care sunt critici pentru aproape toate aplicațiile web mari: Servicii,
redundanţă, segmentare, și tratarea refuzului... Fiecare dintre acești factori implică alegeri și compromisuri, în special în contextul principiilor descrise în secțiunea anterioară. Să dăm un exemplu de clarificare.

Exemplu: aplicație de găzduire a imaginilor

Probabil că ați mai postat imagini pe web. Pentru site-urile mari care stochează și livrează mai multe imagini, există provocări în crearea unei arhitecturi eficiente din punct de vedere al costurilor, foarte fiabile, cu o latență de răspuns scăzută (recuperare rapidă).

Imaginați-vă un sistem în care utilizatorii își pot încărca imaginile pe un server central și imaginile pot fi solicitate printr-un link de site sau API, similar cu Flickr sau Picasa. Pentru a simplifica descrierea, să presupunem că această aplicație are două sarcini principale: posibilitatea de a încărca (scrie) imagini pe server și de a solicita imagini. Desigur, încărcarea eficientă este importantă, dar livrarea rapidă va fi o prioritate la cererea utilizatorilor (de exemplu, imaginile pot fi solicitate să fie afișate pe o pagină web sau altă aplicație). Această funcționalitate este similară cu cea pe care o poate oferi un server web sau un server Edge Content Network (CDN). Un server CDN stochează obiecte de date în multe locații, astfel încât locația lor geografică / fizică să fie mai aproape de utilizatori, ceea ce duce la performanțe mai bune.

Alte aspecte importante ale sistemului:

• Numărul de imagini stocate poate fi nelimitat, astfel încât scalabilitatea stocării trebuie luată în considerare din acest punct de vedere.
• Ar trebui să existe o latență scăzută pentru descărcări / solicitări de imagini.
• Dacă un utilizator încarcă o imagine pe server, atunci datele sale trebuie să rămână întotdeauna complete și accesibile.
• Sistemul trebuie să fie ușor de întreținut (manevrabilitate).
• Deoarece găzduirea imaginilor nu este foarte profitabilă, sistemul trebuie să fie rentabil.

O altă problemă potențială cu acest design este că un server web, cum ar fi Apache sau lighttpd, are de obicei o limită superioară a numărului de conexiuni simultane pe care le poate gestiona (valoarea implicită este de aproximativ 500, dar poate fi mult mai mare). Și cu trafic mare, scrie poate utiliza rapid această limită. Deoarece citirile pot fi asincrone sau pot profita de alte optimizări de performanță, cum ar fi compresia gzip sau chunking, serverul web poate comuta mai repede citirile de fluxuri și poate comuta între clienți, servind mult mai multe cereri decât număr maxim conexiuni (cu Apache și numărul maxim de conexiuni setat la 500, este foarte posibil să se servească câteva mii de cereri de citire pe secundă). Intrările, pe de altă parte, tind să mențină o conexiune deschisă pe parcursul întregului timp de descărcare. De exemplu, transferul unui fișier de 1 MB pe server ar putea dura mai mult de 1 secundă pe majoritatea rețelelor de domiciliu, cu rezultatul că serverul web ar putea procesa doar 500 dintre aceste scrieri simultane.

Figura 1.2: Separarea de citire și scriere

Anticiparea acestei probleme potențiale sugerează că este necesar să se separe citirea și scrierea imaginilor de serviciile independente prezentate în. Acest lucru va permite nu numai scalarea fiecăruia dintre ele în mod individual (deoarece este probabil să facem întotdeauna mai multe citiri decât scrieri), ci și să fim la curent cu ceea ce se întâmplă în fiecare serviciu. În cele din urmă, va delimita problemele viitoare, facilitând diagnosticarea și evaluarea problemelor de acces la citire lentă.

Avantajul acestei abordări este că suntem capabili să rezolvăm problemele independent unul de celălalt - fără a fi nevoie să ne gândim la nevoia de a înregistra și a dobândi noi imagini în același context. Ambele servicii folosesc în continuare corpusul global de imagini, dar atunci când folosesc metode adecvate pentru un anumit serviciu, sunt capabili să-și optimizeze propriile performanțe (de exemplu, prin așteptarea cererilor sau prin stocarea în cache a imaginilor populare - mai multe despre asta mai târziu). În ceea ce privește atât întreținerea, cât și costul, fiecare serviciu poate fi scalat independent, după cum este necesar. Și acesta este un factor pozitiv, deoarece combinarea și amestecarea acestora le-ar putea afecta în mod involuntar performanța, ca în scenariul descris mai sus.

Desigur, modelul de mai sus va funcționa cel mai bine dacă aveți două puncte finale diferite (de fapt, acest lucru este foarte similar cu mai multe implementări ale furnizorilor de stocare în cloud și rețelelor de livrare de conținut). Există multe modalități de a rezolva aceste probleme și, în fiecare caz, poate fi găsit un compromis.

De exemplu, Flickr rezolvă această problemă de citire-scriere distribuind utilizatorii între diferite module, astfel încât fiecare modul să poată deservi doar un număr limitat de utilizatori specifici și, pe măsură ce crește numărul de utilizatori, se adaugă mai multe module în cluster (consultați scalarea Flickr prezentare.
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). În primul exemplu, este mai ușor să scalați hardware-ul pe baza încărcării reale de utilizare (numărul de citiri și scrieri pe întregul sistem), în timp ce scalarea Flickr se face pe baza utilizatorilor (totuși, aceasta presupune o utilizare egală între diferiți utilizatori, deci capacitatea trebuie planificat cu rezervă). În trecut, indisponibilitatea sau o problemă cu unul dintre servicii făcea inutilizabilă funcționalitatea întregului sistem (de exemplu, nimeni nu poate scrie fișiere), atunci indisponibilitatea unuia dintre modulele Flickr va afecta doar utilizatorii asociați acestuia. În primul exemplu, este mai ușor să efectuați operațiuni pe un întreg set de date - de exemplu, actualizarea serviciului de scriere pentru a include metadate noi sau căutarea tuturor metadatelor de imagine - în timp ce cu arhitectura Flickr, fiecare modul trebuia actualizat sau căutat (sau serviciul de căutare a trebuit creat pentru a sorta metadatele care sunt de fapt destinate acestui lucru).

În ceea ce privește aceste sisteme, nu există panaceu, dar ar trebui să procedați întotdeauna de la principiile descrise la începutul acestui capitol: determinați nevoile sistemului (încărcați cu operațiile de „citire” sau „scriere” sau toate simultan, nivelul paralelismului , interogări cu privire la seturi de date, intervale, probe etc.), efectuează comparative comparative ale diferitelor alternative, înțeleg condițiile pentru potențiale defecțiuni ale sistemului și dezvoltă un plan cuprinzător de defecțiuni.

Redundanţă

Pentru a face față eșecului elegant, arhitectura web trebuie să aibă redundanță în serviciile și datele sale. De exemplu, dacă există o singură copie a unui fișier stocat pe un singur server, pierderea acelui server va însemna și pierderea fișierului. Această situație poate fi greu caracterizată pozitiv și, de obicei, poate fi evitată prin crearea mai multor copii sau copii de siguranță.

Același principiu se aplică și serviciilor. Vă puteți proteja împotriva eșecului unui singur nod oferind o parte integrantă a funcționalității unei aplicații pentru a vă asigura că mai multe copii sau versiuni ale aplicației rulează simultan.

Crearea redundanței în sistem vă permite să scăpați puncte slabeși să ofere funcționalități de rezervă sau redundante în caz de urgență. De exemplu, dacă există două instanțe ale aceluiași serviciu care rulează în „producție” și unul dintre ele eșuează total sau parțial, sistemul poate depăși eșecul în detrimentul trecerea la o copie reparabilă.
Comutarea poate avea loc automat sau necesită intervenție manuală.

Un alt rol cheie al redundanței serviciilor este crearea arhitectură nepartajată... Cu această arhitectură, fiecare nod este capabil să funcționeze independent și, în plus, în absența unui „creier” central care controlează stările sau coordonează acțiunile altor noduri. Promovează scalabilitatea, deoarece adăugarea de noi noduri nu necesită condiții sau cunoștințe speciale. Cel mai important, nu există un punct critic de eșec în aceste sisteme, ceea ce le face mult mai rezistente la eșec.

De exemplu, în aplicația noastră pentru serverul de imagini, toate imaginile ar avea copii redundante în altă parte a hardware-ului (în mod ideal, cu o locație geografică diferită în caz de dezastru, cum ar fi un cutremur sau un incendiu în centrul de date), iar serviciile de acces la imagine vor fi redundante , cu toate acestea pot servi solicitările. (Cm. .)
Privind în viitor, echilibratoarele de sarcină sunt o modalitate excelentă de a face acest lucru posibil, dar mai multe despre asta mai jos.

Figura 1.3: Aplicație redundantă de găzduire a imaginilor

Segmentare

Seturile de date pot fi atât de mari încât nu pot fi găzduite pe un singur server. De asemenea, se poate întâmpla ca operațiunile de calcul să consume prea multe resurse de computer, reducând performanța și necesitând o creștere a puterii. În orice caz, aveți două opțiuni: scalare verticală sau orizontală.

Extinderea înseamnă adăugarea mai multor resurse la un singur server. Deci, pentru un set de date foarte mare, acest lucru ar însemna adăugarea mai multor (sau mai multor) hard disk-uri, și astfel întregul set de date ar putea încapea pe un singur server. În cazul operațiunilor de calcul, aceasta ar însemna mutarea calculului pe un server mai mare cu un procesor mai rapid sau mai multă memorie. În orice caz, scalarea verticală este realizată pentru a face o resursă separată a sistemului de calcul capabilă de procesare suplimentară a datelor.

Scalarea orizontală, pe de altă parte, implică adăugarea mai multor noduri. În cazul unui set de date mare, aceasta ar însemna adăugarea unui al doilea server pentru a stoca o parte din întregul volum de date, iar pentru o resursă de calcul, aceasta ar însemna împărțirea lucrului sau încărcarea prin unele noduri suplimentare. Pentru a profita din plin de potențialul de extindere, acesta trebuie implementat ca un principiu de proiectare internă pentru arhitectura sistemului. În caz contrar, schimbarea și evidențierea contextului necesar pentru scalarea orizontală poate fi problematică.

Cea mai comună metodă de redimensionare este împărțirea serviciilor în cioburi sau module. Ele pot fi distribuite în așa fel încât fiecare set logic de funcționalități să funcționeze separat. Acest lucru se poate face prin limite geografice sau prin alte criterii, cum ar fi utilizatorii plătitori și neplătitori. Avantajul acestor scheme este că oferă un serviciu sau un magazin de date cu funcționalitate îmbunătățită.

În exemplul nostru de server de imagine, este posibil ca un singur server de fișiere utilizat pentru a stoca imaginea să poată fi înlocuit cu mai multe servere de fișiere, fiecare conținând propriul set unic de imagini. (Vezi) Această arhitectură va permite sistemului să populeze fiecare server de fișiere cu imagini, adăugând servere suplimentare pe măsură ce se umple spatiu pe disc... Proiectarea va necesita o schemă de denumire care asociază numele fișierului imagine cu serverul care conține. Numele imaginii poate fi generat dintr-o schemă de hash consistentă asociată cu serverele. Sau, alternativ, fiecare imagine poate avea un ID incremental, care va permite serviciului de livrare să proceseze doar gama de ID-uri asociate fiecărui server (ca index) atunci când solicită o imagine.

Figura 1.4: O aplicație de găzduire de imagini cu redundanță și sharding

Desigur, există dificultăți în distribuirea datelor sau funcționalității pe mai multe servere. Una dintre întrebările cheie - localizarea datelor; în sistemele distribuite, cu cât datele sunt mai aproape de locația operațiunilor sau de punctul de calcul, cu atât performanța sistemului este mai bună. În consecință, distribuirea datelor pe mai multe servere este potențial problematică, deoarece de fiecare dată când sunt necesare date, există riscul ca acestea să nu fie disponibile la locul cererii, serverul va trebui să efectueze eșantionarea costisitoare a informațiilor necesare prin rețea. .

O altă problemă potențială apare în formă
inconsecvență (inconsecvență).Când diverse servicii citesc și scriu pe o resursă partajată, potențial un alt serviciu sau magazin de date, există posibilitatea condițiilor de cursă - în care unele date sunt considerate a fi actualizate la starea actuală, dar în realitate sunt citite înainte de a fi actualizate - caz în care datele sunt incompatibile. De exemplu, într-un scenariu de găzduire de imagini, o condiție de cursă ar putea apărea dacă un client a trimis o cerere de actualizare a imaginii câinelui, schimbând titlul „Câine” în „Gizmo”, în timp ce un alt client citea imaginea. Într-o astfel de situație, nu este clar ce titlu, „Câine” sau „Gizmo”, ar fi primit de al doilea client.

Există, desigur, unele obstacole asociate cu partajarea datelor, dar partajarea vă permite să deosebiți fiecare dintre probleme de celelalte: după date, după încărcare, după modele de utilizare etc. în blocuri controlate. Acest lucru poate ajuta la scalabilitate și la gestionare, dar riscul este încă acolo. Există multe modalități de a atenua riscul și de a rezolva întreruperile; cu toate acestea, din motive de scurtă durată, acestea nu sunt acoperite în acest capitol. Dacă doriți mai multe informații despre acest subiect, ar trebui să aruncați o privire la toleranța la erori și monitorizarea postării de pe blog.

1.3. Componente structurale ale accesului rapid și scalabil la date

După ce am acoperit câteva principii de bază în dezvoltarea sistemelor distribuite, să trecem acum la punctul mai dificil - scalarea accesului la date.

Majoritatea aplicațiilor web de bază, cum ar fi aplicațiile de tip LAMP, sunt similare cu imaginea din.

Figura 1.5: Aplicații web simple

Pe măsură ce o aplicație crește, apar două provocări majore: scalarea accesului la serverul de aplicații și la baza de date. Într-un design de aplicație foarte scalabil, serverul web sau serverul de aplicații este de obicei minimizat și implementează adesea o arhitectură care nu partajează resurse. Acest lucru face ca stratul serverului de aplicații al sistemului să fie extins. Ca rezultat al acestei concepții, munca grea se va muta în jos în stiva către serverul de baze de date și serviciile de asistență; Aici intră în joc adevăratele probleme de scalare și performanță.

Restul acestui capitol se concentrează pe unele dintre cele mai comune strategii și tehnici pentru îmbunătățirea performanței și scalabilității pentru aceste tipuri de servicii, oferind acces rapid la date.

Figura 1.6: Aplicație web simplificată

Majoritatea sistemelor pot fi simplificate la o diagramă,
care este un bun punct de plecare pentru a începe să analizăm. Dacă aveți o mulțime de date, puteți presupune că doriți să fie accesibil la fel de ușor și rapid ca cutia de bomboane din sertarul superior al biroului dvs. În timp ce această comparație este simplificată excesiv, aceasta indică două probleme provocatoare: scalabilitatea depozitului de date și accesul rapid la date.

Pentru această secțiune, să presupunem că aveți o mulțime de terabyte (TB) de date și că permiteți utilizatorilor să acceseze bucăți mici din acele date în nici o ordine specială. (Cm. .)
O sarcină similară este de a localiza fișierul de imagine undeva pe serverul de fișiere din aplicația de găzduire a imaginilor.

Figura 1.7: Accesarea datelor specifice

Acest lucru este deosebit de dificil, deoarece încărcarea terabyte de date în memorie poate fi foarte costisitoare și afectează în mod direct numărul de operații I / O pe disc. Viteza de citire de pe un disc este de câteva ori mai mică decât viteza de citire de pe RAM - putem spune că accesul la memorie este la fel de rapid ca Chuck Norris, în timp ce accesul la un disc este mai lent decât coada din clinică. Această diferență de viteză se observă în special pentru seturile de date mari; în număr uscat, accesul la memorie este de 6 ori mai rapid decât citirile pe disc pentru citirile secvențiale și de 100.000 de ori mai rapid pentru citirile aleatorii (consultați Patologiile Big Data, http://queue.acm.org/detail. cfm? id = 1563874). ). În plus, chiar și cu identificatori unici, rezolvarea problemei găsirii locației unei mici bucăți de date poate fi la fel de dificilă ca scoaterea ultimei bomboane umplute cu ciocolată dintr-o cutie cu alte sute de bomboane fără să te uiți.

Din fericire, există multe abordări pe care le puteți lua pentru a simplifica lucrurile, dintre care cele mai importante patru sunt cache-urile, proxy-urile, indexurile și echilibrarea sarcinii. Restul acestei secțiuni discută despre modul în care fiecare dintre aceste concepte poate fi utilizat pentru a face accesul la date mult mai rapid.

Cachete

Memorarea în cache beneficiază de un principiu de bază că datele solicitate recent ar putea fi solicitate din nou. Cache-urile sunt utilizate la aproape fiecare strat de calcul: hardware, sisteme de operare, browsere web, aplicații web și multe altele. O memorie cache este ca o memorie pe termen scurt: limitată în dimensiune, dar mai rapidă decât sursa de date originală și care conține elemente accesate recent. Cache-urile pot exista la toate nivelurile din arhitectură, dar sunt adesea la cel mai apropiat nivel de front-end, unde sunt implementate pentru a returna datele rapid fără o încărcare semnificativă a backend-ului.

Deci, cum se poate utiliza cache-ul pentru a accelera accesul la date în exemplul nostru de API? În acest caz, există mai multe locații cache adecvate. Ca unul dintre opțiuni posibile plasare, puteți selecta noduri la nivelul interogării așa cum se arată în
.

Figura 1.8: Plasarea unui cache pe un nod de nivel de interogare

Plasarea unui cache direct pe un nod la nivel de interogare permite depozitare locală date de răspuns. De fiecare dată când se face o solicitare de serviciu, gazda va returna rapid date locale, în cache, dacă există. Dacă nu se află în cache, atunci nodul de solicitare va solicita date de pe disc. Cache-ul de pe un singur nod la nivelul cererii ar putea fi, de asemenea, localizat atât în ​​memorie (care este foarte rapidă), cât și pe discul local al nodului (mai rapid decât încercarea de a accesa NAS).

Figura 1.9: Sisteme de cache

Ce se întâmplă când răspândiți cache-ul către mai multe noduri? După cum puteți vedea, dacă stratul de interogare va include multe noduri, atunci este probabil ca fiecare nod să aibă propria cache. Cu toate acestea, dacă echilibratorul dvs. de încărcare distribuie în mod aleatoriu cereri între noduri, atunci aceeași solicitare va merge la noduri diferite, crescând astfel eșecurile cache. Memoriile cache globale și distribuite sunt două modalități de a depăși acest obstacol.

Cache global

Semnificația memoriei cache globale este clară din nume: toate nodurile utilizează un singur spațiu cache. În acest caz, se adaugă un server sau un magazin de fișiere de un fel, care este mai rapid decât magazinul dvs. original și care va fi disponibil pentru toate nodurile de nivel de interogare. Fiecare dintre nodurile de solicitare solicită memoria cache în același mod ca și cum ar fi local. Acest tip de schemă de stocare în cache poate provoca o oarecare confuzie, deoarece este foarte ușor să supraîncărcați un singur cache pe măsură ce crește numărul de clienți și solicitări. În același timp, o astfel de schemă este foarte eficientă pentru anumite arhitecturi (mai ales când vine vorba de hardware specializat care face ca această cache globală să fie foarte rapidă sau care să aibă un set fix de date care trebuie memorat în cache).

Există două forme standard de cache globale, prezentate în diagrame. Situația este descrisă atunci când un răspuns cache nu este găsit în cache, cache-ul în sine devine responsabil pentru primirea bucății de date lipsă din stocarea subiacentă. Acesta ilustrează responsabilitatea nodurilor de solicitare pentru a prelua orice date care nu se găsesc în cache.

Figura 1.10: Cache-ul global, unde cache-ul este responsabil de preluare

Figura 1.11: Cache global în care nodurile de solicitare sunt responsabile de recuperare

Majoritatea aplicațiilor globale de întărire a cache-ului tind să utilizeze primul tip, unde cache-ul în sine gestionează înlocuirea și preluarea datelor pentru a împiedica clienții să inunde cereri pentru aceleași date. Cu toate acestea, există unele cazuri în care a doua implementare are mai mult sens. De exemplu, dacă cache-ul este utilizat pentru un foarte fișiere mari, o rată scăzută de accesare a cache-ului va supraîncărca cache-ul tampon cu accesări nereușite ale cache-ului; în această situație, vă ajută să aveți un procent mare din setul de date total (sau set de date fierbinte) în cache. Un alt exemplu este o arhitectură în care fișierele stocate în cache sunt statice și nu trebuie șterse. (Acest lucru se poate datora caracteristicilor de performanță care stau la baza acestei latențe - poate că anumite date trebuie să fie foarte rapide pentru seturile de date mari - atunci când logica aplicației înțelege strategia de înlocuire sau hotspoturile mai bine decât memoria cache.)

Memorie cache distribuită

Acești indexuri sunt adesea stocate în memorie sau undeva foarte local la solicitarea clientului primit. Berkeley DB (BDB) și structurile de date arborescente, care sunt utilizate în mod obișnuit pentru stocarea datelor în liste ordonate, sunt ideale pentru acces indexat.

Există adesea multe niveluri de indexuri care servesc drept hartă, care vă mută dintr-o locație în alta și așa mai departe, până când obțineți datele dorite. (Cm. )

Figura 1.17: Indici pe mai multe niveluri

De asemenea, indexurile pot fi folosite pentru a crea alte câteva vizualizări ale acelorași date. Pentru seturile de date mari, acesta este un mod excelent de a defini diferite filtre și vizualizări fără a fi nevoie să creați multe copii suplimentare ale datelor.

De exemplu, să presupunem că sistemul de găzduire a imaginilor menționat mai sus găzduiește de fapt imagini cu pagini de carte, iar serviciul permite interogările clienților cu privire la textul din aceste imagini, căutând tot conținutul textului pe un subiect dat, la fel cum motoarele de căutare vă permit să căutați HTML . conținut. În acest caz, toate aceste imagini de carte folosesc o mulțime de servere pentru a stoca fișiere, iar găsirea unei pagini pentru a fi prezentată utilizatorului poate fi destul de dificilă. Inițial, ar trebui să fie disponibile cu ușurință indicii inversi pentru interogarea cuvintelor și seturilor de cuvinte arbitrare; apoi există sarcina de a naviga la pagina și locația exactă din acea carte și de a extrage imaginea corectă pentru rezultatele căutării. Astfel, în acest caz, indexul inversat ar fi mapat la o locație (cum ar fi cartea B), iar apoi B ar putea conține un index cu toate cuvintele, locațiile și numărul de apariții din fiecare parte.

Indexul inversat pe care Index1 îl poate afișa în diagrama de mai sus ar arăta cam așa: Fiecare cuvânt sau set de cuvinte servește drept index pentru cărțile care le conțin.

Indexul intermediar va arăta similar, dar va conține doar cuvintele, locația și informațiile pentru Cartea B. Această arhitectură cu mai multe straturi permite ca fiecare dintre indici să ocupe mai puțin spațiu decât dacă toate aceste informații ar fi stocate într-un singur index inversat mare .

Și acesta este un punct cheie în sistemele pe scară largă, deoarece chiar și atunci când sunt comprimate, acești indici pot fi destul de mari și costisitori de stocat. Să presupunem că avem multe cărți din întreaga lume pe acest sistem - 100.000.000 (vezi postarea pe blog „Inside Google Books”) - și că fiecare carte are doar 10 pagini (pentru a simplifica calculele) cu 250 de cuvinte pe pagină: aceasta ne oferă o în total 250 de miliarde de cuvinte. Dacă luăm numărul mediu de caractere dintr-un cuvânt ca 5 și codificăm fiecare caracter în 8 biți (sau 1 octet, chiar dacă unele caractere iau de fapt 2 octeți), cheltuind astfel 5 octeți pe cuvânt, atunci indexul care conține doar fiecare cuvânt o dată ar necesita mai mult de 1 terabyte de stocare. Deci, puteți vedea că indexurile care conțin alte informații, cum ar fi seturile de cuvinte, locațiile de date și numărul de utilizări, pot crește în volum foarte repede.

Crearea acestor indici intermediari și prezentarea datelor în bucăți mai mici face ca problema datelor mari să fie mai ușor de rezolvat. Datele pot fi distribuite pe mai multe servere și în același timp pot fi disponibile rapid. Indexurile sunt piatra de temelie a regăsirii informațiilor și fundamentul motoarelor de căutare moderne de astăzi. Desigur, această secțiune este generală doar pe tema indexării și s-au făcut multe cercetări cu privire la modul de a face indexurile mai mici, mai rapide, să conțină mai multe informații (cum ar fi relevanța) și să fie actualizate fără probleme. (Există unele probleme cu gestionarea termenilor concurenți și numărul de actualizări necesare pentru a adăuga date noi sau pentru a modifica datele existente, mai ales atunci când este implicată relevanța sau scorul.)

Posibilitatea de a vă găsi datele rapid și ușor este esențială, iar indexurile sunt cel mai simplu și mai eficient instrument pentru a realiza acest lucru.

Echilibratoare de sarcină

În cele din urmă, o altă parte critică a oricărui sistem distribuit este echilibrarea sarcinii. Echilibratoarele de încărcare sunt o parte esențială a oricărei arhitecturi, deoarece rolul lor este de a distribui încărcătura între nodurile responsabile de servirea cererilor. Acest lucru permite mai multor noduri să servească în mod transparent aceeași funcție în sistem. (Vezi) Scopul lor principal este de a gestiona multe conexiuni concurente și de a direcționa aceste conexiuni către unul dintre nodurile solicitate, permițând sistemului să se extindă prin simpla adăugare de noduri pentru a servi mai multe solicitări.

Figura 1.18: Echilibratorul de încărcare

Există mulți algoritmi diferiți pentru servirea cererilor, inclusiv selectarea aleatorie a nodurilor, round robin sau chiar selecția nodurilor bazate pe anumite criterii, cum ar fi utilizarea CPU sau RAM. Echilibratoarele de sarcină pot fi implementate ca dispozitive hardware sau software. Printre echilibratoarele de încărcare pe software open source, HAProxy este cel mai utilizat.

Într-un sistem distribuit, echilibratoarele de sarcină sunt adesea în partea din față a sistemului, astfel încât toate cererile primite să treacă direct prin ele. Este foarte probabil ca într-un sistem distribuit complex, solicitarea să fie supusă mai multor echilibre de sarcină, așa cum se arată în
.

Figura 1.19: Echilibratoare de sarcină multiple

La fel ca proxy-urile, unii echilibratori de sarcină pot direcționa cererile în mod diferit, în funcție de tipul de cerere. Acestea sunt, de asemenea, cunoscute sub numele de proxy invers.

Gestionarea datelor specifice unei anumite sesiuni de utilizator este una dintre provocările atunci când se utilizează echilibratoarele de sarcină. Pe un site de comerț electronic, când aveți un singur client, este foarte ușor să permiteți utilizatorilor să pună lucrurile în coșul lor și să-și salveze conținutul între vizite (acest lucru este important, deoarece probabilitatea ca un produs să fie vândut crește semnificativ dacă, după utilizatorul revine pe site, produsul este încă în coșul său). Cu toate acestea, dacă un utilizator este direcționat către un site pentru prima sesiune și apoi către un alt site în timpul următoarei sale vizite, atunci pot apărea neconcordanțe, deoarece noul site ar putea să nu aibă date referitoare la conținutul coșului de cumpărături al acelui utilizator. (Nu te-ai supăra dacă ai pune un pachet de Mountain Dew în coș și când te vei întoarce nu va mai fi acolo?) O soluție ar putea fi să faci sesiunile „lipicioase”, astfel încât utilizatorul să fie întotdeauna orientat la fel. nodul. Cu toate acestea, va fi semnificativ dificil să profitați de unele dintre caracteristicile de fiabilitate, cum ar fi reluarea automată la eroare. În acest caz, coșul utilizatorului va avea întotdeauna conținut, dar dacă nodul său lipicios devine indisponibil, atunci va fi necesară o abordare specială, iar presupunerea despre conținutul coșului nu va mai fi adevărată (deși, sperăm, această presupunere nu va avea să fie încorporat în aplicație). Desigur, această problemă poate fi rezolvată cu alte strategii și instrumente descrise în acest capitol, cum ar fi serviciile și multe altele (cum ar fi cache-urile browser-ului, cookie-urile și rescrierea adreselor URL).

Dacă sistemul are doar câteva noduri, atunci tehnicile precum un carusel DNS sunt probabil mai practice decât echilibratoarele de sarcină, care pot fi costisitoare și pot adăuga straturi inutile sistemului. Desigur, sistemele mari au tot felul de algoritmi de planificare și echilibrare a sarcinii, inclusiv simpli, cum ar fi algoritmi de selecție aleatorie sau carusel, precum și mecanisme mai complexe care iau în considerare caracteristicile de performanță ale modelelor de utilizare ale sistemului. Toți acești algoritmi distribuie traficul și solicitările și pot furniza instrumente utile fiabilitate, cum ar fi trecerea la eroare automată sau eliminarea automată a unui nod deteriorat (de exemplu, atunci când acesta nu mai răspunde). Cu toate acestea, aceste funcții avansate pot face dificilă diagnosticarea problemelor. De exemplu, în situații de încărcare ridicată, echilibratoarele de sarcină vor elimina nodurile care pot fi lente sau expirate (din cauza unei valuri de solicitări), ceea ce va exacerba situația doar pentru alte noduri. În aceste cazuri, controlul extins este important deoarece chiar dacă traficul și încărcarea generală a sistemului par să scadă (deoarece nodurile servesc mai puține solicitări), nodurile individuale pot fi supraîncărcate.

Echilibratoarele de sarcină sunt o modalitate simplă de a adăuga capacitate sistemului dumneavoastră. La fel ca celelalte tehnici descrise în acest articol, joacă un rol esențial în arhitectura unui sistem distribuit. Echilibratoarele de sarcină oferă, de asemenea, o funcție critică pentru verificarea stării de sănătate a nodurilor. Dacă, conform rezultatelor unei astfel de verificări, un nod nu răspunde sau este supraîncărcat, atunci acesta poate fi eliminat din grupul de procesare a cererilor și, datorită redundanței sistemului dvs., sarcina va fi redistribuită între restul de lucru noduri.

Cozi

Până în prezent, am analizat multe modalități de a citi rapid datele. În același timp, gestionarea eficientă a înregistrărilor este o altă parte importantă a scalării nivelului de date. Atunci când sistemele sunt simple, cu sarcini minime de procesare și baze de date mici, scrierile pot fi previzibil de rapide. Cu toate acestea, în mai multe sisteme complexe acest proces poate dura mult timp. Deci, de exemplu, este posibil ca datele să fie scrise în mai multe locații pe diferite servere sau indici, sau sistemul poate fi pur și simplu sub sarcină mare. În cazurile în care scrierile sau chiar orice sarcină durează mult, realizarea performanței și disponibilității necesită integrarea asincroniei în sistem. O modalitate obișnuită de a face acest lucru este de a pune la coadă cererile.

Figura 1.20: Cerere sincronă

Imaginați-vă un sistem în care fiecare client solicită o activitate de serviciu la distanță. Fiecare dintre acești clienți trimite cererea către server, care finalizează sarcinile cât mai repede posibil și le returnează rezultatele clienților corespunzători. În sistemele mici, unde un singur server (sau un serviciu logic) poate deservi clienții primiți cât de repede ajung, acest tip de situație ar trebui să funcționeze bine. Cu toate acestea, atunci când serverul primește mai multe solicitări decât poate suporta, atunci fiecare client este obligat să aștepte ca ceilalți clienți să finalizeze procesarea înainte de a genera un răspuns la propria cerere. Acesta este un exemplu de solicitare sincronă descrisă în.

Acest tip de comportament sincron poate degrada semnificativ performanța clientului; de fapt, inactiv, clientul este obligat să aștepte până când primește un răspuns la cerere. Adăugarea de servere suplimentare pentru a face față încărcării sistemului nu rezolvă, de fapt, problema; chiar și cu o echilibrare eficientă a sarcinii la fața locului, este extrem de dificil să se asigure echilibrarea sarcinii uniformă și echitabilă necesară pentru a maximiza productivitatea clienților. Mai mult, dacă serverul nu este disponibil pentru a procesa această solicitare (sau a eșuat), atunci clientul conectat la acesta nu va mai funcționa. O soluție eficientă la această problemă necesită o abstracție între solicitarea clientului și munca efectivă care se face pentru a o deservi.

Figura 1.21: Utilizarea cozilor pentru gestionarea cererilor

Cozi de intrare. Mecanismul cozii este foarte simplu: o sarcină ajunge, intră în coadă și apoi „lucrătorii” acceptă următoarea sarcină imediat ce au ocazia să o proceseze. (A se vedea) Aceste sarcini pot fi la fel de simple precum scrierea într-o bază de date sau la fel de complexe ca generarea unei imagini de previzualizare pentru un document. Atunci când un client trimite solicitări la sarcini de așteptare, nu mai trebuie să aștepte rezultatele execuției; în schimb, solicitările trebuie doar confirmate în mod corespunzător. Această confirmare poate servi ulterior ca referință la rezultatele muncii atunci când clientul le solicită.

Cozile permit clienților să lucreze într-un mod asincron, oferind o abstractizare strategică a cererii și răspunsului unui client. Pe de altă parte, într-un sistem sincron, nu există nicio diferențiere între cerere și răspuns și, prin urmare, nu poate fi controlată separat. Într-un sistem asincron, clientul configurează o sarcină, serviciul răspunde cu un mesaj care confirmă faptul că sarcina a fost primită, iar apoi clientul poate verifica periodic starea sarcinii, solicitând doar rezultatul imediat ce a finalizat. În timp ce clientul face o cerere asincronă, este liber să facă alte lucrări și chiar să facă cereri asincrone către alte servicii. Acesta din urmă este un exemplu al modului în care cozile și mesajele funcționează în sistemele distribuite.

Cozile oferă, de asemenea, o anumită protecție împotriva întreruperilor și refuzurilor de serviciu. De exemplu, este destul de ușor să creați o coadă foarte persistentă care poate repeta solicitările de servicii care au încetat să funcționeze din cauza întreruperilor temporare ale serverului. Este mai preferabil să folosiți o coadă pentru a aplica garanțiile QoS decât pentru a expune clienții la întreruperi temporare ale serviciilor, necesitând gestionarea complexă și adesea inconsistentă a erorilor din partea clientului.

1.4. Concluzie

Dezvoltare a sisteme eficiente cu acces rapid La un numar mare datele sunt un subiect foarte interesant și există încă un număr semnificativ de instrumente bune care vă permit să adaptați tot felul de aplicații noi. Acest capitol a atins doar câteva exemple, dar în realitate există multe altele - și crearea de noi inovații în acest domeniu va continua doar.

Această lucrare este distribuită sub licența Creative Commons Attribution 3.0. Vezi detalii în

Vă rugăm să activați Javascript pentru a utiliza convertorul de unități

›› Mai multe informații de la convertorul de unitate

Câți cfm în 1 metru cub / minut? Răspunsul este 35.314666212661.
Presupunem că faceți conversia între picior cub / minutși metru cub / minut.
Puteți vizualiza mai multe detalii despre fiecare unitate de măsură:
cfm sau metru cub / minut
Unitatea derivată SI pentru debitul volumului este metrul cub / secundă.
1 metru cub / secundă este egal cu 2118.8799727597 cfm, sau 60 de metri cubi / minut.
Rețineți că pot apărea erori de rotunjire, deci verificați întotdeauna rezultatele.
Utilizați această pagină pentru a afla cum să convertiți între picioare cubice / minut și metri cubi / minut.
Introduceți propriile numere în formular pentru a converti unitățile!

›› Diagrama de conversie rapidă de cfm în metru cub / minut

1 cfm la metru cub / minut = 0,02832 metru cub / minut

10 cfm la metru cub / minut = 0.28317 metru cub / minut

20 cfm la metru cub / minut = 0.56634 metru cub / minut

30 cfm la metru cub / minut = 0.84951 metru cub / minut

40 cfm la metru cub / minut = 1,13267 metru cub / minut

50 cfm la metru cub / minut = 1.41584 metru cub / minut

100 cfm la metru cub / minut = 2.83168 metru cub / minut

200 cfm la metru cub / minut = 5.66337 metru cub / minut

›› Vrei alte unități?

›› Definiție: Picior cub / minut

Picioarele cubice pe minut (CFM) este o măsură utilizată în igiena industrială și ingineria ventilației. Descrie viteza de curgere a unui volum de gaz sau aer în sau în afara spațiului.

O măsurătoare standard a fluxului de aer care indică câte metri cubi de aer trec printr-un punct staționar într-un minut. Cu cât numărul este mai mare, cu atât mai mult aer este forțat prin sistem. Debitul volumetric al unui lichid sau gaz în metri cubi pe minut. 1 CFM este egal cu aproximativ 0,47 litri pe secundă.

›› Conversii metrice și multe altele

site oferă un calculator de conversie online pentru toate tipurile de unități de măsură. Puteți găsi tabele de conversie metrice pentru unități SI, precum și unități englezești, monedă și alte date. Introduceți simbolurile unității, abrevierile sau numele complete pentru unitățile de lungime, suprafață, masă, presiune și alte tipuri. Exemplele includ mm, inch, 100 kg, uncie fluidă americană, 6 "3", 10 pietre 4, cm cubi, metri pătrate, grame, alunițe, picioare pe secundă și multe altele!