Praktyczne porównanie mechanizmów 2PC i 3PC dla rozproszonych baz danych

Transkrypt

1 Praktyczne porównanie mechanizmów 2PC i 3PC dla rozproszonych baz danych Małgorzata Sikorska Wydział Inżynierii Mechanicznej i Informatyki Kierunek Informatyka, Rok V msikorska@vp.pl Streszczenie Artykuł przedstawia porównanie podstawowych protokołów niepodzielnego zatwierdzania 2PC oraz 3PC dla rozproszonych baz danych. Odgrywają one zasadniczą rolę w przetwarzaniu transakcji rozproszonych. W celu praktycznego porównania tych protokołów zaprojektowano interfejsy realizujące mechanizmy 2PC i 3PC w oparciu o model przetwarzania transakcyjnego DTP, a następnie zaimplementowano je w jednej z najpopularniejszych architektur rozproszenia wspomagających przetwarzanie transakcyjne architekturze trójwarstwowej. W pracy skupiono się na przedstawieniu idei protokołów niepodzielnego zatwierdzania oraz ich oceny na podstawie kryteriów, takich jak złożoność czasowa oraz złożoność pod względem komunikatów, pozwalających na określenie ich wydajności. 1 Wprowadzenie Przetwarzanie transakcyjne jest jednym z podstawowych elementów funkcjonalności systemów zarządzania bazami danych. Jest ono niezbędne wszędzie tam gdzie aplikacje wymagają jednoczesnego dostępu do danych, współdzielonych pomiędzy wiele aplikacji, celem wykonania na nich operacji bazodanowych, stanowiących koncepcyjnie logiczną całość. Taki spójny logicznie zestaw operacji wykonywanych na bazie danych określany jest terminem transakcja. Najczęściej transakcja obejmuje operacje na jednej bazie danych. W przypadku rozproszonej bazy danych (DDB ang. Distributed Database), transakcja wykorzystuje dane z wielu baz danych tzw. węzłów systemu rozproszonego. Transakcje wykonujące operacje na danych znajdujących się na wielu niezależnych serwerach baz danych, stanowiących logiczna całość, określane są mianem transakcji rozproszonej (globalnej). Natomiast operacje składowe, czyli lokalne części transakcji globalnej wykonywane na poszczególnych węzłach, są nazywane gałęziami transakcji (ang. transaction branch). Zarówno w przypadku systemu scentralizowanego, jak i rozproszonego transakcja powinna odnosić się do danych odtwarzalnych i być z założenia niepodzielna (ang. atomic). W sytuacji, gdy operacje transakcji zostaną poprawnie zakończone, mówimy wtedy, że transakcja zakończyła się powodzeniem i jej skutki mogą zostać zatwierdzone w bazie danych. W pozostałych przypadkach mówimy o niepowodzeniu transakcji i tym samym 1

2 skutki transakcji powinny być wycofane, a stan bazy danych powinien być przywrócony do stanu sprzed rozpoczęcia transakcji. Aby zagwarantować powyższe własności każda transakcja powinna spełniać postulaty zasady ACID (ang. atomictiy, consistency, isolation, durability), zaproponowane przez Haider a i Reutera [3]: Atomowość (ang. atomicity) określa regułę wszystko albo nic, oznaczającą, że zbiór operacji składowych transakcji musi być wykonany w całości albo wcale. Spójność (ang. consistency) transakcja powinna przekształcać system z jednego stanu spójnego w inny spójny stan. Izolacja (ang. isolation) każda transakcja powinna być wykonywana niezależnie od innych działających współbieżnie transakcji, przetwarzanych w tym samym środowisku. Skutki współbieżnego wykonania transakcji powinny być takie same, jak wówczas gdyby wykonywano je w sposób szeregowy. Trwałość (ang. durability) wyniki działania zatwierdzonych transakcji powinny być zachowane w pamięci trwałej. W systemie rozproszonym zagwarantowanie powyższych własności transakcji nie jest zadaniem łatwym, dlatego też wprowadzono specjalne mechanizmy ułatwiające przetwarzanie transakcji rozproszonych zapewniające własności ACID. Są nimi protokoły niepodzielnego zatwierdzania (ang. atomic commitment protocols ACP). 2 Zatwierdzanie rozproszone Protokół niepodzielnego zatwierdzania jest algorytmem wykonywanym w celu niepodzielnego zatwierdzenia transakcji rozproszonej przez współpracujące w tym celu procesy. Każdy proces może oddać dokładnie jeden z dwóch możliwych głosów (ang. votes) Yes lub No, co pozwala na podjęcie wspólnej decyzji: Zatwierdzenie (ang. Commit) lub Zaniechanie (ang. Abort) transakcji. ACP pozwala zadecydować, czy transakcje rozproszoną należy zatwierdzić, czy też nie [1]. Na podjęcie decyzji mają wpływ następujące kwestie: 1. AC1 Wszystkie procesy, które podejmują decyzje, podejmują tą samą decyzje. 2. AC2 Procesy te nie mogą unieważnić swojej decyzji po tym jak już ją podjęły. 3. AC3 Decyzja o zatwierdzeniu może być podjęta tylko wtedy, gdy wszystkie procesy głosowały za zatwierdzeniem transakcji (oddały głos Yes). 4. AC4 Jeżeli wszystkie procesy głosowały na Yes, wtedy decyzją będzie Zatwierdzenie. 5. AC5 Powinno się rozważyć wykonania algorytmu obejmujące różnego rodzaje niepowodzenia takie jak awarie czy utraty komunikatów, do tolerowania których algorytm został zaprojektowany. Jeżeli wszystkie zaistniałe awarie zostaną naprawione i nie występują dostatecznie długo nowe awarie, wszystkie procesy podejmą w końcu decyzje. 2

3 3 Podstawowe protokoły niepodzielnego zatwierdzania Najczęściej stosowanym protokołem niepodzielnego zatwierdzania jest dwufazowy protokół zatwierdzania (ang. two-phase commit protocol), nazywany w skrócie protokołem 2PC [3]. Wykonanie protokołu 2PC rozpoczyna się w momencie rozpoczęcia zatwierdzania transakcji rozproszonej przez proces zwany koordynatorem na zlecenie klienta. Składa się z dwóch faz, w pierwszej fazie koordynator decyduje, kiedy rozpocząć zatwierdzanie transakcji rozproszonej. Jest to tzw. faza przygotowania (ang. prepare), każdy z uczestników transakcji przygotowuje się do lokalnego zatwierdzenia transakcji rozproszonej. Natomiast druga faza stanowi fazę rzeczywistego zatwierdzania (ang. commit) i rozpoczyna się w momencie, gdy każdy z uczestników transakcji rozproszonej wyraził gotowość do jej zatwierdzenia. Cały ten proces jest koordynowany przez zarządcę transakcji (ang. transaction manager), który może działać jako jeden z procesów systemu zarządzania jednej z rozproszonych baz danych lub może być zewnętrznym modułem wbudowanym w serwer aplikacji. Protokół 2PC jest w wielu przypadkach protokołem blokującym, ponieważ w wielu punktach wykonania tego protokołu procesy (są w stanie niepewności) oczekują na komunikaty, które mogą dotrzeć z dużym opóźnieniem lub nigdy, na skutek awarii lub innych okoliczności. W takich przypadkach procesy te mogą być czekać w nieskończoność, przez co są zablokowane. Na wypadek takich ewentualności stosuje się w protokole 2PC mechanizm anulowania zadań po upływie przewidzianego czasu (ang. timeout). Pozwala to uniknąć blokady procesów, gdyż oczekiwanie procesów jest przerywane przez po określonym czasie, po którym proces musi podjąć pewną akcję (ang. timeout action). W przypadku protokołu 3PC mamy do czynienia z dodatkową fazą (pre-commit), w której koordynator, po wyrażeniu gotowości przez każdego z uczestników transakcji do jej zatwierdzenia, wysyła do nich komunikat informujący o przygotowaniu się do zatwierdzenia transakcji i tym samym opuszczają oni stan niepewności. Dopiero po otrzymaniu koordynatora potwierdzenia otrzymania tego komunikatu przez wszystkich uczestników transakcji, następuje jej rzeczywiste zatwierdzenie. Zapewnia to większą niezawodność protokołu i odporność na awarie koordynatora [1]. 4 Projekt i realizacja mechanizmów 2PC i 3PC Istnieje wiele architektur rozproszenia, które wspomagają przetwarzanie transakcyjne. Obecnie stosuje się trójwarstwową architekturę rozproszoną opartą na oprogramowaniu pośredniczącym (ang. middleware), w której poszczególne węzły porozumiewają się za pomocą oprogramowania pośredniczącego, zakładający wspólny protokół komunikacyjny, przezroczysty dla użytkowników. W celu praktycznego porównania mechanizmy 2PC i 3PC zostały zrealizowane w postaci komponentów oprogramowania middleware na serwerze aplikacji, w oparciu o język Java i funkcjonalności sterownika JDBC [12]. Ponieważ technologie oprogramowania komponentowego, tworzą środowisko, które wymaga korzystania z ogólnie przyjętych modeli przetwarzania transakcyjnego, w niniejszej pracy aplikacja przetwarzająca transakcje rozproszone zbudowana została w oparciu o model przetwarzania transakcji rozproszonych standardu X/Open (ang. Distributed Transaction Processing Model DTP) [11]. Specyfikuje on m.in. komponenty, współpracujące ze sobą celem realizacji transakcji rozproszonej program aplikacyjny, za- 3

4 rządca transakcji, zarządcy zasobów. Określa także rodzaj interfejsów, jakie muszą być dostarczone przez system transakcyjny w celu zapewnienia atomowego wykonania transakcji globalnej. Interfejsy pomiędzy komponentami programowymi, a zarządcą transakcji (określony w specyfikacji X/Open jako interfejs TX) oraz pomiędzy zarządca transakcji, a zarządcą zasobów (zwany interfejsem XA). W niniejszej pracy funkcjonalność interfejsów TX i XA zastąpiono omówionym poniżej interfejsami zawartymi w pakietach dtp, transactions oraz tests. Poniżej omówione zostały komponenty programowe udostępniające te interfejsy zgodnie z modelem DTP. Komponent dtp.transactionmanager pełni funkcje zarządcy transakcji, jest kluczowym elementem budowanej architektury. Dostarcza on przede wszystkim interfejsów niezbędnych do tworzenia transakcji, przypisania jej identyfikatora, rozpoczęcia i kontroli protokołów niepodzielnego zatwierdzania. TID begintransaction() metoda pozwalająca na rozpoczęcie transakcji rozproszonej oraz zwrócenie wynikowego identyfikatora transakcji. boolean committransaction(transaction t) metoda wykonująca operację zatwierdzenia transakcji rozproszonej t. W tym celu realizuje niepodzielny protokół zatwierdzania ACP. Zwraca wartość TRUE, gdy transakcja globalna została zatwierdzona, w przeciwnym wypadku zwraca FALSE. void rollbacktransaction(transaction t) metoda wykonująca operacje zaniechania transakcji. void joinresourcemanager(resourcemanager participant) dodanie nowego uczestnika (zarządcy zasobów) transakcji rozproszonej (tzw. pozyskiwanie zasobów). Pozwala na zapamiętanie w spisie uczestników identyfikatora serwera pełniącego rolę zarządcy zasobów, który zarządza zasobami wykorzystywanymi w danej transakcji globalnej t. Komponent dtp.resorcemanager, pełni rolę zarządcy zasobów, który realizuje przydzieloną mu gałąź transakcji rozproszonej, bierze udział w protokole 2PC (3PC) celem niepodzielnego zatwierdzenia wszystkich gałęzi transakcji globalnej. Poniżej przestawione są interfejsy pozwalające na uczestnictwo w protokole 2PC (3PC): Boolean Prepare(TID tid) metoda wywoływana w pierwszej fazie protokołu 2PC (3PC). Wszyscy uczestnicy transakcji globalnej są poproszeni przez koordynatora (poprzez wywołane tej metody) o głosowanie za zatwierdzeniem tej transakcji lub jej zaniechaniem. Metoda zwraca głos (ang. vote) uczestnika, czyli TRUE, jeżeli uczestnik głosował za zatwierdzeniem transakcji, w przeciwnym wypadku zwraca FALSE. void Commit(TID tid) metoda zlecająca poszczególnym uczestnikom transakcji (określonej identyfikatorem tid) zatwierdzenie ich lokalnych części tej transakcji. Jest wywoływana w drugiej fazie protokołu 2PC lub odpowiednio w ostatniej fazie protokołu 3PC, tylko w przypadku, gdy wszyscy uczestnicy transakcji głosowali za zatwierdzeniem transakcji globalnej. void Abort(TID tid) metoda zlecająca poszczególnym uczestnikom transakcji (określonej identyfikatorem tid) zaniechanie ich lokalnych części tej transakcji. 4

5 Wywoływana w drugiej fazie protokołu 2PC (3PC), w momencie, gdy chociaż jeden z uczestników głosował za zaniechaniem transakcji lub faza ta nie powiodła się (ang. failed commit). W przypadku protokołu 3PC dodatkowo jest udostępniony interfejs: boolean PreCommit(TID tid) metoda wywoływana w drugiej fazie protokołu 3PC przez koordynatora po wykonaniu metody Prepare(). Jeżeli wszyscy uczestnicy głosowali YES, wysyła do nich komunikat PRE-COMMIT. Jest on informacją dla każdego z uczestników, że pozostali głosowali YES i tym samym opuszcza on stan niepewności. Metoda zwraca potwierdzenie odebrania komunikatu, czyli TRUE, w przeciwnym wypadku zwraca FALSE. Każdy z omówionych wyżej komponentów zapewnia rejestrację przebiegu transakcji rozproszonej w postaci wpisów w pliku rekonstrukcji znajdującego się w pamięci trwałej, co pozwala na przeprowadzenie procesu rekonstrukcji w przypadku awarii serwera. Komponent tests.generator klasa Java udostępniająca interfejs, który realizuje funkcjonalność programu aplikacyjnego (ang. Application Program AP) w modelu DTP. Definiuje on transakcję, określa jej granice oraz uzyskuje dostęp do zasobów, w celu wykonania na nich operacji. 5 Porównanie protokołów 2PC i 3PC W tej części przedstawione zostanie praktyczne porównanie protokołu 2PC z 3PC. Aby dokonać realnej oceny każdego z nich przeprowadzono odpowiednie testy wydajnościowe. W tym celu wyznaczono ich złożoność pod względem komunikatów oraz czasową. Omówione w poprzednim rozdziale protokoły 2PC i 3PC zostały zaimplementowane w celach przetestowania ich wydajności w rzeczywistym środowisku. Przeprowadzone eksperymenty pozwalają oszacować koszty ponoszone przy wykorzystaniu każdego z protokołów w aplikacjach trójwarstwowych (ang. three-tier applications). Obecnie największa wagę przy budowaniu aplikacji internetowych przykłada się do wydajności, co często jest decydującym czynnikiem wpływającym na utrzymaniu starych i pozyskiwaniu nowych klientów np. w systemach CRM. Dlatego też użyteczność protokołów 2PC oraz 3PC została określona na podstawie tego kryterium. Mechanizm 2PC (3PC) został zaimplementowany w technologi J2EE na serwerze aplikacji Apache Jakarta Tomcat na maszynie z zainstalowaną maszyną wirtualną Java (JVM) w wersji W celu przeprowadzenia testów pominięto maszyny klientów oraz implementację interakcji pomiędzy klientem (np. przeglądarka WWW), a użytkownikiem, ponieważ celem niniejszej pracy jest praktyczne porównanie obydwu protokołów, a nie ich pełna implementacja. Rolę komponentu aplikacyjnego pełni komponent JavaBean, który wykonuje operacje na zdalnych bazach danych poprzez oprogramowanie middleware. Działa on na tej samej maszynie, co serwer aplikacji. Funkcję zdalnych baz danych pełnią maszyny z zainstalowanym serwerem baz danych MySQLServer 5.0 oraz PostgreSQL 8.0. Komunikacja z warstwą danych się z nimi za pomocą sterownika JDBC w wersji 2.0. Wszystkie maszyny są fizycznie rozmieszczone w sieci lokalnej połączone siecią Ethernet. W pierwszym eksperymencie dokonano symulacji wymiany komunikatów pomiędzy poszczególnymi procesami, biorącymi udział w protokole niepodzielnego zatwierdzania, 5

6 w celu porównania złożoności pod względem komunikatów protokołu 2PC z 3PC. Zakładamy, że złożoność pod względem komunikatów jest mierzona na podstawie liczby komunikatów użytych w protokole. W przeprowadzonym eksperymencie nie bierzemy pod uwagę długości tych komunikatów, ponieważ są one na tyle krótkie, że mają wpływu na tą złożoność. Przebieg eksperymentu był następujący: wygenerowano zbiór żądań req do koordynatora o zatwierdzenie transakcji rozproszonej. Niech n oznacza liczbę uczestników transakcji rozproszonej, tak więc łączna liczba procesów (z koordynatorem) wynosi (n + 1). Rozpoczęto symulację z parametrem n = 2. Dla każdego późniejszego pojedynczego wywołania procedury testującej wartość parametru została zwiększana o 1. Podczas trwania eksperymentu komunikacja pomiędzy procesami przebiegała w następujący sposób: klient składa żądanie do serwera aplikacji warstwy pośredniej. Następnie oprogramowanie warstwy pośredniej przetwarza to żądanie poprzez wykonanie transakcji na odpowiednim serwerze bazy danych. Rzeczywista manipulacja na zasobach udostępnionych przez rozproszoną bazę danych jest taka sama w obydwu przypadkach. Przy realizacji protokołu niepodzielnego zatwierdzania przez oprogramowanie warstwy pośredniej w przypadku protokołu 3PC wymagana jest większa liczba komunikatów niezbędnych do zatwierdzenia transakcji rozproszonej. Po tym procesie, middleware zawraca wynik wykonania operacji SQL do klienta. Analizując wyniki powyższego eksperymentu można wywnioskować, że w przypadku pojedynczego wykonania protokołu 2PC, w każdej rundzie jego wykonania, wysłane zostaje n komunikatów. Zatem przy braku awarii, protokół używa łącznie 3n komunikatów. Jest to nieduża liczba w porównaniu z protokołem 3PC, w przypadku którego przeprowadzone badania wykazały, że wymaga on łącznie około 5n komunikatów. Eksperyment wykazał, że koszt liczony w komunikatach jest wprost proporcjonalny do 3n dla protokołu 2PC, natomiast dla protokołu 3PC jest on wprost proporcjonalny do 5n. Dla pojedynczego wywołania jest to niewielka różnica, natomiast w przypadku dużej liczby żądań zatwierdzenia kolejnych transakcji rozproszonych wykonywanych na wielu serwerach, staje się ona istotnym parametrem wpływającym na wydajności każdego z protokołów. Celem zmierzenia złożoności czasowej protokołu 2PC i 3PC wyliczona została liczba obiegów wymiany komunikatów (ang. message exchange round) potrzebnych przez działające serwery do podjęcia decyzji w najgorszym przypadku. Przez pojęcie obiegu rozumiemy maksymalny czas potrzebny komunikatowi na dotarcie do miejsca przeznaczenia [1]. W przeprowadzonych eksperymentach uwzględniono również czas potrzebny na przetworzenie komunikatów oraz czas pochłaniany przez dostęp do pamięci trwałej w celu zapisania, bądź odczytania informacji zapisanych w plikach rekonstrukcji. Maksymalna liczba obiegów komunikatów (w protokole 2PC) potrzebna działającym procesom do podjęcia decyzji wynosi trzy obiegi: (1) koordynator rozgłasza komunikat VOTE-REQs, (2) uczestnicy odpowiadają poprzez głosowanie, (3) koordynator rozgłasza decyzję. Ma to miejsce podczas bezawaryjnego wykonania protokołu 2PC, w sytuacji, gdy transakcja globalna zostaje zatwierdzona. Poszczególne czasy opóźnienia dla protokołu 2PC przedstawiono w tabeli 1, gdzie: t t całkowity czas opóźnienia, na który jest sumą opóźnień spowodowanych przez obiegi, dostępy do pamięci trwałej oraz rozgłaszanie komunikatów: t r oznacza czas rozgłaszania komunikatu VOTE-REQs (1); 6

7 t g oznacza czas potrzebny na głosowanie (2). t d czas potrzebny na rozgłoszenie decyzji (3). Tab. 1: Złożoność czasowa protokołu 2PC. n t r t g t d t t Złożoność czasowa protokołu 3PC w przypadku braku awarii sprowadza się od co najwyżej pięciu rund komunikatów: (1) rozgłoszenie VOTE-REQs, (2) dostarczenie głosów, (3) rozprowadzenie PRE-COMMITS, (4) potwierdzenie PRE-COMMIT, (5) rozprowadzenie COMMIT. Również ma to miejsce przy bezwaryjnym wykonaniu protokołu 3PC przy zatwierdzeniu transakcji globalnej. Poszczególne czasy opóźnienia dla protokołu 3PC przedstawiono w tabeli 2, gdzie: t t całkowity czas opóźnienia. t r oznacza czas rozgłaszania komunikatu VOTE-REQs (1); t g oznacza czas potrzebny na głosowanie (2). t p przeprowadzenie dodatkowej fazy pre-commit (3), (4). t d czas potrzebny na rozgłoszenie decyzji (5). Tab. 2: Złożoność czasowa protokołu 3PC. n t r t g t p t d t t Porównując wyniki eksperymentów z tabeli 1 z tabelą 2 łatwo wywnioskować, że każdy dodatkowy obieg komunikatów opóźnia proces zatwierdzania transakcji rozproszonej. W przypadku protokołu 3PC opóźnienie to jest spowodowane przez dwa dodatkowe obiegi komunikatów (3), (4). Im większa liczba wezłów biorących udział w transakcji, tym większy jest koszt wykonania dodatkowych obiegów komunikatów oraz dostępów do pamięci trwałej, co skutkuje znacznym opóźnieniem procesu przetwarzania transakcji. Dodatkowy czas musi zostać poświęcony na zapewnienie niepodzielności zatwierdzania transakcji rozproszonej. W przypadku protkołu 2PC czas ten waha się od 38ms dla n = 1 do 198ms dla n = 5. Dla protokołu 3PC są to 54ms dla n = 1 do 273ms dla n = 5. Jak widać różnica w czasie opóźnienia spowodawanym przez protokół 3PC, w prównaniu z protokołem 2PC, zwiększa się wraz z liczbą uczestników. 7

8 6 Podsumowanie W pracy przedstawione wstępne wyniki porównania protokołu 2PC z 3PC. Przeprowadzone eksperymenty wykazały, że protokół 3PC powoduje większe narzuty na wydajność przetwarzania transakcji rozproszonej niż protokół 2PC. W porównaniu z protokołem 2PC wymaga on większej liczby komunikatów do przeprowadzenia procesu zatwierdzania roszproszonego, która rośnie wraz z liczbą uczestników transakcji. Wraz ze wzrostem liczby komunikatów rośnie również czas potrzebny na ich rozsyłanie i przetworzenie. Nie należy również zapominać o czasie pochłanianym przez dostęp do informacji zapisanych w dziennikach transakcji w pamięci trwałej. Takie przymusowe dostępy w pamięci trwałej są dosyć czasochłonne. Koszty te mogą spowodować, że przetwarzanie zatwierdzania transakcji rozproszonej może przyczynić się do wzrostu czasu przetwarzania całej transakcji. Ponieważ w protokołe 2PC liczba i złożoność komunikatów jest o mniejsza, jego wydajność jest większa. Literatura [1] P.A. Bernstein, V. Hadzilacos, N. Goodman, Concurrency control and recovery in database systems, ADDISON-WESLEY PUBLISHING COMPANY, [2] L. Banachowski, K. Stencel, Bazy danych. Projektowanie aplikacji na serwerze, Wydawnictwo Exit, [3] G.Coulouris, J. Dollimore, T. Kindberg, Systemy rozproszone podstawy i projektowanie, Wydawnictwo Naukowo Techniczne, [4] H. Garcia-Molina, J.D. Ullman, J. Widom, Implementacja systemów baz danych, Wydawnictwo Naukowo Techniczne, [5] R. Elmasri S.B. Navath, Wprowadzenie do systemów baz danych, Helion, [6] S. Allamaraju, Nuts and Bolts of Transaction Processing, [7] M. Stróżańki, Systemy rozproszone Konsekwencje wyboru architektury systemu, [8] M. Wojciechowski, M. Zakrzewicz, Obsługa transakcji rozproszonych w języku Java, [9] S. Frolund, S. R. Guerraoui, Exactly-Once Transactions, HP Software Technology Laboratory,1999. [10] R. Gupta, J. Harista, K. Ramamritham, Revisiting Commit Processing In Distributed Database Systems, University of Utah Mathematics Department Software, [11] Distributed Transaction Processing: The XA Specification, [12] JDBC Technology, 8