Ebben a cikkben felvázolunk néhány fogalmat, amelyeket a tokos ventilátor kiválasztásakor használni kell, és beszélünk a különböző típusú ventilátorokra jellemző tulajdonságokról. Emellett tesztelni fogjuk a processzorok és videokártyák tesztelésekor használt 120 mm-es akasa Amber AK-183-L2B ventilátort is, amely több mint egy éve a Thermaltake Sonic Tower processzorhűtőrendszer aktív elemeként szolgál. És meg kell jegyezni, hogy teljes mértékben kiérdemelte a jogot, hogy ő legyen az első hős a rajongóknak szentelt áttekintések sorozatában az erőforrásunkon.

A kérdések, amelyekre megpróbálunk választ adni, a következők...

Milyen követelmények támaszthatók egy házventilátorral szemben?

1. Teljesítményszint.
2. Zajszint.
3. Megjelenés (a háttérvilágítás jelenléte és típusa).
4. További funkciók (PWM tápegység támogatása, fordulatszám-szabályozó, rezgéscsillapító tartó).

Melyek a fő különbségek a tokrajongók között?

1.Méretek– járókerék mérete.

A ház belső szellőzésének létrehozásához a legtöbb esetben szabványos 80 mm, 92 mm vagy 120 mm-es ventilátorokat használnak, mivel kezdetben rögzítőfuratokat biztosítanak a házba való beszerelésükhöz. Nyilvánvaló, hogy minél nagyobb a ventilátor járókereke, annál nagyobb a képessége a levegő áramlására. Ezért a nagyobb modellek hatékonysági szintjének eléréséhez egy kisebb ventilátornak nagyobb sebességgel kell forognia, és ennek megfelelően lényegesen több zajt kell produkálnia. Valójában ezért népszerűek a nagy 120 mm-es ventilátorok.

A tulajdonságok egyértelműbbé tétele érdekében összehasonlíthatja a Xinruilian Science & Technology Co. azonos sorozatú ventilátormodelljeinek jellemzőit. különböző méretűek:

Méret, mm
Sebesség rpm
Légáramlás, CFM
Zajszint, dB
Nyomás, mm H 2 0

A modellek adott jellemzőiből azt a következtetést vonhatjuk le, hogy azonos fordulatszám mellett egy 92 mm-es ventilátor 1,65-ször hatékonyabb, mint egy 80 mm-es, a 120 mm-es ventilátor pedig kétszer olyan hatékony, mint egy 92 mm-es modell. , figyelembe véve azt a tényt, hogy minden ventilátornak egyfajta járókereke van.

A különböző járókerék-átmérők mellett a ventilátor profilmérete vagy mélysége is ugyanolyan fontos. A hagyományos tokok „klasszikus” profilja a 25 mm-es profil. A kisebb profilú ventilátorokat alacsony, míg a nagyobb profilú ventilátorokat magas profilúnak nevezzük. A légáramlás erőssége, amelyet a specifikációban a maximális nyomás értékével jellemeznek, közvetlenül függ a profil méretétől.

Például hasonlítsuk össze két 120 mm-es modell jellemzőit - normál profillal és magas profillal, amelyek azonos forgási sebességgel működnek.

Méret, mm
Sebesség rpm
Légáramlás, CFM
Zajszint, dB
Nyomás, mm H20

A táblázat azt mutatja, hogy a magas profilú ventilátort csak a maximális légáramlási nyomás jobb mutatója különbözteti meg. A hagyományos számítógépes rendszerekben nincs szükség túlnyomás létrehozására, ezért ezeket a ventilátorokat nem használják. A legtöbb esetben nagy profilú ventilátorokat használnak a szerverekben, emellett megnövekedett forgási sebességgel és ennek eredményeként meglehetősen magas működési zajjal rendelkeznek.

2. Csapágy típusa.

A ventilátorok három fő csapágytípust használnak: sikló, kombinált csúszó- és gördülőcsapágyakat, és két gördülőcsapágyból állnak. Az ilyen típusú csapágyak mellett sokkal ritkábban vannak hidrodinamikus típusok, amelyeket egyes gyártók külön-külön fejlesztettek ki.

A csapágy típusát leggyakrabban a következő indexek jelenlétével határozhatja meg a ventilátormodell nevében, bár mindig tanácsos ellenőrizni a hivatalos specifikációt:

S (ujj) – egy csúszócsapágy, amely lényegében egy persely;
VAL VEL (kombó) - egy golyóscsapágy és egy rövid persely;
B (labda) vagy 2B (2 golyó)– két golyóscsapágy.

A legegyszerűbb és legolcsóbb, de sajnos nem különösebben tartós a siklócsapágy. Ez a csapágy úgy néz ki, mint egy kis réz persely, amelyen belül a járókerék tengelye (rúd) forog. Egy új, olajozott siklócsapággyal ellátott ventilátor teljesen csendes lehet, de idővel ez a tulajdonsága elveszhet. Megfelelő kenési szint hiányában a persely elég gyorsan „elhasználódik”, ezért a ventilátor zajt kezd. Ezen túlmenően, kenés hiányában, ha magas hőmérsékletű területen dolgozik, a ventilátor teljesen elakadhat. Ezt a tényt különösen jól mutatják az olcsó kínai tápegységek esetei, amelyekben gyakran előfordult, hogy a ventilátor leállt a siklócsapágyon, ami biztosítja a teljesítmény-félvezető elemek hűtését. Ennek eredményeként az áramellátás meghibásodott.

A csapágy kombinált változatának viszonylag hosszabb a csapágy élettartama.

A két golyóscsapágyból álló csapágy a legdrágább, de ugyanakkor tartósabb is. Az ilyen típusú csapágyak szabadon működhetnek magas hőmérsékletű területeken. Ugyanakkor az ilyen rajongók között gyakran találhatunk olyan példányokat, amelyek meglehetősen hangos és kellemetlen zajt produkálnak. Ez a kép különösen jellemző az olcsó ventilátorokra, mivel az egész szerkezet zajjellemzői közvetlenül függenek a miniatűr csapágy gyártási minőségétől. Ezért, ha golyóscsapágyas terméket választ, semmi esetre se törődjön az olcsóságával, mert a drágább modellek is ritkán csendesek.

3. Motorosztály.

Minden házventilátor négypólusú egyenáramú motorral működik. Sebesség szerint mindegyik három kategóriába sorolható: alacsony fordulatszámú 2000 ford./percig, közepes 2000-3000 ford./perc és nagy sebesség 3000 ford./perc felett. A ventilátormotor osztályát gyakran megtudhatja a nevében szereplő indexből, amelyet gyakran egy matricán jeleznek:

L (alacsony) - alacsony sebesség ( 2000-ig fordulat);
M (középső) - átlagos ( 2000-től 3000-ig fordulat);
H (magas) - Magassebesség ( több mint 3000 fordulat).

Mi jellemzi a gyártók specifikációiban megadott adatokat?

Ventilátor sebesség percenkénti fordulatszámban mérve (RPM - fordulatszám percenként). Mivel maga a ventilátor fordulatszáma a tápfeszültséggel szinte egyenes arányban változhat, ezért a specifikációban megadott érték a névleges tápfeszültségnek felel meg. Minél nagyobb a fordulatszám, annál hatékonyabb a ventilátor, de általában zajosabb is.

Légáramlat CFM-ben (köbláb per perc, CFM) - köbméter per perc vagy köbméter per óra (m 3 / h) -ban jelezhető. Ebben az esetben 1 CFM ≈ 1,7 m 3 / h. Ez az érték a „szivattyúzott” levegő mennyiségét mutatja egy bizonyos időtartam alatt, feltéve, hogy a légáramlással szembeni ellenállás teljesen hiányzik, vagyis a ventilátor mindkét oldalán egyenlő légnyomás mellett. Természetesen minél nagyobb ez az érték, annál jobb.

Légáramlás statikus nyomása A ventilátort általában mm vízoszlopban adják meg, és azt a légáramlási erőt jellemzi, amelyet a ventilátor képes létrehozni.

Emlékezzünk vissza, hogy a nyomás kiszámítása a P=F/S képlettel történik. Ez azt jelenti, hogy a nyomás a légáramlás erejének és annak a területnek az aránya, amelyre hat. A specifikáció azt jelzi, hogy a ventilátor mekkora légáramot hoz létre, ha az ellenállás miatt nem tud légáramlást létrehozni.

A ventilátor teljes jellemzője a „Teljesítménygörbe” grafikonon látható.

A teljesítménygörbe a légáramlás és a nyomás közötti kapcsolatot ábrázolja. A görbe legmagasabb pontja, amely a tengelyen található, nem más, mint a specifikációban megadott maximális nyomás. A görbe legalsó pontja, amely a másik tengelyen fekszik, a ventilátor maximális légáramának felel meg, amikor nem kell nyomást létrehoznia. Valós körülmények között, nevezetesen egy házban, a légáramlásnak le kell győznie bizonyos ellenállást. Minden esetnek megvan a maga ellenállási foka. A rendszer ellenállása meredekségként jelenik meg a grafikonon, az egyenes és a görbe metszéspontja pedig nem más, mint feltételes rendszerünkben a ventilátor működési pontja.

Rajongói élet ezer óra számával mérve, ameddig a ventilátornak működnie kell, és biztosítania kell a deklarált jellemzőket. A cikk szerzője nem tudja teljesen, hogy milyen üzemi körülmények között érik el az adott értékeket, mivel az élettartam közvetlenül függ az üzemi feltételektől. Feltételezhető, hogy a ventilátor a megadott számú órán keresztül képes működni anélkül, hogy elveszítené zajminőségét. Az erőforrás nagymértékben függ a csapágy típusától és minőségétől. A siklócsapágyak esetében általában 30 000 óra, a kombinált csapágyak esetében 45 000 óra, a kettős golyóscsapágyaknál pedig 60 000 óra és a feletti értékeket adnak meg.

A legtöbb esetben egy csúszócsapágyon lévő ventilátor nagyjából egy évig tud csendesen működni, bár a gyártók 30 ezret állítanak, ezért nem szabad elfogultnak lenni ezekkel a számokkal - ezek meglehetősen relatívak. Ha pedig mélyebbre ásunk, kiderül, hogy a gyártó a ventilátorok időszakos karbantartását is feltételezte, pl. olyan kenőanyag, amelyet a hétköznapi felhasználók ritkán állítanak elő.

Most pedig térjünk vissza értékelésünk hőséhez, a rajongóhoz. akasa AK-183-L2Bés nézd meg a specifikációját:

	akasaAK-183-L2B
Méret, mm
Forgási sebesség, rpm
Légáramlás, CFM
Nyomás, mm H20
Erőforrás, h
Csapágy típus	két hinta
	3 tűs
Zajszint, dB
Tápfeszültség, V
Termékek weboldala
átlag ár

Az akasa AK-183-L2B ventilátor átlátszó műanyag csomagolásba van csomagolva. A csomag hátoldalán kék kartonlap található, kiemelve az átlátszó testet és az áttetsző borostyánsárga ventilátorlapátot. Általánosságban elmondható, hogy minden az Akasa Csoporttól megszokott kék és sárga vállalati színekben van díszítve.

A kartonbetét hátoldalán öt különböző nyelvű specifikáció található.

A ventilátoron kívül a csomag legalsó részén egy kis fekete kartondoboz található, amelyen „3-4 tűs adapter” felirat olvasható.

Ezért egyáltalán nem meglepő, hogy a doboz tartalmazott egy adaptert, amely lehetővé teszi a ventilátor csatlakoztatását a perifériás eszközök csatlakozóiról, és ezen felül van egy 3 tűs csatlakozó a ventilátor forgási sebességének szabályozására. Szintén a kis fekete dobozban volt négy csavar a ventilátor házba való felszereléséhez.

Az akasa AK-183-L2B ventilátortest fehér átlátszó műanyagból, járókereke borostyánsárga áttetsző műanyagból készült. Igazából, ha az akasa cég teljes termékpalettáját vesszük figyelembe, akkor ritkán találkozunk egyszerű és standard megoldásokkal, mivel a cég nagyrészt kifejezetten moddolásra tervezett termékeket forgalmaz. De ez egyáltalán nem jelenti azt, hogy ha nem tartja magát moddernek, és megszokta, hogy egy terméket csak gyakorlati okokból értékeljen, akkor ez a ventilátor és más hasonló termékek nem megfelelőek az Ön számára. Valójában az úgynevezett nehéz felhasználók, modderek vagy overlockerek számára készült termékek gyártása során a fokozott figyelem mindenekelőtt a kidolgozás minőségére és annak valamivel magasabb tulajdonságaira vonatkozik. Ezért egyáltalán nem meglepő, hogy az ilyen termékek fogyasztói tulajdonságai szinte mindig magasabbak, mint az egyszerű áruké.

Külsőleg a ventilátor természetesen elsősorban a sárga és fehér színek gyönyörű kombinációjával tűnik ki, és úgy tűnik, hogy egy ilyen ventilátornak egyszerűen kell lennie háttérvilágításnak, de valójában nem. Aerodinamikai szempontból semmi újítást vagy know-how-t nem alkalmaztak a ventilátorban - egy egyszerű hétlapátos járókerék.

Az akasa AK-183-L2B ventilátor alacsony fordulatszámú modell, névleges fordulatszáma 1400 ford./perc, míg a maximális légáramlás elérheti a 44,8 CFM-et, a statikus nyomás pedig 1,1 mm-es vízoszlop. A jellemzők sem nem túl magasak, sem nem egészen hétköznapiak, de ez nem meglepő, hiszen egy otthoni rendszer házventilátora számára mindenekelőtt fokozott zajkövetelményeket támasztanak.

És ebben a tekintetben a specifikáció meglehetősen alacsony, 18 dB-es zajszintet jelez. Megjegyzendő, hogy az akasa AK-183-L2B ventilátor két golyóscsapágyra épül, élettartama a gyártó szerint 80 000 óra. A golyóscsapágyak szokásos értéke 60 000 óra, így a kissé megemelt érték reményt ad a gyártás jobb megközelítésében, mert már korábban is megjegyeztük, hogy a golyóscsapágy minősége határozza meg a zajjellemzőit.

A ventilátort egy 3 tűs tápcsatlakozó táplálja, amely nem támogatja az impulzusszélességű tápegységeket.

Tesztelés

A teszt gyakorlati része a ventilátor névleges fordulatszámon generált légáramának tesztelésének két szakaszából, valamint a térfogatának fülre történő felméréséből áll.

1. számú teszt

Az első tesztben a ventilátor a Thermalright SI-128 hűtő aktív elemeként fog működni. A tesztelés nyitott tokban történik, a fő szabályozott paraméter az Intel Core 2 Duo E6300 processzor 2,8 GHz-re túlhúzott fűtési hőmérséklete és az alaplap hőmérséklete.

2. számú teszt

A második tesztben a ventilátort rendeltetésszerűen a hátsó panelre szerelt házventilátorként használják, és elszívó ventilátorként működnek. A teszt alatt a ház zárva lesz, és nem lesz bekapcsolva más ventilátor. A fő szabályozott paraméter szintén az Intel Core 2 Duo E6300 processzor fűtési hőmérséklete lesz, de immár túlhúzás nélkül, amely Thermaltake Sonic Tower (CL-P0071) passzív hűtőrendszerrel van felszerelve, valamint az alaplap hőmérséklete. A teszt eredményét az Everest alkalmazásban a processzor stressztesztjének 10 perces „futása” után rögzítjük.

Az Intel processzorral ellátott tesztplatform konfigurációja a következő összetevőkből áll:

Alaplap	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 db DDR2-800 1024 MB Apacer PC6400
Videokártya	EVGA GeForce 8600GTS 256 MB DDR3 PCI-E
HDD	Samsung HD080HJ, 80 GB, SATA-300
Optikai meghajtó	ASUS DRW-1814BLT SATA
tápegység	Chieftec CFT-500-A12S 500W, 120 mm-es ventilátor
	CODEGEN M603 MidiTower

Az akasa AK-183-L2B ventilátor a többi versenytárshoz hasonlóan jó teljesítményt nyújt. A meglehetősen alacsony, 18 dB-es deklarált zajszintet csak szubjektív véleményünkkel tudjuk megerősíteni. A jelzett érték valóban teljesen összhangban van a valós zajszinttel - maximális sebességnél enyhe zümmögést ad ki.

Következtetések.

Az akasa AK-183-L2B ventilátor nem kizárólag a modding szép dísze, ahogyan a vásárlónak azonnal tűnhet. Meglehetősen nagy légáramlást tud létrehozni, és ami a legfontosabb, meglehetősen alacsony zajszintet produkál. Ha figyelembe vesszük a golyóscsapágyas ventilátor jó minőségű modelljének elfogadható árát, akkor ebben az árukategóriában ár/fogyasztói minőség arányban az egyik legjobb lesz. Ismételjük meg, hogy tesztlaboratóriumunkban az akasa AK-183-L2B ventilátor már több mint egy éve üzemel, és ezalatt a zajminősége gyakorlatilag változatlan maradt.

Előnyök:

• nagy légáramlást hoz létre;
• alacsony zajszint;
• jó ár/teljesítmény arány.

A hátrányok közé tartozik:

• a PWM támogatás hiánya.

Köszönetünket fejezzük ki a PF Service LLC (Dnepropetrovsk) cégnek a teszteléshez biztosított berendezésekért.

A cikket 4669 alkalommal olvasták

Iratkozzon fel csatornáinkra

Kérjük, engedélyezze a Javascriptet az egységátalakító használatához

›› További információ a mértékegység-átalakítótól

Hány cfm 1 köbméter/perc alatt? A válasz 35.314666212661.
Feltételezzük, hogy között konvertál köbláb/percés köbméter/perc.
Az egyes mértékegységekről további részleteket tekinthet meg:
cfm vagy köbméter/perc
Az SI származtatott mértékegysége térfogatáram a köbméter/másodperc.
1 köbméter/másodperc egyenlő: 2118,8799727597 cfm, vagyis 60 köbméter/perc.
Vegye figyelembe, hogy kerekítési hibák előfordulhatnak, ezért mindig ellenőrizze az eredményeket.
Ezen az oldalon megtudhatja, hogyan lehet átváltani köbláb/perc és köbméter/perc között.
Írja be saját számait az űrlapba a mértékegységek átváltásához!

›› A cfm gyors konverziós diagramja köbméter/perc

1 cfm-köbméter/perc = 0,02832 köbméter/perc

10 cfm-köbméter/perc = 0,28317 köbméter/perc

20 cfm-köbméter/perc = 0,56634 köbméter/perc

30 cfm-köbméter/perc = 0,84951 köbméter/perc

40 cfm-köbméter/perc = 1,13267 köbméter/perc

50 cfm-köbméter/perc = 1,41584 köbméter/perc

100 cfm-köbméter/perc = 2,83168 köbméter/perc

200 cfm-köbméter/perc = 5,66337 köbméter/perc

›› Más egységeket szeretne?

›› Meghatározás: köbláb/perc

A köbméter per perc (CFM) az ipari higiénia és szellőztetés területén használt mérték. Leírja a gáz vagy levegő térfogatának a térbe vagy onnan történő áramlási sebességét.

A légáramlás szabványos mérése, amely azt jelzi, hogy hány köbláb levegő halad el egy álló ponton egy perc alatt. Minél nagyobb ez a szám, annál több levegő áramlik át a rendszeren. Egy folyadék vagy gáz térfogati áramlási sebessége köbláb per percben. 1 CFM körülbelül 0,47 liter másodpercenként.

›› Metrikus konverziók és egyebek

weboldal online konverziós kalkulátort biztosít minden típusú mértékegységhez. Találhat metrikus átváltási táblázatokat az SI-mértékegységekhez, valamint az angol mértékegységekhez, pénznemekhez és egyéb adatokhoz. Írja be a mértékegység szimbólumokat, rövidítéseket vagy teljes neveket a hossz, terület, tömeg, nyomás és egyéb típusok mértékegységeihez. Példák: mm, hüvelyk, 100 kg, amerikai folyadékuncia, 6"3", 10 kő 4, köbcm, négyzetméter, gramm, mol, láb per másodperc és még sok más!

A nyílt forráskódú szoftverek a világ legnagyobb webhelyeinek létrehozásának alapvető építőkövévé váltak. Ezeknek a webhelyeknek a növekedésével bevált gyakorlatok és irányelvek jelentek meg az építészetükhöz. Ez a fejezet a nagy webhelyek tervezése során figyelembe veendő néhány kulcsfontosságú kérdést, valamint az e célok eléréséhez használt alapvető összetevőket kívánja ismertetni.

Ennek a fejezetnek a középpontjában a web alapú rendszerek elemzése áll, bár az anyag egy része extrapolálható más elosztott rendszerekre.

1.1 Az elosztott webes rendszerek felépítésének elvei

Mit jelent pontosan egy méretezhető webhely vagy alkalmazás létrehozása és kezelése? Primitív szinten egyszerűen a felhasználókat távoli erőforrásokhoz kapcsolja az interneten keresztül. És az erőforrások vagy ezekhez az erőforrásokhoz való hozzáférés, amelyek sok szerveren vannak elosztva, és a webhely méretezhetőségét biztosító linket jelentik.

Mint a legtöbb dolog az életben, a webszolgáltatás felépítésének előzetes megtervezésére fordított idő segíthet később; A nagy webhelyek mögött meghúzódó megfontolások és kompromisszumok megértése okosabb döntéseket hozhat kisebb webhelyek készítése során. Az alábbiakban bemutatunk néhány kulcsfontosságú alapelvet, amelyek befolyásolják a nagyméretű webes rendszerek tervezését:

• Elérhetőség: A webhelyek rendelkezésre állása számos vállalat hírneve és funkcionalitása szempontjából kritikus fontosságú. Egyes nagyobb online kereskedők számára, ha akár néhány percig is elérhetetlenek, több ezer vagy több millió dolláros bevételkiesést okozhat. Így a rendszereik olyan fejlesztése, hogy azok mindig elérhetőek legyenek és ellenállóak legyenek a hibákkal szemben, alapvető üzleti és technológiai követelmény. Az elosztott rendszerek magas rendelkezésre állása megkívánja a kulcsfontosságú összetevők redundanciájának gondos mérlegelését, a részleges rendszerhibákból való gyors helyreállítást és a képességek zökkenőmentes korlátozását, ha problémák merülnek fel.
• Teljesítmény: A webhelyek teljesítménye a legtöbb webhely fontos mérőszámává vált. A webhely sebessége befolyásolja a felhasználói élményt és az elégedettséget, valamint a keresőmotorok rangsorolását – ez a tényező közvetlenül befolyásolja a közönségmegtartást és a bevételt. Ennek eredményeként a kulcs egy olyan rendszer létrehozása, amely gyors válaszokra és alacsony késleltetésre van optimalizálva.
• Megbízhatóság: a rendszernek megbízhatónak kell lennie, hogy egy adott adatkérés következetesen meghatározott adatokat adjon vissza. Adatmódosítás vagy frissítés esetén ugyanazon kérésnek új adatokat kell visszaadnia. A felhasználóknak tudniuk kell, hogy ha valamit rögzítenek vagy tárolnak a rendszerben, akkor biztosak lehetnek benne, hogy a helyén marad a későbbi visszakereséshez.
• Méretezhetőség: Ha bármilyen nagy elosztott rendszerről van szó, a méret csak egy elem a listán, amelyet figyelembe kell venni. Ugyanilyen fontosak az átviteli sebesség növelésére irányuló erőfeszítések a nagy mennyiségű munkaterhelés kezelésére, amelyet rendszerint rendszerskálázhatóságnak neveznek. A skálázhatóság a rendszer különféle paramétereire utalhat: a további forgalom mennyiségére, amelyet képes kezelni, mennyire könnyű hozzáadni a tárolókapacitást, vagy mennyivel további tranzakciókat lehet feldolgozni.
• Irányíthatóság: Egy másik fontos tényező a könnyen kezelhető rendszer tervezése. A rendszer menedzselhetősége egyenlő a „karbantartási” és „frissítési” műveletek skálázhatóságával.A kezelhetőség biztosítása érdekében figyelembe kell venni a felmerülő problémák diagnosztizálásának és megértésének egyszerűségét, a frissítés vagy módosítás egyszerűségét, valamint a rendszer egyszerű használatát. (Vagyis az elvárásoknak megfelelően működik, hibák és kivételek nélkül?)
• Ár: A költség fontos tényező. Ez nyilvánvalóan tartalmazhat hardver- és szoftverköltségeket, de fontos figyelembe venni a rendszer telepítéséhez és karbantartásához szükséges egyéb szempontokat is. Biztosítani kell a rendszer felépítéséhez szükséges fejlesztői időt, a rendszer üzembe helyezéséhez szükséges operatív erőfeszítéseket, sőt a megfelelő szintű képzést is. A költség a teljes birtoklási költséget jelenti.

Ezen elvek mindegyike alapot ad a döntéshozatalhoz az elosztott webarchitektúra tervezésénél. Azonban konfliktusba is kerülhetnek egymással, mert az egyik céljainak elérése a másik elhanyagolásának rovására megy. Egy egyszerű példa: a több szerver egyszerű hozzáadásának választása teljesítmény- (skálázhatósági) megoldásként növelheti a kezelési költségeket (további szervert kell futtatnia) és a szervervásárlást.

Bármilyen webalkalmazás fejlesztése során fontos figyelembe venni ezeket a kulcsfontosságú elveket, még akkor is, ha annak megerősítésére van szükség, hogy a projekt feláldozhat ezek közül egyet vagy többet.

1.2 Alapok

A rendszerarchitektúra mérlegelésekor több kérdéssel is foglalkozni kell, például mely összetevőket érdemes használni, hogyan illeszkednek egymáshoz, és milyen kompromisszumokat lehet tenni. Pénzt fektetni a méretezésbe anélkül, hogy egyértelműen szükség lenne rá, nem okos üzleti döntés. Mindazonáltal, a tervezés némi átgondoltsága jelentős időt és erőforrásokat takaríthat meg a jövőben.

Ez a rész néhány alapvető tényezőre összpontosít, amelyek szinte minden nagy webalkalmazás esetében kritikusak: Szolgáltatások,
redundancia, szegmentálás, És hibakezelés. Ezen tényezők mindegyike választásokat és kompromisszumokat foglal magában, különösen az előző részben leírt elvek összefüggésében. A tisztázás kedvéért mondjunk egy példát.

Példa: Képtárhely alkalmazás

Valószínűleg már közzétettél képeket az interneten. A sok képet tároló és szállító nagy webhelyek számára kihívást jelent egy költséghatékony, rendkívül megbízható architektúra létrehozása, amely alacsony válaszidővel rendelkezik (gyors visszakeresés).

Képzeljünk el egy olyan rendszert, ahol a felhasználók fel tudják tölteni képeiket egy központi szerverre, és ahol a képeket webhelyhivatkozáson vagy API-n keresztül lehet lekérni, hasonlóan a Flickrhez vagy a Picasához. A leírás egyszerűsítése érdekében tegyük fel, hogy ennek az alkalmazásnak két fő feladata van: képes képeket feltölteni (írni) a szerverre és képeket kérni. Természetesen a hatékony betöltés fontos kritérium, de a gyors kézbesítés a felhasználók kérésére (például a képeket weboldalon vagy más alkalmazásban megjelenítheti) prioritást élvez. Ez a funkció hasonló ahhoz, amit a webszerver vagy a CDN (Content Delivery Network) élszerver nyújthat. A CDN-kiszolgálók általában több helyen tárolják az adatobjektumokat, így földrajzilag/fizikailag közelebb kerülnek a felhasználókhoz, ami jobb teljesítményt eredményez.

A rendszer további fontos szempontjai:

• A tárolt képek száma korlátlan lehet, ezért a tárolás méretezhetőségét ebből a szempontból kell figyelembe venni.
• A képletöltések/kérések késleltetésének alacsonynak kell lennie.
• Ha egy felhasználó képet tölt fel a szerverre, annak adatainak mindig érintetleneknek és hozzáférhetőknek kell maradniuk.
• A rendszernek könnyen karbantarthatónak (kezelhetőségnek) kell lennie.
• Mivel a képtárolás nem termel sok profitot, a rendszernek költséghatékonynak kell lennie.

Egy másik lehetséges probléma ezzel a kialakítással, hogy egy webszerver, például az Apache vagy a lighttpd általában felső határt szab az egyidejűleg kiszolgálható kapcsolatok számának (az alapértelmezett érték körülbelül 500, de lehet sokkal magasabb is), és nagy forgalommal. , a felvételek gyorsan kimeríthetik ezt a korlátot. Mivel az olvasás lehet aszinkron, vagy kihasználhatja az egyéb teljesítményoptimalizálásokat, például a gzip-tömörítést vagy a darabolást, a webszerver gyorsabban válthat a hírfolyam olvasása között, és válthat a kliensek között, miközben a csatlakozások maximális számánál sokkal több kérést szolgál ki (Apache-val és maximális számú kapcsolattal). 500-ra állítva több ezer olvasási kérés kiszolgálása is lehetséges másodpercenként). A rekordok viszont általában a letöltés teljes időtartama alatt nyitva tartják a kapcsolatot. Így egy 1 MB-os fájl átvitele a szerverre a legtöbb otthoni hálózaton több mint 1 másodpercig tarthat, ami azt eredményezi, hogy a webszerver csak 500 egyidejű bejegyzést tud feldolgozni.

1.2. ábra: Írás/olvasás szétválasztás

Ennek a lehetséges problémának az előrejelzése azt sugallja, hogy a képolvasást és -írást független szolgáltatásokra kell különíteni, amint az látható. Ez lehetővé teszi számunkra, hogy ne csak egyenként skálázzuk mindegyiket (mivel valószínű, hogy mindig többet fogunk olvasni, mint írni), hanem azt is, hogy tisztában legyünk az egyes szolgáltatásokban zajló eseményekkel. Végül megkülönbözteti a jövőben felmerülő problémákat, megkönnyítve a lassú olvasási hozzáférés problémájának diagnosztizálását és értékelését.

Ennek a megközelítésnek az az előnye, hogy képesek vagyunk egymástól függetlenül megoldani a problémákat – anélkül, hogy aggódnunk kellene az új képek ugyanabban a kontextusban történő rögzítéséről és előhívásáról. Mindkét szolgáltatás továbbra is globális képtömböt használ, de szolgáltatás-specifikus technikák használatával képesek optimalizálni saját teljesítményüket (például a kérések sorba állításával vagy a népszerű képek gyorsítótárazásával – erről később). Mind a szolgáltatás, mind a költség szempontjából az egyes szolgáltatások igény szerint egymástól függetlenül méretezhetők. És ez egy pozitív dolog, mivel ezek kombinálása és keverése véletlenül befolyásolhatja a teljesítményüket, mint a fent leírt forgatókönyvben.

Természetesen a fenti modell akkor működik optimálisan, ha két különböző végpont létezik (sőt, ez nagyon hasonlít a felhőalapú tárolási szolgáltatók és a Content Delivery Networks számos megvalósításához). Az ilyen problémák megoldásának számos módja van, és minden esetben lehet kompromisszumot találni.

Például a Flickr úgy oldja meg ezt az olvasási-írási problémát, hogy a felhasználókat különböző podokra osztja el úgy, hogy mindegyik pod csak korlátozott számú meghatározott felhasználót tud kiszolgálni, és ahogy a felhasználók száma növekszik, egyre több pod kerül a fürtbe (lásd a Flickr skálázási bemutatóját ,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). Az első példában könnyebb a hardvert a tényleges használati terhelés (az olvasások és írások száma a teljes rendszerben) alapján skálázni, míg a Flickr a felhasználói bázis alapján skáláz (ez azonban az egyenletes használat feltételezését használja különböző felhasználók, ezért a kapacitást a készletnek megfelelően kell megtervezni). Régebben az egyik szolgáltatás elérhetetlensége vagy probléma a teljes rendszer funkcionalitását tönkretette (például senki sem tudott fájlokat írni), akkor az egyik Flickr modul elérhetetlensége csak a hozzá tartozó felhasználókat érintette. Az első példában egyszerűbb a teljes adatkészleten végrehajtani a műveleteket - például frissíteni a rögzítési szolgáltatást új metaadatokkal, vagy az összes kép metaadatában keresni -, míg a Flickr architektúra esetén minden modult frissíteni vagy keresni kellett ( vagy létre kellett hozni a keresőszolgáltatást a ténylegesen erre a célra szánt metaadatok rendezéséhez).

Ami ezeket a rendszereket illeti, nincs csodaszer, de mindig a jelen fejezet elején leírt alapelvek alapján kell eljárni: határozza meg a rendszerigényeket (olvasási vagy írási terhelés vagy mindkettő, párhuzamosság szintje, lekérdezések adatkészletekre, tartományokra, rendezésre, stb.), végezzen összehasonlító benchmark tesztelést a különböző alternatívákra, ismerje meg a lehetséges rendszerhiba-körülményeket, és átfogó tervet dolgozzon ki hiba esetén.

Redundancia

A hibák kecses kezeléséhez a webarchitektúrának redundanciával kell rendelkeznie a szolgáltatásokban és az adatokban. Például, ha egy fájlnak csak egy példánya van egyetlen szerveren tárolva, a szerver elvesztése a fájl elvesztését jelenti. Nem valószínű, hogy ez pozitív helyzet, és általában több másolat vagy biztonsági másolat készítésével elkerülhető.

Ugyanez az elv vonatkozik a szolgáltatásokra is. Az egyetlen csomópont meghibásodása ellen úgy védekezhet, hogy az alkalmazás funkcióinak szerves részét képezi, így biztosítva, hogy az alkalmazás több példánya vagy verziója futhasson egyidejűleg.

A redundancia létrehozása a rendszerben lehetővé teszi, hogy megszabaduljon a gyenge pontoktól, és vészhelyzet esetén tartalék vagy redundáns funkciókat biztosítson. Például, ha ugyanannak a szolgáltatásnak két példánya fut élesben, és az egyik teljesen vagy részben meghibásodik, a rendszer úgy tudja leküzdeni a hibát munkapéldányra váltás.
A váltás történhet automatikusan vagy kézi beavatkozást igényel.

A szolgáltatási redundancia másik kulcsszerepe a létrehozás olyan architektúra, amely nem biztosítja az erőforrások megosztását. Ezzel az architektúrával minden csomópont képes önállóan működni, ráadásul központi „agy” hiányában, amely más csomópontok állapotait irányítja vagy koordinálja. Elősegíti a méretezhetőséget, mivel új csomópontok hozzáadása nem igényel különleges feltételeket vagy ismereteket. És ami a legfontosabb, ezekben a rendszerekben nincs kritikus hibapont, így sokkal ellenállóbbak a meghibásodásokkal szemben.

Például a képszerver-alkalmazásunkban az összes képnek redundáns másolata van valahol egy másik hardverben (ideális esetben egy másik földrajzi helyen katasztrófa, például földrengés vagy adatközponti tűz esetén), és a szolgáltatások A képekhez való hozzáférés redundáns lesz, mivel mindegyik potenciálisan kéréseket fog kiszolgálni. (cm..)
A jövőre nézve a terheléselosztók nagyszerű lehetőséget nyújtanak ennek lehetővé tételére, de erről alább olvashat bővebben.

1.3 ábra: Redundáns képtárhely alkalmazás

Szegmentáció

Az adatkészletek olyan nagyok lehetnek, hogy nem helyezhetők el egyetlen szerveren. Az is előfordulhat, hogy a számítási műveletek túl sok számítógépes erőforrást igényelnek, ami csökkenti a teljesítményt és megnövelt teljesítményt tesz szükségessé. Mindenesetre két lehetőség közül választhat: függőleges vagy vízszintes méretezés.

A függőleges méretezés azt jelenti, hogy több erőforrást kell hozzáadni egyetlen szerverhez. Tehát egy nagyon nagy adatkészlet esetén ez több (vagy nagyobb) merevlemez hozzáadását jelentené, hogy a teljes adatkészlet elférjen egyetlen szerveren. Számítási műveletek esetén ez azt jelentené, hogy a számítást egy nagyobb, gyorsabb CPU-val vagy több memóriával rendelkező szerverre kell áthelyezni. Mindenesetre vertikális skálázás történik annak érdekében, hogy egyetlen számítási rendszer erőforrás legyen képes további adatfeldolgozásra.

A vízszintes méretezés viszont további csomópontok hozzáadásával jár. Nagy adathalmaz esetén ez egy második szerver hozzáadását jelentené a teljes adatmennyiség egy részének tárolására, egy számítási erőforrás esetében pedig a munka vagy a terhelés felosztását néhány további csomópont között. A vízszintes skálázásban rejlő lehetőségek teljes kihasználása érdekében ezt a rendszerarchitektúra belső tervezési elveként kell megvalósítani. Ellenkező esetben a horizontális méretezéshez szükséges kontextus megváltoztatása és elkülönítése problémás lehet.

A vízszintes skálázás leggyakoribb módszere a szolgáltatások szegmensekre vagy modulokra bontása. Eloszthatók oly módon, hogy minden egyes logikai funkciókészlet külön-külön működjön. Ezt megtehetik földrajzi határok vagy más kritériumok, például fizető és nem fizető felhasználók. Ezeknek a sémáknak az az előnye, hogy bővített funkcionalitású szolgáltatást vagy adattárat biztosítanak.

Képszerver-példánkban lehetséges, hogy a kép tárolására használt egyetlen fájlszervert több fájlszerver helyettesítheti, amelyek mindegyike saját egyedi képkészletet tartalmaz. (Lásd.) Ez az architektúra lehetővé teszi a rendszer számára, hogy minden fájlkiszolgálót képekkel töltsön fel, és a lemezterület megteltével további szervereket adjon hozzá. A tervezéshez szükség lesz egy elnevezési sémára, amely a képfájl nevét társítja az azt tartalmazó kiszolgálóhoz. A képnév létrehozható a kiszolgálókhoz kötött konzisztens kivonatolási sémából. Másik megoldásként minden képnek lehet egy növekményes azonosítója, amely lehetővé teszi a kézbesítő szolgáltatás számára, hogy képkérésekor csak az egyes szerverekhez társított azonosítók tartományát dolgozza fel (indexként).

1.4. ábra: Képtárhely alkalmazás redundanciával és szegmentálással

Természetesen nehézségekbe ütközik az adatok vagy a funkciók sok szerver közötti elosztása. Az egyik kulcskérdés az adatok helye; Az elosztott rendszerekben minél közelebb vannak az adatok a műveleti vagy számítási ponthoz, annál jobb a rendszer teljesítménye. Következésképpen az adatok több szerver között történő elosztása potenciálisan problémás, mivel bármikor szükség lehet az adatokra, fennáll annak a veszélye, hogy nem érhetők el a kívánt helyen, a szervernek költséges lekérést kell végeznie a szükséges információkból. a hálózat.

Egy másik lehetséges probléma a formában merül fel
következetlenség (inkonzisztencia) Amikor a különböző szolgáltatások olvasnak és írnak egy megosztott erőforrást, esetleg egy másik szolgáltatást vagy adattárat, előfordulhat egy „versenyfeltétel” – amikor bizonyos adatokat a legfrissebb állapotra frissítettnek tekintünk, de ténylegesen elolvasásra kerülnek, mielőtt megtörténne. frissítve – ebben az esetben az adatok inkonzisztensek. Például egy képtárolási forgatókönyv esetén versenyhelyzet fordulhat elő, ha az egyik ügyfél kérelmet küldött egy kutya képének frissítésére, a „Kutya” címet „Gizmo”-ra változtatva, miközben egy másik ügyfél a képet olvasta. Ilyen helyzetben nem világos, hogy a második ügyfél melyik címet, a "Kutyát" vagy a "Gizmot" kapta volna meg.

Természetesen vannak akadályok az adatszegmentációval kapcsolatban, de a szegmentálás lehetővé teszi az egyes problémák elkülönítését a többitől: adatok, terhelés, használati minták stb. kezelt blokkokba. Ez segíthet a méretezhetőségben és a kezelhetőségben, de továbbra is fennáll a kockázat. Számos módja van a kockázat csökkentésének és a hibák kezelésének; a rövidség kedvéért azonban ezekkel a fejezet nem foglalkozik. Ha többet szeretne tudni erről a témáról, tekintse meg a hibatűrésről és felügyeletről szóló blogbejegyzést.

1.3. Építőelemek a gyors és méretezhető adathozzáféréshez

Miután megvizsgáltuk az elosztott rendszerfejlesztés néhány alapelvét, térjünk át egy összetettebb kérdésre - az adathozzáférés skálázására.

A legegyszerűbb webalkalmazások, például a LAMP verem-alkalmazások hasonlóak a -ban található képhez.

1.5. ábra: Egyszerű webalkalmazások

Az alkalmazások növekedésével két fő kihívás merül fel: az alkalmazáskiszolgálóhoz és az adatbázishoz való hozzáférés méretezése. A nagymértékben méretezhető alkalmazástervezésben a web- vagy alkalmazásszerver általában minimálisra van csökkentve, és gyakran erőforrás-megosztó architektúrát valósít meg. Ez vízszintesen méretezhetővé teszi a rendszer alkalmazáskiszolgálói rétegét. Ennek a kialakításnak köszönhetően a nehézemelés a veremben lefelé tolódik az adatbázis-kiszolgálóra és a támogató szolgáltatásokra; Ez az a réteg, ahol a valódi méretezési és teljesítményproblémák lépnek életbe.

A fejezet további része az adatokhoz való gyors hozzáférés biztosításával az ilyen típusú szolgáltatások teljesítményének és méretezhetőségének javítására szolgáló legáltalánosabb stratégiákat és technikákat ismerteti.

1.6. ábra: Egyszerűsített webalkalmazás

A legtöbb rendszer leegyszerűsíthető áramkörre
amely jó hely a keresés megkezdéséhez. Ha sok adattal rendelkezik, nyugodtan feltételezheti, hogy azt szeretné, ha olyan könnyen és gyorsan elérhető lenne, mint a felső íróasztal fiókjában lévő cukorka doboz. Bár ez az összehasonlítás túlságosan leegyszerűsítő, két összetett problémára világít rá: az adattárolás skálázhatóságára és a gyors adathozzáférésre.

Ebben a szakaszban tegyük fel, hogy sok terabájtnyi (TB) adata van, és lehetővé teszi a felhasználók számára, hogy véletlenszerű sorrendben hozzáférjenek az adatok kis részeihez. (cm..)
Hasonló feladat egy képfájl helyének meghatározása valahol egy fájlkiszolgálón egy minta képtárhely alkalmazásban.

1.7. ábra: Hozzáférés konkrét adatokhoz

Ez különösen nehéz, mert a terabájtnyi adat memóriába való betöltése nagyon költséges lehet, és közvetlenül befolyásolja a lemez I/O-ját. A lemezről történő olvasás sebessége többszöröse a RAM-ból történő olvasás sebességének – elmondhatjuk, hogy a memória elérése olyan gyors, mint Chuck Norris, míg a lemez elérése lassabb, mint a klinikán lévő sor. Ez a sebességkülönbség különösen nagy adathalmazok esetén észrevehető; Nyers számokban a memória-hozzáférés 6-szor gyorsabb, mint a lemezolvasás szekvenciális olvasás esetén, és 100 000-szer gyorsabb a véletlenszerű olvasásoknál (lásd Patologies of Big Data, http://queue.acm.org/detail. cfm?id=1563874). ). Sőt, még egyedi azonosítók esetén is olyan nehéz lehet egy kis adat megtalálásának problémáját megoldani, mintha az utolsó csokoládéval töltött bonbont próbálnánk kivenni egy több száz cukorkát tartalmazó dobozból anélkül, hogy megnéznénk.

Szerencsére számos megközelítés létezik a dolgok egyszerűsítésére, a négy legfontosabb megközelítés a gyorsítótárak, proxy-k, indexek és terheléselosztók használata. A rész további része azt tárgyalja, hogy ezek a fogalmak hogyan használhatók fel az adatok gyorsabb elérésére.

Gyorsítótárak

A gyorsítótárazás előnyt jelent az alapelv egy jellemzőjéből: a közelmúltban kért adatokra valószínűleg ismét szükség lesz. A gyorsítótárak a számítástechnika szinte minden szintjén használatosak: hardver, operációs rendszer, webböngésző, webalkalmazás stb. A gyorsítótár olyan, mint a rövid távú memória: korlátozott méretű, de gyorsabb, mint az eredeti adatforrás, és a közelmúltban elért elemeket tartalmazza. A gyorsítótárak az architektúra minden szintjén létezhetnek, de gyakran az előtérhez legközelebbi szinten találhatók, ahol úgy vannak megvalósítva, hogy jelentős háttérterhelés nélkül gyorsan visszaadják az adatokat.

Tehát hogyan használható a gyorsítótár az adathozzáférés felgyorsítására példa API-n belül? Ebben az esetben több megfelelő gyorsítótárhely is létezik. Az egyik lehetséges elhelyezési lehetőség a csomópontok kijelölése a lekérdezés szintjén, amint az ábra mutatja
.

1.8. ábra: Gyorsítótár elhelyezése lekérdezési szintű csomóponton

A gyorsítótár közvetlenül a kérésszintű csomóponton történő elhelyezése lehetővé teszi a válaszadatok helyi tárolását. Minden alkalommal, amikor szolgáltatáskérést küldenek, a csomópont gyorsan visszaadja a helyi, gyorsítótárazott adatokat, ha vannak ilyenek. Ha nincs a gyorsítótárban, akkor a kérési csomópont lekéri az adatokat a lemezről. Az egyetlen lekérdezési szintű csomópont gyorsítótára is elhelyezhető a memóriában (ami nagyon gyors), vagy a csomópont helyi lemezén (gyorsabb, mint a hálózati tárolóhoz való hozzáférés kísérlete).

1.9. ábra: Cache rendszerek

Mi történik, ha a gyorsítótárat több csomópontra osztja szét? Amint látható, ha a kérési szint sok csomópontot tartalmaz, akkor valószínű, hogy minden csomópontnak saját gyorsítótára lesz. Ha azonban a terheléselosztó véletlenszerűen osztja el a kéréseket a csomópontok között, akkor ugyanaz a kérés különböző csomópontokhoz fog eljutni, így nő a gyorsítótár hiányosságai. Az akadály leküzdésének két módja a globális és az elosztott gyorsítótárak.

Globális gyorsítótár

A globális gyorsítótár jelentése egyértelmű a névből: minden csomópont egyetlen gyorsítótárterületen osztozik. Ebben az esetben olyan kiszolgálót vagy fájltárolót ad hozzá, amely gyorsabb, mint az eredeti tárhely, és amely minden kérelemszintű csomópont számára elérhető lesz. A kéréscsomópontok mindegyike ugyanúgy lekérdezi a gyorsítótárat, mintha az helyi lenne. Az ilyen típusú gyorsítótárazási séma problémákat okozhat, mivel egyetlen gyorsítótár nagyon könnyen túlterhelhető, ha az ügyfelek és a kérések száma növekszik. Ugyanakkor ez a séma nagyon hatékony bizonyos architektúrákon (különösen azokon, amelyek speciális hardverekhez kapcsolódnak, amelyek nagyon felgyorsítják ezt a globális gyorsítótárat, vagy amelyek rögzített adatkészlettel rendelkeznek, amelyeket gyorsítótárazni kell).

A diagramokon a globális gyorsítótárak két szabványos formája látható. A bemutatott helyzet az, hogy ha a gyorsítótárban lévő válasz nem található a gyorsítótárban, maga a gyorsítótár lesz felelős az adatok hiányzó részének lekéréséért az alapul szolgáló tárolóból. Az Illusztrált a kérelmező csomópontok felelőssége a gyorsítótárban nem található adatok lekérése.

1.10. ábra: Globális gyorsítótár, ahol a gyorsítótár felelős a visszakeresésért

1.11. ábra: Globális gyorsítótár, ahol a kérés csomópontok felelősek a visszakeresésért

A legtöbb globális gyorsítótárat kihasználó alkalmazás általában az első típust használja, ahol a gyorsítótár maga kezeli a cserét és az adatok lekérését, hogy megakadályozza, hogy az ügyfelek elárasszák az azonos adatokra vonatkozó kéréseket. Vannak azonban olyan esetek, amikor a második megvalósítás értelmesebb. Például, ha a gyorsítótárat nagyon nagy fájlokhoz használják, az alacsony gyorsítótár-lekérési arány miatt a puffer-gyorsítótár túlterhelődik a gyorsítótár hiányával; ebben a helyzetben segít, ha a teljes adatkészlet (vagy forró adatkészlet) nagy százaléka a gyorsítótárban található. Egy másik példa egy olyan architektúra, amelyben a gyorsítótárban tárolt fájlok statikusak, és nem szabad őket törölni. (Ez előfordulhat az ilyen adatkésleltetéssel kapcsolatos teljesítményjellemzők miatt – előfordulhat, hogy az adatok bizonyos részeinek nagyon gyorsaknak kell lenniük nagy adathalmazokhoz –, ahol az alkalmazás logikája jobban megérti a helyettesítési stratégiát vagy a hotspotokat, mint a gyorsítótár.)

Elosztott gyorsítótár

Ezeket az indexeket gyakran a memóriában tárolják, vagy a bejövő klienskéréshez nagyon lokális helyen. A Berkeley DB (BDB) és fa adatstruktúrák, amelyeket jellemzően az adatok rendezett listákban való tárolására használnak, ideálisak az indexelt hozzáféréshez.

Az indexek gyakran több rétegből állnak, amelyek térképként működnek, áthelyezik Önt egyik helyről a másikra, és így tovább, amíg meg nem szerzi a szükséges adatot. (cm.)

1.17. ábra: Többszintű indexek

Az indexek több más nézet létrehozására is használhatók ugyanarról az adatról. Nagy adathalmazok esetén ez nagyszerű módja annak, hogy különböző szűrőket és nézeteket határozzon meg anélkül, hogy sok további másolatot kellene létrehoznia az adatokról.

Tegyük fel például, hogy a fent említett képtárolási rendszer valójában könyvoldalak képeit tárolja, és a szolgáltatás lehetővé teszi az ügyfelek számára, hogy lekérdezzenek ezeken a képeken található szövegeket, és ugyanúgy keressenek egy adott témában található szöveges tartalmat, ahogyan azt a keresőmotorok lehetővé teszik. HTML tartalom kereséséhez. Ebben az esetben ezek a könyvképek sok szervert használnak a fájlok tárolására, és elég nehéz lehet egyetlen oldalt megtalálni, amelyet bemutathat a felhasználónak. Kezdetben a fordított indexeknek könnyen elérhetőnek kell lenniük tetszőleges szavak és szókészletek lekérdezéséhez; majd ott van a feladat, hogy navigáljon a könyvben a pontos oldalra és helyre, és keresse meg a megfelelő képet a keresési eredményekhez. Tehát ebben az esetben az invertált index leképezné a helyet (például a B könyvet), majd B tartalmazhatja az indexet az összes szóval, helyekkel és előfordulások számával az egyes részekben.

Egy fordított index, amelyet az Index1 jeleníthet meg a fenti diagramon, valahogy így nézne ki: Minden szó vagy szókészlet indexként szolgál az azokat tartalmazó könyvekhez.

A köztes index hasonlóan fog kinézni, de csak a B könyv szavait, helyét és információit tartalmazza. Ez a réteges architektúra lehetővé teszi, hogy minden index kevesebb helyet foglaljon el, mintha mindezt az információt egyetlen nagy, fordított indexben tárolnák.

Ez pedig kulcsfontosságú pont a nagyméretű rendszerekben, mert még tömörítve is elég nagyok lehetnek ezek az indexek és költséges a tárolásuk. Tételezzük fel, hogy ebben a rendszerben sok könyvünk van a világ minden tájáról – 100 000 000 (lásd az "Inside Google Books" blogbejegyzést) -, és minden könyv csak 10 oldal hosszú (a számítások egyszerűsítése érdekében), oldalanként 250 szóval: nekünk összesen 250 milliárd szó. Ha egy szó átlagos karakterszámát 5-nek vesszük, és minden karaktert 8 bittel kódolunk (vagy 1 bájttal, bár egyes karakterek valójában 2 bájtot foglalnak el), így szónként 5 bájtot költünk, akkor az egyes karaktereket tartalmazó index szó csak egyszer 1 terabájtnál nagyobb tárolást igényelne. Így láthatja, hogy az olyan indexek, amelyek más információkat is tartalmaznak, például szókészleteket, adathelyeket és felhasználási számokat, nagyon gyorsan megnőhetnek.

Az ilyen köztes indexek létrehozása és az adatok kisebb darabokban történő bemutatása megkönnyíti a big data probléma megoldását. Az adatok több szerver között is eloszthatók, ugyanakkor gyorsan elérhetők. Az indexek jelentik az információkeresés sarokkövét és a mai modern keresők alapját. Ez a rész persze csak a felszínét kaparja az indexelés témájának, és rengeteg kutatás folyt arra vonatkozóan, hogyan lehet az indexeket kisebbre, gyorsabbra, több információt (például relevanciát) tartalmazó, könnyen frissíthetővé tenni. (Van néhány probléma a versengő feltételek kezelésével, valamint az új adatok hozzáadásához vagy a meglévő adatok módosításához szükséges frissítések számával, különösen, ha relevanciáról vagy pontozásról van szó).

Az adatok gyors és egyszerű megtalálása fontos, és az indexek a legegyszerűbb és leghatékonyabb eszköz ennek a célnak az eléréséhez.

Terheléselosztók

Végül minden elosztott rendszer másik kritikus része a terheléselosztó. A terheléselosztók minden architektúra alapvető részét képezik, mivel szerepük a terhelés elosztása a kérések kiszolgálásáért felelős csomópontok között. Ez lehetővé teszi, hogy több csomópont transzparensen szolgálja ugyanazt a funkciót a rendszerben. (Lásd.) Fő céljuk, hogy sok egyidejű kapcsolatot kezeljenek, és ezeket a kapcsolatokat a kért csomópontok egyikéhez irányítsák, lehetővé téve a rendszer méretezését egyszerűen csomópontok hozzáadásával több kérés kiszolgálásához.

1.18. ábra: Terheléselosztó

Számos különböző algoritmus létezik a kérések kiszolgálására, beleértve a véletlenszerű csomópont-kiválasztást, a körmérést vagy akár a csomópont-kiválasztást bizonyos kritériumok alapján, például CPU- vagy RAM-használat alapján. A terheléselosztók hardvereszközként vagy szoftverként is megvalósíthatók. A nyílt forráskódú szoftveres terheléselosztók közül a HAProxy a legszélesebb körben használt.

Egy elosztott rendszerben a terheléselosztók gyakran a rendszer "elülső szélén" helyezkednek el, így minden bejövő kérés közvetlenül rajtuk keresztül halad át. Nagyon valószínű, hogy egy összetett elosztott rendszerben egy kérésnek több kiegyenlítőn kell keresztülmennie, amint az az ábrán látható
.

1.19. ábra: Több terheléselosztó

A proxykhoz hasonlóan egyes terheléselosztók is eltérő módon irányíthatják a kéréseket a kérés típusától függően. Fordított proxyk néven is ismertek.

Egy adott felhasználói munkamenetre jellemző adatok kezelése az egyik kihívás a terheléselosztók használatakor. Egy e-kereskedelmi webhelyen, ha csak egy vásárlója van, nagyon könnyen engedélyezheti a felhasználóknak, hogy árukat helyezzenek a kosarukba, és elmentsék a tartalmat a látogatások között (ez azért fontos, mert a termék eladásának valószínűsége jelentősen megnő, ha a felhasználó visszatér az oldalra, a termék még mindig a kosarában van). Ha azonban a felhasználót az első munkamenetben egy csomópontra irányítják, majd a következő látogatáskor egy másik csomópontra, akkor következetlenségek léphetnek fel, mivel az új csomópont nem ismeri az adott felhasználó bevásárlókosarának tartalmát. (Nem lennél ideges, ha betesz egy csomag Mountain Dew-t a kosaradba, és amikor visszajössz, az nincs ott?) Az egyik megoldás az lehet, hogy a munkameneteket "ragadóssá" tesszük, hogy a felhasználó mindig ugyanahhoz a csomóponthoz kerüljön. Néhány megbízhatósági funkció, például az automatikus feladatátvétel előnyeinek kihasználása azonban jelentősen nehézkes lesz. Ebben az esetben a felhasználó kosarának mindig lesz tartalma, de ha a ragadós csomópontja elérhetetlenné válik, akkor speciális megközelítésre lesz szükség, és a kosár tartalmára vonatkozó feltételezés többé nem lesz igaz (bár remélhetőleg ez a feltételezés nem épül be az alkalmazás). Természetesen ez a probléma megoldható más stratégiákkal és eszközökkel, például a jelen fejezetben leírtakkal, például szolgáltatásokkal, és sok mással (például böngésző gyorsítótárai, cookie-k és URL-ek átírása).

Ha a rendszernek csak néhány csomópontja van, akkor az olyan technikák, mint a DNS-körhinta, valószínűleg praktikusabbak, mint a terheléselosztók, amelyek drágák lehetnek, és szükségtelenül összetettebbé teszik a rendszert. Természetesen a nagy rendszerekben mindenféle ütemezési és terheléselosztási algoritmus létezik, beleértve az olyan egyszerű dolgokat, mint a véletlenszerű besorolás vagy a körhinta, a bonyolultabb mechanizmusokig, amelyek figyelembe veszik a rendszer használati mintájának teljesítményjellemzőit. Mindezek az algoritmusok lehetővé teszik a forgalom és a kérések elosztását, és hasznos megbízhatósági eszközöket biztosíthatnak, például automatikus hibatűrést vagy egy meghibásodott csomópont automatikus eltávolítását (például amikor az nem válaszol a kérésekre). Ezek a fejlett funkciók azonban megnehezíthetik a problémák diagnosztizálását. Például nagy terhelési helyzetekben a terheléselosztók eltávolítják azokat a csomópontokat, amelyek esetleg lassan futnak vagy lejárnak az időzítésben (a kérelmek özöne miatt), ami csak rontja a többi csomópont helyzetét. Ezekben az esetekben fontos a kiterjedt figyelés, mert bár a rendszer általános forgalmának és terhelésének csökkenése látszik (mivel a csomópontok kevesebb kérést szolgálnak ki), előfordulhat, hogy az egyes csomópontok korlátaikra nyúlnak.

A terheléselosztók egyszerű módszert jelentenek a rendszer kapacitásának növelésére. A cikkben ismertetett többi módszerhez hasonlóan ez is alapvető szerepet játszik az elosztott rendszer architektúrában. A terheléselosztók a csomópontok állapotának ellenőrzésének kritikus funkcióját is ellátják. Ha egy ilyen ellenőrzés eredményeként egy csomópont nem válaszol vagy túlterhelt, akkor eltávolítható a kérésfeldolgozási készletből, és a rendszer redundanciájának köszönhetően a terhelés újraelosztásra kerül a többi működő csomópont között. .

Sorok

Eddig számos módot megvizsgáltunk az adatok gyors olvasására. Ugyanakkor az adatréteg skálázásának másik fontos része a hatékony iratkezelés. Ha a rendszerek egyszerűek, minimális feldolgozási terhelést és kis adatbázisokat tartalmaznak, az írás kiszámíthatóan gyors lehet. Bonyolultabb rendszerekben azonban ez a folyamat korlátlan ideig tarthat. Például előfordulhat, hogy az adatokat több helyre kell írni különböző szervereken vagy indexeken, vagy a rendszer egyszerűen nagy terhelés alatt áll. Azokban az esetekben, amikor az írás, vagy akár bármilyen feladat hosszú időt vesz igénybe, a teljesítmény és a rendelkezésre állás eléréséhez aszinkronizálást kell beépíteni a rendszerbe. Ennek gyakori módja egy kérési sor szervezése.

1.20. ábra: Szinkron kérés

Képzeljünk el egy rendszert, amelyben minden ügyfél távoli szolgáltatási feladatot kér. Mindegyik kliens elküldi kérését a szervernek, amely a lehető leggyorsabban elvégzi a feladatokat, és visszaküldi az eredményeket a megfelelő ügyfeleknek. Kis rendszerekben, ahol egyetlen szerver (vagy logikai szolgáltatás) képes kiszolgálni a bejövő ügyfeleket, amint azok megérkeznek, az ilyen jellegű helyzeteknek jól kell működniük. Ha azonban a szerver több kérést kap, mint amennyit kezelni tud, akkor minden kliens kénytelen megvárni a többi kliens kérésének befejezését, mielőtt a saját kérésére választ generálna. Ez egy példa egy szinkron kérésre, amelyet a .

Az ilyen típusú szinkron viselkedés jelentősen ronthatja az ügyfél teljesítményét; valójában tétlenül az ügyfél kénytelen megvárni, amíg választ nem kap a kérésre. További szerverek hozzáadása a rendszerterheléssel való megbirkózáshoz valójában nem oldja meg a problémát; Még a hatékony terheléselosztás mellett is rendkívül nehéz az ügyfél termelékenységének maximalizálásához szükséges egyenletes és igazságos terheléselosztást biztosítani. Ezenkívül, ha a kérést feldolgozó szerver nem elérhető (vagy összeomlott), akkor a hozzá csatlakozó kliens is leáll. A probléma hatékony megoldásához absztrakcióra van szükség az ügyfél kérése és a kiszolgálása érdekében végzett tényleges munka között.

1.21. ábra: Várólisták használata kérések kezelésére

Belépési sorok. A sor működése nagyon egyszerű: egy feladat érkezik, bekerül a sorba, majd a „dolgozók” amint lehetőségük van feldolgozni, elfogadják a következő feladatot. (Lásd.) Ezek a feladatok lehetnek egyszerű adatbázis-bejegyzések, vagy olyan összetett dolgok, mint egy dokumentum előnézeti képének létrehozása. Amikor egy ügyfél feladatkéréseket küld egy sorba, többé nem kell várnia a végrehajtási eredményekre; ehelyett a kéréseknek csak meg kell erősíteniük, hogy megfelelően kapták meg őket. Ez a visszaigazolás később hivatkozásként szolgálhat a munkaeredményekre, amikor az ügyfél kéri.

A sorok lehetővé teszik az ügyfelek számára, hogy aszinkron módon dolgozzanak, stratégiai absztrakciót biztosítva az ügyfél kéréséről és válaszáról. Másrészt egy szinkron rendszerben nincs különbség a kérés és a válasz között, ezért nem kezelhetők külön. Aszinkron rendszerben a kliens beküld egy feladatot, a szolgáltatás egy üzenettel válaszol, amely megerősíti, hogy a feladat megérkezett, majd a kliens időszakonként ellenőrizheti a feladat állapotát, és csak a befejezés után kéri le az eredményt. Amíg a kliens aszinkron kérést intéz, szabadon végezhet más munkát, sőt aszinkron kéréseket is intézhet más szolgáltatásoktól. Ez utóbbi egy példa arra, hogyan működnek a sorok és az üzenetek elosztott rendszerekben.

A várólisták bizonyos védelmet is nyújtanak a szolgáltatás megszakítása és meghibásodása ellen. Például nagyon könnyű létrehozni egy nagyon rugalmas sort, amely újrapróbálhatja azokat a szolgáltatáskéréseket, amelyek pillanatnyi szerverhiba miatt meghiúsulnak. A szolgáltatás minőségi garanciáinak érvényesítésére előnyösebb sorokat használni, ahelyett, hogy az ügyfeleket ideiglenes szolgáltatáskimaradásoknak tennénk ki, ami bonyolult és gyakran inkonzisztens hibakezelést igényel az ügyféloldalon.

1.4. Következtetés

A nagy mennyiségű adathoz gyors hozzáférést biztosító hatékony rendszerek fejlesztése nagyon érdekes téma, és még mindig jelentős számú jó eszköz létezik, amelyek mindenféle új alkalmazást képesek befogadni. Ez a fejezet csak néhány példát érintett, de a valóságban sokkal több van – és az új innovációk ezen a területen csak tovább születnek.

Ez a munka a Creative Commons Nevezd meg! 3.0 módosítatlan licenc alatt áll rendelkezésre. Lásd a részleteket a

• Fordítás

A szűk keresztmetszetek áteresztőképességének mérése egy csomag kettős áthaladási ideje alapján

Mindent összevetve a mai internet nem képes olyan gyorsan mozgatni az adatokat, mint kellene. A legtöbb mobilhasználó a világon néhány másodperctől néhány percig terjedő késéseket tapasztal: a reptereken és konferenciákon a nyilvános WiFi hotspotok még rosszabbak. A fizikusoknak és az éghajlatkutatóknak petabájtnyi adatot kell megosztaniuk kollégáikkal szerte a világon, de úgy találják, hogy kidolgozott több gigabites infrastruktúrájuk gyakran csak néhány megabitet termel másodpercenként transzkontinentális kapcsolatokon keresztül.

Ezek a problémák az 1980-as években a TCP-torlódás létrejöttekor hozott építészeti döntésekből adódnak, amikor a csomagvesztést "torlódásként" értelmezték. E fogalmak egyenértékűsége akkoriban igaz volt, de csak a technológiai korlátok miatt, és nem definíció szerint. Ahogy a NIC-ek (hálózati interfészvezérlők) megabitről gigabitre, a memóriachipek pedig kilobájtról gigabájtra bővültek, a csomagvesztés és a torlódás közötti kapcsolat kevésbé egyértelmű.

A modern TCP-ben a csomagvesztés torlódásos szabályozása - még a maga nemében a legfejlettebb technológiában, a CUBIC-ban is - a problémák fő oka. Ha a szűk keresztmetszet-pufferek túl nagyok, a csomagvesztés-torlódás-szabályozás telten tartja őket, ami szükségtelen hálózati pufferelést okoz. Ha a pufferek túl kicsik, a csomagvesztés-torlódás-ellenőrző rendszer helytelenül értelmezi a csomagvesztést torlódási jelként, ami csökkenti az áteresztőképességet. Ezeknek a problémáknak a megoldásához a csomagvesztés torlódások szabályozásának alternatívája szükséges. Ennek az alternatívának a megtalálásához meg kell értenie, hol és hogyan fordul elő torlódás.

Torlódás és szűk keresztmetszet

Egy adott időpontban csak egy leglassabb link van egy (full duplex) TCP-kapcsolatban, ill palacknyak minden irányban. A szűk keresztmetszet a következő okok miatt fontos:

• Meghatározza a maximális adatátviteli sebességet a kapcsolaton keresztül. Ez a tömörítetlen adatfolyam fő tulajdonsága (például képzeljünk el egy hatsávos autópályát csúcsforgalomban, ha egy baleset miatt az út egy kis szakasza csak egy sávra korlátozódik. A baleset előtti forgalom nem halad gyorsabban, mint a forgalom ezen a sávon keresztül.
• Ez az a hely, ahol folyamatosan sorok alakulnak ki. Csak akkor csökkennek, ha a szűk keresztmetszetből kilépő áramlás intenzitása meghaladja a bejövő áramlás intenzitását. A maximális bitsebességgel futó kapcsolatoknál a szűk keresztmetszet felé kimenő összes folyam mindig nagyobb kimenő áramlási sebességgel rendelkezik, így a sorok a szűk keresztmetszet felé haladnak.

Függetlenül attól, hogy hány kapcsolat van egy összeköttetésben, és mi az egyéni sebességük, TCP szempontból egy tetszőlegesen összetett útvonal egyetlen kapcsolatként jelenik meg, azonos RTT-vel (oda-vissza úti idővel) és szűk keresztmetszetű átviteli sebességgel. Két fizikai korlát RTprop(oda-vissza terjedési idő, kettős csomagtovábbítási idő) és BtlBw(szűk keresztmetszeti sávszélesség) befolyásolják az átviteli teljesítményt. (Ha a hálózati út egy anyagcső lenne, az RTprop a cső hossza, a BtlBw pedig az átmérője).

Az 1. ábra az RTT és az adatátviteli sebesség különféle kombinációit mutatja az adatmennyiséggel repülés közben, azaz berepülés (az adatok elküldve, de kézbesítési visszaigazolás nélkül). A kék vonalak az RTprop határt, a zöld vonalak a BtlBw határt, a piros vonalak pedig a szűk keresztmetszet puffert mutatják. A szürke területeken végzett műveletek nem lehetségesek, mert legalább egy korlátozásnak ellentmondanak. A korlátozások közötti átmenet három régió (alkalmazás-korlátozott, sávszélesség-korlátozott és puffer-korlátozott) kialakulásához vezetett, amelyek minőségileg eltérő viselkedést mutatnak.

1. kép

Ha nincs elegendő adat repülés közben a cső feltöltéséhez, az RTprop meghatározza a viselkedést; egyébként a BtlBw dominál. A korlátozó vonalak a pontban metszik egymást, más néven BDP-csövek (a sávszélesség-késleltetés szorzata, az áteresztőképesség és a késleltetés származéka). Mivel a cső e pont után megtelik, a többlet egy sort hoz létre a szűk keresztmetszethez, ami lineáris kapcsolatot eredményez az RTT és a bejárati adatok között a felső grafikonon. A csomagokat eldobjuk, ha a többlet meghaladja a pufferkapacitást. Torlódás egyszerűen folyamatosan a BDP vonaltól jobbra van, és torlódások szabályozása- valamilyen séma, amely korlátozza, hogy a BDP vonaltól átlagosan jobbra mennyivel történik az adatátvitel.

A veszteség alapú torlódásvezérlés a sávszélesség-korlátozott régió jobb szélén működik, teljes szűk keresztmetszeti kapacitást biztosítva magas késleltetés és gyakori csomagvesztés árán. Azokban az időkben, amikor a memória drága volt, a puffer mérete csak valamivel volt nagyobb, mint a BDP, ami minimálisra csökkentette a veszteséges torlódásvezérlés túlzott késleltetését. A memóriaárak későbbi csökkenése a szükségtelen hálózati pufferelés növekedéséhez és az RTT-nek ezredmásodpercek helyett másodpercekre való növekedéséhez vezetett.

A csatorna kapacitása által korlátozott terület bal szélén a jobbnál jobb feltételekkel rendelkező üzemi pont található. 1979-ben Leonard Kleinrock kimutatta, hogy ez a működési pont optimális; maximalizálja a tényleges átvitelt, miközben minimalizálja a késéseket és a veszteségeket, mind az egyes kapcsolatok, mind a hálózat egésze esetében. Sajnos, nagyjából ugyanebben az időben Jeffrey Yaffe bebizonyította, hogy lehetetlen olyan elosztott algoritmust létrehozni, amely ezen a munkaponton konvergál. Ez a megállapítás megváltoztatta a kutatás irányát. Ahelyett, hogy olyan elosztott algoritmust kerestek volna, amely az optimális Kleinrock-működési pontra törekszik, a kutatók elkezdték feltárni a torlódások csökkentésének alternatív megközelítéseit.

Google-csapatunk naponta órákat tölt a TCP-fejléc rögzítési naplóinak tanulmányozásával a világ minden tájáról, megértve az anomáliákat és a kóros viselkedést. Általában először az útvonal legfontosabb jellemzőit keressük, az RTprop és a BtlBw. Az, hogy a hálózati nyomokból kikövetkeztethetők, arra utal, hogy Jaffe következtetése nem biztos, hogy olyan egyértelmű, mint korábban gondolták. Következtetése alapvető mérési bizonytalanságon alapul (például, hogy az RTT mért növekedését az úthossz változása, a szűk keresztmetszetek kapacitásának csökkenése vagy a sorban állási késések növekedése okozza-e egy másik kapcsolatról érkező forgalom miatt). Bár az egyes mérések bizonytalanságát nem lehet kiküszöbölni, a kapcsolat időbeli viselkedése világosabb képet ad, ami a bizonytalanság kiküszöbölésére tervezett mérési stratégiák alkalmazásának lehetőségére utal.

Ha ezeket a méréseket egy robusztus szervo hurokkal kombináljuk, és kihasználjuk a vezérlőrendszerek legújabb fejlesztéseit, reménykedhetünk abban, hogy olyan elosztott torlódáskezelési protokollt fejlesztünk ki, amely inkább a tényleges torlódásra reagál, nem pedig a csomagvesztésre vagy a pillanatnyi várakozási sor késésekre. És nagy valószínűséggel konvergál az optimális Kleinrock működési ponton. Így kezdődött három éves projektünk egy olyan torlódáskezelő rendszer kifejlesztésére, amely az útvonalat jellemző két paraméter mérésén alapul: a szűk keresztmetszetek kapacitása és a csomagok oda-vissza úti ideje, vagyis a BBR.

Szűk keresztmetszet jellemzői

Egy kapcsolat akkor működik maximális átviteli teljesítménnyel és minimális késleltetéssel, ha a (sebességegyensúly) csomagok érkezési aránya a szűk keresztmetszetben egyenlő BtlBw-vel, és a (teljes kapcsolat) teljes adat a repülés során egyenlő BDP().

Az első feltétel biztosítja a szűk keresztmetszet 100%-os kihasználását. A második biztosítja, hogy elegendő adat álljon rendelkezésünkre ahhoz, hogy megakadályozzuk a szűk keresztmetszetek leállását, de ne terheljük túl a csatornát. Maga a sebesség egyensúly feltétele Nem nem garantálja a várakozási sort, csak az állandó méretét (például ha egy kapcsolat úgy kezdődik, hogy egy 10 csomagból álló kezdeti ablakot küld egy ötcsomagos BDP-re, majd pontosan ugyanolyan szűk keresztmetszeti sebességgel fut, akkor a tíz kezdeti csomagból öt kitölti a csatornát, és a felesleg szűk keresztmetszetben álló sort képez, amely nem tud feloldódni). Hasonlóképpen, a teljes kapcsolat feltétele nem garantálja, hogy nincs várólista (például egy kapcsolat BDP-t küld börsztökben a BDP/2-n keresztül, és teljes mértékben kihasználja a szűk keresztmetszetet, de az átlagos sor BDP/4). Az egyetlen módja annak, hogy minimálisra csökkentsük a szűk keresztmetszetnél és a teljes kapcsolaton keresztüli sorban állást, ha mindkét feltételt egyszerre teljesítjük.

A BtlBw és RTprop értékek a kapcsolat élettartama során változnak, ezért ezeket folyamatosan értékelni kell. Jelenleg a TCP figyeli az RTT-t (az adatcsomag elküldése és a kézbesítés jelentése közötti időintervallumot), mert ez szükséges a veszteségek meghatározásához. Bármikor,

ahol az útvonalon lévő sorok „zajt”, a fogadó nyugtázási késleltetési stratégiáját, nyugtázási zsúfoltságot stb. Az RTprop a kapcsolat fizikai tulajdonsága, és csak akkor változik, ha maga a csatorna változik. Mivel a csatornaváltások időskálán történnek ≥ RTprop, akkor az idő elfogulatlan és hatékony becslése lenne
azaz időablakban fut (ami jellemzően több tíz másodperctől percig tart).

Ellentétben az RTT-vel, a TCP-specifikációkban semmi sem igényel implementációt a szűk keresztmetszetek átviteli sebességének nyomon követéséhez, de ennek jó becslése a kézbesítési sebesség nyomon követésével érhető el. Amikor egy csomag kézbesítésének visszaigazolása visszaérkezik a feladóhoz, az megmutatja a csomag RTT-jét, és bejelenti az adatok kézbesítését repülés közben, amikor a csomag elindul. A csomag küldése és a nyugtázás fogadása közötti átlagos kézbesítési sebesség a kézbesített adatok és az eltelt idő aránya: . Ennek az aránynak kisebbnek vagy egyenlőnek kell lennie, mint a szűk keresztmetszet-kapacitás (az érkezési mennyiség pontosan ismert, tehát minden bizonytalanság benne van, aminek nagyobbnak vagy egyenlőnek kell lennie, mint a valós érkezési intervallum; ezért az aránynak kisebbnek vagy egyenlőnek kell lennie a valós kézbesítési sebesség, amely viszont sorban áll, felülről a szűk keresztmetszet kapacitása korlátozza). Ezért a maximális kézbesítési sebesség ablak a BtlBw hatékony, elfogulatlan becslése:

ahol az időablak jellemzően hat és tíz RTT között van.

A TCP-nek rögzítenie kell az egyes csomagok elküldésének idejét az RTT kiszámításához. A BBR kiegészíti ezeket a rekordokat a szállított adatok teljes mennyiségével, így az egyes nyugtázások érkezése mind az RTT-t, mind a kézbesítési sebesség mérésének eredményét jelenti, amelyet a szűrők RTprop és BtlBw becslésekké alakítanak át.

Ne feledje, hogy ezek az értékek teljesen függetlenek: az RTprop változhat (például amikor az útvonal változik), de ugyanazt a szűk keresztmetszetet szenvedi el, vagy a BtlBw változhat (például amikor a vezeték nélküli csatorna kapacitása megváltozik) anélkül, hogy megváltoztatná az útvonalat. (Mindkét moderáló tényező függetlensége az oka annak, hogy ezeket ismerni kell ahhoz, hogy a szállítási viselkedést a szállítási útvonalhoz kapcsolhassuk). Mivel az RTprop csak a BDP bal oldalán, a BtlBw pedig csak a jobb oldalon látható az 1. ábrán, rájuk a bizonytalansági elv vonatkozik: amikor a kettő közül az egyik mérhető, a másik nem mérhető. Intuitív módon ez a következőképpen értelmezhető: egy csatorna kapacitásának meghatározásához túl kell tölteni, ami egy olyan sort hoz létre, amely lehetetlenné teszi a csatorna hosszának mérését. Például előfordulhat, hogy egy kérelem/válasz protokollt használó alkalmazás soha nem küld elegendő adatot a csatorna kitöltéséhez és a BtlBw figyeléséhez. Egy nagy adattömb többórás átvitele minden idejét egy korlátozott sávszélességű területen töltheti, és csak egyetlen RTprop mintát kap az első csomag RTT-jéből. A benne rejlő bizonytalanság elve azt jelenti, hogy a két útvonalparaméter rekonstruálásához szükséges becsléseken túlmenően olyan állapotoknak kell lenniük, amelyek egyszerre követik nyomon azt, hogy mit lehet megtanulni az aktuális üzemi ponton, és az információ kevésbé frissessége miatt hogyan lehet eljutni a működési ponthoz. ahol frissebb adatokhoz lehet hozzájutni.

Csomagfolyam hozzárendelése szállítási útvonalhoz

Az alapvető BBR algoritmus két részből áll:

Amikor megerősítést kapunk (ack)

Minden megerősítés új RTT-t és átlagos szállítási sebesség mérést ad, amely frissíti az RTprop és BtlBw becsléseket:

Függvény onAck(csomag) rtt = most - csomag.küldési idő frissítés_min_szűrő(RTpropFilter, rtt) kézbesítve += csomag.méret szállítási_idő = most szállításRate = (szállítási idő - csomag.szállítási_idő) if (deliveryBwFil Btl. currentMax || ! packet.app_limited) update_max_filter(BtlBwFilter, deliveryRate) if (app_limited_ig > 0) app_limited_until = app_limited_amíg - packet.size
Az if-ellenőrzés az utolsó bekezdésben tárgyalt bizonytalansági probléma miatt szükséges: a küldőket korlátozhatja az alkalmazás, ami azt jelenti, hogy az alkalmazás kifogyhat a hálózat kitöltéséhez szükséges adatokból. Ez egy meglehetősen tipikus helyzet a kérés/válasz forgalom miatt. Ha van lehetőség a küldésre, de nem küldenek adatokat, a BBR a megfelelő sávszélesség-mintákat "alkalmazáskorlátozott"-ként, azaz app_limitedként jelöli meg (lásd send() pszeudokód). Ez a kód határozza meg, hogy mely minták szerepeljenek az átviteli modellben, hogy az inkább a hálózati korlátokat tükrözze, mint az alkalmazáskorlátokat. A BtlBw a bejuttatási sebesség kemény felső korlátja, ezért a BtlBw jelenlegi becslésénél nagyobb mért bejuttatási sebesség a BtlBw alulbecslését jelenti, függetlenül attól, hogy a minta alkalmazásra korlátozott volt-e vagy sem. Ellenkező esetben az alkalmazás által korlátozott mintákat a rendszer eldobja. (Az 1. ábra azt mutatja, hogy a deliveryRate alkalmazási korlátozással rendelkező régióban a BtlBw paraméter alulbecsült). Ezek az ellenőrzések megakadályozzák, hogy a BtlBw szűrő túl alacsony értékekkel töltse fel a BtlBw szűrőt, ami lelassíthatja az adatok küldését.

Amikor adatot küldenek

Annak érdekében, hogy a csomagok érkezési sebességét a szűk keresztmetszetből való távozás sebességével össze lehessen hangolni, a BBR nyomon követi az egyes adatcsomagokat. (A BBR-nek egyeznie kell mérték szűk keresztmetszet: ez azt jelenti, hogy a követés az architektúra szerves része és a működés alapvető része - tehát pacing_rate a fő szabályozási paraméter. Segédparaméter cwnd_gainösszeköt repülés közben egy kis BDP-készlettel a tipikus hálózati és vevőpatológiák kezelésére (lásd alább a késleltetett és elnyújtott nyugtázásról szóló fejezetet). Elméletileg a TCP küldési eljárása a következő kódhoz hasonlít. (Linuxon az adatküldés egy hatékony sorba állítási eljárást, az FQ/pacinget használ, amely lineáris, egykapcsolatos BBR-teljesítményt biztosít több gigabites kapcsolatokon, és több ezer kisebb sebességű kapcsolatot kezel elhanyagolható CPU-ráfordítás mellett.)

Send(packet) függvény bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin if (inflight >= cwnd_gain × bdp) // várjon visszaigazolásra vagy újraküldési időtúllépésre return if (now >= nextSendTime) packet = nextPacketToSend() if (! packet_limit) appuntil_limit = inflight return packet.app_limited = (app_limited_until > 0) packet.sendtime = most packet.delivered = kézbesítve packet.delivered_time = szállítási_idő szállítás(csomag) nextSendTime = most + packet.size / (pacing_gain × BtlBwFilter.currentAtback) nextSendTime)
Állandó állapotú viselkedés

A BBR-n keresztül küldött adatok sebessége és mennyisége csak a BtlBw-től és az RTprop-tól függ, így a szűrők nem csak a szűk keresztmetszet-kényszer becsléseket, hanem azok alkalmazását is szabályozzák. Ez létrehozza a 2. ábrán látható egyéni vezérlőhurkot, amely az RTT-t (kék), a bejárati időt (zöld) és a kézbesítési sebességet (piros) mutatja 700 ezredmásodperc alatt egy 10 Mbites 40 ezredmásodperces adatfolyam esetén. A szállítási sebesség feletti vastag szürke vonal a BtlBw max szűrő állapota. A háromszög alakzatokat úgy kapjuk meg, hogy a BBR-ben a pacing_gain tényezőt ciklusba állítjuk, hogy meghatározzuk a BtlBw növekedését. A ciklus minden részében az erősítés az általa érintett adatokhoz igazítva jelenik meg. Ez a tényező korábban az adatok elküldésekor működött az RTT-n. Ezt mutatják a vízszintes gerincek a bal oldali eseménysor leírásában.

2. ábra

A BBR minimalizálja a késleltetést, mivel az idő nagy részét ugyanazzal a BDP-vel töltik működés közben. Emiatt a szűk keresztmetszet a küldő felé mozdul el, így a BtlBw növekedése észrevehetetlenné válik. Következésképpen a BBR időnként az RTprop intervallumot pacing_gain > 1 értékre tölti, ami növeli a küldési sebességet és a kézbesítés megerősítése nélkül küldött adatok mennyiségét (berepülés). Ha a BtlBw nem változik, akkor a szűk keresztmetszet előtt sor jön létre, növelve az RTT-t, ami változatlan marad a szállítási rátában. (A várakozási sor kiküszöbölhető kompenzáló pacing_gain értékű adatok küldésével< 1 для следующего RTprop). Если BtlBw увеличивается, то скорость deliveryRate тоже увеличивается, а новое максимальное значение фильтра немедленно увеличивает базовую скорость отслеживания (pacing_rate). Emiatt a BBR exponenciálisan gyorsan alkalmazkodik az új szűk keresztmetszetek méretéhez. A 3. ábra ezt a hatást mutatja egy 10 Mbps-os 40 ms-os adatfolyamon, amelyet a BtlBw 20 másodperces folyamatos működés után hirtelen 20 Mbps-ra növel (a grafikon bal oldalán), majd 10 Mbps-ra csökken további 20 másodperces, 20 Mbit/s-os folyamatos működés után (jobbra). a grafikon oldala).

3. ábra

(Lényegében a BBR a "max-plus" vezérlőrendszer egyszerű példája, a vezérlési rendszerek új megközelítése, amely nem szabványos max-plus algebrán alapul. Ez a megközelítés lehetővé teszi a sebesség adaptációját [erősítéssel vezérelve max] a sor növekedésétől függetlenül [átviteli arány vezérli átlagos]. Ha a problémánkra alkalmazzuk, ez egy egyszerű, feltétel nélküli vezérlőkörbe vezet le, ahol a fizikai korlátok változásaihoz való alkalmazkodás automatikusan megtörténik a megszorításokat kifejező szűrők megváltoztatásával. Egy hagyományos rendszerhez sok vezérlőhurok létrehozására lenne szükség, amelyeket egy összetett állapotgéppel kombinálnak, hogy ezt az eredményt elérjék).

Viselkedés egyetlen BBR-szál futtatásakor

A modern megvalósítások számos kódsorral rendelkező „esemény” algoritmusok segítségével kezelik az olyan eseményeket, mint az indítás, leállítás és veszteség-helyreállítás. A BBR a fenti kódot használja (az előző fejezetben, "Csomagfolyam illesztése szállítási útvonalhoz") mindenre. Az események feldolgozása „állapotok” sorozatán keresztül történik. Magukat az „állapotokat” egy táblázat határozza meg, amely egy vagy több rögzített együtthatóértéket és kilépési kritériumot tartalmaz. Az idő nagy részét ProbeBW állapotban tölti, amelyet az „Állandó állapotú viselkedés” című fejezet ismertet. Az Indítás és a Leürítés állapotok a kapcsolat indításakor használatosak (4. ábra). Egy olyan kapcsolat kezeléséhez, ahol az átviteli sebesség 12 nagyságrenddel nő, az indítási állapot egy bináris keresési algoritmust valósít meg a BtlBw számára, amely átviteli tényezőt használ az átviteli sebesség megduplázására, amikor a kézbesítési sebesség nő. Ez határozza meg a BtlBw-t az RTT-ben, ugyanakkor szükségtelen sort hoz létre -ig. Amint a Startup megtalálja a BtlBw-t, a BBR rendszer Drain állapotba lép, amely a Startup inverz erősítését használja fel, hogy megszabaduljon a felesleges várakozási sortól, majd a ProbeBW állapotba lép, amint a járat a BDP vonalra esik.

4. ábra

A 4. ábra egy 10 Mbps 40 ms sebességű BBR adatfolyam első másodpercét mutatja. A felső grafikon mutatja az események időpontját és sorrendjét, valamint a küldő (zöld) és a címzett (kék) előrehaladását: a továbbított és fogadott adatok mennyiségét. A piros vonal a küldő CUBIC teljesítményét mutatja azonos feltételek mellett. Függőleges szürke vonalak jelzik a BBR állapotok közötti átmeneti időt. Az alsó grafikon mindkét kapcsolat esetén a csomagok oda-vissza úti idejének (RTT) változását mutatja. Vegye figyelembe, hogy ennek a grafikonnak az időskálája megfelel az érkezési visszaigazolás (ack) kézhezvételének időpontjának. Ezért a grafikonok időben eltoltnak tűnhetnek, de valójában az alábbi események azoknak a pillanatoknak felelnek meg, amikor a BBR rendszer tudomást szerez ezekről az eseményekről és reagál.

A 4. ábra alsó grafikonja összehasonlítja a BBR-t és a CUBIC-ot. A viselkedésük eleinte szinte megegyezik, de a BBR teljesen kiüríti a kapcsolat indításakor keletkezett sort, míg a CUBIC ezt nem tudja megtenni. Nem rendelkezik nyomkövetési modellel, amely megmondaná, hogy az elküldött adatok mekkora része redundáns. Ezért a CUBIC kevésbé agresszívan növeli a kézbesítés visszaigazolása nélküli adatátvitelt, de ez a növekedés addig folytatódik, amíg a szűk keresztmetszet-puffer túlcsordul és el nem kezdi a csomagokat, vagy amíg el nem éri a fogadó korlátját a megerősítés nélküli adatküldésre (TCP fogadási ablak).

Az 5. ábra az RTT viselkedését mutatja az előző 4. ábrán bemutatott kapcsolat első nyolc másodpercében. A CUBIC technológia (pirossal) kitölti a teljes rendelkezésre álló puffert, majd néhány másodpercenként 70% és 100% között megtelik. A kapcsolat elindítása után a BBR (zöld színben) gyakorlatilag sor létrehozása nélkül működik.

5. ábra

Viselkedés, amikor több BBR-szál találkozik egy szűk keresztmetszetben

A 6. ábra azt mutatja, hogy a többszörös BBR-folyamok átviteli sebessége hogyan konvergál a 100 megabit/10 ezredmásodperces szűk keresztmetszetű kapcsolat megfelelő szakaszán. A lefelé néző háromszög alakú struktúrák a ProbeRTT kapcsolatok állapotai, amelyekben az önszinkronizálás felgyorsítja az esetleges konvergenciát.

6. ábra

A ProbeBW erősítési ciklusai (2. ábra) arra ösztönzik a nagyobb áramlásokat, hogy adják fel a sávszélességet kisebb áramlásoknak, így mindegyik folyam megérti a megfelelő állapotát. Ez elég gyorsan megtörténik (több ProbeBW ciklus), bár a méltánytalanság továbbra is fennállhat, ha a későn induló szálak túlbecsülik az RTprop-ot, mivel a korábbi szálak (ideiglenesen) létrehoznak egy sort.

A valódi RTProp meghatározásához az adatfolyamot a BDP sor bal oldalára helyezik a ProbeRTT állapot használatával: ha az RTProp becslés sok másodpercig nem frissül (vagyis egy kisebb RTT mintavételével), akkor a BBR belép a ProbeRTT-be. állapotba, négy csomagra csökkentve az elküldött (inflight) adatmennyiséget legalább egy dupla menetre, majd visszatér az előző állapotba. Amikor nagy szálak lépnek ProbeRTT állapotba, sok csomag sorra kerül, így több szál is látja az új RTprop értéket (az új minimális RTT-t). Ez egyidejűleg nullára állítja az RTprop becsléseiket, így mindannyian együtt lépnek ProbeRTT állapotba – és a várólista még tovább zsugorodik, amitől még több szál látja az új RTprop értéket, és így tovább. Ez az elosztott koordináció kulcsfontosságú tényező mind a méltányos sávszélesség-allokáció, mind a stabilitás szempontjából.

A BBR szinkronizálja a szálakat a kívánt esemény körül, amely egy szűk keresztmetszetben lévő üres sor. Ezzel a megközelítéssel ellentétben a csomagvesztési torlódások szabályozása szinkronizálja a nem kívánt események körüli folyamokat, mint például a periodikus sornövekedés és a puffertúlcsordulás, ami növeli a várakozási időt és a csomagvesztést.

B4 WAN bevezetésében szerzett tapasztalat a Google-nál

A Google B4-es hálózata egy nagy sebességű WAN (nagy kiterjedésű hálózat), amely közönséges olcsó switchekre épül. Ezeken a kis pufferes kapcsolókon a veszteségek elsősorban a kis forgalom időnkénti beáramlása miatt következnek be. 2015-ben a Google megkezdte az éles forgalom áttelepítését a CUBIC-ról a BBR-re. Nem jelentettek problémákat vagy regressziókat, és 2016 óta az összes B4 TCP-forgalom BBR-t használ. A 7. ábra szemlélteti az egyik okot, amiért ez így történt: a BBR átviteli sebessége folyamatosan 2-25-ször nagyobb, mint a CUBIC-é. Még nagyobb javulást tapasztaltunk, de azt tapasztaltuk, hogy a BBR-kapcsolatok 75%-át korlátozta a rendszermagban lévő TCP fogadópuffer, amelyet a hálózati kezelők szándékosan alacsony értékre (8 MB) állítottak be, hogy megakadályozzák, hogy a CUBIC elárassza a hálózatot megabájtokkal. túlzott forgalom kézbesítési visszaigazolás nélkül (ha 8 MB-ot eloszt 200 ms-os interkontinentális RTT-vel, akkor a maximális sebesség 335 Mbps). A vételi puffer manuális növelése egy USA-Európa útvonalon azonnal 2 Gbps-ra növelte a BBR adatátviteli sebességet, míg a CUBIC 15 Mbps maradt - ezt a 133-szoros relatív átviteli sebességnövekedést Mathis és munkatársai 1997-ben jósolták meg tudományos munkájuk során.

7. ábra

A 7. ábra a BBR relatív javulását mutatja a CUBIC-hoz képest; Inset: kumulatív eloszlási függvények (CDF) a kapacitáshoz. A mérések egy aktív érzékelő szolgáltatással készültek, amely állandó BBR és CUBIC kapcsolatokat nyit meg távoli adatközpontok felé, majd percenként 8 MB adatot továbbít. A szondák számos B4-es útvonalat kutatnak Észak-Amerika, Európa és Ázsia között.

A hatalmas javulás a BBR közvetlen eredménye Nem csomagvesztést használ a torlódás jelzőjeként. A teljes átvitel eléréséhez a meglévő csomagvesztés-torlódás-ellenőrzési módszerek megkövetelik, hogy a veszteség aránya kisebb legyen, mint a BDP fordított négyzete (például 10 Gbps-os, 100 ms-os kapcsolat esetén kevesebb, mint egy veszteség 30 millió csomagonként). A 8. ábra összehasonlítja a mért használható áteresztőképességet különböző csomagvesztési szinteken. A CUBIC algoritmusban a csomagvesztési tolerancia az algoritmus strukturális tulajdonsága, míg a BBR-ben konfigurációs paraméter. Ahogy a BBR veszteségi szintje megközelíti a ProbeBW maximális nyereségét, a valós BtlBw szállítási sebességének mérésének valószínűsége meredeken csökken, ami miatt a szűrő alábecsüli a max.

8. ábra

A 8. ábra a BBR és a CUBIC használható átviteli sebességét hasonlítja össze 60 másodperces adatfolyamban 100 Mbps és 100 ms-os kapcsolaton a 0,001% és 50% közötti véletlen veszteségekkel. A CUBIC áteresztőképessége 10-szeresére csökken 0,1%-os veszteség mellett, és teljesen leáll 1%-nál nagyobb értéknél. A maximális áteresztőképességet a sávszélesség mínusz csomagveszteség () hányadának tekintjük. A BBR ezen a szinten marad 5%-os veszteségszintig, és ennek közelében 15%-ig.

YouTube Edge implementációs tapasztalat

A BBR-t a YouTube és a Google.com videószervereken telepítik. A Google egy kis kísérletet futtat, amelyben a felhasználók egy kis százalékát véletlenszerűen áthelyezik a BBR-be vagy a CUBIC-ba. A videó BBR-n keresztüli lejátszása jelentős javulást mutat a szolgáltatás minőségére vonatkozó összes felhasználói értékelésben. Talán azért, mert a BBR viselkedése következetesebb és kiszámíthatóbb. A BBR csak kis mértékben javítja a kapcsolat átviteli sebességét, mivel a YouTube már a BtlBw alatti szintekhez igazítja a streamelési sebességet, hogy minimalizálja a szükségtelen hálózati pufferelést és újrapufferelést. De még itt is a BBR globálisan 53%-kal, a fejlődő országokban pedig több mint 80%-kal csökkenti az átlagos átlagos RTT-t.

A 9. ábra az RTT medián javulását mutatja a BBR és a CUBIC között, több mint 200 millió YouTube-videómegtekintésnél, öt kontinensen, egy hét alatt mérve. A világ 7 milliárd mobilkapcsolatának több mint fele 2,5 G-n keresztül kapcsolódik 8 és 114 Kbps közötti sebességgel, jól dokumentált problémákkal, amelyek abból adódnak, hogy a csomagvesztés-torlódás-ellenőrzési technikák hajlamosak túlcsordulni a puffereken. Ezekben a rendszerekben a szűk keresztmetszet általában az SGSN (Serving GPRS Support Node) és a mobileszköz között van. Az SGSN szoftver szabványos PC-platformon fut, rengeteg RAM-mal, ahol gyakran megabájt puffer van az internet és a mobileszköz között. A 10. ábra összehasonlítja az (emulált) SGSN késleltetést az internet és a mobileszköz között a BBR és a CUBIC esetében. A vízszintes vonalak jelzik a legsúlyosabb következményeket: a TCP alkalmazkodik a hosszú RTT-késésekhez, kivéve a kapcsolatot kezdeményező SYN-csomagot, amelynek az operációs rendszertől függően fix időkorlátja van. Ha egy mobileszköz nagy mennyiségű adatot kap (például egy automatikus szoftverfrissítésből) egy nagy puffer SGSN-en keresztül, az eszköz nem tud kapcsolatot létesíteni az internettel mindaddig, amíg a várólista nem törlődik (a SYN ACK csomag hosszabb ideig késik, mint a rögzített SYN időtúllépés) .

9. ábra

A 10. ábra az állandósult állapotú RTT-változások mediánját mutatja a pufferméret függvényében egy 128 Kb/s-os, 40 ms-os kapcsolaton nyolc BBR (zöld) vagy CUBIC (piros) folyamon. A BBR minimális értéken tartja a sort, függetlenül a szűk keresztmetszet-puffer méretétől és az aktív szálak számától. A CUBIC adatfolyamok mindig kitöltik a puffert, így a késleltetés lineárisan növekszik a puffer méretével.

10. ábra

Adaptív sáv a mobil cellás kommunikációban

A cellás rendszerek az egyes felhasználókhoz igazítják a sávszélességet részben az igény-előrejelzés alapján, amely figyelembe veszi az adott felhasználónak szánt csomagok sorát. A BBR korai verzióit úgy konfigurálták, hogy nagyon kis sorokat hozzanak létre, ami miatt a kapcsolatok alacsony sebesség mellett leálltak. A ProbeBW csúcs pacing_gain értékének növelése és a várakozási sorok növelése az elakadt kapcsolatok csökkenéséhez vezetett. Ez kiváló alkalmazkodóképességet mutat egyes hálózatok esetében. A jelenlegi csúcserősítési beállítás mellett a CUBIC-hoz képest egyetlen hálózatban sem jelenik meg romlás.

Késleltetett és kinyújtott akck-csomagok

A cellás, a WiFi és a szélessávú hálózatok gyakran késleltetik és felhalmozzák a nyugtázási csomagokat. Ha a repülés egyetlen BDP-re korlátozódik, az olyan fennakadásokat okoz, amelyek csökkentik az átviteli sebességet. A ProbeBW cwnd_gain tényezőjének kettőre növelése lehetővé tette a zökkenőmentes átvitel folytatását az előre jelzett kézbesítési sebességgel, még akkor is, ha az Ack csomagok egy RTT-re késtek. Ez nagymértékben megakadályozza a meghibásodásokat.

Jelenlegi kanál határolók

A BBR kezdeti bevezetése a YouTube-on azt mutatta, hogy a világ legtöbb internetszolgáltatója a jelenlegi gyűjtősebesség-korlátozók használatával torzította a forgalmat. A vödör általában a kapcsolat elején megtelik, így a BBR megtanulja a BtlBw paramétert az alapul szolgáló hálózathoz. De amint a vödör kiürült, a vödör töltési sebességénél gyorsabban (sokkal kisebb, mint a BtlBw) elküldött összes csomag eldobásra kerül. A BBR végül megtanulja ezt az új kézbesítési sebességet, de a ProbeBW növekedési ciklusa állandó, mérsékelt veszteséget eredményez. A felfelé irányuló sávszélesség-veszteség és a veszteség miatti alkalmazási késleltetés növekedésének minimalizálása érdekében egy dedikált rendőrdetektort és egy explicit rendőrmodellt adtunk a BBR-hez. Emellett aktívan tanulmányozzuk a sebességkorlátozók által okozott károk kiküszöbölésének legjobb módjait.

Versenyeznek a csomagvesztésen alapuló torlódáskezelési módszerekkel

A BBR lényege a szűk keresztmetszetek sávszélességének méltányos megosztása, akár versenyben más BBR-folyamatokkal, akár a csomagvesztéses torlódáskezelési technikákkal vezérelt folyamokkal. Még akkor is, ha ez utóbbi kitölti a rendelkezésre álló puffert, a ProbeBW továbbra is megbízhatóan eltolja a BtlBw becslését a méltányos szálmegosztás felé, és a ProbeRTT az RTProp becslését elég magasnak tartja a tit-for-tat konvergenciához a fair megosztáshoz. A néhány BDP-nél nagyobb, nem menedzselt útválasztó pufferek azonban a csomagvesztési torlódások szabályozásával járó régi versenytársakat felduzzasztják a várólista, és a méltányos részesedésüknél többet rögzítenek. Ennek megszüntetése az aktív kutatás másik területe.

Következtetés

A torlódások kezelésének újragondolása óriási előnyökkel jár. Ahelyett, hogy olyan eseményeket használna, mint például a pazarlás vagy a pufferfoglalás, amelyek csak gyengén korrelálnak a torlódással, a BBR egy formális Kleinrock torlódási modellel és a hozzá tartozó optimális működési ponttal indul. Azt a sajnálatos következtetést, hogy a késleltetés és a sávszélesség kritikus paramétereit „lehetetlen” egyidejűleg meghatározni, megkerüli az a megfigyelés, hogy ezek egyidejűleg előre jelezhetők. A vezérlőrendszerek és a becslési elmélet legújabb fejlesztéseit alkalmazzák egy egyszerű elosztott vezérlési hurok létrehozására, amely megközelíti az optimumot a hálózat teljes kihasználásával, miközben fenntart egy kis sort. A Google BBR megvalósítása a nyílt forráskódú Linux kernelben érhető el, és a cikk mellékletében található részletes leírás.

A BBR technológiát a Google B4 gerincén használják, ami nagyságrendekkel javítja az átvitelt a CUBIC-hoz képest. A Google és a YouTube webszervereire is telepíthető, jelentősen csökkentve a késleltetést mind az öt eddig tesztelt kontinensen, és különösen erőteljesen a fejlődő országokban. A BBR technológia kizárólag a küldő oldalon működik, és nem igényel változtatást a protokollon, a címzetten vagy a hálózaton, lehetővé téve a fokozatos telepítést. Csak az RTT-től és a csomagkézbesítési értesítésektől függ, így a legtöbb internetes szállítási protokollban használható.

Köszönetnyilvánítás

A szerzők hálásak Len Kleinrocknak, hogy rámutattak a torlódások megfelelő kezelésére. Köszönettel tartozunk Larry Brakmónak a vegasi és a New Vegas-i torlódáscsökkentő rendszerek terén végzett úttörő munkájáért, amely a BBR számos elemét előrevetítette, valamint a BBR korai fejlesztése során nyújtott tanácsaiért és útmutatásaiért. Ezúton is szeretnénk köszönetet mondani Eric Dumazetnek, Nandita Dukkipatinak, Jana Iyengarnak, Ian Swettnek, M. Fitz Nowlannek, David Wetherallnak, Leonidas Leonidas Kontothanassisnak, Amin Vahdatnak, valamint a Google BwE és a YouTube infrastruktúra csapatának a felbecsülhetetlen segítségért és támogatásért.

Függelék - részletes leírás

Állapotgép szekvenciális tapintáshoz

A pacing_gain azt szabályozza, hogy a BtlBw-hez képest milyen gyorsaságú a csomagok küldése, és ez a kulcsa a BBR intelligenciájának. Ha a pacing_gain egynél nagyobb, a berepülés növekszik és a csomagok érkezése közötti intervallum csökken, ami az 1. ábrán a jobb oldalra helyezi a kapcsolatot. Ha a pacing_gain kisebb egynél, az ellenkező hatás lép fel, a kapcsolat balra mozdul el.

A BBR a pacing_gain segítségével egy egyszerű szekvenciális állapotvizsgáló gépet valósít meg, amely felváltva teszteli a nagyobb sávszélességet és a rövidebb kettős csomagidőt. (Kisebb sávszélességet nem kell tesztelni, mert azt a BtlBw msx szűrő automatikusan kezeli: az új mérések tükrözik az esést, így a BtlBw azonnal korrigálja magát, amint az utolsó régi változtatásokat eltávolítja az időtúllépési szűrőből. Az RTprop min. a szűrő ugyanúgy kezeli a növekvő szállítási útvonalakat) .

Ha a szűk keresztmetszet átviteli sebessége megnő, a BBR-nek gyorsabban kell adatokat küldenie annak észleléséhez. Hasonlóképpen, ha egy csomag tényleges oda-vissza ideje megváltozik, ez megváltoztatja a BDP-t, és így a BDP-nek lassabban kell adatokat küldenie, hogy a berepülést a BDP alatt tartsa az új RTprop mérése érdekében. Ezért ezeknek a változásoknak az egyetlen módja a kísérletek elvégzése, gyorsabban küldve a BtlBw növekedésének tesztelésére, vagy lassabban küldve az RTprop csökkenésének tesztelésére. A kísérletek gyakorisága, léptéke, időtartama és kialakítása a már ismert dolgoktól (futó kapcsolat vagy állandósult állapot) és az adatokat küldő alkalmazás viselkedésétől (szakaszos vagy állandó) függően változik.

Állandó állapot

A BBR szálak idejük nagy részét ProbeBW állapotban töltik, és az úgynevezett technikával vizsgálják a sávot nyerj kerékpározást, amely segít a BBR-folyamoknak nagy átviteli sebességet, alacsony várakozási várakozási időt és méltányos sávszélesség-konvergenciát elérni. Használata nyerj kerékpározást, a BBR egy sor érték között mozog a nyereség érdekében pacing_gain. A ciklus nyolc fázisát használjuk a következő értékekkel: 5/4, 3/4, 1, 1, 1, 1, 1, 1. Általában mindegyik fázis a megjósolt RTprophoz fut. Ez a kialakítás lehetővé teszi az együttható hurok számára, hogy először a csatornát nagyobb kapacitásra szondázza értékkel pacing_gain nagyobb, mint 1,0, majd szórja szét az eredményül kapott sort a használatával pacing_gain ugyanennyivel kevesebb, mint 1,0, majd utazósebességgel mozogjon, pontosan 1,0-s együtthatósorral. Az összes fázis átlagos nyeresége 1,0, mivel a ProbeBW az átlagra törekszik, hogy kiegyenlítse a rendelkezésre álló sávszélességet, és így fenntartsa a magas sávszélesség-kihasználást a várakozási sor növelése nélkül. Vegye figyelembe, hogy bár a sebességciklusok változnak pacing_gain, hanem a jelentése cwnd_gain mindig egyenlő kettővel, mivel a késleltetett és megnyújtott ack csomagok bármikor megjelenhetnek (lásd a késleltetett és megnyújtott ack csomagok fejezetet).

Ezenkívül a szálkeverés és a méltányos sávszélesség-megosztás javítása, valamint a sorban állás csökkentése érdekében, amikor több BBR-szál osztozik egy szűk keresztmetszeten, a BBR véletlenszerűen változtatja a ProbeBW hurok fázisait, véletlenszerűen kiválasztva az első fázist 3/4 kivételével az összes érték közül. Miért nem 3/4-nél kezdődik a ciklus? Ennek az együttható értéknek a fő célja az 5/4-es együttható alkalmazása során keletkező sorok szétszórása, amikor a csatorna már megtelt. Amikor egy folyamat kilép a Drain vagy ProbeRTT állapotból, és belép a ProbeBW-be, nincs sor, így a 3/4-es tényező nem látja el a feladatát. A 3/4 alkalmazása ilyen kontextusban csak negatív hatást fejt ki: a csatorna kitöltése ebben a fázisban 3/4 lesz, nem 1. Így a ciklus 3/4-gyel való indítása csak negatív hatással jár, de nem pozitív. , és mivel a ProbeBW állapotba való belépés hosszú ideig bármely kapcsolat elején megtörténik, ezért a BBR ezt a kis optimalizálást használja.

A BBR-szálak együtt dolgoznak a szűk keresztmetszet-sor időszakonkénti kiürítésére a ProbeRTT nevű állapot használatával. Magán a ProbeRTT-n kívül bármely más állapotban, ha az RTProp becslést 10 másodpercnél tovább nem frissítették (például kisebb RTT mintavételével), akkor a BBR ProbeRTT állapotba lép, és a cwnd értéket nagyon kis értékre (négy csomagra) csökkenti. ). Ha ezt a minimális számú csomagot legalább 200 ms-ig repülés közben és egy csomag áthaladási időn keresztül fenntartja, a BBR kilép a ProbeRTT állapotból, és vagy az Indítás vagy a ProbeBW állapotba lép, attól függően, hogy értékeli, hogy a csatorna már megtelt-e.

A BBR-t úgy tervezték, hogy az idő nagy részében (körülbelül 98%-ban) ProbeBW állapotban, a fennmaradó időben ProbeRTT-ben működjön, kompromisszumok alapján. A ProbeRTT állapot elég hosszú ideig tart (legalább 200 ms), hogy lehetővé tegye a különböző RTT-vel rendelkező szálak párhuzamos ProbeRTT állapotát, ugyanakkor elég rövid ideig tart ahhoz, hogy a teljesítményt körülbelül két százalékra korlátozza (200 ms / 10 másodperc). ). Az RTprop szűrőablak (10 másodperc) elég kicsi ahhoz, hogy gyorsan alkalmazkodjon a változó forgalmi szintekhez vagy útvonalváltozásokhoz, de elég nagy az interaktív alkalmazásokhoz. Az ilyen alkalmazások (pl. weboldalak, távoli eljáráshívások, videorészletek) gyakran természetes csendet vagy csekély aktivitást mutatnak ennek az ablaknak a résein, ahol az áramlási sebesség elég alacsony vagy elég hosszú ahhoz, hogy a sor szűk keresztmetszetbe kerüljön. Az RTprop szűrő ezután opportunista módon illeszkedik ezekhez az RTprop mérésekhez, és az RTProp frissítésre kerül a ProbeRTT bekapcsolása nélkül. Így az áramlásoknak általában csak a sávszélesség 2%-át kell feláldozniuk, ha több áramlás erősen kitölti a csatornát a teljes RTProp ablakban.

Indítási viselkedés

Amikor egy BBR-szál elindul, végrehajtja az első (és leggyorsabb) szekvenciális sorvizsgálati/ürítési folyamatot. A hálózati sávszélesség 10 12 tartományban változik – néhány bittől 100 gigabitig másodpercenként. A BtlBw értékének kiszámításához a tartomány ilyen óriási változásához a BBR bináris keresést végez a sebességtérben. Nagyon gyorsan megtalálja a BtlBw-t (kettős áteresztésű csomagokat), de a 2BDP-ben a keresés utolsó szakaszában sor létrehozásának rovására. A keresés a BBR-ben Indítás állapotban, a létrehozott sor ürítése pedig Drain állapotban történik.

Először is, a Startup exponenciálisan növeli az adatküldés sebességét, minden körben megduplázza azt. Ilyen gyors szondázás elérése a legnyugodtabb módon az erősítési értékek indításakor pacing_gainÉs cwnd_gainértékre állítva, az a minimális érték, amely lehetővé teszi az adatküldési sebesség megduplázását minden körben. Ha a csatorna megtelt, az együttható cwnd_gain-ra korlátozza a sor méretét.

A kapcsolat indítási állapotában a BBR kiértékeli, hogy a csatorna megtelt-e úgy, hogy egy platót keres a BtlBw becslésben. Ha úgy találja, hogy több (három) körön ment keresztül, ahol a kézbesítési sebesség megduplázása nem igazán eredményez nagy sebességnövekedést (kevesebb, mint 25%), akkor úgy tekinti, hogy elérte a BtlBw-t, ezért kilép Indítási állapot, és leeresztés állapotba lép. A BBR három kört vár, hogy meggyőző bizonyítékot szerezzen arra vonatkozóan, hogy a küldő által megfigyelt kézbesítési sebesség platója nem a fogadási időszak átmeneti hatása. A három kör kivárása elegendő időt hagy a fogadóoldali automatikus hangolásra, hogy megnyissa a vételi ablakot, és a BBR-küldő észlelje a BtlBw növelésének szükségességét: első körben a vételi ablak automatikus hangolási algoritmusa megnöveli a vételi ablakot; a második körben a feladó kitölti a megnövelt fogadási ablakot; a harmadik körben a feladó megnövelt kézbesítési sebességgel kapja meg a mintákat. Ez a három körből álló limit bevált a YouTube-on való bevezetésének eredményei alapján.

Leürítés állapotban a BBR algoritmus gyorsan igyekszik kiüríteni a kapcsolatindítási állapotban kialakult sort azáltal, hogy pacing_gain fordított értékekkel, mint az Indítási állapotban használtak. Ha a repülésben lévő csomagok száma megegyezik a BDP becsléssel, ez azt jelenti, hogy a BBR úgy becsüli, hogy a sor teljesen üres, de a csatorna még mindig tele van. Ezután a BBR kilép a Drain állapotból, és belép a ProbeBW-be.

Vegye figyelembe, hogy a BBR kapcsolat indítása és a CUBIC lassú indítása egyaránt exponenciálisan fedezi fel a szűk keresztmetszet áteresztőképességét, és minden körben megduplázza a küldési sebességet. Ezek azonban gyökeresen különböznek egymástól. Először is, a BBR megbízhatóbban határozza meg az elérhető sávszélességet, mert nem hagyja abba a keresést csomagvesztés vagy (mint a CUBIC Hystart) megnövekedett késleltetése esetén. Másodszor, a BBR simán növeli a küldési sebességet, míg a CUBIC minden körben (még ingerléssel is) egy csomagot, majd egy csendet. A 4. ábra mutatja a repülés közben lévő csomagok számát és a megfigyelt RTT-időt minden egyes nyugtázó üzenethez BBR és CUBIC esetén.

Válasz az átmeneti helyzetekre

A hálózati útvonal és a rajta folyó forgalom hirtelen, drámai változásokon mehet keresztül. Az ezekhez való zökkenőmentes és megbízható alkalmazkodás, valamint a csomagvesztés csökkentése érdekében a BBR számos stratégiát alkalmaz alapmodelljének megvalósításához. Először is a BBR azt a célt tekinti, amely felé a jelenlegi cwndóvatosan alulról közelít, növelve cwnd minden alkalommal legfeljebb annyi adatmennyiség, amelyre a szállítási visszaigazolások érkeztek. Másodszor, egy újraküldési időtúllépéskor, ami azt jelenti, hogy a küldő az összes repülésben lévő csomagot elveszettnek tekinti, a BBR konzervatív módon csökkenti cwnd legfeljebb egy csomagot, és egyetlen csomagot küld (csakúgy, mint a csomagvesztési torlódást vezérlő algoritmusok, például a CUBIC). Végül, amikor a küldő észlel egy csomagvesztést, de még mindig vannak csomagok repülés közben, a veszteség-helyreállítási folyamat első lépésében a BBR átmenetileg az aktuális kézbesítési sebességre csökkenti a küldési sebességet; a második és az azt követő veszteség-visszatérítési körben ellenőrzi, hogy a küldési sebesség soha ne haladja meg a jelenlegi kézbesítési sebesség kétszeresét. Ez jelentősen csökkenti a veszteségeket átmeneti helyzetekben, amikor a BBR sebességkorlátozókkal találkozik, vagy versenyez más áramlásokkal a BDP-vel összehasonlítható méretű pufferben.

Linkek

1. Abrahamsson, M. 2015. TCP ACK elnyomás. IETF AQM levelezőlista;