Rozdział 7 Koncepcja systolicznego wspomagania integracji systemów informatycznych Streszczenie. Rozdział przedstawia koncepcję alternatywnego rozwiązania do obecnie stosowanych metod integracji systemów informatycznych w zróżnicowanym środowisku produkcyjnym. Współczesne, nowe i starsze systemy produkcyjne mogą współdzielić dane bez potrzeby kosztownych migracji danych oraz zagrożenia naruszenia ich spójności. W rozdziale zaprezentowano problemy związane z przetwarzaniem transakcji w środowiskach rozproszonych wraz z omówieniem architektury prezentowanego rozwiązania, chroniącego przed wystąpieniem sytuacji wzajemnego zakleszczenia transakcji w dostępie do danych. W punkcie 6 opisano systoliczny algorytm oraz dedykowany układ sprzętowy, które tworzą akcelerator systoliczny. Przedstawione rozwiązanie minimalizuje łączny czas oczekiwania systemów na realizację zgłoszonych transakcji. Zaletą rozwiązania jest możliwość uwzględniania priorytetów w dostępie do danych oraz skalowalność w odniesieniu do zapotrzebowania w środowisku rozproszonym. 1 Wstęp Współcześnie małe i średnie przedsiębiorstwa, w celu uproszczenia organizacji lub zwiększenia efektywności pracy, używają wielu różnych systemów informatycznych. Niezależne wymagania stawiane systemom, różne terminy wdrożeń lub czynniki ekonomiczne uniemożliwiają współpracę systemów informatycznych. Także mnogość dostawców nie wpływa na ujednolicenie zastosowanych technologii oraz implementacji bez zastosowania interfejsów, umożliwiających integrację. Dlatego niezależne systemy funkcjonujące w firmach i obsługujące np. magazyn czy księgowość wykorzystują własną przestrzeń składowania danych, zazwyczaj pojedynczą bazę danych. Wymagania stawiane współczesnym systemom wynikające z wielodostępu, niezawodności czy też wydajności bezpośrednio wymuszają tworzenie rozproszonych systemów umożliwiających przetwarzanie znacznej ilości danych. Mateusz Smoliński, Ewa Lipowska-Nadolska Politechnika Łódzka, Samodzielny Zakład Sieci Komputerowych, ul. Stefanowskiego 18/22, 90-924 Łódź, Polska email:{mmolinski, eln}@zsk.p.lodz.pl
M. Smoliński, E. Lipowska-Nadolska Rosnące wymagania technologiczne jak i funkcjonalne często wprowadzają potrzebę wymiany informacji pomiędzy systemami informacyjnymi EIS (ang. Enterprise Information System). Podstawowym założeniem jest utrzymanie spójności danych. Większość obecnie stosowanych technik integracji wymaga zazwyczaj wprowadzenia zmian w istniejących systemach. Zwiększanie funkcjonalności pracujących systemów produkcyjnych jest ograniczone technologicznie oraz brakiem kodu źródłowego lub dokumentacji. Dodatkowo integracja systemów wykonanych w odmiennych technologiach wprowadza utrudnienia, a w niektórych przypadkach jest niemożliwa. Powszechnie stosowanym rozwiązaniem jest stworzenie nowego systemu z wykorzystaniem współczesnych technologii, który pokrywa zakres funkcjonalności integrowanych systemów. Rozważając aspekty ekonomiczne budowy nowego systemu należy uwzględnić jeden z głównych kosztów, związany z migracją danych produkcyjnych. Alternatywnym rozwiązaniem do budowy nowego systemu jest omawiany w rozdziale systoliczny akcelerator, którego wprowadzenie w środowisku produkcyjnym umożliwia udostępnienie wielu systemom produkcyjnych baz danych z zachowaniem spójności danych. [1] Prezentowane rozwiązanie bazuje na opracowanym algorytmie systolicznym, który poprzez wykonywanie licznych operacji logicznych zapewnia synchronizację transakcji rozproszonych. Ponieważ wprowadzony akcelerator jest centralnym punktem synchronizacji w środowisku rozproszonym, zatem wpływa na zwiększenie opóźnień w realizacji transakcji. Dlatego tylko dedykowany układ przetwarzający zapewni minimalizację łącznego czasu przestojów systemów związanego z oczekiwaniem na przetworzenie transakcji. Innym przyjętym wymaganiem jest elastyczność, dzięki czemu prezentowane rozwiązanie jest skalowalne i może być stosowane w różnych środowiskach rozproszonych. Spełnienie przedstawionych wymagań dotyczących efektywnego koordynowania transakcji rozproszonych umożliwia sprzętowy układ - programowalna tablica systoliczna wraz z odpowiednim algorytmem systolicznym. 2 Przetwarzanie transakcji rozproszonych Stworzenie produkcyjnego środowiska z uwzględnieniem istniejących systemów informatycznych, umożliwiającego nowym systemom współdzielenie dostępu do istniejących danych, wymaga wprowadzenia synchronizacji transakcji. Zazwyczaj istniejące systemy pracują na oddzielnych bazach danych. Uwzględniając cztery podstawowe cechy transakcji (ACID): niepodzielność (ang. Atomicity), spójność (ang. Consistency), izolację (ang. Isolation) oraz trwałość (ang. Durability) nie można zapewnić spójności danych w omawianym środowisku. [2] Wyjątkiem jest przypadek, gdy wszystkie systemy wykorzystują jedną bazę danych. Wówczas wymogi ACID są spełnione, ponieważ synchronizacja wszystkich transakcji jest wykonywana przez system zarządzania bazami danych DBMS (ang. DataBase Management System). Wówczas stosując wysoki poziom izolacji transakcji zapewniamy spójność współdzielonych danych. W sytuacji kiedy pojedynczy DBMS zarządza większą liczbą baz danych, synchronizacja transakcji powinna zostać przeprowadzona na wyższym poziomie. W omawianym środowisku każdy system, który wykorzystuje większą liczbę baz danych, musi wykorzystywać transakcje rozproszone. Dzięki standardowi X/Open definiującemu standard interfejsów XA dla aplikacji oraz zasobów takich jak bazy danych, możliwe jest przeprowadzanie transakcji rozproszonych w środowiskach heterogenicznych. [3], [4] Często wykorzystuje się protokół dwufazowego zatwierdzania w celu synchronizacji zmian wykonanych w wielu bazach danych. [4] 98
Koncepcja systolicznego wpomagania integracji ssytemów informatycznych W omawianym środowisku zakładającym brak bezpośredniej wymiany informacji pomiędzy systemami współdzielącymi dane może doprowadzić do zakleszczenia transakcji, co w konsekwencji może doprowadzić do wstrzymania pracy systemu. Problem powstałej blokady jest spowodowany brakiem wspólnych mechanizmów synchronizujących przetwarzanie transakcji. Rys. 1. Prosty scenariusz wzajemnej blokady transakcji prowadzący do zablokowania systemów EIS. W przedstawionym schemacie (rys. 1) system EIS1 zgłasza transakcję T1, która modyfikuje rekord a z bazy danych A i następnie zmienia rekord b z bazy danych B. Przebieg transakcji T2 zgłoszonej przez system EIS2 ma odwrotną kolejność wykonywanych operacji. Brak globalnej koordynacji transakcji prowadzi do wzajemnego zakleszczenia transakcji, które nie powinny być przetwarzane równolegle. Oczywiście ten prosty scenariusz może być początkiem lawiny blokad kolejnych transakcji. Zaawansowane scenariusze prowadzące do wzajemnego zakleszczenia mogą obejmować większą liczbę systemów, przy czym sytuacja zakleszczenia powstaje w wyniku pośrednich kolizji w dostępie do danych. Każda kolizja transakcji prowadzi do blokowania jednej z transakcji, co w konsekwencji opóźnia realizację logiki biznesowej. Praktycznym rozwiązaniem przedstawionego problemu zakleszczeń jest wprowadzenie ograniczenia czasu realizacji transakcji, wówczas każda transakcja, która przekroczy ten czas jest automatycznie odwoływana. Jednakże to proste rozwiązanie problemu zakleszczeń prowadzi do odwołania transakcji, bez żadnego uzasadnienia względem logiki biznesowej. W wybranych zastosowaniach zmiana kolejności przetwarzania transakcji prowadząca do innego stanu danych, może skutkować naruszeniem zasad obowiązujących w systemie. Jako przykład można rozważyć systemy aukcyjne, gdzie kolejność zgłoszeń klientów wpływa na końcowy wynik licytacji. 3 Założenia względem środowiska przetwarzania transakcji Klasyfikacja systemów bazodanowych ze względu na sposób przetwarzania danych uwzględnia: przetwarzanie wsadowe i na bieżąco (on-line). Przedstawione sposoby przetwarzania danych są od siebie niezależne. Przetwarzanie danych on-line w bazie danych jako grupy niepodzielnych operacji wymaga wprowadzenia transakcji. Rozpatrując specyfikę operacji przeprowadzanych w transakcjach, systemy informatyczne możemy podzielić na OLAP (ang. On-line Analytical Processing) i OLTP (ang. On-line Transaction Processing). Transakcje systemów OLAP obejmują znaczne ilości danych (zazwyczaj odczytu), dlatego w dalszej części rozważane będą jedynie systemy OLTP. Transakcje zgłaszane przez syste- 99
M. Smoliński, E. Lipowska-Nadolska my OLTP są krótsze, ze względu na mniejszą liczbę wykonywanych operacji odczytu/zapisu oraz liczbę danych wykorzystanych w transakcji. W celu wprowadzenia centralnego punktu koordynacji w przetwarzaniu transakcji należy dodać dla każdego z integrowanych systemów agenta pośredniczącego w zgłaszaniu transakcji oraz dynamiczną usługę nazw (rys. 2). Podstawowa funkcjonalność agenta to przechowywanie wszystkich zgłoszonych przez system EIS transakcji w kolejce FIFO (First-In First-Out) i sterowanie ich przetwarzaniem względem decyzji podjętych w centrum koordynacji. Dodatkowo agent zapewnia określenie danych niezbędnych do wykonania transakcji względem baz danych. Rys. 2. Rozproszone środowisko przetwarzania transakcji. W pierwszym kroku agent wstrzymuje realizację transakcji i przeprowadza konwersję reprezentacji zasobów danych wykorzystywanych przez transakcję do postaci binarnej (rys. 3). Wprowadzone mapowanie ujednolica zapis, redukuje rozmiar danych reprezentujących dane wykorzystywane w transakcji i upraszcza przetwarzanie. Konwersja jest realizowana przez dynamiczną usługę nazw. Każdy zasób danych taki jak rekord w bazie danych posiada jednoznaczną reprezentację bitową w n-bitowym słowie. 100
Koncepcja systolicznego wpomagania integracji ssytemów informatycznych Rys. 3. Rejestracja zasobów transakcji w dynamicznej usłudze nazw. W procesie rejestracji wykonywanym przez agenta (rys. 4) unikalna reprezentacja każdego wykorzystywanego w transakcji zasobu danych (odczyt lub zapis) występuje w zwracanym binarnym słowie, identyfikującym zasoby transakcji (ozn. IR). Mapowanie stworzone przez dynamiczną usługę nazw obowiązuje przez określony czas, gdyż ta sama reprezentacja binarna po zakończeniu przetwarzania transakcji może zostać przypisana do innego zasobu danych. Należy też zauważyć, że jednoczesna liczba zasobów poddanych mapowaniu jest zależna od długości przyjętego słowa. Rys. 4. Uzyskanie identyfikatora zasobów transakcji. Jeżeli agent uzyskał identyfikator zasobów transakcji IR i nie posiada wcześniej zgłoszonych oczekujących transakcji, wówczas wysyła otrzymany identyfikator binarny IR do centrum koordynacji (rys. 5). 101
M. Smoliński, E. Lipowska-Nadolska Rys. 5. Zgłoszenie zasobów transakcji w centrum koordynacji. W celu przeciwdziałania zgłaszaniu wielu IR do centrum koordynacji przez jednego agenta wprowadzono żetony. Centrum koordynacji zarządza wydawaniem żetonów w celu zapewnienia by przekazane do koordynacji IR pochodziły od różnych agentów. Rys. 6. Wydanie żetonu przez centrum koordynacji. Wszystkie transakcje zgłoszone przez system zostają wstrzymane i są przechowywane przez agenta zgodnie z kolejnością zgłoszeń (FIFO). Agent po uzyskaniu żetonu (rys. 6) przekazuje najstarszą z oczekujących transakcji do realizacji (rys. 7). Oczywiście jeżeli w kolejce FIFO oczekuje kolejna transakcja, wówczas jej IR jest przekazywany do centrum koordynacji. 102
Koncepcja systolicznego wpomagania integracji ssytemów informatycznych Rys. 7. Realizacja transakcji rozproszonej. Kiedy transakcja zakończy się, agent jest zobligowany do wyrejestrowania zasobów z dynamicznej usługi nazw. Dodatkowo informacja o zwolnieniu zasobów jest przekazywana do centrum koordynacji (rys. 8). Rys. 8. Wyrejestrowanie zasobów transakcji z usługi nazw. Wszystkie identyfikatory zasobów przekazane do centrum koordynacji należą do transakcji zgłoszonych przez różne systemy, zatem kolejność ich przetwarzania może być dowolna. W środowisku, gdzie pracuje wiele systemów, może zaistnieć potrzeba wyróżnienia części z nich w dostępie do danych. Przykładem prostej klasyfikacji jest pierwszeństwo systemu ustalającego limity magazynowe przed systemami handlowymi. Rozwiązaniem problemu rozróżnienia preferencji systemów w dostępie do danych jest wprowadzenie priorytetów przypisanych do agentów. Wówczas centrum koordynacji dla każdego IR uwzględnia przy określaniu kolejności przetwarzania transakcji wartości priorytetów. Prosty mechanizm priorytetów ma wpływ na systemy mniej uprzywilejowane w dostępie do danych, prowadząc nawet do sytuacji tzw. zagłodzenia w realizacji zgłoszonych transakcji. [5] 103
M. Smoliński, E. Lipowska-Nadolska Centrum koordynacji powinno przeciwdziałać sytuacji zagłodzenia systemu w szczególności, gdy systemy są równie uprzywilejowane w dostępie do danych. Zaproponowanym rozwiązaniem tego problemu jest odroczony termin (algorytm deadline) przypisany do transakcji rozproszonej. Wówczas każda transakcja posiada licznik określający liczbę transakcji, zgłoszonych przez pozostałe systemy, jaka może zostać zrealizowana wcześniej. [6] Głównym zadaniem centrum koordynacji jest ustalenie porządku w przetwarzaniu transakcji z eliminacją kolizji. Sytuację kolizji dwóch różnych transakcji można określić wykonując alternatywę logiczną dla ich identyfikatorów zasobów IR. Wynik różny od zera wskazuje kolizję transakcji. Uwzględniając aktualnie wykorzystywane zasoby i detekcję kolizji względem danych pomiędzy dowolnymi transakcjami możliwe jest określenie właściwej kolejności zapewniającej równoległe przetwarzanie jak największej liczby zgłoszonych transakcji. Zastosowane podejście minimalizuje czas oczekiwania systemów EIS na realizację zgłoszonych transakcji. Należy zauważyć, że wykrywanie kolizji umożliwia określenie kolejności przetwarzania transakcji, w której nie występują blokady na poziomie bazy danych, przez co czas przetwarzania transakcji może zostać skrócony. Zaproponowane rozwiązanie całkowicie eliminuje problem wzajemnej blokady transakcji. jednakże wymaga wykonania znacznej liczby prostych operacji arytmetycznych w możliwie najkrótszym czasie. Wymagania te spełnia dedykowany układ: tablica systoliczna. 4 Systoliczny akcelerator transakcji rozproszonych Obliczenia wykonywane w centrum koordynacji niezbędne do ustalenia kolejności w przetwarzaniu transakcji muszą być przeprowadzone w możliwie najkrótszym czasie, gdyż mogą wpływać na czas przestoju systemów produkcyjnych. Istnieje zatem potrzeba użycia dedykowanego układu sprzętowego. Uwzględnienie charakterystyki przetwarzania obejmującej wielokrotne wykorzystanie tych samych danych wejściowych oraz wymogu dostosowania do środowiska dowolnej liczby integrowanych systemów wykazuje potrzebę wykorzystania tablicy systolicznej. [7] Zaproponowana tablica umożliwia przekazywanie danych pomiędzy kolejnymi jednostkami przetwarzającymi [7], [8], [9]. Jednoczesne wykonywanie obliczeń przez wiele procesorów wraz z możliwością przekazywania pomiędzy procesorami danych wejściowych (tablica IR) i wyjściowych przy obliczeniach związanych z wykrywaniem kolizji redukuje potrzebę wykonywania licznych operacji odczytów/zapisów tych samych struktur danych z/do pamięci. Przygotowanie zbioru danych wejściowych i interpretację danych wyjściowych z tablicy systolicznej realizuje centrum koordynacji. Proponujemy wykorzystanie, jako modelu akceleratora, komputera systolicznego Systola1024. Komputer jest wyposażony w 1024 procesory, tworzące tablicę ortogonalną 32 wiersze na 32 kolumny. Systola 1024 jest programowalna w języku LAISA (LAnguage Instruction Systolic Array). [9] Wprowadzone do programowalnej tablicy systolicznej instrukcje są propagowane pomiędzy procesorami. Zastosowanie selektorów zapewnia możliwość kontrolowania wykonania zleconych instrukcji przez poszczególne procesory, zatem istnieje możliwość logicznego podziału na moduły (mniejsze tablice systoliczne zestawione w potok). Opracowany algorytm systoliczny uwzględnia czas oczekiwania transakcji w centrum koordynacji, a dzięki modułowości tablicy umożliwia rozpatrzenie kolejności realizacji zgłoszonych transakcji rozproszonych na ustalonym poziomie np. trzy transakcje w przód. Liczba poziomów dla rozpatrywanych scenariuszy jest ograniczona jedynie przez liczbę integrowanych systemów. Wyższy poziom wydłuża czas wykonywa- 104
Koncepcja systolicznego wpomagania integracji ssytemów informatycznych nia algorytmu systolicznego ale jednocześnie wpływa też na zmniejszenie łącznego czasu wstrzymania pracy systemów oczekujących na realizację transakcji. Wszystkie obliczenia mogą być wykonywane w trakcie przetwarzania innych transakcji, zatem po zakończeniu każdej z realizowanych transakcji centrum koordynacji interpretując wyniki zwrócone wcześniej przez tablicę systoliczną może natychmiast podjąć decyzję i rozdać żetony dla odpowiednich agentów. Cechy tablic systolicznych, których modelem jest komputer Systola 1024, a mianowicie modułowość i skalowalność zapewniają elastyczność w dostosowaniu rozwiązania do integrowanego środowiska produkcyjnego. 5 Wnioski Integracja systemów w środowisku produkcyjnym jest wyzwaniem, w szczególności gdy istniejące systemy nie zapewniają właściwych interfejsów. Dlatego ich funkcjonalność jest wprowadzana do nowych., współczesnych systemów. Jednakże w tym rozwiązaniu znaczną cześć kosztów generuje migracja danych produkcyjnych. Alternatywą dla powyższego rozwiązania jest wprowadzenie centralnej koordynacji w przetwarzaniu transakcji, w celu umożliwienia współpracy pomiędzy istniejącymi i nowymi systemami informatycznymi. Z punktu widzenia systemu operacyjnego jest to pośrednik w komunikacji ze źródłami danych, który gwarantuje zachowanie spójności danych. Podstawową zaletą prezentowanego rozwiązania jest wyeliminowanie wzajemnego zablokowania transakcji, prowadzącego do wstrzymania pracy systemów produkcyjnych. Wprowadzone centralne elementy prezentowanego rozwiązania: dynamiczna usługa nazw oraz centrum koordynacji, przejmując funkcjonalność związaną z synchronizacja dostępu do danych mogą dodatkowo zwiększyć wydajność przetwarzania transakcji. Wszystkie niezbędne obliczenia są wykonywane przez tablicę systoliczną w centrum koordynacji, która sprzętowo zapewnia wysoką efektywność obliczeniową. Podział na moduły, możliwość programowania oraz elastyczność algorytmu systolicznego umożliwiają zastosowanie rozwiązania w różnych integrowanych środowiskach produkcyjnych. Zaletą zastosowania akceleratora systolicznego jest wykonywanie niezbędnych obliczeń w trakcie przetwarzania innych, kolizyjnych względem danych transakcji. Uzyskane wyniki służą ustaleniu najkorzystniejszej sekwencji realizacji transakcji, która minimalizuje czas przestoju zintegrowanych systemów informatycznych. Zatem centrum koordynacji posiada przygotowane scenariusze kolejności przetwarzania oczekujących transakcji, opracowane względem pierwszeństwa zakończenia aktualnie przetwarzanych transakcji. Dodatkowo nowe lub istniejące systemy informatyczne mogą zostać wyróżnione w dostępie do danych poprzez wprowadzenie wielu poziomów priorytetów, względem których centrum koordynacji będzie ustalać kolejność realizacji zgłoszonych transakcji. Jednakże nawet przy zastosowaniu priorytetów, część systemów może posiadać identyczną wartość preferencji, zatem niezbędne będzie wykorzystanie zaproponowanego akceleratora systolicznego. Literatura 1. Smoliński M.: Koncepcja systolicznego akceleratora transakcji rozproszonych, XV Konferencja Sieci i Systemy Informatyczne, październik 2007. 105
M. Smoliński, E. Lipowska-Nadolska 2. Bernstein A., Kifer M.: Databases and Transaction Processing: An Application-Oriented Approach, 1st edition, Addison-Wesley, Longman Publishing, 2001. 3. Linthicum D.: Enterprise Application Integration, Addison Wesley Professional, 1999. 4. Bernstein P.A., Newcomer E.: Principles of Transaction Processing: for the Systems Professionals, 1996. 5. Smoliński M.: Priorytetyzacja transakcji rozproszonych z eliminacją kolizji w trzywarstwowej architekturze JEE, XIV Konferencja Sieci i Systemy Informatyczne, październik 2006. 6. Stankovic J, Spuri M, Ramamritham K., Buttazzo G.: Deadline Scheduling for Real-Time Systems, Kluwer Academic Publishers,1998. 7. Lipowska-Nadolska E, Morawski M.: Tablice systoliczne. Problemy wybrane, Akademicka Oficyna Wydawnicza PLJ, Seria Informatyka W-wa 1999. 8. Lipowska-Nadolska E., Kwapisz M., Lichy K.: Systoliczne przetwarzanie sygnałów cyfrowych, Akademicka Oficyna Wydawnicza EXIT, Seria Informatyka, W-wa 2007. 9. The ISATEC Parallel Computer, SYSTOLA 1024, version 3.0, 1998. 106