A forgalom optimalizálásának módja

A szabványos WAN "hatékonysága" csak körülbelül 10%

Ha a fiókiroda és az adatközpont közötti szinte minden kommunikációs csatornát néz ki, meglehetősen szuboptimális képet lát:

• Először is, a redundáns információ nagymértékben (a csatorna legfeljebb 60-70% -a) kerül továbbításra. amelyekre már vagy egy ilyen módon kérték.
• Másodszor, a csatorna "csattogó" alkalmazásokkal van betöltve. amelyeket helyi hálózatban dolgoznak - rövid üzeneteket cserélnek, ami kedvezőtlenül befolyásolja a kommunikációs csatornák teljesítményét.
• Harmadszor, a TCP-t eredetileg a helyi hálózatok számára hozták létre, és kiváló a kis RTT késések és a csomagvesztés hiányában a hálózaton. Valódi csatornáknál, a csomagvesztésnél a sebesség nagymértékben lebomlik, és lassan helyreáll a nagy RTT.

A CROC távközlési részlegének mérnöki csapatának vezetőjeként dolgozom, és rendszeresen optimalizáljuk adatközpontjaink, valamint energiavállalataink, bankjaink és más szervezetek adatközpontjainak kommunikációs csatornáit. Az alábbiakban elmagyarázom az alapokat, és véleményem szerint a legérdekesebb megoldást találom.

Tömörítés és deduplikáció

Az első probléma már le van írva: sok redundáns duplikált adatot továbbítanak a csatornában. A legszembetűnőbb példa a Citrix-gazdaság, amelyben a bank fiókjai működnek: ugyanabban az irodában ugyanazokat az adatokat 20-30 különböző gépre lehet kérni. Ennek megfelelően a csatorna 60-70% -kal biztonságosan kirakható a deduplikáció miatt.

Magában a Citrixen természetesen az adattömörítés is beletartozik, de a hatékonyság (tömörítés) többszörösen alacsonyabb, mint a speciális forgalomoptimalizátoroknál. Főleg azért, mert az optimalizátorok nem csak tömörítik az adatokat, hanem deduplikálják is. Az optimalizáló segítségével a forgalom átkerül az egész ágon. És minél több felhasználó van a fiókban, annál több felhasználó megkérdezi, és annál nagyobb a deduplikáció hatása. Egy felhasználó számára a standard tömörítés, például a Limpel-Ziv, még nagyobb lehet, mint a deduplikáció, de több eszközzel deduplikáció jön először.

Az optimalizálók általában PAC-k, de virtuális gépek formájában is megvalósíthatók. A kommunikációs csatornán a forgalom optimalizálása érdekében mindkét webhelyen optimalizálókat kell telepíteni. Az optimalizálók a VPN-átjárók elé kerülnek, mert a titkosított forgalom deduplikálása nem haszontalan.

A deduplikációs munka algoritmusa a következő:

Továbbra is hozzá kell adni, hogy a szótár folyamatosan frissül, és egy speciális algoritmusnak köszönhetően a legelterjedtebb adatblokkok a szótárban maradnak.

Egy másik probléma az, hogy a TCP sebességét az ablakméret (TCP Windows Size) korlátozza. Ablak mérete - a feladó által küldött adatok mennyisége, mielőtt a címzett megerősítést kapna. A tömörített forgalom továbbításához TCP Windows Méretet kell küldeni kisebb időkre, ami az átviteli sebesség növekedéséhez vezet.

Így ismét így működik:

• Az A eszköz deduplikálja a forgalmat.
• A B eszköz "teljes képet" gyűjt a helyi adattárból.
• Mindkét eszköz szimmetrikusan működik.
• Mindkét készüléknek nincs hatása az infrastruktúra és a konfiguráció minden, ami mögöttük, ez egyszerűen a csatornán szereplő különbség, például a termelés az adatközpont és a bejárat a regionális hivatal.
• Az eszközök nem korlátozzák a kommunikációt a csomópontokkal, ahol ilyen eszközök nincsenek.

Titkosított csatornák dedikáltsága

Titkosított csatornán egyértelműen rosszabb tömörítési és duplikáció-, azaz a gyakorlati munka előnyeit titkosított forgalom már majdnem ott van. Ezért optimalizáló szerepel a különbség, hogy a titkosító berendezés: DPC küld adatokat optimalizáló, az optimalizáló küld egy kódolt üzenetet (például egy biztonságos VPN-csatorna) oldalán a forgalom dekódolására és az optimalizáló kap a helyszínen, és hogy már elküldi őket a hálózathoz. Ez az "optimalizáló dobozok" rendszeres funkciója, és mindez a forgalomromlás veszélyének csökkentése nélkül történik.

Deduplikáció a mobil alkalmazottak számára

Az utóbbi években a laptopokkal és tablettákkal rendelkező emberek, akiknek sok adatra van szüksége (ugyanazok a virtuális gépekről vagy mintákból származó képek), közvetlenül együttműködnek az adatközpontokkal. Számukra nem "optimalizáló dobozokat" használnak, hanem egy speciális szoftver, amely egyszerűen csak a processzor erőforrásainak egy részét és a merevlemez egy részét használja ugyanarra a célra. Valójában megváltoztatjuk a laptop teljesítményének romlását, és a merevlemez gyorsítótárába helyezzük a gyorsítótárat. A felhasználók általában nem veszik észre semmit, csak felgyorsítják a hálózati szolgáltatásokat.

Ki teszi ezeket az optimalizálókat?

Az ügyfél kereskedelmi igazgatója szempontjából több doboz van, amelyek egyszerű kapcsolódás után felgyorsítják a lassú csatornákat 2-3-szor, és csökkentik a csatornák betöltését 2-szer. Szinte mindenki szereti őket!

Optimalizáló kapcsolat

A legegyszerűbb és legmegbízhatóbb mód az "élettartam" és a LAN kapcsoló közötti "megszakítás". Ha az optimalizáló nem sikerül, lezárja a LAN és a WAN kapcsolódási pontokat - és a forgalom csak átmegy rajta, mint egy normál keresztkábellel. Ennek megfelelően, a nem optimalizált forgalom figyelembevételével, a másik oldalon lévő optimalizáló egyszerűen feldolgozás nélkül áthalad.

• A fiók kapcsolata az optimalizálóval és az adatközponttal az optimalizálóval - a forgalom optimalizálva van.
• Az optimalizáló és az adatközpont optimizálóval rendelkező fiókja - az adatközpont optimalizálója egyszerűen átlátható módon továbbítja a forgalmat változások nélkül.
• Az optimalizáló és az adatközpont összekapcsolása az optimalizálóval, ha valamelyik optimalizátor meghibásodik, a forgalom egyszerűen nem csökken, és "ahogy van".

Természetesen az adatközpont-optimalizátorok fürtözöttek a hibatűréshez vagy a kapacitásbővítéshez, valamint az Interceptor-balanszerek. De ez egy kicsit alacsonyabb, amikor egy speciális berendezéshez jutunk.

TCP gyorsítás

A TCP sebességét az ablak mérete korlátozza. Az ablak az az információmennyiség, amelyet a kiszolgáló az átvételi elismervény beérkezése előtt elküldhet az ügyfélnek.

A TCP szokásos viselkedése így néz ki:

• a kapcsolatok lassú gyorsulása, a TCP ablak mérete növekszik;
• amikor a csomagvesztés - a sebesség gyors csökkenése (2-szer csökkentve az ablakot);
• és ismét lassan növeli (növeli az ablakot);
• ismét a csomagok elvesztése és a szalag elcsúszása, és így tovább.

Narancssárga "fűrész" a diagramon - a TCP standard viselkedése

A kommunikációs csatornák nagy sávszélességű, de a jelenléte bizonyos szintű veszteség és a magas látencia RTT álló sávszélességet hatékonyan használják fel, azaz a csatorna nem teljesen betöltve.

A Riverbed cég ugyanabba az irányba gondolt. És mivel már van doboz-optimalizáló a bemenettel és a kimenettel kapcsolatban, buta, hogy ne használja őket a TCP protokoll módosítására, hogy elkerüljék a szokásos problémákat. Ezért az optimalizáló nemcsak az adatforgalom optimalizálására képes (deduplikáció / tömörítés), hanem a közlekedési réteg felgyorsítására is.

A TCP gyorsítására többféle mód áll rendelkezésre:

• HighSpeed ​​TCP mód - itt a sebesség sokkal gyorsabban eléri a TCP-vel való munkavégzést. A veszteségeknél ez nem olyan alacsony, és nem süllyed el annyira, mint a hagyományos TCP;
• MaxTCP mód - a sávszélesség 100% -át lassítja. A csomag elvész - nincs lassulás. Azonban ez a mód igényli a QoS szolgáltatás minőségi szabályainak meghatározását annak érdekében, hogy meghatározzák az MX-TCP forgalom által rendelkezésre bocsátott rendelkezésre álló sávszélesség-korlátozásokat;
• SCPS mód - kifejezetten műholdas kommunikációs csatornákhoz tervezve. Itt a sávok nincsenek korlátozva, mint a MaxTCP-ben. Az SCPS tökéletesen illeszkedik a műholdas csatornák lebegő tulajdonságaihoz.

Alkalmazások optimalizálása

Sok alkalmazás "csevegő", azaz maximum 50 csomagot küldhet, ha csak egy elég. Ahogy mondtam, ez a helyi hálózatok tervezésének következménye, nem pedig a "távoli" kommunikáció csatornáin keresztül. Az optimalizátorok használatával az oda-vissza járatok száma több mint 50-szer csökken.

Így néz ki:

Az optimalizálók a legelterjedtebb alkalmazási protokollok közül a hetedik szinten átlátszó proxiként működnek.

Az adatközpont optimalizáló kliensként működik a kiszolgálón. Az ág optimalizáló az ügyfelek kiszolgálójaként működik. Így az alkalmazások nem hatékony, "csaló" kommunikációja marad a helyi hálózatban. Az optimalizálók között az alkalmazások üzenetküldése a kommunikációs csatornáknál megfelelőbb formában történik - az üzenetek száma csökken.

A folyómeder-optimalizáló eszközök felgyorsíthatják a következő alkalmazási protokollokat a hetedik szinten:

Érdekes módon vannak titkosított alkalmazások, köztük a titkosított Citrix és MAPI. A titkosított forgalom optimalizálásakor nem csökken a biztonság szintje.

Példák az alkalmazás gyorsítására. Valódi hálózatban a gyorsítás a kommunikációs csatornától függ. Minél rosszabb a kommunikációs csatorna, annál nagyobb a gyorsulás sebessége.

Tipikus bekötési rajz

A Steelhead optimalizátorokat az adatkapcsolat előtt helyezik el, de a titkosítási eszközök előtt. A speciális követelményekkel rendelkező adatközpontok a klaszterezést a megbízhatóság növelése és a terhelésmérő interceptor használatával is használják.

Eredmény (példa)

Zöld - WAN forgalom. Kék - LAN forgalom. A folyómeder optimalizáló nélkül ugyanúgy lennének.

A kiemelt oszlop a tömörítés százalékát mutatja a TCP portokon.

Vasrudak

A kapacitás licenccel meghosszabbítható. A teljesítmény javítása érdekében egyes esetekben hardverfrissítésre van szükség. Az emelvényen belüli upstream lehetőségeket zöld nyilak jelzik.

A fiatalabb modell egy kis online áruház számára is alkalmas: 1 megabit / másodperc és 20 csatorna. És a zászlóshajó akár 150 000 egyidejű nyitott kapcsolatot támogat 1,5 gigabites másodpercenként. Ha ez nem elegendő, az Integeror kiegyenlítőt használják. A balanszerek és optimalizátorok klaszterei lehetővé teszik a 40 gigabites / másodpercenkénti csatorna működtetését, 1 millió kapcsolatot nyitva egyszerre.

Mennyibe kerül az ár?

A fiatalabb modell kb. 100 ezer rubel, a közepes adatközpontok eszköz 1,1 millió rubel, a nagy adatközpontok esetében - 5,5 millió rubel. Ugyanakkor az ár jelentősen változik az adott felhasználási rendszerektől függően, plusz lehetnek kedvezmények, így az említett számok pusztán példaszerűek, pontosabban meghatároznak mailen (ez a téma végén található). Az ilyen megoldások megtérülése a közepes és nagyvállalatok számára könnyen kiszámítható, csak úgy, hogy a csatornától 30-60% -ig szabaddá válik (ismét egy konkrét szám 10% -os pontossággal, postai úton hívható, a csatornahasználat típusától függően), és a felhasználók nem panaszkodnak az alkalmazás fékekre.

Részletek:

Miután a csatornát optimalizáltuk a leírt módszerrel, gyakran nyomon követjük és megoldjuk a problémákat bizonyos szolgáltatásokkal és berendezésekkel kapcsolatban. A gyakorlatban ezek teljes nyomozók. Később elmondok róla. Ha érdekel, iratkozzon fel a Habr vállalati CROC blogjára.

Kinek személyesen vezettem be:

Nincs jogom felhívni az összes ügyfelet, de azt mondhatom, hogy a Riverbed megoldását a forgalom optimalizálására használták:

• a bankszektor öt legnagyobb képviselője;
• egy nagy aranybányászati ​​cég;
• egy nagy logisztikai cég;
• Számos vállalat kisebb méretű.