Zarzadzanie użytkownikami i wirtualnymi organizacjami w centrum obliczeniowym

Transkrypt

1 Akademia Górniczo - Hutnicza im. Stanisława Staszica w Krakowie Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki Katedra Informatyki Zarzadzanie użytkownikami i wirtualnymi organizacjami w centrum obliczeniowym Liwiusz Ociepa liwiusz.ociepa@gmail.com Praca magisterska napisana pod kierunkiem dr inż. Mariana Bubaka, konsultacje mgr inż. Marcin Radecki Kraków, 2009

2 Serdeczne podziękowania składam Panu dr inż. Marianowi Bubakowi, bez pomocy Którego praca ta nie zostałaby napisana. Goraco pragnę podziękować także Panu mgr inż. Marcinowi Radeckiemu, opiekunowi mojej pracy, za cenne wskazówki, dzięki którym praca ta zyskała na wartości oraz za możliwość zapoznania się z działaniem centrum obliczeniowego. Praca została wykonana przy wsparciu projektu PL-Grid. numer umowy: POIG /08-00, strona WWW: Projekt jest częściowo finansowany ze środków Europejskiego Funduszu Regionalnego, jako element Programu Operacyjnego Innowacyjna Gospodarka.

3 Streszczenie Tematem pracy jest zarzadzanie użytkownikami od strony systemu operacyjnego. Z tego punktu widzenia wirtualne organizacje występuja przede wszystkim jako jednostka grupujaca użytkowników oraz maszyny obliczeniowe. Tytułowy system jest oparty o bazę danych PostgreSQL zawierajac a dane systemu replikujac a, z zastosowaniem metody push, dane do bazy LDAP i serwera haseł Kerberos5. System ten został zaprojektowany jako system zarzadzania wykorzystywany w środowisku obliczeń gridowych. Opracowanie zawiera opis konfiguracji poszczególnych serwerów systemu - zarówno serwerów głównych jak i serwerów obliczeniowych korzystajacych z usług Systemu Zarzadzania Użytkownikami i Wirtualnymi Organizacjami. Opisy te obejmuja konfigurację serwerów PostgreSQL, slapd (zarówno serwera master jak i serwerów slave), krb5-kdc-ldap (serwer KDC MIT Kerberos5 z backendem w bazie LDAP), bibliotek systemowych pam_krb5, nssldapd. Przedstawione zostały metody tunningu i partycjonowania baz PostgreSQL (PL/Proxy) i OpenLDAP (chainning i referral). Przedstawione zostały również mechanizmy zapewniajace wysoka dostępność poszczególnych komponentów systemu - walmgr w przypadku PostgreSQL, replikacja multimaster i master-slave w przypadku OpenLDAP i zapewnienie wysokiej dostępności bazy haseł Kerberos poprzez zastosowanie serwera LDAP jako backendu KDC. Praca powstała w ramach projektu PL-Grid. Słowa kluczowe: zarządzanie użytkownikami, zarządzanie wirtualnymi organizacjami, PostgreSQL, OpenLDAP, MIT Kerberos 5, krb5-kdc-ldap, replikacja multimaster, replikacja master-slave, replikacja push, polling, zarządzanie certyfikatami, wysoka dostępność, systemy gridowe.

4 Spis treści Wstęp 6 Cel pracy Struktura pracy Istniejace rozwiazania Perun Architektura systemu Perun Virtual User System Grid User Management System Podsumowanie Analiza i projekt Systemu Zarzadzania Użytkownikami i Wirtualnymi Organizacjami Metodologia Wstępna analiza zagadnienia Zarządzanie użytkownikami a zarządzanie wirtualnymi organizacjami Wymagania funkcjonalne i niefunkcjonalne Wymagania funkcjonalne Wymagania niefunkcjonalne Wymagania a istniejące rozwiązania Diagramy przypadków użycia Plan architektury systemu Planowane technologie Diagram klas Systemu Zarządzania Użytkownikami i Wirtualnymi Organizacjami Diagram klas zarządzania maszynami obliczeniowymi Diagramy sekwencji

5 Spis treści 4 3 Prototypy aplikacji bazodanowej realizujacej stawiane wymagania Zmiany technologii w stosunku do projektu Architektura systemu Pierwsza wersja architektury systemu zarządzania Druga wersja architektury systemu zarządzania Przyczyny zmian w architekturze Architektura bazy danych Opisy tabel systemu zarządzania Tabele techniczne Widoki używane do replikacji danych Procedury składowane używane do operacji na tabelach właściwych Procedury używane w mechanizmach replikacji danych Architektura bazy LDAP Dublowanie danych - wady i zalety Replikacja danych z bazy SQL do LDAP i Kerberos Replikacja danych z bazy SQL do LDAP Replikacja danych z bazy SQL do Kerberos Dyskusja na temat technologii zastosowanej do replikacji z bazy PostgreSQL do LDAP Przygotowanie serwerów do współpracy z Systemem Zarzadzania Użytkownikami i Wirtualnymi Organizacjami Konfiguracja serwera głównego bazy danych i instalacja aplikacji OpenLDAP MIT Kerberos PostgreSQL Konfiguracja replikacji z bazy SQL do LDAP i Kerberos Konfiguracja serwerów głównych dla projektów Konfiguracja maszyn obliczeniowych Konfiguracja Name Service Switch Konfiguracja Pluggable Authentication Modules Zmiana obejmująca wszystkie serwery LDAP Podsumowanie

6 Spis treści 5 5 Rozwiazania zwiększajace niezawodność poszczególnych komponentów Systemu Zarzadzania Użytkownikami i Wirtualnymi Organizacjami Serwis www Systemu Zarządzania Użytkownikami i Wirtualnymi Organizacjami Zarządzanie sesjami Scenariusze awarii Serwer PostgreSQL Serwer Kerberos Serwer OpenLDAP Podsumowanie Optymalizacja i skalowalność usług wchodzacych w skład Systemu Zarzadza- nia Użytkownikami i Wirtualnymi Organizacjami Analiza systemowa Wpływ zwiększenia liczby użytkowników na obciążenie poszczególnych elementów systemu zarządzania Wpływ zwiększenia liczby maszyn czy projektów na obciążenie poszczególnych elementów systemu zarządzania Poszukiwanie wąskich gardeł systemu i analiza ich wpływu na działanie systemów obliczeniowych Metody eliminacji wąskich gardeł Serwer Baza danych PostgreSQL Baza danych LDAP Podsumowanie Podsumowanie i dalszy rozwój Systemu Zarzadzania Użytkownikami i Wirtualnymi Organizacjami Dalszy rozwój systemu Bibliografia 102 Spis ilustracji 106 Spis akronimów 107

7 Wstęp Wraz ze wzrostem popularności dziedzin w których zastosowanie mają obliczenia wielkiej skali rośnie zapotrzebowanie na moc obliczeniową. Równocześnie można zaobserwować tendencję zastępowania najmocniejszych maszyn starszego typu nie nowymi ich modelami ale klastrami złożonymi z wielu urządzeń indywidualnie o dużo mniejszej mocy obliczeniowej dostarczających w sumie dużo większą ilość zasobów. Zmiany te są pochodną rozwoju rozwiązań sieciowych - dzięki nim możliwe jest zastąpienie bardzo drogich maszyn SMP 1 klastrami maszyn połączonymi szybkimi sieciami - gigabitowym ethernetem czy infiniband. Wraz z takimi zmianami rośnie znacząco stopień skomplikowania prac wykonywanych przy zarządzaniu centrum obliczeniowym - począwszy od samego zarządzania konfiguracją, na zarządzaniu użytkownikami kończąc. Większa liczba użytkowników oraz większa liczba urządzeń, którymi trzeba zarządzać, znacząco zwiększają czasochłonność codziennych czynności administracyjnych. Dodatkowo w wypadku ręcznego wykonywania tego typu zadań rośnie prawdopodobieństwo popełnienia błędu czy pominięcia któregoś z urządzeń (na przykład w wypadku jego chwilowej niedostępności). Pojawienie się bardzo dużej liczby urządzeń posiadających bardzo liczną bazę użytkowników spowodowało konieczność zrewidowania dotychczasowych procedur postępowania. Pojawiły się nieznane do tej pory na taką skalę problemy z zachowaniem spójności baz użytkowników, z systemami zarządzania hasłami, wreszcie z centralizacją zarządzania samymi maszynami. Do tej pory stosowane rozwiązania w tym zakresie (głównie NIS 2 ) okazały się być zbyt mało elastyczne a dodatkowo podatne na rożne ataki od zakłócających działanie po naruszenia ograniczeń dostępu do zasobów. Zaczęto wprowadzać mechanizmy centralnego zarządzania użytkownikami nowego typu - przechowywanie haseł w serwerach Kerberos czy LDAP 3. Jednak rozwiązania te nie są same w żaden sposób zintegrowane z systemami 1 Symmetric multiprocessing 2 Network Information Service 3 Lightweight Directory Access Protocol

8 Wstęp 7 obliczeń gridowych. Nie możemy przy tym zapomnieć, że systemy gridowe wprowadzają własne pojęcia grupujące różne byty funkcjonujące w ich ramach - użytkowników czy klastry obliczeniowe. Są one o tyle ważne, że bardzo często nie będziemy operować na pojedynczych użytkownikach czy klastrach - ale na całych ich grupach poprzez zmiany w ramach wirtualnych organizacji. Cel pracy Specyfiką pracy użytkowników gridowych jest szerokie stosowanie certyfikatów. Począwszy od ich wygenerowania, podpisania, poprzez ich stosowanie do uwierzytelniania w systemach gridowych aż do działań związanych z ich odwoływaniem. Mechanizmy te są w dalszym ciągu bardzo słabo zintegrowane z systemami zarządzania użytkownikami. Celem tej pracy jest stworzenie systemu, który przy użyciu standardów przemysłowych w zarządzaniu użytkownikami i sprzętem zapewniałby podstawową integrację z systemami gridowymi. Integrację obejmującą w pierwszej kolejności zarządzanie certyfikatami. Dodatkowym utrudnieniem jest to, że bardzo często zamiast zarządzać pojedynczymi użytkownikami będziemy operować na całych ich grupach poprzez wirtualne organizacje. Celem pracy jest stworzenie projektu i implementacja prototypu części bazodanowej. Aplikacja bazodanowa obejmuje strukturę bazy SQL 4, system replikacji danych do baz LDAP i bazy haseł Kerberos oraz logikę aplikacji zlokalizowaną w procedurach składowanych w bazie danych. W skład tej części aplikacji wchodzi również przygotowanie serwerów do współpracy z nią oraz opracowanie rozwiązań z zakresu wysokiej niezawodności. Sama praca stanowi tylko pierwszy krok do stworzenia kompleksowego rozwiązania. Dodatkowo opisana zostanie niezbędna konfiguracja serwerów wchodzących w skład klastrów obliczeniowych. Jednym z podstawowych problemów, które system ma rozwiązywać jest skalowalność i wysoka niezawodność dostarczonego rozwiązania. Struktura pracy Pierwszy rozdział koncentruje się nad analizą systemów już istniejących dla których tworzone rozwiązanie jest alternatywą. 4 Structured Query Language

9 Wstęp 8 Kolejny, drugi rozdział przedstawia analizę i projekt systemu zarządzania. Przedstawione w nim są wymagania jakie spełniać musi aplikacja, do jakich zastosowań będzie używany (analiza przypadków użycia), jak będzie wyglądało przetwarzanie każdego żądania (sekwencje wykonywanych operacji) czy plan architektury systemu i zastosowanych technologii. Dodatkowo w rozdziale tym zostanie zaprezentowany projekt struktury bazy danych. Następny rozdział - trzeci - zawiera opis prototypów aplikacji. Jego początek opisuje zmiany w technologii będące skutkiem zmiennych wymagań środowiska. Przedstawione zostały opisy architektury - zarówno końcowej jak i wersji pośrednich. Opisana została również w całości aplikacja bazodanowa - jej struktura jak i opis tego czym jest tabela przedstawiana na poszczególnych schematach. Rozdział ten zawiera również opis architektury bazy LDAP wraz z uzasadnieniem takiego a nie innego doboru podziału na poddrzewa. Oczywiście w rozdziale opisującym działającą aplikację nie może zabraknąć opisu zrealizowanego mechanizmu replikującego dane z bazy SQL do bazy LDAP czy Kerberos. W rozdziale czwartym opisany został sposób konfiguracji serwerów do współpracy z systemem zarządzania. Opis ten dotyczy zarówno serwerów głównych jak i serwerów obliczeniowych. Rozdział piąty opisuje w jaki sposób aplikacja spełnia wymagania wysokiej dostępności i jakie mechanizmy dodatkowe można zastosować aby nie istniały w systemie zarządzania pojedyncze punkty awarii (single points of failure). Rozdział kolejny - szósty opisuje zagadnienia związane z wydajnością, strojeniem (tunningiem) oraz skalowalnością tego rozwiązania. Rozdział siódmy przedstawia spostrzeżenia jakie pojawiły się w trakcie prac nad systemem oraz wnioski z jego realizacji wraz możliwymi kierunkami dalszego jego rozwoju.

10 Rozdział1 Istniejące rozwiązania Rozdział zawiera opisy konkurencyjnych rozwiazań działajacych w tym samym oraz zbliżonym obszarze zastosowań zarzadzania użytkownikami co System Zarzadzania Użytkownikami i Wirtualnymi Organizacjami. Przedstawiony został system Perun, jego architektura i sposób działania. Poza Perunem zostały bardzo krótko opisane systemy VUS i GUMS, które mimo działania w przestrzeni zarzadzania użytkownikami, obejmuja inny jej obszar (zarzadzanie użytkownikami z punktu widzenia systemów gridowych a nie systemu operacyjnego wykorzystywanego do współpracy z systemami gridowymi). Przedstawione zostały braki tych systemów, szczególnie w obszarze zarzadzania certyfikatami oraz wirtualnymi organizacjami. 1.1 Perun Jednym z pierwszych rozwiązań próbującym sprostać opisanym we wstępie problemom był Perun [3] - system powstał w ramach projektu czeskiego narodowego gridu. System ten miał dostarczać zunifikowane środowisko dla pracowników korzystających z jego zasobów. Miał eliminować biurokratyczne bariery dla użytkowników jednego centrum obliczeniowego chcących wykonać obliczenia w innym centrum. W trakcie jego tworzenia starano się w pierwszej kolejności rozwiązać następujące problemy: Rosnąca liczba systemów obliczeniowych jest geograficznie rozproszona - zasoby są dostępne w trzech miastach - Praga, Brno i Pilzno. Każde z centrów obliczeniowych uczestniczących w projekcie ma własny, niezależny zespół administratorów.

11 Rozdział 1. Istniejące rozwiązania 10 System działa w środowisku heterogenicznym - obejmując swoim działaniem urządzenia od komputerów klasy PC, poprzez superkomputery Silicon Graphics, Digital Equipment, Compaq czy Hawlett Packard, klastry linuksowe czy urządzenia produkcji IBM. Daje to potrzebę obsługiwania wielu różnych architektur sprzętowych (MIPS 1, IA-32 2, IA-64 3, x86-64, Power i inne) oraz wielu różnych systemów operacyjnych (Linux, IRIX, Digital Unix i inne). System działa w istniejącym środowisku i jego wdrożenie nie może doprowadzić do zakłóceń działania dla dotychczasowych użytkowników - co więcej systemy zarządzające muszą uwzględniać istnienie na maszynach obliczeniowych środowiska pracy. Muszą uwzględniać istnienie kont użytkowników nieobsługiwanych przez ten system. Ze względu na dużą liczbę różnych urządzeń rozproszonych geograficznie twórcy systemu musieli przyjąć, że nie istnieje taki moment, gdy wszystkie urządzenia są włączone i sprawne. Przy tak złożonych problemach zarządzanie ad-hoc systemami okazało się zbyt skomplikowane i mało skalowalne. Analizując potrzeby użytkowników twórcy systemu opracowali listę podstawowych wymagań jakie musi spełniać system zarządzania zasobami: zarządzanie użytkownikami w środowiskach heterogenicznych konfiguracja powiązanych z tym usług (Kerberos, AFS 4, LDAP... ) odporność na awarie systemów obliczeniowych nie może wprowadzać nowych pojedynczych punktów awarii skalowalność i rozszerzalność różne interfejsy dla różnych rodzajów użytkowników i zadań - przykładowo interfejs webowy dla systemów rejestracji użytkownika czy nieinteraktywny zestaw narzędzi konsolowych do celów administracyjnych. 1 Microprocessor without Interlocked Pipeline Stages 2 Intel Architecture, 32-bit 3 Intel Itanium architecture, 64-bit 4 Andrew File System

12 Rozdział 1. Istniejące rozwiązania 11 W trakcie dalszych prac nad systemem musiano rozważyć kilka sprzecznych podejść: Rozproszone czy scentralizowane repozytorium konfiguracji. W wypadku centralnego zarządzania konfiguracją dużo łatwiej można zapewnić wysokie wymagania odnośnie zachowania spójności danych. Zapewnienie ich w architekturze rozproszonej jest zadaniem niezwykle skomplikowanym - czego przykładem są istniejące do tej pory problemy i niedociągnięcia w stosowanych w bazach danych mechanizmach replikacji multimaster. Wprowadzenie rozproszonego modelu zarządzania konfiguracją wymagałoby opracowania i wdrożenia efektywnych algorytmów takiej replikacji na poziomie systemu zarządzania. Z drugiej strony dużo wyższą odporność na awarie można uzyskać korzystając z rozproszonych repozytoriów danych. Odporność na awarie czy ścisłe przestrzeganie/wymuszanie ograniczeń. Zmiany w konfiguracji mogą dotyczyć wielu zasobów równocześnie. Ścisłe przestrzeganie ograniczeń wymagałoby zastosowania dwuetapowego zatwierdzania (2-phase commit). Z drugiej strony stosowanie takich rozwiązań bywa kłopotliwe i nieskalowalne w systemach z dużym prawdopodobieństwem awarii zarządzanych systemów. Projektując system jako całość jego twórcy musieli podjąć kilka naprawdę trudnych decyzji i obniżyć niektóre wymagania aby móc spełnić inne. Skutkiem tego w systemie Perun istnieje centralna baza danych, w której można bardzo łatwo wymusić zastosowanie ograniczeń. Jednak zmiany te są następnie propagowane do systemów docelowych przy zastosowaniu metody push (centralny serwer wypycha zmiany do komputerów docelowych, a nie jest odpytywany o nie). Maszyny obliczeniowe nigdy nie odpytują centralnego serwera - dzięki czemu w razie jego awarii nie można co prawda prowadzić działań zmieniających parametry kont użytkowników, zmieniających konfigurację maszyn i tym podobnych - lecz podstawowe zadania maszyn pozostają niezakłócone Architektura systemu Perun Baza danych - baza danych składa się z tabel systemowych i tabel zawierających dane użytkowników (tabele aplikacji zawierające dane systemu). W tabelach aplikacji są przechowywane dane opisujące konfigurację zarządzanych zasobów. Tabele systemowe opisują system Perun i są bezpośrednio używane i dostępne dla

13 Rozdział 1. Istniejące rozwiązania 12 usług zarządzających. Podstawową tabelą jest JOURNAL do której zapisywane są wszelkie zmiany w tabelach aplikacyjnych - zarówno w celach historycznych jak i w celu pobrania ich przez system propagujący zmiany na maszynach docelowych. Pozostałe tabele systemowe opisują konfigurację systemu Perun oraz informacje o stanie usług wchodzących w jego skład. Interfejsy użytkowników - na podstawie poziomu uprawnień rozróżniamy dwie klasy użytkowników: administratorzy zasobów - mają możliwość zmieniać konfigurację danego zasobu. Logują się do bazy jako nazwani użytkownicy (każdy ma imienne konto w bazie danych) zwykli użytkownicy - użytkownicy zasobów. Mają minimalne możliwości zmian danych w bazie - dokładniej tylko informacji osobistych ich dotyczących. Z punktu widzenia bazy danych logują się korzystając ze wspólnego konta bazodanowego o minimalnych uprawnieniach. W systemie dostępne są trzy różne interfejsy dla użytkowników: Interfejs webowy - używany przez zwykłych użytkowników do zmian ich danych osobowych, rejestracji czy zapytań o dodatkowe konta. Poza tym przez ten interfejs są dostępne dla administratorów informacje globalne na temat konfiguracji zasobów czy ich stanu. CLI 5 - interfejs linii komend - zbiór nieinteraktywnych komend używanych przez administratorów zarówno bezpośrednio jak i do konstrukcji skryptów automatyzujących bardziej złożone czynności. Bezpośredni dostęp do bazy - używany przez administratorów do wykonywania rzadszych czynności do których budowa narzędzi konsolowych byłaby ekonomicznie nieuzasadniona. Usługi - usługą w systemie Perun nazywamy jednostkę konfiguracji zmienianą tylko jako całość przy użyciu atomowych operacji. Dokładna definicja usługi zależy od konkretnej aplikacji - lecz powyższa zasada dotyczy każdej usługi. Przykładem jest passwd - jej zmiana powoduje zmiany we wszystkich plikach 5 command-line interface

14 Rozdział 1. Istniejące rozwiązania 13 odpowiadających za informacje o użytkownikach czyli: /etc/passwd, /etc/shadow, /etc/group czy /etc/aliases. Zmiany w konfiguracji są propagowane z zastosowaniem poniższej procedury. Zmiany w bazie są przechwytywane przez triggery na poziomie bazy danych i wstawiane do dziennika (tabela JOURNAL ). Zmiany w dzienniku są monitorowane przez inny trigger, który budzi/powiadamia service planner daemon. Usługa planująca, bazując na nazwie zmienianej tabeli, filtruje zmiany z wykorzystaniem wtyczek (planning plugins). Wtyczki te posiadają wiedzę na temat struktury i semantyki przetwarzanych danych i przetwarzają je w pary - usługa i zasób docelowy, które powinny być zaktualizowane. Usługa planująca (planner daemon) sortuje wyniki działań wtyczek, eliminuje powtarzające się dane i oznacza wynikowe usługi do aktualizacji. Opóźnienia między zmianą danych w bazie a zmianą usługi są konfigurowane w zależności od usługi Kolejne kroki są wykonywane przez aplikację rozdzielającą zadania (service dispatcher): usługi, które powinny zostać zaktualizowane są regularnie monitorowane zależności między usługami są rozwiązywane (przetwarzane a nie znoszone) dla każdej pary usługa, zasób uruchamiana jest wtyczka aktualizująca (update plugin). Wtyczka posiada wiedzę na temat struktury i semantyki przetwarzanych danych wtyczka może albo samodzielnie dokonać zmiany (dodanie konta do bazy Kerberos) albo połączyć się ze zdalnym zarządcą zasobów i dostarczyć mu danych niezbędnych do dokonania zmian Wszelkie błędy są przechwytywane przez aplikację rozdzielającą zadania. W zależności od konfiguracji aktualizacja zmian może być ponawiana kilkukrotnie zanim błąd zostanie zgłoszony administratorom (zgłoszenie typu permanent failure ). Akcje wykonywane ręcznie - mimo, że tworząc Peruna starano się zautomatyzować tak wiele działań jak tylko było to możliwe i ekonomicznie uzasadnione, istnieją

15 Rozdział 1. Istniejące rozwiązania 14 przypadki gdy wymagane jest działanie administratora bezpośrednio na serwerze. Przykładem jest wspomniane wcześniej zgłoszenie typu permanent failure. 1.2 Virtual User System System VUS 6 [4] został stworzony w odpowiedzi na potrzebę umożliwiania użytkownikom wykorzystywania zasobów obliczeniowych centrum obliczeniowego bez konieczności zakładania im imiennych kont na serwerach. Wywodzi się częściowo z rozwiązania opartego o współdzielone konta. Podstawowym usprawnieniem wprowadzonym przez VUS jest zapisywanie historii mapowania między kontem a jego użytkownikiem wraz ze zliczaniem wykorzystania zasobów w trakcie pracy. Dzięki takiemu podejściu możliwe stało się nie tylko monitorowanie działań w powiązaniu z rzeczywistym użytkownikiem systemu, ale również wyliczanie rzeczywistych kosztów użytkowania systemu przez poszczególnych użytkowników, co jest bardzo istotnym zagadnieniem przy komercyjnym stosowaniu rozwiązań gridowych. 1.3 Grid User Management System GUMS 7 [11] jest systemem odwzorowującym identyfikatory gridowe na konta systemowe. Takie działania są niezbędne, gdy systemy obliczeniowe nie używają wyłącznie gridowych systemów uwierzytelniania, lecz stosują własne oparte o konta systemu UNIX czy o hasła przechowywane w bazie Kerberos. W takiej sytuacji każde zadanie przychodzące do węzła musi zostać zestawione z odpowiadającym mu kontem lokalnym. GUMS nie zajmuje się egzekwowaniem przestrzegania tych odwzorowań. Jedyne co robi to zwraca odpowiednie wartości do gatekeepera, który jest odpowiedzialny za samo przestrzeganie tych ograniczeń. 1.4 Podsumowanie Żaden z trzech opisywanych systemów nie odpowiada w pełni wymaganiom (Rozdział 2.4) stawianym przed naszym systemem zarządzania. Najbliższy mu funkcjonalnie jest Perun, przed którym dodatkowo postawiono wymagania zmniejszenia ograniczeń 6 Virtual User System 7 Grid User Management System

16 Rozdział 1. Istniejące rozwiązania 15 natury organizacyjnej. Podstawowymi funkcjonalnościami, których brakuje Perunowi są mechanizmy zarządzania certyfikatami oraz operacje na wirtualnych organizacjach. Systemy VUS i GUMS, mimo działania w tym samym obszarze zarządzania użytkownikami, obsługują nieco inny krąg zastosowań - mapowanie konta użytkownika gridowego na rzeczywiste konto w systemie.

17 Rozdział2 Analiza i projekt Systemu Zarządzania Użytkownikami i Wirtualnymi Organizacjami Rozdział przedstawia projekt i analizę Systemu Zarzadzania Użytkownikami i Wirtualnymi Organizacjami wykonany z zastosowaniem notacji UML. Projekt i analiza obejmuja analizę wymagań, diagramy przypadków użycia, diagramy sekwencji, projekt architektury, planowane do wykorzystania technologie i diagramy klas. 2.1 Metodologia W trakcie projektowania system zarządzania użytkownikami i wirtualnymi organizacjami nie był do końca zdefiniowany zbiór funkcjonalności, który będzie realizowany w ramach tej pracy. Z tego też powodu została podjęta decyzja o zastosowaniu modelu przyrostowego tworzenia oprogramowania. Do opisu poszczególnych faz projektu użyty został język UML 1 - najpowszechniej stosowany język formalny służący do modelowania fragmentów rzeczywistości, w tym do przedstawiania projektu systemów informatycznych. 1 Unified Modeling Language

18 Rozdział 2. Analiza i projekt Systemu Zarządzania Użytkownikami i Wirtualnymi Organizacjami Wst pna analiza zagadnienia Wstępna analiza zagadnienia pod kątem przyszłych zastosowań oraz środowiska w którym system będzie działał wykazały, że będzie miał trzy klasy użytkowników. Zwykłego użytkownika, administratora systemu oraz administratora systemu z uprawnieniami do zarządzania certyfikatami. Zwykły użytkownik jest osobą, która korzysta z możliwości jakie daje centrum obliczeniowe - wykorzystuje serwery do wykonywania obliczeń czy przetwarzania danych. Administrator systemu jest osobą, która wykonuje zadania ściśle związane z funkcjonowaniem systemu - ma możliwość zakładania kont w systemie, przydzielania dostępu do serwerów czy zmian przyporządkowywania do grup systemowych. Jednym z podstawowych zadań administratora jest przydzielanie użytkowników do wirtualnych organizacji i wiązanie wirtualnych organizacji z projektami. Administrator systemu wraz z uprawnieniami do zarzadzania certyfikatami jest niespotykaną zbyt powszechnie rolą w tego typu systemach. Jego obecność jest związana ze szczególną rolą certyfikatów w procesie używania systemów gridowych oraz koniecznością wykonywania operacji zatwierdzających zapytania o podpisanie certyfikatu użytkownika centrum obliczeniowego. Jego podstawowym zadaniem jest weryfikacja i potwierdzanie zgłoszeń podpisania certyfikatu wysyłanych do centrum certyfikacji - CA Zarz dzanie u»ytkownikami a zarz dzanie wirtualnymi organizacjami Z punktu widzenia projektowanego systemu wirtualne organizacje są głównej mierze obiektami grupującymi. Z jednej strony grupują użytkowników ułatwiając wykonywanie operacji na większej ich liczbie jednocześnie. Z drugiej grupują klastry obliczeniowe co umożliwia większą automatyzację działań dla pojedynczych użytkowników - dodanie jednego użytkownika do wirtualnej organizacji umożliwiać ma w prosty sposób dodanie 2 Certification Authority

19 Rozdział 2. Analiza i projekt Systemu Zarządzania Użytkownikami i Wirtualnymi Organizacjami 18 go do wszystkich projektów / klastrów obliczeniowych z którymi wirtualna organizacja jest powiązana. 2.4 Wymagania funkcjonalne i niefunkcjonalne Wymagania funkcjonalne Wymagania funkcjonalne będą rozpatrywane z punktu widzenia każdej z klas użytkownika przedstawionej wcześniej. Zbiory wymagań funkcjonalnych zawierają się w sobie. Oznacza to, że wszystkie wymagania użytkownika systemu są również wymaganiami obu administratorów, a wymagania funkcjonalne administratora dotyczą również administratora z uprawieniami do zarządzania certyfikatami. Analiza wymagań jest kluczowa dla zrozumienia zbioru funkcjonalności jakie ma realizować system. Każda z funkcjonalności jest opisana następującymi atrybutami: nazwa, zadanie jakie realizuje, parametry wejściowe, wynik i ewentualne uwagi. Użytkownik systemu zmiana hasła użytkownika cel: zmiana hasła używanego do uwierzytelniania w systemie zarządzania oraz w klastrach obliczeniowych parametry wejściowe: stare hasło, nowe hasło zwracany wynik: sukces, porażka wygenerowanie nowego żadania podpisania certyfikatu cel: uzyskanie nowego certyfikatu używanego w systemach gridowych parametry wejściowe: dane osobowe zwracany wynik: sukces, porażka uwagi: wygenerowanie żądania nowego certyfikatu nie powiedzie się, gdy w kolejce czeka już żądanie danego użytkownika do tego samego CA wycofanie oczekujacego na akceptację żadania podpisania certyfikatu cel: wycofanie żądania podpisania certyfikatu parametry wejściowe: identyfikator żądania zwracany wynik: sukces, porażka

20 Rozdział 2. Analiza i projekt Systemu Zarządzania Użytkownikami i Wirtualnymi Organizacjami 19 udostępnienie sobie możliwości używania certyfikatu w wybranym projekcie cel: umożliwienie sobie używania wybranego certyfikatu na wszystkich maszynach wchodzących w skład wybranego projektu parametry wejściowe: identyfikator projektu, identyfikator certyfikatu zwracany wynik: sukces, porażka usunięcie sobie możliwości używania certyfikatu w wybranym projekcie cel: zlikwidowanie możliwości podpisywania wybranym certyfikatem na maszynach należących do danego projektu parametry wejściowe: identyfikator projektu, identyfikator certyfikatu zwracany wynik: sukces, porażka Administrator zarzadzanie wirtualnymi organizacjami dodanie wirtualnej organizacji cel: dodanie do systemu zarządzania wirtualnej organizacji grupującej użytkowników parametry wejściowe: nazwa wirtualnej organizacji, rodzaj wirtualnej organizacji, adres listy dyskusyjnej wirtualnej organizacji zwracany wynik: identyfikator wirtualnej organizacji usunięcie wirtualnej organizacji cel: usunięcie niepotrzebnej wirtualnej organizacji z systemu zarządzania parametry wejściowe: identyfikator wirtualnej organizacji zwracany wynik: sukces, porażka zmiana atrybutów wirtualnej organizacji cel: modyfikacja niektórych atrybutów wirtualnej organizacji parametry wejściowe: identyfikator wirtualnej organizacji, atrybuty do zmiany zwracany wynik: sukces, porażka dodanie użytkownika do wirtualnej organizacji cel: dodanie użytkownika do wirtualnej organizacji oraz do wszystkich projektów i list dyskusyjnych, do których wirtualna organizacja należy parametry wejściowe: identyfikator użytkownika, identyfikator wirtualnej organizacji