ZASTOSOWANIE OPROGRAMOWANIA OPENSOURCE DO ZAPEWNIENIA NIEZAWODNO CI I SKALOWALNO CI SERWISÓW E-BIZNESOWYCH

Transkrypt

1 ZASTOSOWANIE OPROGRAMOWANIA OPENSOURCE DO ZAPEWNIENIA NIEZAWODNO CI I SKALOWALNO CI SERWISÓW E-BIZNESOWYCH KRZYSZTOF MAŁECKI JAROSŁAW W TRÓBSKI Pa stwowa Wy sza Szkoła Zawodowa w Gorzowie Wlkp. ANDRZEJ NAKONIECZNY Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Streszczenie Obecnie wiele przedsi biorstw prowadzi działalno w Internecie, nie zdaj c sobie sprawy z potencjalnego zagro enia utraty swoich danych, b d utraty dost pu do swoich danych. W niniejszym artykule omówiono zagadnienie zapewnienia niezawodno ci serwisów webowych. Przedstawiono elementy oprogramowania bior ce udział w udost pnianiu tre ci b d usług oraz sposoby ich zabezpieczenia przed awari. Kolejnym istotnym elementem było zbadanie mo liwych rozwi za pozwalaj cych na skalowanie usługi reakcji na zwi kszenie liczby u ytkowników. Słowa kluczowe: o rodek zapasowy, OpenID, replikacja, wirtualna maszyna, ci gła dost pno 1. Wprowadzenie Nadrz dnym celem pracy jest analiza sposobów zapewnienia wysokiej osi galno ci usług sieciowych na przykładzie serwisów webowych z zastosowaniem oprogramowania o otwartych ródłach. Artykuł obejmuje zagadnienia techniczne zwi zane z klastrowaniem serwerów frontend oraz backend, klastrowaniem i replikacj baz danych, współdzieleniem systemu plików, klastrowaniem systemów operacyjnych oraz zapewnieniem O rodka Zapasowego udost pniaj cego usług. Pojawienie si, w latach dziewi dziesi tych ubiegłego wieku, swobodnego dost pu do Internetu zmieniło podej cie wielu przedsi biorstw. Obecnie do przekazania zwykłej wiadomo ci wykorzystuje si wszechobecne komunikatory, bramki SMS czy poczt elektroniczn. Niektóre przedsi biorstwa s całkowicie, w swojej działalno ci, uzale nione od wiatowej sieci, która z jednej strony bardzo ułatwiła prowadzenie działalno ci, z drugiej za spowodowała zagro enie bytu awaria serwerów danego przedsi biorstwa pozbawia dochodu i zmniejsza zaufanie kontrahentów. Dlatego, tak istotne jest dla przedsi biorcy prowadz cego e-biznes, aby oferowane przez niego usługi działały w trybie 24/365. Zapewnienie ci głego dost pu do usług nie jest proste. Elementów, które mog zawie jest wiele. Pomi dzy odbiorc a usług istnieje szereg mocno ze sob powi zanych komponentów. Na cz z nich nie mamy wpływu. Mo emy natomiast zaprojektowa i uruchomi nasz usług w taki sposób, by zminimalizowa prawdopodobie stwo jej niedost pno ci. W artykule skupiono si na problemie uruchomienia serwisu OpenID w taki sposób, by zminimalizowa czas nieosi galno ci usługi i umo liwi jego skalowalno. W dalszej cz ci opisano czym jest OpenID oraz przedstawiono kilka sposobów zabezpieczania si przed awariami.

2 190 Krzysztof Małecki, Jarosław W tróbski, Andrzej Nakonieczny Zastosowanie oprogramowania Opensource do zapewnienia niezawodno ci i skalowalno ci serwisów e-biznesowych 2. OpenID Upowszechnienie si dost pu do Internetu umo liwiło nam dost p do wielu usług. Niestety, wprowadziło te liczne problemy. Jednym z nich jest identyfikacja to samo ci. Wcze niej, id c do urz du (na poczt czy do banku) posługiwano si dowodem osobistym. Identyfikacja była natomiast niepotrzebna w sklepie towar przynoszony był do kasy i opłacany. W tzw. sieci jest inaczej. Do praktycznie ka dej usługi czy to konto bankowe, portal aukcyjny, czy te sklep internetowy nale y si wst pnie zalogowa. Pozwala to systemowi na rozpoznanie kto próbuje uzyska dost p i jakie ma uprawnienia. Niestety, wymaga to pami tania dziesi tków loginów i haseł. Mo na oczywi cie, w ka dym miejscu, stosowa te same sekrety, jednak jest to mało bezpieczne rozwi zanie. W przypadku, gdy do systemu dostanie si niepowołana osoba, prawdopodobnie b dzie w stanie odczyta nasze hasła i wykorzysta je w celu nieuprawnionego dost pu do kont bankowych czy aukcji klientów. Dostawcy usług staraj si minimalizowa tak mo liwo poprzez papierowe hasła jednorazowe, tokeny sprz towe czy sekrety wysyłane u ytkownikom z wykorzystaniem SMS. Nie jest to jednak wygodne rozwi zanie. Poza tym, nadal nale y pami ta loginy w banku jest to np. numer u ytkownika, w portalu aukcyjnym nazwa u ytkownika, a w skrzynce elektronicznej adres . W tym temacie zauwa alny jest brak ujednolicenia. Rozwi zaniem powy szego problemu jest zastosowanie mechanizmu OpenID zbioru protokołów i specyfikacji udost pniaj cych mechanizm rozproszonego uwierzytelniania oraz dystrybucji to samo ci w usługach webowych. Jest to sposób na jednorazowe okre lenie swoich podstawowych danych jak: imi, nazwisko, miejsce zamieszkania, czy i wykorzystywanie ich w innych systemach wspieraj cych protokół OpenID. Zasada działania przedstawia si nast puj co: po wyborze dostawcy to samo ci u ytkownik zakłada konto i definiuje w nim wszystkie dane, jakie w przyszło ci b d udost pniane innym usługom. Zwie czeniem tego procesu b dzie przyznanie identyfikatora OpenID maj cego posta URL (Uniform Resource Locator ujednolicony format adresowania zasobów, stosowany w Internecie). Identyfikator ten nast pnie wykorzystuje si w serwisach w celu uwierzytelnienia. Co wa ne, sekrety (nazwa u ytkownika i hasło) pozostaj wył cznie w systemie dostawcy usługi OpenID, natomiast w serwisie np. sklepu przechowywany jest wył cznie nasz identyfikator. Dzieje si to dzi ki temu, e w celu uwierzytelnienia, docelowy serwis pobiera od u ytkownika jego identyfikator, przekierowuje go do dostawy, który weryfikuje dane, a do docelowego serwisu wraca jedynie odpowied potwierdzaj ca wraz z danymi, które pozwalamy udost pni, np. imieniem, nazwiskiem i adresem . Co wa ne, to u ytkownik decyduje co pozwala przekaza do docelowej usługi, a do pozostałych danych nie b dzie dost pu [2]. Takie rozwi zanie to kolejny krok w ułatwieniu codziennego dost pu do usług sieciowych. Pozostaje jednak pytanie: co si stanie, je li z jaki przyczyn usługa OpenID u naszego dostawcy jest niedost pna? Powodów mo e by wiele od problemów z ł czem, poprzez problem z serwerem, czy awari oprogramowania, po przeci enie systemu. W takiej sytuacji u ytkownik traci dost p do wszystkich serwisów, w których wykorzystywał OpenID. O ile w przypadku dost pu do forum nie jest to problem, to utrata dost pu do skrzynki pocztowej, komunikatora albo co gorsza, konta bankowego stanowi pewien dyskomfort a czasami uniemo liwia wr cz prac. Niniejszy artykuł analizuje i rozwi zuje ten problem. Istniej pewne skuteczne metody zabezpieczaj ce systemy informatyczne przed awari. Metody te powinny by rozpatrywane na etapie projektowania systemu:

3 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 28, SPOF (Single Point Of Failure), czyli pojedynczy punkt awarii. W celu unikni cia lub chocia by, zminimalizowania SPOF, nale y wykorzysta mo liwo ci jakie udost pnia nam zarówno sprz t jak i oprogramowanie. Klastrowanie serwerów aplikacji i baz danych. Wyró nia si tutaj ró ne tryby: standby, active-active, multi master lub te master-multi slave. Skalowanie definiowane jako łatwo modyfikowania systemu b d komponentu celem dostosowania do dziedziny problemu. Ka dy skalowalny system musi spełnia trzy warunki: obsługa zwi kszonej liczby da, prawidłowe przetwarzanie poszerzonego zbioru danych, stałe zapewnienie mo liwo ci utrzymywania i konserwacji [3]. DNS mechanizm ten wykorzystuje si w poł czeniu z klastrowaniem serwerów i umo liwia przedstawienie wielu serwerów pod jedn nazw domenow. Dzi ki temu, w przypadku awarii jednego z nich, oprogramowanie klienta mo e spróbowa skontaktowa si z kolejnym serwerem przypisanym do tej samej nazwy wykorzystywany jest tu algorytm round-robin. Reverse proxy zmniejszenie obci enia serwerów przetwarzaj cych. Mo e by równie wykorzystywany, podobnie jak DNS, do balansowania obci enia poszczególnych serwerów. W dodatku ukrywa on wewn trzn struktur obsługuj c usług, co mo e by istotne z punktu widzenia bezpiecze stwa [4]. Wirtualizacja polega na uruchamianiu wielu systemów w wirtualnej maszynie (Virtual Machine). Takie rozwi zania nie tylko pozwalaj na zoptymalizowanie wykorzystania bazy sprz towej oraz zmniejszenie wydatków na energi elektryczn zarówno na potrzeby samych serwerów jak i klimatyzacji ale tak e, posiadaj mechanizmy automatycznego uruchamiana systemów, które z jaki przyczyn przestały by widoczne (awaria serwera, awaria sieci). Dodatkowo, dzi ki funkcjonalno ci migracji, pozwalaj na przenoszenie uruchomionych systemów pomi dzy w złami klastra wirtualnego, co pozwala na nieprzerwane wiadczenie usług, a jednocze nie na przeprowadzanie prac konserwacyjnych poszczególnych w złów zarówno wymiana sprz tu, jak i samego oprogramowania. O rodek Zapasowy gdy zawiod wszystkie dotychczasowe zabezpieczenia, jedynym rozwi zaniem mo e by uruchomienie O rodka Zapasowego. O rodek taki, musi by oczywi cie wcze niej przygotowany, a wymagane dane replikowane. Tak jak i w przypadku systemów zklastrowanych, tak e i tutaj mamy do czynienia z ró nymi problemami. W dodatku, pojawiaj si kolejne ograniczona przepustowo ł cz mi dzy O rodkiem Podstawowym, a O rodkiem Zapasowym, widoczno wył cznie w warstwie trzeciej, a tak e wysokie opó nienia (w porównaniu z sieci lokaln ). Innym problemem jest decyzja w sprawie przeł czenia si na O rodek Zapasowy. Nie da si tego w prosty sposób rozwi za. Jest to zwi zane z brakiem mo liwo ci przegłosowania takiej konieczno ci w przypadku istnienia dwóch o rodków podstawowego i zapasowego. W takim przypadku konieczny byłby trzeci, niezale ny o rodek, maj cy kontakt z podstawowym i zapasowym oraz dost p do monitoringu w celu podj cia decyzji, czy brak widoczno ci pomi dzy o rodkami to awaria jednego z nich, czy te mo e wył cznie awaria ł czno ci pomi dzy nimi. Dlatego te decyzja o przeł czeniu si pomi dzy o rodkami cz sto podejmowana jest przez wykwalifikowany personel, który jest w stanie na podstawie wskaza monitoringu oraz do wiadczenia podj wła ciw decyzj [5].

4 192 Krzysztof Małecki, Jarosław W tróbski, Andrzej Nakonieczny Zastosowanie oprogramowania Opensource do zapewnienia niezawodno ci i skalowalno ci serwisów e-biznesowych 3. Realizacja praktyczna Poni ej znajduje si propozycja implementacji usługi webowej OpenID z wykorzystaniem szeregu mechanizmów pozwalaj cych na zapewnienie niezawodno ci i skalowalno ci usługi [1, 3]. Rozwi zanie opiera si na balansowaniu obci enia z wykorzystaniem DNS (Domain Name System system nazw domenowych), klastrze serwerów WWW i aplikacji oraz rozproszeniu zapyta do replikowanych asynchronicznie baz danych. Poszczególne usługi zarz dzane s z wykorzystaniem oprogramowania Red Hat Cluster Suite. Na potrzeby współdzielenia danych pomi dzy serwerami wykorzystano klastrowy system plików. Proponowany system składa si z 5 grup serwerów, wszystkie poza zarz dzaj cym w pełni redundantne: serwery DNS główny i zapasowy, serwery WWW aktywne oraz zapasowy, oznaczone jako www1, www2 i www (zapasowy), serwery aplikacji aktywne oraz zapasowy, oznaczone jako aplikacji1, aplikacji2 oraz aplikacji (zapasowy), serwery baz danych główny oraz zapasowy, oba aktywne, z uruchomion replikacj danych, oznaczone jako master i slave, serwer zarz dzaj cy oznaczony jako zarz dca klastra. Serwery DNS odpowiedzialne s za konwersj nazwy domenowej serwisu na jej adresy IP. U ytkownik ł czy si bezpo rednio z farm serwerów WWW, których zadaniem jest udost pnienie statycznej cz ci usługi oraz przekazanie da dynamicznych do serwerów aplikacji. Dane pobierane s z klastra baz danych. Nad działaniem całego systemu czuwa oprogramowanie klastrowe, którego zadaniem jest przeciwdziałanie awarii któregokolwiek z elementów klastra. W przypadku jej wykrycia, nast puje automatyczne przeł czenie wiadczonej usługi na jeden z serwerów zapasowych. Do zarz dzania klastrem wykorzystuje si dedykowany serwer. Ogólny schemat systemu zał czono poni ej. W dalszej cz ci opisane zostan poszczególne grupy, wraz z zastosowanymi rozwi zaniami. Ze wzgl du na znaczn ilo sprz tu, koniecznego do poprawnej implementacji usługi w zaprezentowanej architekturze, u yto technologii wirtualizacji systemów [1]. Pozwala to na lepsze wykorzystanie mo liwo ci sprz tu, zmniejszenie wydatków koniecznych do uruchomienia systemu, a jednocze nie ułatwi zarz dzanie infrastruktur i obsług awarii całych serwerów. Poza tym jest to rozwi zanie przyszło ciowe, pozwalaj ce w łatwy sposób skalowa usług poprzez wydzielenie fizycznych maszyn dla konkretnych implementacji wirtualnych na potrzeby najbardziej obci onych elementów usługi i to bez przerywania jej działania. Jako oprogramowanie systemowe, pod którego kontrol pracuje ka dy z przedstawionych serwerów, wykorzystano system Linux CentOS 5.4. Jest to darmowy odpowiednik komercyjnej wersji systemu Red Hat Enterprise Linux. W jego skład wchodzi m.in. Red Hat Cluster Suite, na którego podstawie zbudowano rozwi zanie klastrowe. Zabezpieczenie prezentowanego rozwi zania przed awari zbudowane mo e by zarówno na poziomie samego systemu jak i aplikacji. W pierwszym przypadku obejmuje wszelkie mechanizmy działaj ce na poziomie systemu operacyjnego. W ród nich nale y wymieni redundantn obsług sieci, wielo cie kowy dost p do dysków czy ró ne poziomy RAID urz dze dyskowych. Mo na do nich zaliczy tak e klastry aplikacji. W drugim przypadku s to rozwi zania realizowa-

5 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 28, ne bezpo rednio w aplikacjach wykorzystanie mechanizmów rozpraszania poł cze i balansowania obci enia w serwerach WWW, aplikacji, czy baz danych [1]. ródło: Opracowanie własne. Rysunek 1. Ogólny schemat systemu Pierwszym z elementów prezentowanego systemu s serwery DNS. Jest to typowa rozproszona usługa o hierarchicznej budowie. Sposób jej działania polega na tłumaczeniu nazw domenowych na adresy IP; i na odwrót. Z punktu widzenia u ytkownika, serwery wiadcz ce t usług s sobie równowa ne i, poza przypadkami zmian konfiguracji i czasu potrzebnego na ich synchronizacj, zawieraj te same informacje. W zwi zku z tym wszystkie z nich mog udziela autorytatywnych odpowiedzi dla zdefiniowanych na nich domen. Pozwala to na łatwe ich wykorzystanie jako elementów redundantnych. Cech DNS jest wykorzystanie protokołu bezstanowego (UDP) w komunikacji z klientem. Umo liwia to rozproszenie kolejnych zapyta po wi cej ni jednym serwerze, daj c rozwi zanie w prosty sposób skalowalne liniowo. W przedstawionym systemie wykorzystano darmowe i otwarte oprogramowanie implementuj ce protokół i serwer DNS o nazwie BIND. Za jego pomoc udost pniona została domena, w której uruchomiona jest prezentowana usługa. U ycie mechanizmu round-robin, który w przypadku DNS pozwala na cykliczne zwracanie kolejnych adresów IP obsługuj cych usług, umo liwia rozproszenie zapyta kierowanych do serwera WWW. Jest to wi c rozwi zanie na bazie którego buduje si zarówno redundantne jak i skalowalne systemy [1]. Kolejnymi elementami prezentowanego systemu s serwery WWW. Odpowiadaj one za bezpo redni komunikacj z u ytkownikiem i warstw prezentacyjn usługi. Oparte zostały na wolnym oprogramowaniu Lighttpd. Jest to lekki serwer WWW o du ych mo liwo ciach. Posiada

6 194 Krzysztof Małecki, Jarosław W tróbski, Andrzej Nakonieczny Zastosowanie oprogramowania Opensource do zapewnienia niezawodno ci i skalowalno ci serwisów e-biznesowych wsparcie do rozbudowanych modułów pozwalaj cych rozszerzy jego mo liwo ci. Dzi ki zastosowaniu specyficznych mechanizmów systemowych, umo liwia równoległ i szybk obsług du ej ilo ci zapyta, dostosowan do konkretnej wersji systemu [1]. Serwer WWW powinien bezpo rednio udost pnia wył cznie cz statyczn, dzi ki temu jego praca jest zoptymalizowana i polega wył cznie na serwowaniu plików lokalnych, bez konieczno ci ich interpretacji. Pozwala to tak e na podwy szenie bezpiecze stwa, gdy na maszynie frontendowej nie znajduj si pliki aplikacji, z jej kodem ródłowym. Nie istnieje wi c mo liwo zmian w ich tre ci co oznaczałoby zmian w logice aplikacji. Aby zminimalizowa czas nieosi galno ci serwisu w przypadku awarii, zastosowano trzy serwery WWW dwa z nich s aktywne i na bie co obsługuj komunikacj z u ytkownikiem, trzeci działa w trybie standby i oczekuje na jej wyst pienie. Mechanizm ten oparty został na klastrze aplikacji, którego zadaniem jest ci głe nadzorowanie jego elementów i w przypadku wykrycia uszkodzenia którego z nich, przeł czenie uszkodzonej usługi na w zeł zapasowy [1]. Dost p do wspólnej tre ci oraz mechanizm odtwarzania usługi na serwerze zapasowym wymaga zastosowania wspólnego zasobu plików. Musi on by uruchomiony na wszystkich elementach klastra. Dzi ki niemu mo liwe jest udost pnienie znajduj cych si na nim plików przez dowolny z jego w złów. Poniewa s to pliki statyczne, mo liwe jest zastosowanie jednego z kilku rozwi za. Najprostszym jest wykorzystanie synchronizacji plików pomi dzy wszystkimi serwerami WWW. Mo na to zrealizowa poprzez r czne kopiowanie plików, wykorzystanie mechanizmu RSYNC czy chocia by aktualizacj plików na podstawie repozytorium. Kolejnym z dost pnych rozwi za jest zastosowanie sieciowego systemu plików jakim jest NFS. Jest to standard stosowany od przeszło 20 lat i ma ugruntowan pozycj. Niestety wymaga dedykowanego zasobu w postaci serwera NFS. Oczywi cie, zasób ten mo e by uruchomiony na jednym z serwerów wraz z innymi usługami, mo e by równie udost pniony przez macierz. Niestety, nale y zwróci szczególn uwag, aby nie stał si on pojedynczym punktem awarii (SPOF). Zapewnienie tego wymaga cz sto zbudowania kolejnego rozwi zania redundantnego co znacznie komplikuje system i zwi ksza jego koszta. W zwi zku z tym najlepszym rozwi zaniem wydaje si wykorzystanie kolejnej z mo liwo ci jak jest klastrowy system plików. System taki wymaga do działania wspólnego zasobu dyskowego. Mo na tutaj zastosowa dyski lokalne replikowane synchronicznie za pomoc mechanizmu DRBD lub te skorzysta z mo liwo ci, jakie udost pnia macierz SAN. Pierwsza z opcji jest rozwi zaniem pocz tkowo ta szym jednak wymaga dodatkowych nakładów na konfiguracj i zarz dzanie replikacj, wprowadza te wi ksze opó nienia ze wzgl du na konieczno synchronizacji. Natomiast zastosowanie dedykowanej macierzy SAN wymaga wi kszych nakładów, mog si one jednak zwróci ze wzgl du na uproszczenie procesu administracji zasobem. Poza tym, macierze posiadaj własne, wewn trzne, mechanizmy zapobiegaj ce SPOF, pozwalaj ce na udost pnienie bardziej niezawodnego rozwi zania [1]. W prezentowanym przykładzie zastosowano klastrowy system plików GFS2. Wykorzystanie wi kszej liczby serwerów WWW pozwala równie na rozproszenie zapyta u ytkownika, co prowadzi do rozwi za skalowalnych. W powi zaniu z mechanizm round-robin, na poziomie DNS, pozwala na łatwe balansowanie obci enia i ruchu [1]. W celu obsługi da dynamicznych, zastosowano serwery aplikacji s to serwery backendowe. Ich zadaniem jest przyjmowanie zdalnych da od u ytkownika, za po rednictwem serwerów WWW, wykonanie kodu aplikacji i zwrócenie wyniku. Komunikacja pomi dzy serwerami WWW, a serwerami aplikacji wykonana została w oparciu o protokół FastCGI. Dzi ki mechanizmowi puli serwerów FastCGI, mo liwe jest balansowanie obci enia oraz łatwa rozbu-

7 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 28, dowa daj ca mo liwo prostego skalowania. Wbudowane w Lighttpd rozwi zanie pozwalaj ce na rozpoznanie wadliwie działaj cego serwera aplikacji, pozwala na unikni cie SPOF [1]. Wydzielenie z serwerów WWW logiki aplikacji na osobne serwery, zwi ksza ich bezpiecze stwo. Wszelkie dane nie s bezpo rednio dost pne na serwerach frontendowych, w przypadku ich kompromitacji dost p b dzie wył cznie do plików statycznych, do których zalicza si kaskadowe arkusze stylów, pliki graficzne, itp. Podobnie jak w przypadku serwerów bezpo rednio bior cych udział w komunikacji z u ytkownikiem, tak e i tutaj, konieczne jest wykorzystanie wspólnego zasobu dyskowego. Jednak o ile dla serwerów WWW mo liwe było r czne b d półautomatyczne synchronizowanie plików, to w przypadku serwera aplikacji jest to niedopuszczalne. Zwi zane jest to z plikami tymczasowymi, jakie tworzone s w trakcie działania aplikacji. Nale do nich m.in. pliki sesji. Dlatego te konieczne jest zastosowanie sieciowego b d klastrowego systemu plików, na którym to umieszczony zostanie kod aplikacji oraz pliki tymczasowe. W celu unifikacji, podobnie jak w przypadku serwerów frontendowych, zastosowano klastrowy system plików GFS2 [1]. Pomimo zabezpieczenia przed SPOF na poziomie serwerów WWW, tak e i tutaj zastosowano rozwi zanie klastrowe. Zbudowane zostało w oparciu o trzy serwery aplikacji PHP, dwa z nich aktywne, obsługuj ce na bie co nadchodz ce z wykorzystaniem protokołu FastCGI dania, oraz trzeci serwer działaj cy w trybie standby. Nad poprawnym działaniem serwisów czuwa oprogramowanie zarz dzaj ce klastrem. W przypadku wykrycia awarii nast puje odtworzenie uszkodzonej usługi na serwerze zapasowym. Podobnie jak w przypadku serwerów frontendowych, zastosowanie kilku serwerów aplikacji, pozwala na rozproszenie pomi dzy nimi nadchodz cych da co w rezultacie daje rozwi zanie łatwo skalowalne. W prezentowanym rozwi zaniu wykorzystano standardowy interpreter j zyka PHP, uruchomiony jako pula procesów, działaj ca w trybie FastCGI. Dodatkowo, do zarz dzania pul skorzystano z rozwi za dostarczanych przez Lighttpd [1]. Ostatnim elementem bior cym bezpo redni udział w przetwarzaniu da u ytkownika jest system baz danych. Oparty został na oprogramowaniu PostgreSQL w wersji 8.3 wraz z asynchroniczn replikacj danych i implementacj puli poł cze. Replikacja danych oparta została na pakiecie Slony1, natomiast pula poł cze wykorzystuje oprogramowanie pgpool-ii [1]. W prezentowanym przykładzie zastosowano dwa serwery bazodanowe, pierwszy master, działaj cy w trybie R/W (SELECT/INSERT/UPDATE), drugi slave, obsługuj cy wył cznie zapytania R/O (SELECT). Zastosowanie replikacji asynchronicznej nie zapewnia pełnego bezpiecze stwa danych gdy istnieje mo liwo utraty transakcji, które nie zostały zreplikowane, tu przed wyst pieniem awarii serwera głównego. Przewag takiego rozwi zania jest jednak niedu y narzut na sam replikacj oraz wysoka wydajno zapyta niemodyfikuj cych. Realizuje si to poprzez ich rozproszenie po obu serwerach bazodanowych. Poniewa w prezentowanym przykładzie wszystkie zapytania s typu SELECT, asynchroniczno nie jest adnym ograniczeniem. Mechanizm pgpool-ii uruchomiony został jako usługa klastrowa. Pozwala to na jej wznowienie na drugim w le klastra, w przypadku, gdy serwer główny ulegnie awarii. Ze wzgl du na charakter replikacji, zamiana trybu pracy obu serwerów nie jest wykonywana automatycznie. To administrator systemu powinien potwierdzi awari serwera głównego i przy u yciu mechanizmów wewn trznych przeł czy serwer slave w tryb pracy serwera master [1]. Tak przygotowany system, zawieraj cy elementy frontendowe, backendowe oraz bazodanowe, gotowy był do udost pnienia usługi. W prezentowanym rozwi zaniu wykorzystano zmodyfikowan wersj aplikacji phpmyid udost pniaj c serwer OpenID. Konieczne było dosto-

8 196 Krzysztof Małecki, Jarosław W tróbski, Andrzej Nakonieczny Zastosowanie oprogramowania Opensource do zapewnienia niezawodno ci i skalowalno ci serwisów e-biznesowych sowanie jej do obsługi wielu u ytkowników, przechowywania o nich informacji w bazie danych oraz poprawnej obsługi w podziale na cz front i backendow. Dzi ki wolnej licencji, na której wydana została aplikacja, wprowadzenie zmian było dopuszczalne. W prezentowanym systemie, wykorzystany został równie serwer zarz dzaj cy. Jego zadanie ogranicza si do łatwego z poziomu przegl darki internetowej wprowadzania zmian i modyfikacji rodowiska klastrowego. Poniewa nie pełni on roli kontrolnej, która wbudowana jest bezpo rednio w ka dy z w złów klastra, jego awaria nie ma bezpo redniego wpływu na działanie usługi, nie jest wi c traktowany jako SPOF. W przypadku jego braku, nadal istnieje mo liwo wprowadzania poprawek, bezpo rednio na ka dym z systemów. Z nich równie mo na zarz dza w złami klastra, z wykorzystaniem polece systemowych. W przedstawionym przykładzie, wszystkie wykorzystane elementy stanowiły rozwi zania otwarte, oparte na wolnych licencjach. Zastosowanie technologii klastrowych pozwoliło na niemal ci głe udost pnienie usługi. Wiele z zastosowanych mechanizmów ma swoje odpowiedniki w oprogramowaniu komercyjnym. Niektóre z nich, jak na przykład elementy systemu bazodanowego, nie posiadaj tak rozbudowanych mo liwo ci jak w przypadku płatnych rozwi za, jednak nie były one wymagane do poprawnej realizacji usługi. 4. Podsumowanie Niniejsza publikacja stanowi analiz dotychczasowych rozwi za technicznych, pozwalaj cych na udost pnienie usług sieciowych na przykładzie e-biznesowych serwisów WWW charakteryzuj cych si wysok osi galno ci, zbli on do nieprzerwanego działania, z mo liwo- ci ich skalowania oraz obsług rosn cej w przyszło ci liczby u ytkowników. Ponadto rozpatrzony został problem O rodka Zapasowego, który jest cz sto wymogiem dla usług wiadczonych w trybie 24/365. E-biznes wspierany jest przez oprogramowanie komercyjne płatne oraz darmowe. Opłaty za niestandardowe modyfikacje oprogramowania komercyjnego cz sto s wysokie i przedsi biorcy rozpoczynaj cy swoj e-działalno mog nie by w stanie ich ponie. Dodatkowo, przewidywany czas wykonania nie nale y do najkrótszych. Takie podej cie kłóci si z ide prowadzenia e-biznesu, czyli stałego dost pu i szybkiej reakcji na zmiany na rynku. Dlatego te autorzy zaproponowali mechanizmy oparte na ogólnodost pnych i bezpłatnych rozwi zaniach, oraz na wolnych licencjach i oprogramowaniu o otwartych ródłach. Ich mo liwo- ci s zbli one do rozwi za komercyjnych. Niestety, wci posiadaj pewne braki. Niektóre z nich mo na omin stosuj c dodatkowe oprogramowanie, innych niestety si nie da. Najwi kszym problemem, który wci nie jest rozwi zany to pełna replikacja synchroniczna. O ile istniej mechanizmy pozwalaj ce na jej stosowanie na poziomie oprogramowania systemowego, o tyle brakuje ich ju na poziomie aplikacji. Z pewno ci zwi zane jest to z wi kszym zainteresowaniem problemami niskopoziomowymi, których rozwi zanie cz sto opłacane jest przez du e korporacje, chc ce wykorzysta wyniki prac w swoich produktach. Poza tym wprowadzanie udoskonale w aplikacjach powoduje ich wi ksz konkurencyjno na rynku i mo e le wpłyn na sprzeda komercyjnych rozwi za. Kolejnym problemem, z którym mo na spotka si w rozwi zaniach otwartych, to nie najlepsza dokumentacja. Utrudnia to ich wykorzystanie i powoduje generowanie dodatkowych kosztów, wiele mechanizmów musi by przetestowane w celu okre lenia sposobu ich działania, cz sto metod prób i bł dów. W przypadku rozwi za darmowych pomocna okazuje si społeczno która,

9 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 28, wcze niej, spotkała si z podobnymi problemami i wypracowała sobie metody ich omini cia. Niestety nie mo e ona zagwarantowa rozwi zania ka dego z nich. Co gorsza, nie zapewnia ani czasu reakcji, ani samej reakcji na zgłoszony problem. Mo e si wi c zdarzy, e nie zostanie on rozwi zany. Istotn zalet oprogramowania o otwartym kodzie jest dost p do ródeł. Umo liwia on nie tylko analiz działania aplikacji, pozwala te na wprowadzanie zmian i dostosowywanie ich do wymaga konkretnego systemu. Innym, wa nym aspektem jest brak przywi zania do konkretnej wersji oprogramowania. W przypadku rozwi za komercyjnych natrafi mo na na aplikacj, która działa wył cznie z wybran wersj systemu. Producent najcz ciej nie wiadczy wsparcia je li zostanie ona uruchomiona w innym rodowisku ni przez niego zakładane. Co wi cej, nie istotne jest nawet to, e rodowisko jest zgodne binarnie ze swoim komercyjnym odpowiednikiem, jak to jest w przypadku CentOS i Red Hat Enterprise Linux. Dost p do ródeł pozwala na przebudowanie aplikacji w dowolnym rodowisku, a w przypadku braku kompatybilno ci, mo liwe jest wprowadzenie zmian dostosowuj cych j do niego. Mimo wszystkich powy szych uwag autorzy s zwolennikami wolnego oprogramowania. Jak w ka dym rozwi zaniu istniej plusy i minusy. Wiele niedoci gni mo na nadrobi wiedz i sprytem. Dost p do ródeł daje nieograniczone mo liwo ci wprowadzania modyfikacji, co co praktycznie nie istnieje w wiecie komercyjnym. B d c zaopatrzonym w odrobin samozaparcia mo liwe jest budowanie rozwi za, które nie były przewidywane nawet przez twórców oprogramowania. Co wi cej, rozwi zania te, w swojej funkcjonalno ci, dorównuj cz sto ich komercyjnym odpowiednikom, w niektórych przypadkach nawet je przewy szaj. [1] Nakonieczny A.: Zapewnienie niezawodno ci i skalowalno ci serwisów webowych z wykorzystaniem oprogramowania Open Source, praca dyplomowa pod kierunkiem dr in. Krzysztofa Małeckiego, Wydział Informatyki ZUT, [2] dost p: [3] Henderson C.: Skalowalne witryny internetowe, Helion. [4] dost p: [5] Miesi cznik Linux+, pa dziernik 2008.

10 198 Krzysztof Małecki, Jarosław W tróbski, Andrzej Nakonieczny Zastosowanie oprogramowania Opensource do zapewnienia niezawodno ci i skalowalno ci serwisów e-biznesowych OPEN SOURCE APPLICATION FOR QUALITY ASSURANCE OF THE RELIABILITY AND SCALABILITY FOR E-BUSINESS SERVICES Summary Currently, many companies run a e-business on the Internet, unaware of the potential risk losing their data or losing access to their data. This article discusses the issue of ensuring the reliability of Web services. The software components involved in providing content and services and how to protect against failure are presented. Another important element was to investigate possible solutions for the scaling of services - response to the increasing number of users. Keywords: Disaster Recovery, OpenID, Replication, Virtual Machine, High Availability Krzysztof Małecki Jarosław W tróbski Pa stwowa Wy sza Szkoła Zawodowa w Gorzowie Wlkp. Andrzej Nakonieczny Zachodniopomorski Uniwersytet Technologiczny w Szczecinie