CHMUROWY SYSTEM WEBOWY GWARANTUJĄCY CZAS OBSŁUGI A CLOUD-BASED WEB SYSTEM WITCH GUARANTEE SERVICE TIME

Transkrypt

1 STUDIA INFORMATICA 2017 Volume 38 Number 4 (138) Maciej PŁATEK, Krzysztof ZATWARNICKI Politechnika Opolska, Instytut Automatyki i Informatyki CHMUROWY SYSTEM WEBOWY GWARANTUJĄCY CZAS OBSŁUGI Streszczenie. W artykule opisano koncepcję systemu gwarantującego obsługę żądań w chmurowym systemie chmury obliczeniowej, uwzględniającego podejście minimalizujące koszty poniesione przez dostawcę usługi chmurowej. Słowa kluczowe: system chmurowy, gwarantowanie obsługi żądań A CLOUD-BASED WEB SYSTEM WITCH GUARANTEE SERVICE TIME Summary. This paper describes the concept of system guaranteeing service of request in cloud computing system which is taking into account the approach to minimize costs incurred by cloud vendor. Keywords: Cloud computing system, guarantee service of requests 1. Wprowadzenie Internet towarzyszy życiu człowieka praktycznie w każdym jego aspekcie. Spowodowało to znaczący wzrost prac nad stabilnością i niezawodnością systemów Webowych, które potrafią obsługiwać duże liczby nadchodzących żądań od użytkowników. Aktualnie, by to osiągnąć, tworzone są systemy na podstawie chmur obliczeniowych. Chmury obliczeniowe to model przetwarzania danych oparty na rozbudowanej infrastrukturze, dostarczany zazwyczaj jako usługa przez zewnętrzne ośrodki. Wszystkie aspekty systemu są dostosowywane przez dostawcę usługi chmurowej. Od dostawcy zależy, jaki typ systemu zostanie udostępniony

2 130 M. Płatek, K. Zatwarnicki klientowi oraz jakie zadania będzie on spełniał. Główny podział chmur obliczeniowych został dokonany na podstawie tego, w jaki sposób dostarczana jest usługa dla klienta [6]: 1) IaaS (ang. Infrastructure as a Service) Infrastruktura jako usługa, model dostarczający klientowi całej infrastruktury informatycznej, tzn. sprzętu, oprogramowania, serwerów wirtualnych oraz serwisowania. Najczęściej dostawca oferuje klientowi konkrety przydział mocy obliczeniowej lub pamięci. 2) PaaS (ang. Platform as a Service) Platforma jako usługa, w tym przypadku dostawca przekazuje klientowi komplet aplikacji lub środowisko gotowe do pełnienia funkcji wymaganej przez niego. Klient uzyskuje dostęp do zasobów poprzez dowolny komputer połączony z Internetem. 3) SaaS (ang. Software as a Service) Oprogramowanie jako usługa, klient otrzymuje konkretną funkcjonalność i oprogramowanie spełniające jego aktualne wymagania. Najczęściej funkcjonalności są od siebie odseparowane i nie posiadają wspólnego interfejsu użytkownika. Systemy Webowe należą do kategorii SaaS. Każda strona WWW zamieszczona w chmurze obliczeniowej jest traktowana jako odizolowane oprogramowanie. Kluczowym zadaniem w tego typu systemie jest dostosowanie go pod względem przepustowości, dostępności oraz czasu obsługi do wymagań klienta [1-4]. W literaturze opisywane są systemy, które oferują minimalizowanie czasu obsługi żądania zarówno dla całych stron, jak i pojedynczych żądań [4, 7, 8]. Brak jest projektów systemów, które gwarantują czas obsługi żądań jednocześnie, w przypadku gdy nie jest to możliwe, minimalizują straty finansowe dostawcy usługi chmurowej. W artykule przedstawiono propozycję systemu opartego na modelu chmury obliczeniowej, korzystającego z elementów rozwiązania wykorzystanego w systemie MLF (ang. Most loaded first) [5]. System ten został przedstawiony w poprzednich pracach, gdzie zostało potwierdzone jego działanie zarówno w środowisku symulacyjnym, jak i po implementacji na rzeczywistych serwerach. Elementy systemu MLF zostaną wykorzystane do zagwarantowania czasu obsługi każdego pojedynczego żądania przychodzącego do klienta odczytującego stronę WWW. Dodatkowo zaproponowano podejście kosztowe do obsługi żądań, które w przypadku niedotrzymania czasów obsługi żądania zminimalizuje koszty poniesione przed dostawcę usługi chmurowej. Założono, że niektóre obiekty na stronie WWW są ważniejsze i ich dostarczenie jest kluczowe, są to pliki HTML zawierające szkielet strony WWW. Mniej ważne są obiekty zagnieżdżone w dokumencie HTML definiującym stronę WWW, np. obrazki. Podejście kosztowe sprawia, że dostawca usług w chmurze w przypadku niedostarczenia gwarantowanego żądania w czasie będzie musiał wnieść opłatę karną dla klienta zależną od typu żądanego elementu.

3 Chmurowy system webowy gwarantujący czas obsługi Architektura systemu System składa się z klientów wysyłających żądania, pośrednika strefowego wybierającego strefę, złożonego z pośrednika lokalnego oraz serwerów mogących obsłużyć żądania użytkowników, całość została przedstawiona na rys. 1. Każdy z serwerów na końcowym etapie obsługi żądania jest kompletnym elementem posiadającym wszystko, by móc dostarczyć klientowi dowolny element strony WWW. Zadaniem pośrednika strefowego jest wybór strefy, w której znajduje się serwer mogący obsłużyć żądanie w czasie tmax, który system gwarantuje dla tego typu elementu. Pośrednik lokalny, znajdujący się w strefie, ma za zadanie kolejkowanie żądań oraz dystrybucję ich do odpowiedniego serwera. Kluczowa jest komunikacja pomiędzy pośrednikiem strefowym i pośrednikiem lokalnym. Zakłada się, że serwery pośredniczące mają dostęp do tego samego zestawu danych. Rys. 1. Architektura proponowanego systemu Fig. 1. Architecture of proposed system Najważniejszymi elementami, które w głównej mierze odpowiadają za gwarancję czasu obsługi, są oba serwery pośredniczące. Pośrednik strefowy jako pierwszy odbiera żądania od użytkownika. Następnie nawiązuje komunikację z pośrednikami lokalnymi, zlokalizowanymi w każdej ze stref wchodzących w skład systemu w celu znalezienia strefy, w której znajduje

4 132 M. Płatek, K. Zatwarnicki się serwer mogący obsłużyć dane żądanie w czasie th mniejszym niż gwarantowane tmax. By to określić, sprawdzane jest obciążenie każdej ze stref. Obciążenie definiowane jest jako suma liczby aktualnie obsługiwanych żądań na wszystkich serwerach wchodzących w skład strefy. Następnie strefy są szeregowane malejąco według obciążeń i według tej kolejności sprawdzane. Sprawdzanie odbywa się do momentu odnalezienia najbardziej obciążonej strefy, mogącej obsłużyć żądanie w wymaganym czasie. Po poprawnym odnalezieniu strefy żądanie przekazywane jest do pośrednika lokalnego. Pośrednik lokalny jest elementem bazującym na wcześniejszych pracach [5]. Podzielony jest na dwie logiczne sekcje sekcję kolejkującą oraz sekcję przełączającą. Pierwsza, kolejkująca, odpowiedzialna jest za kolejkowanie żądań, natomiast druga pełni rolę dystrybutora żądań do serwerów WWW. Schemat przełącznika przedstawiono na rys. 2. Rys. 2. Przełącznik lokalny Fig. 2. Local switch Część kolejkująca składa się z trzech modułów: modułu analizującego, modułu serwisu oraz modułu kolejki. Po przyjęciu przez przełącznik lokalny żądania pochodzącego od klienta, kierowane jest ono do modułu analizującego, gdzie pobierane są następujące informacje: adres obiektu ai oraz identyfikator klienta c. Po otrzymaniu wszystkich informacji moduł serwisowy wylicza termin d, określający, kiedy powinna zacząć się obsługa żądania oraz termin di, określający moment, w którym obsługa żądania powinna się skończyć. Po wyliczeniu terminu d moduł kolejkujący szereguje żądania, zgodnie z polityką EDF (ang. Earliest deadline first), czyli od najbliższego terminu. By móc spełnić wymaganie systemu, mające minimalizować poniesione koszty, zakłada się, że opłata karna za elementy niedostarczone w odpowiednim czasie jest zależna od typu żądanego obiektu. Największa opłata karna będzie poniesiona za pliki definiujące jej strukturę, czyli dokumenty HTML,

5 Chmurowy system webowy gwarantujący czas obsługi 133 a najmniejsza za statyczne obiekty zagnieżdżone na stronie. Schemat kolejki przedstawiono na rys. 3. Rys. 3. Schemat kolejki Fig. 3. Queue schema Po sprawdzeniu, w którym miejscu w kolejce ma się znaleźć żądanie, weryfikowane jest, czy opóźnione w ten sposób zakolejkowane żądania będą w stanie dotrzymać terminu d. Jeżeli nie zostaną one opóźnione, żądanie umieszczane jest w wyznaczonym miejscu. Jeśli miałyby zostać opóźnione, porównywane są koszty opóźnienia kolejkowanego żądania k 2 oraz koszty opóźnienia kolejnych żądań k 1. Jeżeli k 2 > k 1, to zadanie jest umieszczane w wyznaczonym miejscu, w przeciwnym razie przesuwane jest miejsce docelowego umieszczenia kolejkowanego żądania i weryfikacja odbywa się ponownie. Weryfikacja kończy się, gdy k 2 > k 1. Moduł serwisu składa się z modelu strony, bazy czasów obsługi, modułu estymującego i modułu adaptacyjnego, schemat przedstawiono na rys. 4. Model strony przechowuje informacje o czasach obsługi konkretnych elementów strony. Moduł estymujący, używając informacji z modelu strony, wylicza terminy d i i ' d i. Moduł adaptacyjny jest odpowiedzialny za adaptację informacji. Czas obsługi każdego żądania jest do niego przesyłany po opuszczeniu kolejki. W kolejnym kroku żądanie przekazywane jest do sekcji przełączającej, która składa się z modułu wykonawczego, modułu decyzyjnego oraz modeli serwerów, których liczba jest równa liczbie rzeczywistych jednostek w danej strefie systemu. Modele serwerów są odpowiedzialne za estymowanie czasu obsługi dla danego serwera.

6 134 M. Płatek, K. Zatwarnicki Moduł decyzyjny wybiera serwer, na którym ma zostać przeprowadzona obsługa danego żądania. Wybierany jest najbardziej obciążony serwer, gdzie obciążenie jest liczbą aktualnie obsługiwanych żądań, który może obsłużyć żądanie, by dotrzymać terminu d. Rys. 4. Moduł serwisu Fig. 4. Service module Jeżeli taki serwer jest niedostępny, to wybierany jest serwer, który obsłuży żądanie najszybciej. Dzięki takiemu rozwiązaniu serwery o niskich indeksach są najbardziej obciążone, ale nadal są w stanie obsługiwać żądania, a serwery o wysokich indeksach są w stanie zawsze obsłużyć żądanie w krótkim czasie. Obciążenie serwerów jest utrzymywane na poziomie 80% maksymalnej mocy obliczeniowej. Po podjęciu decyzji moduł wykonawczy przekazuje żądanie do wybranego serwera. Moduł ten jest również odpowiedzialny za zbieranie informacji o mierzonym czasie obsługi, który służy do aktualizacji informacji w pozostałych modułach. 3. Podsumowanie System bazuje na wcześniejszych pracach, których poprawne działanie zostało poparte badaniami, więc przedstawiona propozycja systemu może być podstawą do dalszych prac nad gwarantowaniem czasu obsługi żądań w systemach chmur obliczeniowych. Dodatkowo po-

7 Chmurowy system webowy gwarantujący czas obsługi 135 dejście kosztowe jest nowym elementem i może prowadzić do udoskonalenia procesu gwarancji czasu obsługi. Dalsze prace będą skupione na weryfikacji przedstawionej propozycji oraz konstrukcji algorytmów obsługi części modułów. Najważniejszym elementem będzie zaprojektowanie modeli serwerów w taki sposób, by pozwalały spełnić założenia funkcjonalne systemu. W kolejnym kroku należy zaprojektować algorytm kolejki, który będzie minimalizował koszty według zadanego problemu. W końcowym etapie system zostanie zaimplementowany w środowisku testowym. BIBLIOGRAFIA 1. Kaur B.: Software As A Service: A Brief Study. International Research Journal of Engineering and Technology, Volume Amazon.: A Practical Guide to Cloud Migration Migrating Services to AWS , dostęp: , 3. Amazon.: Software as a service (Saas) on AWS. dostęp: , 4. Amazon: Web Application Hosting in the AWS Cloud. 2012, dostęp: , 5. Zatwarnicki K., Płatek M. Zatwarnicka A.: A Cluster-Based Quality Aware Web System, Information Systems Architecture and Technology. Proceedings of 36 th International Conference on Information Systems Architecture and Technology ISAT 2015 Part II, Springer, 2016, p Voda I.: Migrating Existing PHP Web Applications to the Cloud, Informatica Economica, Vol Google Cloud Platform for AWS Professionals, dostęp Google Cloud Platform for Azure Professionals, dostęp

8 136 M. Płatek, K. Zatwarnicki Abstract This paper presents the proposal of system which will guarantee service time of requests in cloud computing system. Proposed system is based on previous work and expand its idea into cloud computing. It also offer new approach to queuing requests, by minimizing costs incurred by cloud system vendors. First section of the article discusses problem of servicing users requests in Web systems and describes basics about cloud computing. Next section provides information about proposed system with schemas and description of every module in the system. The third section sums up provided information and presents future work. Adres Maciej PŁATEK: Politechnika Opolska, Instytut Automatyki i Informatyki, ul. Prószkowska 76, Opole, Polska, mac.platek@doktorant.po.edu.pl Krzysztof ZATWARNICKI: Politechnika Opolska, Instytut Automatyki i Informatyki, ul. Prószkowska 76, Opole, Polska, k.zatwarnicki@po.opole.pl