| Akceleracja WAN
15959
single,single-post,postid-15959,single-format-standard,ajax_fade,page_not_loaded,,,wpb-js-composer js-comp-ver-4.2.1,vc_responsive

Akceleracja WAN

Akceleracja WAN

Jak mądrze rozwijać sieci rozległe? Na to pytanie szukają odpowiedzi tysiące administratorów na całym świecie. Odpowiedź jest prosta, lecz przy jej udzielaniu nie bierze się pod uwagę mniej znanych faktów.
Przyczyn do zadania powyższego pytania jest kilka: aplikacje w sieci WAN zaczynają działać wolniej, przesłanie pliku zaczyna zajmować pół godziny, ludzka frustracja rośnie a wydajność pracowników spada. Naturalną reakcją administratora w wielu firmach, od lat było poszerzanie łącza u providera internetu. Myśląc, że jest to jeśli nie jedyne, to główne i najskuteczniejsze remedium na problemy z siecią. Jednak, wbrew pozorom, poszerzanie łącza organicza porblem w bardzo limitowanym stopniu lub nie ogranicza go wcale. Co więcej, analiza zużycia łącza pokazuje pracownikom IT, że wcale nie jest ono utylizowane w 100%. Tajemnica tego zjawiska kryje się w prawdziwych wąskich gardłach sieci WAN.Ukryte przyczyny
Powszechnie wiadomo, że pierwszym ograniczeniem szybkości sieci jest sama szerokość łącza. Żadna aplikacja nie jest w stanie przesyłać danych szybciej niż maksymalnie dopuszcza to łącze. To ograniczenie nie budzi wątpliwości. Pozostałe jednak są bardziej subtelne i dlatego, częściej się o nich zapomina. Spróbujmy się więc im przyjrzeć.TCP – sędziwy protokół
Pierwszą przyczyną wzrostu latencji (opóźnień w sieci) jest nasz stary dobry znajomy – protokół TCP. Wymyślony w połowie lat siedemdziesiątych służy z pewnymi zmianami do dziś. Od swojej pierwszej implementacji w latach osiemdziesiątych specyfikacja protokołu była wzbogacana o nowe mechanizmy i algorytmy mające na celu poprawienie wydajności, jak również adaptacji TCP do różnych środowisk sieciowych.
Niestety standardowe wdrożenie TCP w systemach operacyjnych używanych obecnie nie zawsze korzysta z tych mechanizmów. Przykładem tego jest mający duży wpływ na wydajność rozmiar okna, czyli liczba bajtów, jaką nadawca może zaakceptować. Zbyt małe okno ogranicza transmisję danych do wysyłania dużej ilości segmentów o małym rozmiarze, zbyt duże może wprowadzać opóźnienia transmisji jak również powodować mało efektywne wykorzystanie pasma.
Efektywny podejściem byłaby dynamiczna możliwość zmiany rozmiaru okna w zależności od rodzaju transmisji. Jest niestety to dość rzadko stosowane i tak na przykład w systemie operacyjnym Windows XP okno ma stały rozmiar 64 KB, a żeby to zmienić i wprowadzić dynamiczne skalowanie okna należy zmodyfikować rejestr systemowy co może być nie lada wyzwaniem w sieciach dużych przedsiębiorstw.
Kolejna wadą protokołu TCP jest problem tak zwanego wolnego startu – sesje TCP mimo dostępnego pasma nie potrafią wystarczająca szybko z niego skorzystać. I tak na przykład, standardowa sesja TCP, korzystająca z 1500-bajtowych pakietów w sieci o 100 ms czasie RTT, aby osiągnąć stabilny stan o przepływności 10 Gbps potrzebuje ok 100 minut. Następnym słabym punktem podstawowej implementacji protokołu TCP jest drastyczny spadek szybkości pojedyńczej sesji (o 50%) w przypadku wystąpienia przeciążenia w sieci.
Ostatnim zagadnieniem jest działanie aplikacji trzecich, które pracują w sieci “równolegle” do protokołu TCP. Podobnie jak w przypadku problemów z wielkością okna danych, tak i tutaj szerokość dostępnego łącza nie przyspiesza aplikacji, które mają określony rozmiar wysyłanych wiadomości i często muszą czekać na odpowiedź lub potwierdzenie otrzymania danych. Problem ten nie dotyczy zazwyczaj tych protokołów aplikacji, które były tworzone z myślą o sieciach rozległych jak HTTP czy FTP. Problem dotyczy jednak tych protokołów, które tworzono z myślą o sieci LAN, jak np. MS CIFS.Możliwości rozwiązańNa miejsce problemów wkracza optymalizacja,  i akceleratory sieciowe, które  próbują w rożny sposób zaadresować wszystkie z wymienionych problemów standardowej implementacji protokołu transportowego. Ważne jest jednak, aby wykorzystywane przez nie mechanizmy były zgodne z normami (RFC compliant) wykorzystywanymi podczas projektowania i implementacji innych wersji protokołu TCP. Zgodność ta pozwala zabezpieczyć się przed sytuacja w której ruch optymalizowany wywłaszczy ruch nie optymalizowany uniemożliwiając nie optymalizowanym aplikacja/użytkownikom poprawna prace w sieci.

Okazuje się, że dobrze przeprowadzona optymalizacja pozwala bez dodatkowych nakładów na łącza przyspieszyć ruch w sieci w takim stopniu, że z punktu widzenia pracowników zaciera się różnica między wymianą danych w sieci LAN i w sieci WAN. Co więcej, działy IT są w stanie konsolidować i centralizować infrastrukturę np. przechodząc na zwirtualizawane serwery w miejsce serwerów “fizycznych.” Łatwiejszy i szybszy staje się też backup, co bezpośrednio przekłada się na bezpieczeństwo danych. Z tego powodu to właśnie optymalizację WAN nazywa się coraz częściej kluczowym narzędziem dla rozproszonych organizacji.

‹ Powrót
Tags:
No Comments

Sorry, the comment form is closed at this time.