Każdemu po równo

Urządzenie Cisco optymalizuje pracę serwerów internetowych.

Urządzenie Cisco optymalizuje pracę serwerów internetowych.

Osiągnięcie optymalnego obciążenia zadaniami serwerów pracujących w sieciach intranet i Internet jest trudnym zadaniem i wymaga od administratora cierpliwości, umiejętności sprawnego analizowania pracy serwerów oraz dobrego planowania. Problemu ten rozwiązuje nowe urządzenie Cisco, o nazwie LocalDirector. Odpowiedzialne jest ono za rozdzielanie ruchu internetowego i intranetowego w optymalny sposób między kilkoma serwerami realizującymi te same zadania.

Namniej atrakcyjną cechą urządzenia jest jego cena, która wynosi 32 tys. USD. Jeśli firma posiada wysoce obciążone serwery intranetowe i potrzebuje zaawansowanych mechanizmów dystrybucji zadań między nimi, powinna wygospodarować fundusze na zakupienie Cisco.

Dystrybucja zadań

Obecnie firmy wykorzystują dwa rozwiązania pozwalające rozdzielać nadmierny ruch internetowy. Pierwsze, dosyć proste w implementacji, polega na wykorzystaniu DNS-u (Domain Name System) odpowiedzialnego za konwersję nazw internetowych na numery IP (i odwrotnie). DNS może służyć jako punkt rozdzielający zadania między serwerami, ale czyni to w sposób losowy i nie zwraca uwagi na aktualne obciążenie każdego z nich.

Innym sposobem odciążenia serwerów jest udostępnienie ich nie pod jednym adresem WWW, tak jak ma to miejsce zazwyczaj, ale jako kilka. Niemniej jednak to rozwiązanie, choć często stosowane, nie umożliwia użytkownikowi orientacji, który serwer jest w danej chwili najmniej zatłoczony.

LocalDirector nie zmusza użytkownika do zgadywania, ponieważ sam automatycznie i w niezauważalny sposób kieruje go do najmniej obciążonego w danej chwili serwera.

Wirtualne adresowanie

LocalDirector używa jednego numeru IP, pod którym ukryty jest wirtualny serwer o określonym adresie internetowym. W rzeczywistości nie jest to prawdziwy serwer internetowy lecz jedynie oprogramowanie, odpowiedzialne za dystrybucję całego ruchu przychodzącego do serwerów firmy.

Gdy zapytanie klienta trafia pod wirtualny adres IP, LocalDirector kieruje je do każdego z fizycznych serwerów obsługujących ruch internetowy w firmie. Następnie urządzenie sprawdza czas odpowiedzi każdego z serwerów i za pośrednictwem specjalnego algorytmu SDA (Session Distribution Algorithm) przesyła wszystkie kolejne odwołania do najszybciej odpowiadających na nie serwerów. Kiedy obciążenie wybranego przez LocalDirectora serwera znacząco się zwiększa i szybkość jego odpowiedzi na żądania maleje, SDA wybiera inny, najszybszy w danej chwili serwer.

Zaletą tego rozwiązania jest fakt, że technologia SDA nie powoduje nadmiernego ruchu w sieci, ponieważ nie opiera się na wysyłaniu zapytań PING ani UDP (User Datagram Protocol), a jedynie na analizie czasu odpowiedzi poprzednio wysłanego zapytania. Ponadto LocalDirector pracuje jako prosty mostek. Jest to o tyle korzystne, że przy odpowiednim skonfigurowaniu sieci można uniknąć zbędnego tłoku sieciowego w tej części farmy serwerowej, która odpowiedzialna jest za obsługę ruchu internetowego.

Na sprzętową część LocalDirectora składa się procesor Pentium 166 MHz Intela oraz odpowiednia dla niego płyta główna, do której dołączone są dwie karty sieciowe, zgodne ze standardem Ethernet i Fast Ethernet (Intel EtherExpress 10/100Base-TX). Jak na razie LocalDirector nie umożliwia pracy z szybszymi sieciami.

Prosta instalacja

LocalDirector jest bardzo prosty w konfiguracji i eksploatacji. Oferuje administratorowi możliwość zarządzania za pośrednictwem dowolnego terminala zgodnego ze specyfikacją VT100. My podłączyliśmy go do urządzenia za pośrednictwem kabla null modem.

Aby przetestować LocalDirectora, zbudowaliśmy trójserwerowy segment sieci. Każdy z serwerów miał zainstalowane oprogramowanie serwera WWW i FTP. Ponadto na jednym z nich pracował także serwis DNS.

W innym segmencie sieci zainstalowaliśmy dwóch klientów sieciowych, a następnie oba segmenty połączyliśmy za pomocą kart sieciowych, pracujących w testowanym urządzeniu Cisco.

Podczas konfiguracji LocalDirectora zdefiniowaliśmy adresy IP prawdziwych serwerów i adres wirtualnego serwera, a następnie użyliśmy polecenia bind w celu przyporządkowania wszystkich rzeczywistych adresów do jednego adresu wirtualnego. Stworzyliśmy też w bazie serwisu DNS dwa odnośniki: dla serwera WWW i FTP. Oba wskazywały na wirtualny adres IP LocalDirectora.

Urządzenie Cisco potrafi obsłużyć 1024 prawdziwych i 1024 wirtualnych adresów serwerów i umożliwia przyporządkowanie jednego prawdziwego serwera do wielu wirtualnych adresów. Możliwe jest także określenie portów fizycznego serwera, do których odwoływać się mają wirtualne adresy. Jest to szczególnie pomocne w przypadku tych firm, które posiadając jeden wydajny serwer, zamierzają umieścić na nim wiele WWW o różnych adresach sieciowych.

Dystrybucja pakietów

Gdy rozpoczęliśmy oglądanie zawartości serwera WWW, LocalDirector pracował tak jak przewidywaliśmy, wysyłając początkowo zapytanie do wszystkich serwerów, a następnie - po otrzymaniu informacji zwrotnej - wybierając serwer z najkrótszym czasem odpowiedzi. Zaletą tego rozwiązania jest fakt, że nie zmniejsza ono w żaden sposób wydajności pracy serwerów i sieci i umożliwia wykonywanie odwołań, zarówno poprzez podanie adresu wirtualnego, jak i fizycznych adresów IP serwerów.

LocalDirector wysyła zapytania SDA co najmniej raz na minutę, a więc na bieżąco otrzymuje informację o czasie odpowiedzi każdego z serwerów. W przypadku połączeń typu FTP może to powodować pewne problemy, gdyż urządzenie Cisco oddzielnie rozważa każdą prośbę o przesłanie pliku lub wyświetlenie zawartości katalogu. O ile w przypadku połączeń HTTP nie ma to żadnego znaczenia, to przełączenie w trakcie sesji FTP na inny serwer zawsze wiązało się z utratą łączności i zawieszeniem klienta FTP pracującego na naszym komputerze.

Jest jednak sposób na rozwiązanie tego problemu. LocalDirector pozwala administratorowi ustawić specjalny parametr czasowy, określający jak długo użytkownik ma być obsługiwany przez jeden serwer (bez względu na zmiany wydajności jego pracy). Przykładowo, gdy ustawiliśmy ten parametr na 5 minut, mogliśmy być pewni, że przez 5 minut sesja łączności z serwerem FTP nie zostanie zakłócona. Po upływie tego czasu LocalDirector ponownie szukał najmniej obciążonego serwera i kierował na niego kolejne zapytania klienta FTP.

Awaria

Aby sprawdzić reakcję LocalDirector na wyłączenie serwera, nawiązaliśmy z nim najpierw sesję łączności, a następnie odłączyliśmy go od koncentratora. Ponieważ pozostawiliśmy ustawiony wcześniej parametr czasowy, LocalDirector nadal próbował wysyłać wszystkie odwołania do odłączonego serwera. Dopiero gdy czwarty raz z rzędu otrzymał zwrotną informację o nieosiągalności serwera, zdecydował się przełączyć cały ruch na inny serwer.

Ponadto urządzenie co minutę wysyłało zapytania SDA do odłączonego serwera, co w tym wypadku powodowało dodatkowe opóźnienia. Jedynym sposobem uniknięcia tego działania była rekonfiguracja LocalDirectora i określenie jednego z podporządkowanych mu serwerów (tego odłączonego) jako urządzenie nieczynne (out of service).

W idealnych warunkach powinno być możliwe założenie pułapki SNMP, dzięki której administrator byłby informowany, że serwer ileś razy z rzędu nie odpowiedział na pytania LocalDirectora. To pozwoliłoby osobie zarządzającej pracą sieci na szybkie zatelnetowanie się do urządzenia Cisco i zdalną zmianę jego konfiguracji.

Niestety, testowany przez nas LocalDirector nie mógł być zarządzany za pośrednictwem SNMP ani nie obsługiwał zdalnego Telnetu (administrowany mógł być jedynie za pośrednictwem dołączonego bezpośrednio do niego kabelka). Według zapewnień Cisco, obie te cechy są dostępne we wszystkich dostarczanych urządzeniach.

Usprawnienia

LocalDirector ma być także w przyszłości zarządzany za pośrednictwem sieci WWW i dowolnej przeglądarki internetowej. Ponadto za pomocą kabla można będzie łączyć dwa urządzenia Cisco w jedną funkcjonalnie jednostkę. Dzięki temu w przypadku awarii jednego z nich drugie natychmiast przejmowałoby zarządzanie całością ruchu internetowego. Cisco nie podała jednak terminu realizacji tych założeń.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200