Rychlost vázne v sítích WAN

Ohlédneme-li se o deset let zpátky, sítě WAN (Wide Area Network) byly výhradně doménou komunikace založené na protoko...


Ohlédneme-li se o deset let zpátky, sítě WAN (Wide Area Network) byly výhradně
doménou komunikace založené na protokolu frame-relay a na pronajatých linkách.
Dnes mohou WAN využívat cokoliv od IPsec spojení a kabelových modemů až po
protokol MPLS tunelovaný přes sítě s propustností mnoha megabitů. Metody se
možná změnily, ale výzva zůstává stále stejná: Jak zařídit, aby se WAN jevila
jako jedna velká síť LAN?

Zbavit se tohoto problému jednoduše zvýšením šířky pásma přitom není řešením.
Řešení MPLS (Multiprotocol Label Switching) může být velkým krokem kupředu
směrem ke zlepšení výkonu WAN, avšak jádro problému leží mnohem hlouběji, pod
úrovní MPLS.
Latence, přetížení, náročné aplikace či provoz soupeřící o šířku pásma, to
všechno má vliv na to, jak dokáže WAN v daném okamžiku reagovat. Jsou to
nepříjemná tajemství výkonu WAN, která jsou většinou zametena pod koberec. Po
většinu času je pozornost ale zaměřena na propustnost komunikační cesty a
nikoliv na to, jakým způsobem je využívána.
Na velikosti nezáleží
Ve světě WAN má velikost (tedy šířka pásma) spoje jen malý vliv na celkový
výkon, obzvláště pokud se jedná o dlouhý spoj (a slovo "dlouhý" znamená více
než několik stovek kilometrů). Částečně je problém v tom, že TCP a další
protokoly původně nebyly určeny pro použití za hranicí lokální sítě.
"Důvodem, proč rozlehlé sítě nefungují dobře, je hlavně to, že využívané
protokoly nebyly pro tyto účely původně navrženy," vysvětluje Dick Pierce z
firmy Orbital Data, která prodává zařízení pro optimalizaci WAN. "Tyto
protokoly pracují docela dobře na lokální bázi a v některých případech i na
krátké vzdálenosti. Ne však v případě WAN. Na tomto faktu se přitom vyvíjí celá
historie tržního segmentu optimalizace WAN."
Problémem je to, že efektivita protokolů se snižuje s tím, jak se zvyšuje
latence. Ta se přitom odvíjí od rychlosti světla a celkové délky WAN spoje nad
těmito parametry obvykle kontrolu nemáme. Myslíte si, že rychlost světla není
důležitým faktorem? Jen se podívejte na latenci u satelitního spojení.
Před několika lety bylo možné říci, že latenci WAN spojů významně zvyšují
směrovače a přepínače, avšak většina dnešních páteřních zařízení pracuje se
zpožděními menšími než milisekunda.
Latence přitom ovlivňuje síťové protokoly různými způsoby. Kupříkladu protokol
TCP využívá pakety ACK (Acknowledgement), zajišťující vyšší spolehlivost
přenosu. Při obdržení ACK z přijímajícího bodu vysílající systém ví, že
odeslaný paket dorazil bez jakýchkoliv chyb. Avšak u spojů s vysokou latencí
čekání na ACK pakety omezuje propustnost.
Latence je tudíž jedním z největších ne-li největším nepřítelem výkonu WAN, a
to jak z hlediska doby odezvy, tak celkové propustnosti. Sítě typu Long Fat
Network (LFN) jsou provozovány při rychlostech E1 nebo vyšších, avšak značně
trpí kvůli vlastní latenci spoje. Pro většinu terestrických linek je průměrná
doba odezvy RTT (Round-Trip Time) přibližně 150 ms, u satelitních spojení činí
v průměru kolem 800 ms. U globálních spojů se to různí, ale není výjimečné
setkat se s RTT časy mezi 200 a 400 ms i delšími. Zvyšování šířky pásma tady
ale nepomůže.
Ve skutečnosti jsou LFN sítě právě kvůli latenci často z velké míry nevyužité.
"Důvodem, proč lidé vybudovali dálkové komunikační kanály, které se nakonec
ukázaly být zbytečné, bylo to, že se pokoušeli dosáhnout očekávaného výkonu
aplikací nadměrným poskytováním síťových kapacit," říká Pierce z firmy Orbital.
"Problémem byl ale vlastní design sítí tedy to, že nebyly navrženy pro velké
vzdálenosti."

Provozní špička
Také zahlcení sítě pochopitelně ovlivňuje výkonnost WAN. K zahlcení může dojít
tehdy, pokud nejsou na síťový provoz WAN aplikovány žádná pravidla pro alokaci
dostupné šířky pásma. Tok síťového provozu může praskat ve švech, když se
například jeden uživatel snaží stáhnout velkou e-mailovou přílohu, zatímco jiný
se přihlašuje do CRM portálu. Bez účinné správy šířky pásma může probíhající
download způsobit, že spojení využívající menší část šířky pásma skončí
neúspěšně.
P. G. Narayanan z firmy Allot Communications je přesvědčen, že většina problémů
se zahlcením sítě může být vyřešena nasazením pravidel QoS (Quality of Service)
na síťový provoz. "Problémem většiny těchto sítí je ovšem dočasně jen ta
sekunda nebo minuta, kdy je ucpána, čemuž lze uniknout pouze stanovením priorit
pro různé aplikace. Do centrální lokality je možné umístit gigabitové zařízení,
které zajistí prioritizaci provozu těchto aplikací (především kritických
aplikací) po dočasnou dobu. Tím se lze vyhnout zahlcení v momentech zvýšeného
provozu, zatímco po zbytek doby je vše v pořádku," popisuje Narayanan.
Prioritizace aplikačních toků je důležitou součástí správy provozu WAN,
nepovede ovšem k řešení základních omezení provozu, pokud se do hry vloudí
latence. U kratších spojů, kde latence problém nepředstavuje, může předem
definovaná alokace šířky pásma jednoduše pomoci k tomu, aby se důležité pakety
udržely v pohybu bez ohledu na to, co dalšího ještě danou linkou prochází.

Mluvit, mluvit, mluvit
Z pohledu koncového uživatele se latence stává méně přijatelnou v době, kdy se
zvyšuje obousměrná komunikace vyžadovaná pro některé akce. A protokoly sedmé,
tedy aplikační vrstvy jsou "upovídané", vyžadují až absurdní počet obousměrných
výměn dat pro vykonání jediné úlohy. Podobně jako TCP i protokoly CIFS (Common
Internet File System) a MAPI (Mail Application Programming Interface) byly
navrženy tak, aby byly provozovány uvnitř LAN, nikoliv napříč WAN.
"Upovídanost" dosahuje vrcholu, když uživatelé přes WAN zobrazují data ze
síťových disků s použitím protokolu CIFS (využívaného ve Windows sítích). Každý
uživatel, který zkoušel otevřít, editovat a uložit dokument aplikace Microsoft
Word či Excel ze vzdáleného souborového serveru, dobře ví, jak dlouho může tato
jednoduchá úloha trvat, a to dokonce i při využití WAN připojení s vysokou
kapacitou. Ze stejného důvodu pak trpí i uživatelé aplikací Microsoft Outlook a
Exchange 2000, pokud přes WAN otevírají e-mail s přílohou. Ačkoliv se totiž
zdá, že je zpráva ve schránce, ve skutečnosti je stále na serveru a čeká, až
bude přenesena.
Microsoft Exchange Server 2003 byl navržen tak, aby tento problém maskoval
stahováním zpráv a příloh na pozadí (cachovaný režim Exchange serveru). Ačkoliv
je to skvělé pro koncového uživatele, ve výsledku to zvyšuje provoz ve WAN.
Například Outlook stahuje všechny přílohy ve vaší schránce bez ohledu na to,
zda jste se je vůbec chystali otevřít. To klade na WAN dodatečnou zátěž, k níž
by nikdy docházet nemuselo.

Pryč se starým...
Tradičně byl výkon WAN ohrožován velikostí paketů. Ještě v roce 1998 byla firma
Expand Networks jedním z lídrů v oblasti WAN komprese. Liad Ofek z této firmy
říká, že v té době bylo cílem do existujících spojů "natlačit tolik dat, kolik
jen bylo možné".
Expand využíval řadu kompresních algoritmů tak, aby počet paketů v linkách
redukoval. Další dodavatelé, jako firma Packeteer, také používali vysoce
vyspělá kompresní schémata a navíc začali přidávat QoS funkcionalitu kvůli
tomu, aby bylo možné dále alokovat a spravovat toky provozu ve WAN.
Dalším způsobem, jak redukovat provoz na WAN, je cachování souborů, tj.
ukládání kopií nedávno vyvolávaných souborů do zařízení, jež jsou umístěna
blíže k uživatelům, kteří tato data vyžadují, podobně jako je tomu u cache
prohlížečů. To napomáhá překonat latenci a předejít nadměrným, redundantním
požadavkům na přenos. Cachování celých souborů ale není zdaleka tak efektivní
jako novější metody cachování celých segmentů, neboť šance, že druhý nebo třetí
uživatel bude vyžadovat stejný soubor, je nepatrná. Stejně tak pokud je soubor
na file serveru přejmenován nebo pozměněn, nebude už
odpovídat souboru, který se nachází
v cache a musí být přenesen znovu.

... sem s novým
V posledních letech se stala středem pozornosti akcelerace TCP coby jedna z
cest, jak zlepšit výkon redukovány jsou ACK pakety a mění se i velikost okna
TCP. Výrobci jako Swan Labs, Juniper Networks, Expand Network či Riverbed
Technology vyvinuli řešení založená na zlepšování výkonu TCP. Jednou z
nejefektivnějších metod je zpracovávat ACK pakety lokálně s využitím
hardwarového zařízení. Takové zařízení zabalí více paketů ACK do jediného
požadavku, čímž redukuje zpoždění způsobované vysokou latencí. Pro aplikaci
vyžadující data se nic nemění, obdrží ACK tak, jak očekává, pouze s tím
rozdílem, že ACK přijde z lokálního WAN zařízení, a nikoliv ze vzdálené strany
WAN.
Dalším krokem může být akcelerace postavená na aplikační bázi. Někteří z
dodavatelů systémů pro optimalizaci WAN totiž ve svých zařízeních používají
plug-iny, jež jim pomáhají zlepšit odezvu aplikací. Aplikace jako jsou DNS,
Exchange, FTP, Citrix, Notes a CIFS/NFS mohou z redukované komunikace v
komunikačních linkách těžit. Plug-iny pracují podobně jako optimalizace TCP
ACK, a to tak, že redundantní požadavky zpracovávají lokálně namísto toho, že
by odesílaly každý z nich jednotlivě.

Jednotné řešení není
Celá oblast optimalizace a akcelerace v prostředí WAN směřuje ke konvergenci
různých typů metod. V minulosti se někteří z výrobců specializovali na jediné
technologické řešení, avšak nyní, aby vyřešili další části problému s WAN,
přidávají nové technologie. Současným trendem, který výrobci sledují, je tedy
přechod od jednotlivých, specializovaných řešení ke komplexnějšímu řízenému
systému. Některá WAN zařízení nabízejí kompresi a TCP akceleraci společně s
cachováním souborů a akcelerací provozu specifického pro určité aplikace.
Zdaleka ne všichni výrobci se shodují na tom, že je taková konsolidace rozumná.
"Mám dojem, že většinu zákazníků zajímá spíše provoz v síti," tvrdí Narayan z
Allotu. "Chtějí především dobré řešení pro řízení provozu, které je schopné
správně dekódovat každou aplikační vrstvu, nikoliv ji zkreslovat."
Další dodavatelé, jako třeba Swan Labs, Riverbed, Disksites či Juniper Network,
naopak spoléhají na komplexní řešení v jediném boxu. Tom Tansy z firmy Swan
Labs vidí budoucnost v pokračující konsolidaci příslušných technologií. Věří
totiž, že mnozí ze zákazníků jsou frustrováni "neustálým růstem počtu skříní" a
namísto několika různorodých systémů požadují jediné zařízení.
Ať už je to jakkoliv, když se přejde na téma zrychlení WAN, všichni se shodují
na tom, že samotné zvyšování šířky pásma řešením není. Dokud zůstane beze změn
samotný protokol TCP (a alespoň prozatím tomu tak bude) a latenci bude určovat
zejména rychlost světla, neobejde se zvyšování výkonnosti WAN bez zásahů na
úrovni protokolů v kombinaci s prioritizací toku síťového provozu a redukcí
paketů prováděnou specificky pro různé aplikace. Řešení pro akceleraci WAN se
budou nadále vyvíjet a zahrnovat množství technik, s nimiž bude možné vytěžit
maximum ze vzdáleného připojení tedy alespoň do té doby, než bude nalezen
způsob, jak posílat data rychleji než rychlostí světla.



Vzdálená obsluha souborů
Zařízení typu WAFS (Wide-Area File Sharing) kombinují optimalizaci WAN s
cachováním souborů ve snaze odstranit potřebu souborových serverů na vzdálených
pracovištích. Systémy, označované někdy také termínem Wide-Area File-Server
Replacements, se soustřeďují na aplikačně specifickou akceleraci, především pak
na CIFS a MAPI.
Cílem WAFS je zajistit provoz kompletně "bezserverové" kanceláře.
V nepříliš vzdálené budoucnosti by měli IT manažeři rozmísťovat do všech
vzdálených pracovišť předkonfigurovaná rozvaděčová zařízení jako náhradu za
souborové a e-mailové servery. Tyto nové systémy by eventuálně mohly obsahovat
i předem nahraná cachovaná data.
Jedním z faktorů, který bude odlišovat skutečné hráče na poli WAFS od těch, jež
si budou chtít pouze "přihřát svoji polívčičku", je to, jak bude dané zařízení
zajišťovat uzamykání souborů. Uvažujme například, že uživatel ve vzdálené
kanceláři otevře přes WAN excelovskou tabulku. WAFS systém uchovává kopii
souboru ve svojí cache na lokálním disku. Zatímco uživatel s tabulkou pracuje,
veškeré úložné operace jsou prováděny lokálně v tomto zařízení a nejsou
posílány přes WAN což výrazně zlepší odezvu aplikace. Jakmile uživatel soubor
zavře, WAFS pošle aktualizovaný dokument souborovému serveru.
Během tohoto editačního procesu WAFS zařízení zajistí pokud pracuje korektně
uzamčení otevřeného souboru na serveru a zámek pak uvolní při konečném uložení
a uzavření souboru. Zajímavá situace může nastat, pokud dojde k výpadku ve WAN,
zatímco soubor zůstal u uživatele otevřený.
Vzdálený uživatel bude pokračovat v práci s lokálně cachovanou kopií. Co se
však bude dít s uzamčeným souborem na serveru? Co se stane, když jiný uživatel
otevře tentýž soubor dříve, než bude mít ten první možnost svůj soubor uložit?
Dobrý výrobce WAFS řešení by měl být schopen na takové otázky odpovědět,
nicméně přesná odpověď zatím neexistuje.
Jednou z aplikací, která široce využívá výhod vyspělého cachování ve WAFS, je i
distribuované zálohování. Zatímco zálohování dat ze vzdálených poboček v
datových centrech zabralo celé hodiny, nyní může trvat jen několik minut, a to
díky algoritmům, které pracují s rozdíly v souborech. Namísto přenášení celé
sady souborů přes WAN tak budou posílány jenom změny, čímž se značně zredukuje
čas potřebný pro provedení zálohy.
Aby však mohly WAFS technologie uspět, budou muset plynule kombinovat techniky
pro akceleraci WAN do jediného komplexního řešení. Oblastmi, kde skutečně
vynikají, je hlavně aplikace různých typů cachování a přístup k lokálním
souborům. Už to může být důvodem, proč je do sítí s vysokou latencí instalovat.


Co ve WAN nelze řídit
Při honbě za maximálním výkonem IT správci vylepšují TCP, odstraňují nadbytečné
služby a řídí tok datového provozu. Avšak pokud jde o WAN, některé věci
spočívají spíše v rukou poskytovatelů internetových služeb (ISP), nežli v rukou
IT personálu firem. Životní realita je smutná s tím, jak se zvyšují rychlosti
spojů a RTT (latence), dochází, pokud v routerech nejsou patřičně nastaveny
velikosti front, k nesmírné degradaci propustnosti. Vědečtí pracovníci Curtis
Villamizar a Cheng Song zjistili, že výkon TCP spoje nezávisí pouze na samotné
rychlosti spoje, ale také na mnoha faktorech, jako je hodnota součinu rychlosti
spoje a RTT, známé pod označením BDP (Bandwidth Delay Product). Zajímavou
aplikací BDP je určení odpovídající velikosti fronty (v paketech) pro páteřní
router. Tato hodnota je dána vydělením BDP výslednou hodnotou velikosti
jednotky MTU (Maximum Transmission Unit) převedené na bity.
Mnohé směrovače mají předkonfigurovány úrovně bufferů, jež nejsou nastaveny pro
optimální výkon. Jestliže je velikost bufferu příliš malá, existuje riziko
zahlcení a opakovaného TCP přenosu to je závažnou příčinou poklesu výkonnosti.
Příliš velký buffer zase může zapříčinit nárůst latence. Obě situace přitom
vedou ke zpomalení TCP provozu a výrazně snižují efektivitu a propustnost WAN
spoje. Jinými slovy, uvedená hodnota nesmí být ani příliš velká, ani příliš
malá, ale zkrátka ta správná.)
Přednastavená hodnota MTU u Ethernetu 1 500 bajtů je vhodná pro rychlosti 10
Mb/s nebo i 100 Mb/s, je však příliš malá, pokud se dostanete na gigabitovou
nebo vyšší rychlost. Jedním ze způsobů, jak pomoci zlepšit výkon WAN připojení,
je tedy použit větší MTU. Nicméně protože firemní uživatel nemá nad nastavením
MTU u poskytovatele služeb žádnou kontrolu, může dojít k tomu, že pokud firma
použije jumbo rámce a ISP přitom pracuje se standardním dimenzováním, budou
pakety fragmentovány a sestaveny do menších celků tak, jak je to určeno
směrovačem ISP. Přitom ovšem dojde ke zvýšení zatížení směrovače, což snahu o
maximalizaci výkonu dále zkomplikuje.
Problémem je, alespoň pokud neprovozujete svoji vlastní páteřní síť, že ISP
sotva upraví konfiguraci svých routerů, aby vyhovovaly rychlosti a latenci
vašeho připojení. Mohli byste sice požádat svého providera, aby velikost fronty
modifikoval pro vaše potřeby, nicméně váš provoz je smíchán se zbytkem provozu,
který poskytovatel také zpracovává, takže optimální nastavení pro vaši
instalaci může nepříznivě ovlivnit jiného uživatele. Proto obvykle skončíte u
velikosti fronty na půli cesty pohybuje se někde uprostřed.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.