Rozproszone współdziałające serwery Web.

Transkrypt

1 Computer Networks 31 (1999) Rozproszone współdziałające serwery Web. Scott M. Baker, Bongki Moon Dział Informatyki, Uniwersytet w Arizonie, Tucson, AZ 85721, USA Abstrakt Tradycyjne techniki dla rozproszonego projektowania serwera Web polegają na manipulacji centralnymi zasobami, takimi jak rutery albo usługi DNS, rozprowadzanie zgłoszenia stworzonego dla pojedynczego adresu IP do wielorakich serwerów Web. Celem rozproszonych współpracujących serwerów Web (DCWS) są badania na różnych poziomach zastosowania pod kątem rozprowadzania zawartości w sieci. Osiągamy to przez dynamicznie manipulowanie hiperłączami zgromadzonymi w dokumentach Web. System DCWS skutecznie eliminuje wąskie gardło scentralizowanych zasobów, zachowując równowagę obciążenia między rozmieszczonymi serwerami Web. Serwery DCWS mogą zostać rozmieszczone w różnych sieciach, albo nawet na różnych kontynentach i nadal skutecznie zachowują równowagę obciążenia. Projekt systemu DCWS jest w pełni kompatybilny z istniejącą semantyką protokołu HTTP i istniejącymi produktami oprogramowania typu klient Web. 1. Wstęp Z ogromną popularnością Internetu i World Wide Web (WWW) szybko rosną potrzeby dostarczania bezprecedensowego dostępu do globalnie rozprowadzonych źródeł danych przez Internet. Dostępność Web będzie podstawową częścią usługi, przyszłe cyfrowe biblioteki powinny utrzymać klientów. Ta potrzeba utworzyła silny popyt na dostęp do zasobów baz danych przez Internet [16] i dużą wydajność przez rozpowszechnianie serwerów Web [13,20]. Ponieważ większość popularnych stron sieci doświadcza przeciążenie od wzrastającej liczby użytkowników uzyskujących dostęp równocześnie, to jest pożądane, aby skalowane serwery Web były przystosowane do zmieniających charakterystyk dostępowych i powinny być zdolne do posługiwania się bardzo dużą ilością równoważnych zgłoszeń jednocześnie z sensownymi czasami reakcji. Zbiór dokumentów w sieci może być przeglądany jako digraf, gdzie każdy dokument jest węzłem i każde hiperłącze (albo odsyłacz obrazkowy) jest łączem z jednego węzła do innego. Jeśli istnieje droga, by zastosować ten wykres pomiędzy serwerami, taka że obciążenie jest równo rozłożone pomimo dynamicznie zmieniającym się dostępem do sieci, wtedy problem wyrównywania obciążenia, jednej z najważniejszych kwestii tworzenia rozproszonego serwera Web, został rozwiązany. Nasze rozwiązanie opiera się na bazowym wykresie i opiera się na hipotezie, że większość stron sieci ma tylko kilka dobrze znanych wejściowych gniazd (e.g., od których użytkownicy zaczynają nawigację przez sieciowe dokumenty. Proponowane rozwiązanie polega na dynamicznym zmodyfikowaniu dokumentu Web, zmianie zwartości hiperłącza i tym samym rozprowadzeniu szkieletu dokumentu pomiędzy serwerami. Dynamiczne modyfikacje są wykonane automatycznie przez serwery Web i nie wymagają interwencji użytkownika. Wszystkie dobrze znane gniazda wejściowe będą utrzymane na domowych serwerach, gdzie powstają dokumenty Web, mniej znane 1

2 dokumenty zostaną przeniesione do innych komputerów, które nazywamy serwerami kooperacji dla celów wyrównywania obciążenia. Domowe serwery i serwery kooperacji mogą współpracować jako rozproszony współpracujący serwer Web (DCWS) dla potrzeb procesów sieciowych przetwarzających z wielką elastycznością i skalowalnością. Mogą być wiele możliwych sytuacji, gdzie rozproszony współpracujący serwer Web może zostać rozmieszczony, by obsługiwać szybko zmieniające się sieciowe żądania. Jakikolwiek niezależny serwer Web może być wspomagany przez kilka komputerów połączonych ze sobą przez sieć lokalną w tej samej organizacji. Kiedy niezależny (domowy) serwer jest przeładowany, inne komputery mogą spełniać rolę serwerów kooperacji przez rozładowywanie dokumentów od domowego serwera i dostarczanie ich w imieniu domowego serwera. Dodatkowo, dwa lub więcej wydziałowe serwery Web, które pracują niezależnie w zwykłym trybie operacyjnym, mogą stać się rozproszonym kooperującym serwerem Web; odkąd względne obciążenie może być różne dla każdego wydziałowego serwera Web w zależności od daty i założeń związanych z linią krytyczną, jedne z mało obciążonych serwerów mogą być serwerem kooperacji dla innych bardziej obciążonych serwerów. Serwery mogą być rozproszone pod względem geograficznym. Jeśli organizacja uruchamia pewną liczbę niezależnych serwerów Web dla oddziałów na wschodnich i zachodnich wybrzeżach Stanów Zjednoczonych, Azji i krajów europejskich, wtedy działanie DCWS umożliwiają serwerom Web przystosować się do zmian w geograficznym rozpowszechnieniu dokumentów i zmian z powodu różnych stref czasowych. To też umożliwia serwerom Web skorzystanie z geograficznego buforowania dokumentów [5]. Rozwiązania z rozproszonym kooperacyjnym serwerem Web stanowią wiele korzyści ponad tradycyjnymi systemami bazującymi na manipulacji pakietami, albo usługami DNS czy rozproszonymi systemami plików: Sieć albo manipulacja pakietami nie jest konieczna. Nie ma żadnego obiektu ( takiego jak np. ruter), który potrzebowałby zlokalizować wszystkie pakiety przesyłane między klientem i serwerem. To eliminuje wąskie gardło, które ma miejsce w tradycyjnych systemach. Zamiast domniemanego wyrównywania obciążenia przez używanie serwerów DNS, współpracujące serwery wykorzystują zwartości hiperłączy, by bezpośrednio i precyzyjnie kontrolować obciążenie w dokumentach. Współpracujące serwery nie muszą być w tej samej domenie administracyjnej albo sieci lokalnej. Mogą być rozproszone geograficznie i mogą rozprowadzać ruch w sieci przez wielokrotne sieci. Dodatkowo nowy serwer jest łatwy, elastyczny i efektywny. Jakikolwiek komputer będący w dyspozycji może zostać dodany jako współpracujący serwer, bez rozważania co do lokacji komputera w stosunku do innych istniejących serwerów. W pracy tej, przedstawiamy zasady projektowania systemu DCWS i rezultaty wprowadzania jego pierwowzoru. Demonstrujemy również działanie systemu DCWS na przykładach z rzeczywistymi zestawami danych. Reszta pracy jest zorganizowana w następujący sposób. W części 2 krótko przeglądamy pracę związaną z budowaniem skalowanych serwerów Web. Część 3 przedstawia argumenty za rozwinięciem systemu DCWS i opisuje najważniejsze rozwiązania projektowe. W części 4 opisujemy metrykę dla wybierania i przemieszczania dokumentów i przedstawiamy szczegółowy proces przemieszczania się dokumentu. Część 5 przedstawia doświadczalne skutki, pokazuje jak dobrze pracuje system DCWS w czasie rzeczywistym. Na koniec, w części 6 rozważamy powstanie tego artykułu i zasugerujemy przyszłą pracę. 2. Powiązana współpraca z otoczeniem W literaturze były proponowane różne techniki wyrównywania obciążenia bazujące na usłudze (DNS). Skalowalny sieciowy serwer NCSA jest zbudowany na klastrze identycznie skonfigurowanych serwerów i używa planującej usługi DNS i system plików Andrew (AFS) dla obciążenia występującego pomiędzy serwerami [13,15]. Skalowalny sieciowy serwer IBM jest zbudowany na równoległym systemie SP-2, który jest głównym klastrem identycznych stacji roboczych RS6000. Sieciowy serwer IBM używa ruteru TCP zamiast DNS do planowania wyrównywania obciążenia [11], ale jego użycie jest ograniczone do mocno związanych ze sobą systemów takich jak SP-2. Istnienie różnorodnych serwerów Web nie tylko powiększają złożoność wybierania DNS, ale również ułatwia usługi planowanie DNS nie dające się wprost zaplanować. Liczne odchylenia od usługi planowania DNS zostały proponowane dla niejednorodnych serwerów Web i niejednorodnego rozmieszczenia klientów. Dwuwarstwowa usługa planowania DNS dzieli klientów na dwie klasy "zwykłych" i "gorących", aby utrzymać 2

3 niejednorodne rozpowszechnienie wśród różnych zgłoszeń klientów [8]. Zostały tutaj zastosowane probabilistyczne i deterministyczne algorytmy bazujące na metodzie TTL (czas życia)[7]. Młodsze wartości TTL są wyznaczone kiedy DNS wybiera mniej nadający się serwer albo zgłoszenie odwzorowania adresów pochodzi od "gorącego" klienta. Inne rozwiązanie proponowane w [4] towarzyszyło rozwojowi rozproszonego planowania heurystycznego opartego na koszcie funkcji wielu zmiennych (wykorzystanie CPU, dysków i sieci), który pomaga w podejmowaniu decyzji o migracji zadania. Do wyrównywanie obciążenia są użyte dwie techniki: rotacja DNS i przeadresowanie URL HTTP. Rotacja DNS jest użyta do inicjowania obciążenia i zmiany kierunku URL HTTP oraz by dynamicznie dostosować obciążenie w sieci przez wykorzystanie serwera. Potencjalny problem z rotacją DNS jest rozwinięciem tzw. 'hot spots' (publicznych punktów dostępowych), które prowadzą do poważnego braku równowagi w obciążeniu. Szczegółowe badanie zostało zamieszczone w [3]. Dynamiczny wybór serwera [10] jest zaproponowany jako rozwiązanie oparte na kliencie, gdzie klienci automatycznie wyznaczają najlepszy serwer dla danego pliku bez wcześniejszej wiedzy o wydajności serwera. Technika polega na kopiowaniu sieciowych dokumentów przez serwery proxy. Przyjmuje, że istnieje lista serwerów proxy, która zawiera dany dokument. Zadaniem algorytmu zarządzania buforami [20] było zachowanie równowagi wewnątrz-klastrowej ruchu w sieci oraz temu, by dostęp do dysku odbywał się przez dynamiczne kontrolowanie ilości powtarzanych danych. Scentralizowany algorytm round-robin jest używany do przesyłania zgłoszeń pomiędzy serwerami. Systemy LocalDirector Cisco [19] używają wirtualnego serwera, by kierować przybywającymi zgłoszeniami w wirtualnym adresie IP. Funkcje LocalDirector jako inteligentnego ruter'a, wyznaczają trasy zgłoszeń z wirtualnego adresu IP do fizycznych serwerów o prawdziwych adresach IP. Jest to celowe rozwiązanie do regulowania innymi usługami w sieci. Nie ma żadnych raportów na temat tego co jest wąskim gardłem systemu L ocaldirector. Szybkie łączenie pakietów jest techniką na poziomie użytkownika rozwiniętą w [2] i jest ona używana przez MagicRouter do rozdzielania obciążenia. MagicRouter jest używany do tego by pewna grupa serwerów miała pojedynczy adres IP, bez konieczności modyfikacji w innych serwerach. Szybkie łączenie pakietów jest używane do modyfikacji adresów sieciowych w pakietach danych, które przechodzą przez MagicRouter. W pracy tej szczególną uwagę zwracamy na odporność na błędy i wyrównywanie obciążenia. A MagicRouter jest wąskim gardłem, gdyż wszystkie pakiety muszą przejść przez to centralne wyjście. Technika zwana dynamicznym przepisywaniem pakietów (DPR) [6] jest używana do rozdzielania obciążenia. DPR obsługuje żądania router'a na poziomie IP przez manipulowanie adresami IP które są odwzorowane do hosta. To jest algorytm rozproszony, który polega na eliminacji wąskiego gardła scentralizowanego rozwiązania. Każdy host pełni rolę zarówno serwera jak router'a dla napływających zgłoszeń. Rotacja DNS jest używana jako początkowa metoda dzielenia na części dla osiągnięcia przybliżonego rozproszenia. 3. Zasady projektowania W tym rozdziale przedstawiamy zalety rozwoju rozproszonych współpracujących serwerów Web (DCWS) i opisujemy najważniejsze rozwiązania projektowe elastycznego, w pełni symetrycznego i skalowalnego serwera Web, który osiąga dynamiczne i równoważne obciążenia Wstęp - istotne hipotezy Większość stron w sieci ma tylko kilka dobrze znanych punktów wejścia na stronę. Dobrze znanym punkt wejścia jest URL, który jest ogólnie znany. Na przykład, typowe cyfrowe aplikacje biblioteczne, takie jak strony gazet, archiwizowanych artykułów i usług informacyjnych powinny opublikować URL ich stron indeksowych niż publikować URL dla każdej pojedynczej strony. Rozwiązanie DCWS, proponowane w tym artykule, jest oparte na obserwacjach i uogólnieniach o możliwościach dostępu do dokumentów w sieci: Dokumenty Web są spisane w wykaz (dobrze znane punkty wejściowe) albo nie. Strony sieci, które nie są ogólnie znane są zwykle odwiedzane przez szczególnego klienta, który początkowo odwiedza znane strony i poprzez hiperłącza dociera do punktu przeznaczenia. 3

4 URL z wbudowanymi informacjami wizyjnymi są rzadko publikowane w dokumentach. Użytkownicy nie muszą znać tych URL, ponieważ są one automatycznie pobierane wraz z odpowiadającym im dokumentem Web bez interwencji użytkownika. Użycie ramek na większości nowoczesnych stronach sieci promuje dobrze znany szablon ramki. Szablon ramki jest zwykle mały i łatwo gospodarowany przez serwer macierzysty. W tym miejscu, użytkownicy nie dbają o to jaki jest tekst URL dla wewnętrznych stron, ponieważ oni w pierwszej kolejności uzyskują dostęp do miejsce przez dobrze znany punkt wejściowy. Jest kilka wyjątków od powyższych zasad, które muszą też zostać rozważone. Przede wszystkim indeksy przeszukiwania w sieci i znaczniki użytkownika. Indeksy przeszukiwania są utrzymywane przez duże wyszukiwarki internetowe takie jak AltaVista czy Infoseek. Te wyszukiwarki internetowe mogą udostępnić jakichś URL zawarty na pewnej stronie w sieci. Znaczniki użytkownika są ręcznie zgromadzonymi URL przez użytkowników końcowych na ich komputerach. W ten właśnie sposób jakikolwiek użytkownik może potencjalnie zaznaczyć dowolną stronę. Jednakże, trzeba wspomnieć, że jest wiele możliwości, by zmusić ich do odwiedzin stron głównych, np. poprzez cookies, albo numery sekwencyjne do URLs (wygenerowane przez skrypty CGI JavaScript). Proponowane rozwiązanie przyjmuje, że większość zgłoszeń idzie za wspólnym wzorcem przybywania do dobrze znanego punktu wejścia, podczas gdy mniejszość zgłoszeń będzie mogła zostać zaznaczona albo przeszukana przez wyszukiwarki Migracja dokumentu Wszystkie dokumenty pierwotnie są umieszczone na serwerze macierzystym, gdzie administrator albo autorzy umieścili dokumenty podczas procesu tworzenia ich. Trwała kopia oryginalnego dokumentu zawsze będzie utrzymywana na tym serwerze dla spójności i ewentualnej odporności na błędy. Wszystkie dobrze znane punkty wejścia są utrzymywane na serwerze macierzystym, żeby użytkownicy mieli bezsprzeczne spojrzenie na daną stron w sieci. Dokumenty albo informacje wizyjne inne niż dobrze znane punkty wejścia mogą być migrowany do serwer kooperacji. Serwer kooperacji jest innym serwerem, który została wyznaczony jako komputer, który będzie rozdzielał obciążenie na serwerze macierzystym. Nawiązując do migracji dokumentu, ważne jest, by zauważyć, iż hiperłącza dokumentu są zmodyfikowane w taki sposób, że obciążenie jest w równowadze między pozycją początkową i serwerami kooperacji do przeadresowywania zgłoszeń użytkownika od jednego do innego. Na przykład, na rys.1, dokumenty A E i F K początkowo były obsługiwane przez dwa różne serwery. Numery w nawiasach przedstawiają obciążenie związane z każdym dokumentem. Gdy pierwszy serwer został przeciążony, dokument D został wybrany do przeniesienia go na drugi serwer. W tym przykładzie, drugi serwer stało się serwerem kooperacji dla dokumentu D. Zaadoptujemy leniwy algorytm podziału migracji w próbie zmniejszenia przeciążenia poniesionego przez fizyczną migrację danych. Następnie w rozdziale 4 powiemy o procesie migracji dokumentu Wykresy wyrównywania obciążenia Rozproszony współpracujący serwer Web (DCWS) jest zaprojektowany, by być w pełni symetryczny, czyli każdy serwer może być zarówno serwerem macierzystym dla swoich własnych dokumentów jak również może być potencjalnym serwerem kooperacji dla rozdzielania obciążenia jakiegoś innego serwera macierzystego. Są dwie kluczowe struktury danych, które muszą być zarządzane przez serwery DCWS, a co za tym idzie mogą uczestniczyć i zachować równowagę obciążenia pomiędzy uczestniczącymi serwerami. Przede wszystkim, każdy serwer musi mieć informacje o lokalnych dokumentach i o strukturze między tymi dokumentami. Wszystkie te informacje są przechowywane na lokalnym wykresie dokumentu i każdy serwer jest odpowiedzialny za przechowywanie tych dokumentów. Po drugie, serwery muszą wymieniać między sobą informacje o obciążeniu, żeby mogły zostać podjęte odpowiednie decyzje związane ze zrównoważeniem obciążenia. To jest ogólna informacja, ale każdy węzeł utrzymuje swój własny obraz globalnego stanu. Najlepsze globalne informacje o obciążeniu są przechowywane w globalnej tablicy obciążenia, która znajduje się na każdym serwerze. 4

5 Rysunek 1. Ilustracja migracji dokumentu w celu wyrównania obciążenia (z oryginału) Graf lokalnego dokumentu Graf lokalnego dokumentu (LDG) składa się z uporządkowanego zestawu: (Name, Location, Size, Hits, LinkTo, LinkFrom, Dirty). Pole Name jest po prostu nazwą dokumentu, którą wpisuje użytkownik. Wiąże się to bezpośrednio z nazwą pliku na lokalnym dysku serwera, dzięki temu serwer wie, gdzie umieszczona jest zawartość dokumentu. Pole Location wskazuje, który serwer obecnie obsługuje dokument; może to być macierzysty serwer, bądź serwer kooperacji, gdzie dokument został umieszczony. Pola Size i Hits s użyte do szacowania wyrównywania obciążenia. Pole LinkTo jest listą dokumentów, na której bieżący dokument ma hiperłącza wskazujące na nią; pole LinkFrom jest listą dokumentów, na której są hiperłącza wskazujące do bieżącego dokumentu. Bitowe pole Dirty jest używane do sprawdzenia czy zestaw dokumentów LinkTo został przeniesiony, w ten sposób wymagając, by system zregenerował dokument z jakimiś zmodyfikowanymi hiperłączami. Tablica 1 przedstawia lokalny graf dokumentu przechowywanego na pierwszym serwerze, po uprzednim przeniesieniu dokumentu D na drugi serwer. Warto zauważyć, że jakakolwiek informacja, np. rozmiary dokumentu, jest zostawiona dla lepszej przejrzystości. Graf lokalnego dokumentu jest obliczony do inicjalizacji serwera Web przez skanowanie jego dysku i analizy składniowej dokumentów. Jest to potrzebne do stworzenia dynamicznej struktury i może być modyfikowane przez czas, jeśli zawartość stron jest zmieniona przez administratora. Rozdział 4 opisuje jak lokalny graf dokumentu jest uaktualniany w przypadku gdy dokument jest migrowany. Tablica haszująca jest wykorzystywana do szybkiego znajdowania nazwy dokumentu. Ważne jest aby zoptymalizować tablicą haszujacą, szybkie znajdywanie nazw jest konieczne dla każdego zgłoszenia, które serwer obsługuje. Graf lokalnego dokumentu z reguły jest na tyle mały, że może być całkowicie przechowywany w pamięci. Name Location Size Hits LinkTo LinkFrom Dirty A #1 - - C Nil 0 B #1 - - {D,E} Nil 1 C #1-100 Nil A 0 D #2-200 Nil {B,E} 0 E #1-50 D B 1 Tabela 1. Wejścia LDG do dokumentów na pierwszym serwerze z Rysunku 1. 5

6 Globalna tablica obciążenia Globalna tablica obciążenia(glt) przechowuje całkowity stan grupy serwera. Chociaż informacje o obciążeniu są z natury globalne, każdy serwer utrzymuje lokalną kopię informacji. Globalna tablica obciążenia składa się z uporządkowanego zestawu: (Serwer, LoadMetric). Pole Serwer jest nazwą (albo adresem IP) serwera. Pole LoadMetric jest miarą obciążenia serwera i zmienna ta jest używana do celów wyrównywania obciążenia. Przykładowo, jednostką obciążenia może być sumaryczna liczba zgłoszeń na minutę. Każdy serwer może bez problemu obliczyć własne obciążenie dzięki LoadMetric w momencie pracy użytkownika. Interesujące jest jak informacja o obciążeniu jest przenoszona z jednego serwera do drugiego. W momencie gdy sieć jest już przypuszczalnie przepełniona wieloma zgłoszeniami użytkownika i relacjami, to nie jest konieczna dodatkowa transmisje danych do komunikowania się informacji o obciążeniu. Takie rozwiązanie byłoby stratą czasu dla systemu, gdzie ważna jest szerokość pasma sieci. Zamiast tego, zastosowano rozwiązanie (zw. piggyback) polegające na dołączaniu informacji o obciążeniu do istniejących transferów HTTP [14]. Protokół HTTP uwzględnia wstawianie dodatkowych nagłówków do istniejącej semantyki protokołu. Dodatkowe nagłówki mogą być równocześnie zgłoszeniem HTTP (klient do serwer) i odpowiedzią (serwer do klienta). Dzięki temu możliwe jest wstawienie arbitralnej ilości dwukierunkowych informacji do istniejącej obsługi żądania HTTP. Często dochodzi do migracji dokumentów pomiędzy serwerami DCWS, co stwarza doskonałą okazję, by poprzez piggybacking przesyłać informacje o obciążeniu. W ten sposób, żadne dodatkowe kanały transmisyjne nie są wymagane do przesyłania informacji i o obciążeniu. W rzadkich przypadkach informacja o obciążeniu nie jest wystarczająco często wysyłana, wtedy stosuje się tzw. symulowane przesyłanie informacji o obciążeniu. Stosuje się specjalny wątek (pinger), który ma za zadanie obserwować czy nie występują przestarzałe informacje i jeśli tak, automatycznie wygenerować symulowane przesyłanie do przesyłania aktualnych informacji. Rysunek 2 przedstawia funkcjonalne moduły i struktury danych systemu DCWS i ilustrują zgłoszenia od klientów Web i współdziałania między macierzystymi serwerami i serwerami kooperacji do przetwarzania zgłoszeń. Dodatkowe informacje dotyczące wielowątkowej implementacji DCWS są opisane w rozdziale Proces migracji dokumentu W rozdziale tym opisujemy metrykę wybierania dokumentów do migracji i szczegółowy proces migrujących dokumentów zawierających "leniwy" algorytm podziału migracji, modyfikację hiperłącza, aktualizację informacji o obciążeniu i rozważania spójności. 6

7 Rysunek 2. Funkcjonalny diagram DCWS (z oryginału) Metryka wybierania dokumentów do migracji. Może być wiele okoliczności i czynników do rozważenia, który dokument powinien zostać migrowany. Między innymi, wybraliśmy kilka kryteriów do wybierania dokumentów do migracji, takich które pozwolą wyrównywać obciążenia przy niewielkiej migracji dokumentów. Algorytmiczna instrukcja wyboru dokumentu jest przedstawiona w Algorytmie 1 na rysunku 3. Typowym jest, że dobrze znane punkty wejścia przedstawiają użytkownikom zewnętrzny obraz serwera. Użytkownicy użyją dobrze znanych punktów wejścia, by zyskać dostęp do serwera. Jeśli jakiś z dobrze znanych punktów wejścia jest migrowany do serwera kooperacji, serwer macierzysty powinien przeadresować każde zgłoszenie użytkownika do serwera kooperacji. W ten sposób, krok (ii) jest konieczny, by utrzymać niesprzeczny obraz serwera macierzystego i uniknąć uciążliwych zmian kierunku zgłoszenia. Krok (iii) jest ważny, ponieważ chcemy zachować równowagę obciążenia przez migrowanie możliwie najmniejszej liczby dokumentów. Inaczej mówiąc, częstotliwość dostępu do dokumentu powinna być na tyle duża, by umotywować proces migracji, gdyż migrując dokument, który jest rzadko wykorzystywany nie jest zbyt dobre dla wyrównywanie obciążenia. Jeśli dokument jest migrowany z serwera macierzystego do serwera kooperacji, wszystkie dokumenty wskazujące do dokumentu migrowanego (dokumenty w liście Link From) muszą zostać zmodyfikowane, by uaktualnić hyperłaącza i informacje o zwartości. W kroku (iv) poszukujemy możliwości minimalizacji dodatkowy ruchu w sieci, który byłby wymagany do uaktualniania hiperłączy w dokumentach LinkFrom na zdalnych serwerach. Krok (v) znajduje dokument, który wskazuje do minimalnego numeru dokumentów w LinkTo. 7

8 Algorytm 1 Wybór dokumentu do migracji Na wejściu: Dany jest lokalny graf dokumentu na serwerze macierzystym i graniczna wartość obciążenia T. Na wyjściu: Ten algorytm wybiera dokument do migracji na serwer kooperujący. (i) Niech zbiór dokumentów C kandydata będzie zbiorem wszystkich dokumentów w grafie. (ii) (iii) (iv) (v) koniec Algorytmu Usuń wszystkie dobrze znane punkty wejścia ze zbioru C. Jeśli C jest pusty zwróć nil. Usuń dokumenty ze zbioru C jeśli ich obciążenie jest mniejsze niż założone w zmiennej T. Jeśli C jest pusty odśwież go do poprzedniego ustawienia i powtarzaj te kroki ze zmniejszona wartością T do momentu kiedy C nie będzie już pusty. Wybierz dokument (lub zbiór dokumentów) wskazywanych przez minimalną liczbę dokumentów LinkFrom które nie znajdują się na serwerze macierzystym. Jeśli w kroku (iv) zostało wybranych więcej niż dwa dokumenty, wybierz te z minimalną liczbą dokumentów w LinkTo. Rysunek 3. Wybór dokumentu do migracji "Leniwa" migracja Jeśli jest założenie, że jeden lub więcej dokumentów powinno być migrowanych, wtedy postępuje się według poniżej procedury: Serwer z młodszą wartością LoadMetric jest wybrany z globalnej tablicy obciążenia. Może to zostać zrobione przez proste przeskanowanie tablicy. Ten serwer stanie się serwerem kooperacji dla serwera macierzystego i gospodaruje migrowanymi dokumentami. Lokalny graf dokumentu jest odpowiednio uaktualniany. Szczególnie, pole Location dla dokumentu jest zmodyfikowane, by odzwierciedlić nową lokalizację. Dla każdego dokumentu wskazanego przez Link From bit Dirty jest ustawiony. To spowoduje, że dokumenty wskazane przez pole LinkFrom zostaną zregenerowane przy następnym zgłoszeniu po któreś z nich. Nawiązując do powyższych kroków, wydzielone dokumenty są migrowane tylko logicznie. Fizyczna migracja dokumentu jest odłożona do momentu, aż zaistnieje taka potrzeba. Nazywamy to "leniwą" migracją dokumentów. Aby zrozumieć fizyczny proces migracji konieczne jest szczegółowe omówienie działanie serwera DCWS. W momencie, kiedy serwer otrzymuje zgłoszenie mogą mieć miejsce dwa przypadki. Albo to jest zgłoszenie dla dokumentu, który jest lokalny dla serwera (serwer jest serwerem macierzystym dla dokumentu), albo zgłoszenie jest dla dokumentu, który został przysłany do serwera (serwer jest serwerem kooperacji dla dokumentu). Jeśli zgłoszenie jest dla przysłanego dokumentu, wtedy istnieją dwie możliwości: Serwer kooperacji nie ma kopii dokumentu na jego lokalnym dysku. W tym przypadku, serwer kooperacji musi zainicjować sesję HTTP z macierzystym serwerem dokumentu, by odzyskać dokument. Gdy dokument jest z odzyskany serwera macierzystego, wtedy kopia jest przechowywana na lokalnym dysku serwera kooperacji dla przyszłych zadań; zawartości też są wysłane z powrotem do użytkownika, który zainicjował oryginalne zgłoszenie. Jeśli serwer kooperacji ma kopię dokumentu na swoim lokalnym dysku, wtedy dokument musiał już fizycznie zostać umieszczony i kopia na lokalnym dysku serwera kooperacji może zostać wysłana do końcowego użytkownika Procedura tworzenia grafów dokumentu i ich rekonstrukcja Aby zmodyfikować hiperłącza przypisane dokumentowi, parser HTML tworzy prostą analizę drzewa tekstu dokument programu HTML. Jakiekolwiek zmodyfikowane odsyłacze są wtedy zastąpione drzewem analizy składni. Odkąd procedura tworzenia grafów i regeneracja dokumentów są intensywnymi procesami, to istnieje zapotrzebowanie, by odłożyć realizację proces na możliwie ostateczny termin, by wyeliminować jakąś nadmiarową albo niepotrzebną pracę. Bit Dirty dokumentu w lokalnym grafie dokumentu jest użyty jako znak czy dokument musi być analizowany i zregenerowany przez nowe odsyłacze. W momencie, gdy nastąpi zgłoszenie wyszukania dokument i jeśli bit Dirty nie jest ustawiony, wtedy dokument jest uważany za bieżący i jest uzyskana jego kopia z dysku. Jeśli bit Dirty jest ustawiony, wtedy 8

9 dokument jest uważany za przedawniony i jest poddany analizie, regeneracji, a na dysku będzie zapisana nowa kopia oraz bit Dirty będzie zresetowany. 5. Doświadczenia 5.1. Rozwój prototypu. Serwer DCWS jest zbudowany w postaci modularnej używającej wielowątkowy paradygmat. Elementy zawierają wielowątkowy protokół HTTP, który jest odpowiedzialny za przyjmowanie i analizowanie zgłoszeń. Wielowątkowe zabezpieczenie zostało wprowadzony w życie z myślą, że będzie nadzorowało całą pracę. Serwer może działać na Linux'ie używając biblioteki Posix, jak również na produkcieh Microsoft Windows używające Win32 Thread API. Bieżąca implementacja Linux została przetestowana używając wersji jądra Linux i wersji pthreads 0.5. Parser HTML ogólnego przeznaczenia został złączony z innego projektu. Parser HTML ogólnego przeznaczenia został użyty zbudowania prostego drzewa analizy dla tekstów programu HTML. Chociaż parser nie jest zoptymalizowany dla prototypu DCWS, to oczekuje się, że zoptymalizowany parser tylko ulepsza wydajność przez stałą ilość i nie oddziałuje na przyspieszenie bądź powiększenie wydajności serwera Doświadczalne ustawiania Sprawdzania i testy zostały wykonane na klastrze 64 stacji roboczych Pentium Intel 200MHz. Każda stacja robocza ma 128 MB pamięci i 2 albo 4 GB pamięci dyskowej. Stacje robocze są łączone przez 100 Mbps komutowaną sieć Ethernet. Przełącznik może posługiwać się łączną szerokością pasma 2.4 Gbps w transmisji wszyscy-do-wszystkich. Proces serwera (albo macierzystego albo kooperującego) działa na każdej ze stacji roboczych Pentium. Każdy proces serwera zawarł 12 wątków. Każdy serwer macierzysty został skonfigurowany w ten sposób, by migrować pliki w maksimum 10 sekundach na jeden plik. Żaden z serwerów kooperacji nie akceptował większej ilości plików w 60 sekundach. Ten przedział czasowy jest potrzebny do, by uniknąć przeładowywania serwera kooperacji przez migrujące zbyt szybko dokumenty. Serwery kooperacji zostały skonfigurowane, by zatwierdzić migrujące dokumenty stale co 120 sekund. Parametry doboru serwera są zreasumowane w Tablicy 2. Parametr Wartość parametru N fe 1 Nπ 1 N wk 12 L sq 100 T st 10 sekund Tπ 20 sekund T val 120 sekund T home 300 sekund T coop 60 sekund Tablica 2. Wykaz parametrów Wzorzec konfiguracji klienta. 9

10 Standardowa konfiguracja została zbudowana na bazie unikatowych własności rozproszonych serwerów kooperacji Web, hiperłącza dokumentów mogą zostać zmodyfikowane dynamicznie. Konwencjonalne konfiguracje takie jak SPECWeb96 [9] nie są odpowiednie do zaprojektowania żądań dokumentów bez odniesienia do dynamicznie zmiennych hiperłączy zawartych w dostarczonych dokumentach. Wzorcowa konfiguracja jest zamierzona do odzwierciedlenia prawdziwego zachowania się większości klientów w momencie kiedy logują się do sieci. Użytkownicy Web uruchamiają przeglądarki typowo konserwując swoją pamięć podręczną. Ze zwykłym wzorcem konfiguracji klienta spotykamy się, gdy symulujemy to zachowanie przez budowanie klienckiej pamięci podręcznej do programu konfiguracji. Pamięć podręczna jest utrzymana na okres, kiedy każda symulowana sekwencja dostępu (1 25 zgłoszeń na dokument) jest konfigurowana i resetowana po każdej z tych sekwencji. Efekty związane z powyższym zagadnieniem na wydajności systemu DCWS są dwojakie: (1) zachowanie obszaru aktywnego informacji wizyjnych odnoszącego się do wielokrotnych stron jest zmniejszone i (2) zmiany kierunku są powiększone z powodu przestarzałych danych zgromadzonych po stronie klienta. Oba te zjawiska są prawdziwe, powiększają realizm konfiguracji wzorcowego systemu DCWS. Program wzorcowej konfiguracji klienta jest wielowątkowy i zawiera jeden główny wątek służący do załadowania dokumentu i cztery dodatkowe wątki do załadowania równolegle obrazków. Równoległość ta jest zamierzona i służy tu do symulacji istniejących przeglądarek, takich jak np. Netscape, która wykorzystuje wielokrotne wątki. Liczba wzorcowych konfiguracji klienta (średnio osiem) została wybrana, by wykorzystać optymalnie wszystkie będące w dyspozycji jednostki CPU. Przepustowość informacyjna na klienta stacji roboczej, na środkowym zestawie danych, LOD, wynosiła w przybliżeniu 700 połączeń na sekundę i 1.7 Mb na sekundę. Zestaw danych LOD będzie opisany później w tym rozdziale. Dwadzieścia pięć stacji roboczych zostało skonfigurowanych jako komputery służącej do wzorcowej konfiguracji. Szczegółowe instrukcje zawiera Algorytm 2 na rysunku Zgłoszenie pomija zachowanie. Prawdopodobnym jest, że częstotliwość wpływania zgłoszenia mogłaby być często wyższa niż wielkość obsługi żądań. Zgłoszenia backlogged są ustawiony w kolejce do gniazda na serwerze i kolejka ta może urosnąć poza wstępnie wyznaczoną maksymalną długością kolejki (zobacz w Tablicy 2). Wtedy, połączenie jest zrywane z błędem odpowiedzi 503. Jest to jeden ze sposobów zrywania połączenia, ale jednocześnie metoda ta bardzo obciąża serwer. Kiedy 503 jest otrzymany, klient jest rozłączony. Wątek klienta jest wstrzymany na sekundę od pierwszego rozłączenia, na dwie sekundy od drugiego rozłączenia, na cztery sekundy od trzeciego rozłączenia i tak dalej Zestawy danych Wybraliśmy cztery prawdziwe zestawy danych z różnych adresów i charakterystycznymi publicznymi punktami dostępowymi w odniesieniu do system DCWS w różnych sytuacjach. Specyficzne informacje znajdują się pod adresem: Czwartym zestawem danych jest Sequoia 2000 publicznie dostępna pod adresem: / sekwoja / test wzorcowy punkt odniesienia /. MAPUG Mailing List Archive: Ten zestaw danych jest objęty 1534 sformatowanych wiadomości zawierających w sumie 28,998 odnośników o łącznym rozmiarze 5918 Kbajtów. Wiadomości są przesuwane i umieszczone w kolejności: data, temat i autor. Od czasu, kiedy sześć obrazków bitmapowych zostało włączonych do prawie wszystkich dokumentów, mają duże zapotrzebowanie na zgłoszenia i tworzą znaczące publiczne punkty dostępowe. Statistics Web SBLog: został wygenerowany przez automatyczny program statystyczny, ten zestaw danych zawiera 402 dokumentów, 57,531 odnośników i zajmuje 8468 Kbajtow. Wykres z linkami tego zestawu danych jest podobny do drzewa z kilkoma indeksowanymi stronami jako wewnętrzne węzły drzewa i duża ilość stron zajmujących liście drzewa. Pojedynczy obraz JPEG jest wykorzystywany do konstrukcji tzw. wykresu słupkowego na prawie wszystkich stronach i formach w znaczących punktach dostępowych z powodu dużej ilości zgłoszenia. LOD Role-Playing Adventure Guide: Ten zestaw danych jest stosunkowo mniejszy niż poprzednie, składa się z 349 dokumentów, 1433 odnośników i 750 kilobajtów danych; a 200 dokumentów spośród 349 obrazy 10

11 JPEG. Ten zestaw danych został wybrany do reprezentacji rzeczywistego przemieszczania stron w sieci do powiększania graficznej złożoności. Chociaż duża liczba obrazów nie jest ściśle publicznymi punktami dostępowymi tak jak inne zestawy, kilka z indeksowanych stron jest znacząco częściej odwiedzanych niż wspominane strony czy obrazy. Sequoia benchmark data: Dane rastrowe dla Sequoia przechowujące 2000 wzorców składających się ze 130 AVHRR (Advanced Very High Resolution Radiometer) plików obrazu z terminalu satelitarnego NOAA. Obrazy są kompresowane w skalach Mbajtowych. Utworzyliśmy stronę HTML dla rastra danych Sequoia, który zawiera hiperłącze do każdego graficznego pliku. Algorytm 2 Tradycyjne benchmark do forever begin odświeżenie pamięci podręcznej ustawić current_url <- losowo wybrany dobrze znany punkt (pozycja) wyjściowy(a ustawić no_steps <- losowo wybrana liczba z przedziału for i=1 to no_steps do begin zgłosić dokument current_url z serwera jeśli nie jest obecnie w pamięci podręcznej. zażądać równolegle wszystkich wklejonych obrazów (używając wątków pomocniczych). czekać do momentu kiedy żądane dokumenty przybędą. dokonać składniowej analizy i wybrać nowe łącze z dokumentu ustawić current_url <- nowe łącze end end end Algorytmu Rysunek 4. Szkic symulowanych wątków klienta Doświadczalne skutki Wśród wielu sposobów oceny wydajności serwerów Web, pojawia się zgodność, że trzema najważniejszymi miarami są: połączenia na sekundę (CPS), transfer bajtów na sekundę (BPS) i tzw. round-trip time (RTT) [15,17]. Jednakże, trzecia miara, round-trip time jest trudna do zmierzenia dla bieżącego serwera Web i zależy od współczynnika wydajności sieci globalnej i ewentualnych wąskich gardeł które nie jest bezpośrednio związane z samym serwerem Web. W ten sposób, w naszych eksperymentach, zdecydowaliśmy się użyć pierwszych dwóch miar, by ocenić wydajność i skalowalność prototypu systemu DCWS. 11

12 Rysunek 5. Wydajność DCWS (z oryginału) Maksymalne obciążenie Jednym z poważnych wyzwań dla serwerów Web jest zajmowanie się maksymalnym możliwym obciążeniem. Aby dokładnie zmierzyć maksymalną wydajność DCWS, uśredniliśmy przesłane bajty na sekundę (przepustowość informacyjna) i połączenia na sekundę (wątki uruchomione na stacjach roboczych klientów). Wzrastająca liczba współdziałających klientów od 16 aż do 400, powtórzyliśmy ten sam eksperyment i otrzymaliśmy uśrednienie miar. Trzeci zestaw danych (LOD) został wykorzystany dla tego kompletu eksperymentów, gdyż jego graficzna właściwość najbardziej odzwierciedla rzeczywiste strony Web. Rysunki 5a,b przedstawiają BPS i miary CPS, kolejno porównując ilość współdziałających klientów. Na obu wykresach miara wydajności powiększyła się prawie linearnie, aż do osiągnięcia maksimum. Gdy maksimum zostało osiągnięte miary pozostały stałe, przypuszczalnie z powodu pomijania nadmiarowych zgłoszeń poza możliwości serwera. Z drugiej strony oczywistym jest, że prototyp DCWS pracuje w sposób skalowalny. W momencie gdy zostanie podwojona liczba serwerów maksymalna wydajność wzrasta proporcjonalnie. Na przykład, z 8 serwerami maksymalna wydajność wynosi około 18.6 Mega BPS i 7150 CPS dla 176 klientów. Z 16 serwerami, maksymalna wydajność wynosi około 39.4 Mega BPS i CPS dla 368 klientów Skalowalność i publiczne punkty dostępowe. Publiczne punkty dostepowe (niezmiernie popularne dokumenty albo obrazy) ograniczają równoległość większości skalowalnych systemów serwera Web. Odkąd DCWS jest w stanie kontrolować, które dokumenty są obsługiwane przez które serwery kooperacji, niezmiernie "gorące" dokumenty automatycznie są dzielone do rozłącznych serwerów kooperacji, skutecznie dzieląc komplet "gorących" dokumentów pomiędzy wieloma serwerami kooperacji. Rysunek 6a,b przedstawia maksymalną wydajność prototypu DCWS mierzoną kolejno w BPS i CPS. Z LOD i zestawami danych Sequoia charakterystyki obu miar są zbliżone to liniowych dla 16 serwerów, które były wykorzystane do eksperymentu. Jednakże przestrzegaliśmy mniejszej skalowalności dla dwóch różnych zestawów danych SBLog i MAPUG. Dla tych dwóch zestawów danych system DCWS dobrze zmieniał skalę dla ośmiu konfiguracji serwera, jednak nie działał poprawnie dla liczby serwerów z przedziału od 8 do 16. Wykonaliśmy szczegółowe ręczne badanie zestawu danych MAPUG i stwierdziliśmy, że przyczyną tego był ekstremalne zachowanie publicznych punktów dostępowych sześciu obrazów JPEG w aktualnym w zestawie danych. Chociaż obrazy zostały poprawnie migrowane do rozłącznych serwerów kooperacji przez DCWS, każdy obraz miał priorytetowy wskaźnik dostępu, który spowodował, że kilka z serwerów kooperacji osiągało maksimum pracując na 16 serwerach. Obecnie 12

13 pracujemy nad rozwiązaniem, by zwiększyć skalowalność poprzez kopiowanie ważnych dokumentów na wielokrotnych serwerach kooperacji. Od tych eksperymentów, uznajemy to rozpowszechnienie danych i charakterystyki dostępu do danych za znaczący wpływ na wydajność oraz publiczne punkty dostepowe mogą ograniczyć potencjalny równoległość systemu DCWS. Przypuszczamy, że jedyną drogą do rozwiązania tego problemu jest zaadoptowanie kopii publicznych punktów dostępowych, co nie jest aktualnie stosowane w prototypie DCWS. Rysunek 6. Wydajność DCWS dla różnych zestawów danych (z oryginału) CPS kontra BPS Miary CPS i BPS są związane z rozmiarem zaangażowanych dokumentów i globalnym połączeniem. Wykonywanie obsługi żądania Web przez TCP wymaga wymiany wielu połączeń konfiguracyjnych ściągnięciu pakietów, w tym pakietów zawierających aktualne dane. W ten sposób mały rozmiar CPS wzrasta przez zmniejszanie liczby bajtów na przesłania, to również zmniejsza BPS przez marnowanie większej szerokości pasma na dodatkowe połączenia globalnych pakietów. Jest to potwierdzone przez wyniki przedstawione na rysunkach 6a,b. Górny BPS jako zachowany przez Sequoia i następnie przez SBLog, MAPUG i zestawy danych LOD. Tak jak oczekiwaliśmy, miary CPS zostały zachowane w odwrotnej kolejności. Od kiedy w rzeczywistości transakcje Web dość zmalały [5] wybraliśmy CPS jako miarę wyrównującą - raczej niż BPS w rozdziale 4. Z drugiej strony, możliwe jest, że w systemie, który używa znacząco większych rozmiarów pliku (takie jak zestaw danych Sequoia), BPS może być lepszą metryką wyrównywaniem obciążenia. 6. Podsumowanie i przyszła praca Zaprojektowaliśmy i wprowadziliśmy w życie system rozproszonych współpracujących serwerów Web (DCWS). System DCWS jest oparty na dynamicznej manipulacji hiperłączy dołączonych do dokumentów Web w celu rozprowadzenia zgłoszenia między współpracującymi serwerami Web. Analizowaliśmy wydajność prototypu systemu DCWS z prawdziwymi zestawami danych, zawierającymi składowe wzorce danych Sequoia. Eksperymenty pokazują, że system DCWS ma wysoki potencjał do osiągnięcia linearnej skalowalności przez skutecznie unikanie wąskiego gardła scentralizowanych zasobów takich jak dyski i szerokości pasma sieci. Globalnie włączony w modyfikację hiperłączy był bez znaczenia porównywany z ulepszoną wydajnością uzyskaną przez wykorzystanie rozproszonych serwerów. Zostało przedstawione, że bez obecności publicznych punktów 13

14 dostępowych linearna maksymalna wydajność została zważona aż do 16 współpracujących serwerów. Obciążenie zostało równo rozprowadzony między serwerami i wyrównywanie obciążenia zostało osiągnięte szybciej niż gdyby było liniowe od samego początku. Wnioskujemy, że system DCWS proponowany w tej pracy jest rozwiązaniem do budowania skalowalnych serwerów Web, zarówno lokalnie i w środowisku geograficznie rozproszonym. Jako przykład, system DCWS może zostać użyty do połączenia grupy pierwotnie niezależnych serwerów, by zbudować zjednoczony serwer Web przeznaczony do archiwizacji obrazów w dużej skali oraz do tworzenia i przechowywania danych geograficznie rozproszonych. Zauważmy, że nadal pozostaje wiele kwestii do dalszych rozważań na temat rozwoje systemu DCWS. Te rozważania mogą poprawić zrozumienie wydajności systemu DCWS w realistycznych sytuacjach. Planujemy nadal prowadzić eksperymenty w odniesieniu do oceny algorytmów podziału dla migracji dokumentu i spójności oraz doboru parametrów wydajności w środowiskach geograficznie rozproszonych i niejednorodnych. Planowaliśmy również rozbudować bieżącą implementację systemu DCWS, aby mogła ona utrzymać publiczne punkty dostępowe przez kopiowanie popularnych dokumentów i badała efekty rozpowszechnienia danych równolegle i ich skalowalności. Literatura: [1] V. Almeida, A. Bestavros, M. Crovella and A. de Oliveira, Characterizing reference locality in the WWW, in: 4th Int. Conf. on Parallel and Distributed Information Systems, Miami Beach, FL, 1996, pp [2] E. Anderson, D. Patterson and E. Brewer, The Magic-Router: an application of fast packet interposing, submitted for publication, [3] D. Andresen, T. Yang, O. Egecioglu, O. Ibarra and T. Smith, Scalability issues for high performance digital libraries on the World Wide Web, in: Proc. ADL 96 Forum on Research and Technology Advances in Digital Libraries, 1996, Washington, DC, pp [4] D. Andresen, T. Yang and O.H. Ibarra, Toward a scalable distributed WWW server on workstation clusters, Journal of Parallel and Distributed Computing 42 (1997) [5] M.F. Arlitt and C.L. Williamson, Internet Web servers: workload characterization and performance implications, IEEE/ACM Transactions on Networking 5 (1997) [6] A. Bestavros, M. Crovella, J. Liu and D. Martin, Distributed packet rewriting and its application to scalable server archi-tectures, Technical Report TR , Feb, 1998, Boston University, Boston, MA, [7] M. Colajanmi and P.S. Yu, Adaptive TTL schemes for load balancing of distributed Web servers, ACM Sigmetrics Performance Evaluation Review 25 (2) (1997) [8] M. Colajanmi, P.S. Yu and D.M. Dias, Scheduling algo-rithms for distributed Web servers, in: Proc. 17th Int. Conf. on Distributed Computing Systems, Baltimore, MD, 1997, pp [9] SPECweb96 Benchmark, Standard Performance Evaluation Corporation, SPECweb96 Benchmark, April, 1996, [10] M.E. Crovella and R.L. Carter, Dynamic server selection in the Internet, in: 3rd IEEE Workshop on the Architectur and Implementation of High Performance Communication Subsystems (HPCS 95), 1995 (also available as TR , Boston University, 14

15 [11] D.M. Dias, W. Kish, R. Mukherjee and R. Tewari, Scalable and highly available Web server, in: Proc. IEEE COMP-CON Conf. on Technologies for the Information Super-highway, 1996, pp [12] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee, Hypertext Transfer Protocol HTTP/1.1, Internet Draft, 1997, [13] E.D. Katz, M. Butler and R. McGrath, A scalable HTTP server: the NCSA prototype, Computer Networks and ISDN Systems 27 (1994) [14] B. Krishnamurthy and C.E. Wills, Piggyback server invali-dation for proxy cache coherency, Computer Networks and ISDN Systems 30 (1998) [15] T.T. Kwan, R.E. McGrath and D.A. Reed, NCSA s World Wide Web server: design and performance, IEEE Computer 28 (1995) [16] T. Nguyen and V. Srinivasan, Accessing relational databases from the World Wide Web, in: Proc ACM- SIGMOD Conference, 1996, Montreal, Canada, pp [17] V.N. Padmanabhan and J.C. Mogul, Improving HTTP la-tency, Computer Networks and ISDN Systems 28 (1995) [18] M. Stonebraker, J. Frew, K. Gardels and J. Meredith, The SEQUOIA 2000 storage benchmark, in: Proc ACM-SIGMOD Conference, Washington, DC, 1993, pp [19] Cisco System, Scaling the Internet Web Servers, 1997, White Paper, [20] S. Venkataraman, M. Livny and J.F. Naughton, Memory management for scalable Web data servers, 13th Int. Conf.on Data Engineering, Birmingham, UK, 1997, pp

16 Spis treści: Abstrakt 1. Wstęp 2. Powiązana współpraca z otoczeniem 3. Zasady projektowania 3.1 Wstęp - istotne hipotezy 3.2 Migracja dokumentu 3.3 Wykresy wyrównywania obciążenia Graf lokalnego dokumentu Globalna tablica obciążenia 4. Proces migracji dokumentu 4.1 Metryka wybierania dokumentów do migracji 4.2 "Leniwa" migracja 4.3 Procedura tworzenia grafów dokumentu i ich rekonstrukcja 5. Doświadczenia 5.1 Rozwój prototypu 5.2 Doświadczalne ustawiania Wzorzec konfiguracji klienta Zgłoszenie pomija zachowanie Zestawy danych 5.3 Doświadczalne skutki Maksymalne obciążenie Skalowalność i publiczne punkty dostępowe CPS kontra BPS 6. Podsumowanie i przyszła praca Literatura 16