Wiadomości
Poszerzać łącze czy optymalizować?
18 maja 2009 15:30,
NetWorld
Tytułowy dylemat pojawia się na drodze wielu menedżerów IT w tysiącach firm. Odpowiedź na postawione pytanie nie zawsze jest jednak prosta, zbyt często jednak przy jej udzielaniu nie bierze się pod uwagę mniej znanych faktów.
Na początku zazwyczaj jest tak: aplikacje w sieci WAN zaczynają zwalniać, przesłanie pliku zaczyna zajmować pół godziny a ludzka frustracja rośnie. Niezadowoleni pracownicy pukają do drzwi IT i pada proste oskarżenie - “sieć za wolno działa." Naturalną reakcją w wielu filmach, od lat było poszerzanie łącza u providera internetu. Przyjęło się myśleć, że jest to jeśli nie jedyne, to główne i najskuteczniejsze remedium na problemy z siecią. A jednak, ku zaskoczeniu wielu, zazwyczaj okazuje się, że po rozszerzeniu łącza problemy zamiast znikać trwają. Co więcej, analiza zużycia łącza pokazuje pracownikom IT, że wcale nie jest ono utylizowane w 100%. Tajemnica tego zjawiska tkwi w prawdziwych wąskich gardłach sieci WAN.
Prawdziwa przyczyna spowolnienia
Powszechnie wiadomo, że pierwszym ograniczeniem szybkości sieci jest sama szerokość łącza. Żadna aplikacja nie będzie przesyłał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 - cichy "zabójca"
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 po pewnych modyfikacjach 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 standardowa implementacja TCP w systemach operacyjnych używanych obecnie nie zawsze korzysta z tych mechanizmów. Przykładowym elementem mającym duży wpływ na wydajność jest rozmiar okna, czyli liczba bajtów, jaka nadawca może zaakceptować. Zbyt mały rozmiar okna ogranicza transmisje danych do wysyłania dużej ilości segmentów o małym rozmiarze, zbyt duży 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 "ułomnością" 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 zbyt duży spadek szybkości pojedyńczej sesji (o 50%) w przypadku wystąpienia przeciążenia w sieci.
Ostatnim zagadnieniem jest działania 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.
Rozwiązanie
W to miejsce 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.
***
Autorem artykułu jest Wojciech Gołębiowski, regionalny dyrektor sprzedaży w firmie Riverbed Technology.
Redakcja NetWorld dołożyła wszelkich starań, aby wyeliminować ewentualne nawiązania autopromocyjne w powyższym artykule. Czytelnicy powinni jednak mieć na uwadzę, że porady firmowe mogą zachęcać do wyboru określonych rozwiązań, produktów lub aplikacji sieciowych.
Prawdziwa przyczyna spowolnienia
Powszechnie wiadomo, że pierwszym ograniczeniem szybkości sieci jest sama szerokość łącza. Żadna aplikacja nie będzie przesyłał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 - cichy "zabójca"
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 po pewnych modyfikacjach 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 standardowa implementacja TCP w systemach operacyjnych używanych obecnie nie zawsze korzysta z tych mechanizmów. Przykładowym elementem mającym duży wpływ na wydajność jest rozmiar okna, czyli liczba bajtów, jaka nadawca może zaakceptować. Zbyt mały rozmiar okna ogranicza transmisje danych do wysyłania dużej ilości segmentów o małym rozmiarze, zbyt duży 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 "ułomnością" 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 zbyt duży spadek szybkości pojedyńczej sesji (o 50%) w przypadku wystąpienia przeciążenia w sieci.
Ostatnim zagadnieniem jest działania 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.
Rozwiązanie
W to miejsce 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.
***
Autorem artykułu jest Wojciech Gołębiowski, regionalny dyrektor sprzedaży w firmie Riverbed Technology.
Redakcja NetWorld dołożyła wszelkich starań, aby wyeliminować ewentualne nawiązania autopromocyjne w powyższym artykule. Czytelnicy powinni jednak mieć na uwadzę, że porady firmowe mogą zachęcać do wyboru określonych rozwiązań, produktów lub aplikacji sieciowych.
Komentarze (0)
- Kingston: Nowa linia dysków SSD
- Microsoft zapowiada nowy system plików - ReFS
- Intel: SSD 520 - nowa linia szybkich dysków
- Praktyczne porady dla administratorów na 2012 rok
- Co powinien wiedzieć każdy specjalista IT?
- Narzędzia dla administratorów sieci
- Windows Intune 3.0 - szansa na perfekcyjne narzędzie?
- Kontrowersyjne decyzje Oracle odnośnie Javy
- Testy penetracyjne pomogą w obronie przed cyberatakami
- 2012 - rok przełomowy dla internetu?
Polecane
Przełomowy rok... znowu
Lektura firmowych informacji prasowych i prognoz firm analitycznych nie pozostawia wątpliwości - każdego roku...
Spokój i luz administratora
Wymagania wobec pracowników działów IT rosną proporcjonalnie do stopnia rozwoju teleinformatyki. Oczekuje się, że...