Założenia projektu

Ponieważ przedmiot nosi tytuł Systemy operacyjne, odpowiedni nacisk musi być położony na wykorzystanie mechanizmów systemowych do realizacji celu. Druga rzecz to wykonanie zadanego tematu, podchodzącego bardziej pod systemy rozproszone, niemniej myślę, że warto przyjrzeć się całej sprawie bliżej. Choć nie będę implementować wszystkiego, co da się o temacie napisać, moim zamiarem jest stworzyć jakąś sensowną implementację ogólnego przeznaczenia.

Transakcje rozproszone - co do...?

W systemach komputerowym przez termin transakcja rozumiemy zbiór operacji, które ze względów bezpieczeństwa danych tworzą pewną zamkniętą całość. Wszystkie własności transakcji określa się czteroliterowym skrótem ACID od słów Atomicity, Consistency, Isolation, Durability:

1. Atomowość - transakcja musi wykonać się w całości poprawnie albo nie wykonać się w ogóle. W tym drugim przypadku operacje, które zakończyły się sukcesem, muszą zostać anulowane. Przykład: wykonując przelew bankowy, musimy zmniejszyć środki na jednym koncie i zwiększyć na drugim. System nie może pobrać pieniędzy z jednego konta bez dodania ich do innego, ani dodać pieniędzy znikąd.
2. Spójność - po zakończeniu transakcji wszystkie dane mają być spójne. Przykład: prowadzimy dziennik operacji wykonywanych w systemie. Po zakończeniu transakcji nie mogą znaleźć się w nim wpisy, które dotyczą nieistniejących bytów.
3. Izolacja - jeśli dwie transakcje operują na tym samym obiekcie, nie widzą nawzajem wprowadzanych przez siebie zmian. Każda transakcja operuje na swojej własnej kopii danych i dopiero podczas zatwierdzania, jedna z transakcji zostaje ostatecznie zapisana, a druga jest anulowana, gdy nie istnieje możliwość wgrania jej zmian.
4. Trwałość danych - w razie awarii system potrafi po uruchomieniu udostępnić spójne i nienaruszone dane w ramach zatwierdzonych już transakcji.

Transakcje są powszechnie wykorzystywane w systemach baz danych, gdzie niezawodność oraz utrzymanie spójności danych jest kluczowym czynnikiem. Można je spotkać również w systemach plików z tzw. księgowaniem.

Dotychczas omawialiśmy ogólne właściwości transakcji przy założeniu, że wszystkie wchodzące w jej skład operacje wykonuje po kolei jeden i ten sam system. Jednak oprócz tego, wyróżnia się tzw. transakcje rozproszone, gdzie poszczególne operacje mogą być wykonywane przez różne procesy, które mogą wykonywać się także na różnych serwerach. Wykonanie poszczególnych operacji przebiega więc równolegle, zaś my musimy zadbać, aby procesy mogły się ze sobą skomunikować i zdecydować, czy transakcję można uznać za zatwierdzoną czy nie.

Działanie transakcji rozproszonych

W transakcji rozproszonej biorą udział następujące strony: serwery zarządzające zasobami oraz klient zlecający wykonanie pewnej operacji na zasobach. Gdy klient rozpoczyna transakcję, łączy się z jednym serwerów i zleca mu wykonanie zadania. Ten serwer zostaje koordynatorem transakcji; wskazanie takiego serwera jest niezbędne, gdyż będzie on odpowiedzialny za nadzorowanie przebiegu transakcji. Wszystkie pozostałe serwery dysponujące zasobami, które będą użyte w zadaniu, dołączają do transakcji jako uczestnicy.

Wyróżniamy dwa rodzaje transakcji rozproszonych: płaskie oraz zagnieżdżone. W drugim przypadku dopuszczamy, aby uczestnik naszej transakcji mógł w jej ramach rozpocząć inną podtransakcję, jeżeli tego potrzebuje, tworząc tym samym pewną hierarchię. Transakcje płaskie są prostsze w implementacji, ale mają pewne ograniczenia funkcjonalne, np. nie mamy możliwości częściowego zatwierdzenia wyników (pomimo że transakcja ma być atomowa, niekiedy taka właściwość może okazać się przydatna).

W zatwierdzaniu transakcji rozproszonej wykorzystuje się kilka protokołów:

1. Jednofazowy - koordynator informuje uczestników o zaniechaniu bądź zatwierdzeniu transakcji. Nie każdy uczestnik może przerwać transakcję.
2. Dwufazowy (2PC) - w fazie pierwszej uczestnicy przygotowują się do lokalnego zatwierdzenia transakcji, zapisując nowy stan do pamięci, ale nie udostępniając go pozostałej części systemu. Koordynator odbiera informację od każdego uczestnika, czy jego część transakcji się powiodła. Gdy spłynęły już wszystkie odpowiedzi, rozpoczyna się faza druga. Koordynator wysyła do wszystkich uczestników polecenie ostatecznego zatwierdzenia transakcji.

Protokół dwufazowy zapewnia już każdemu uczestnikowi możliwość anulowania transakcji, lecz to koordynator decyduje o tym, kiedy rozpocząć fazę pierwszą zatwierdzania. Nie wszystkie procesy muszą mieć identyczną ilość pracy do wykonania, dlatego może wystąpić problem długiego blokowania zasobów. Procesy, które skończyły pracę wcześniej, mogą potencjalnie czekać bardzo długo, aż reszta powiadomi koordynatora o swoim stanie. Dla celów bezpieczeństwa wprowadza się maksymalny czas oczekiwania, po którym transakcja jest anulowana. Problemy te może rozwiązać protokół trójfazowy. Pomiędzy fazą pierwszą a drugą pojawia się trzecia, tzw. pre-commit, gdy koordynator wysyła do uczestników informację o przygotowaniu się do zatwierdzenia. Przejście do fazy zatwierdzenia następuje dopiero po odebraniu potwierdzenia odebrania tej informacji od uczestników.

Bez względu na to, jaki protokół wybierzemy, musimy pamiętać o kilku czynnikach:

1. Transakcja musi stabilnie pracować w systemie asynchronicznym (np. sieci Internet).
2. Zakłada się, że serwery pracują całkowicie poprawnie, albo są całkowicie zepsute.
3. Wiadomości mogą ulec zagubieniu, duplikacji bądź przekłamaniu.

Niezawodność

Cały ten arsenał środków służy temu, aby zapewnić systemowi niezawodność i maksymalną odporność na awarie. Niemniej zidentyfikowałem już grupę potencjalnych problemów, które wymagają jeszcze rozwiązania:

1. Teoretycznie możliwa jest sytuacja, że zasilanie zostanie wyłączone akurat w środku procesu zatwierdzania transakcji przez serwer. Oczywiście same dane nanoszone są wcześniej, ostateczne zatwierdzenie to jedynie kwestia powiadomienia, że to one są od teraz obowiązujące. Właśnie w środku tego etapu może nastąpić awaria. Tutaj potencjalnym rozwiązaniem jest kasowanie poprzedniego stanu dopiero po jakimś czasie. Podczas ponownego startu system musi sprawdzić poprawność ostatnio zatwierdzonej transakcji. Jeśli tylko coś się nie zgadza, należy problem rozwiązać, dokańczając proces.
2. Komunikat koordynatora o ostatecznym zatwierdzeniu transakcji może nie dotrzeć do uczestnika. Tu niestety nie wymyśliłem jeszcze, jakie miałoby to nieść ze sobą skutki. Przyczyn może być wiele. Jakiś złośliwiec może przeciąć kabel w środku transji pakietu, gdzieś może wysunąć się wtyczka, ktoś zawadzi o kable... wprawdzie mówi się, że prawdziwy admin jest w stanie przepiąć kable w routerze bez utraty żadnego pakietu, ale nie możemy zakładać, że właśnie z kimś takim będziemy mieli okazję pracować. Tutaj problem pozostawiam otwarty i gdy tylko znajdę odpowiedź, powrócę do niego.

Zakończenie

To koniec pierwszej części cyklu poświęconego transakcjom rozproszonym. Co będzie w kolejnym - zobaczymy, gdy pchnę prace projektowe dalej :).

Powrót

• Transakcje rozproszone cz. 2
• Transakcje rozproszone cz. 3

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.