Grid computing, czyli nowe spojrzenie na rozproszone bazy danych Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl

Cześć I Trochę o grid computing Trochę o rozproszonych lub federacyjnych bazach danych

Jak widzą grid dziennikarze... Kasia z księgowości używa komputera od 8 do 16, potem idzie do domu. Tomasz z laboratorium w tej samej firmie po nocach ślęczy przed komputerem, czekając na wynik skomplikowanych obliczeń. Niedługo Tomasz będzie mógł pracować szybciej - bo po godzinach wykorzysta komputer Kasi. I wszystkie inne, które stoją bezczynnie. Jakie to proste! Że też nikt wcześniej na to nie wpadł!

Trochę mniej optymizmu... Dla większości zadań obliczeniowych nie istnieją lub nie są znane metody dekompozycji na pod-zadania wykonywane równolegle. Dla zadań typu data intensive rozproszenie obliczeń implikuje konieczność rozproszenia danych. Tomasz będzie musiał trzymać ogromne dane na komputerze Kasi, inaczej nie będzie mógł nic policzyć. Rozproszenie danych i usług musi stać się elementem procesu projektowego, który wyklucza rozpraszanie ad hoc, na podstawie dynamicznie pojawiających się mocy obliczeniowych. Równie problematyczne jest przeniesienie trwających już obliczeń na inny komputer (kiedy Kasia wróci do pracy, a Tomasz jeszcze nie skończy).

Jak widzą grid specjaliści.... ... ma docelowo pozwalać na samokonfigurację czy samonaprawę systemu (...) - Na razie tego typu oprogramowanie jest w początkowej fazie rozwoju - przyznaje Paweł Sypiański, IBM. Koszt przekształcenia danych w formę pozwalającą na przetwarzanie rozproszone byłby zbyt duży - uważa Tomasz Kulisiewicz. Koszty programów do przetwarzania siatkowego są zbyt wysokie - uważa dr Norbert Meyer, kierownik działu komputerów dużej mocy poznańskiego PCSS. Obecnie wiele inicjatyw zmierza do stworzenia gridów, wśród nich Open Grid Service Architecture (OGSA) bazująca na Web Services, zmierzająca do stworzenia infrastruktury (OGSI) dla Grid Services. (www.ggf.org) Koncepcja zdaje się rozszerzać (niepewny) sukces OMG CORBA. Wynik – moim zdaniem jeszcze mniej pewny, poczekamy, zobaczymy.

Dlaczego grid? Grid computing jest nową wersją starego marzenia o masowej równoległości przetwarzania. Marzenie to miało wiele materializacji, większość nieudanych. Chyba największą klapę można przypisać japończykom i ich projektowi 5-tej generacji komputerów (1982-1992) – 3 miliardy dolarów utopione w „programowanie w logice” i inne akademickie utopie. Termin „grid”, nawiązujący do ustawienia komputerów w siatkę (klaster), sam niczego nie posuwa do przodu. Nowy termin wzbudza jednak nowe nadzieje i nowe środki przeznaczone na realizację starego marzenia. Wiele firm i zespołów badawczych skorzysta z tych środków. Jest to jeden z najlepszych sposobów pozyskiwania pieniędzy. Temat jest nieustannie fascynujący.

Równoległe przetwarzanie Nowy poziom technologiczny w dużym stopniu już tę równoległość zapewnia: Rozproszone lub federacyjne bazy danych (np. Oracle10G). Oprogramowanie komponentowe: CORBA, DCOM, .NET, EJB, RMI, J2EE+WebServices. Sieci P2P (peer-to-peer), czyli korzystanie z zasobów udostępnianych przez poszczególnych uczestników sieci dla całej społeczności sieci. Web Services, tj. utylizacja usług dostarczanych przez odlegle serwery na gruncie standardu XML. Technologie agentowe, czyli mobilni geograficznie niewolnicy wykonujące pracę na rzecz swojego mistrza. W tym referacie (nietypowo) skupimy uwagę na podejściach nawiązujących do koncepcji baz danych.

Krótka ocena Największe znaczenie mają rozproszone bazy danych, oprogramowanie komponentowe i P2P. Mój lekki sceptycyzm dotyczy Web Services (mimo licznych potencjalnych zastosowań). Ubogość koncepcji spowoduje, że będzie ona rosnąć na zasadzie piramidy postawionej na czubku. Mogą być użyte/przykryte przez bardziej „konceptualne” protokoły. Niejasny (naiwny?) stosunek do heterogeniczności. Mój spory sceptycyzm dotyczy agentów. Poza antropomorfizmami lub pobożnymi życzeniami tam na razie zbyt wiele nie ma. Brak kluczowych aplikacji (killer applications) pokazujących techniczny lub biznesowy sens pomysłu. Nadzieje w technologii workflow – ale czy uzasadnione?

Cztery najważniejsze problemy Przezroczystość (transparency): traktowanie rozproszonych zasobów i usług tak, jak gdyby były one wewnątrz przestrzeni adresowej jednego komputera. Bezpieczeństwo: przeciwdziałanie losowym awariom oraz możliwościom ataku z zewnętrz. Interoperacyjność (interoperability): umożliwienie współpracy heterogenicznych platform, aplikacji, logik biznesowych i organizacji danych. Efektywność: uzyskanie czasów przetwarzania akceptowalnych dla szerokiego kręgu użytkowników rozproszonych aplikacji.

Przezroczystość Redukcja złożoności przy pracy z rozproszonymi zasobami danych i usług, polegająca na uwolnieniu programisty od myślenia na temat położenia i organizacji rozproszonych danych. Przezroczystość ma bezpośrednie skutki dla czasu i kosztu wytworzenia rozproszonej aplikacji, jej przenaszalności i pielęgnacyjności.

Formy przezroczystości (1) Przezroczystość położenia i dostępu: Uwolnienie użytkowników od konieczności korzystania z informacji o aktualnym położeniu geograficznym danych i usług. Przezroczystość współbieżności: Umożliwienie wielu użytkownikom jednoczesnego dostępu do danych i usług. Przezroczystość skalowania: Umożliwienie dodawania lub usuwania serwerów, danych i usług bez wpływu na działanie aplikacji i pracę użytkowników. Przezroczystość fragmentacji (podziału): automatyczne scalanie obiektów lub kolekcji, których fragmenty są przechowywane w różnych miejscach.

Formy przezroczystości (2) Przezroczystość replikacji: Umożliwienie tworzenia i usuwania kopii danych w innych miejscach geograficznych ze skutkiem dla efektywności przetwarzania. Przezroczystość awarii: Umożliwienie nieprzerwanej pracy większości użytkowników rozproszonej bazy danych w sytuacji, gdy niektóre z jej węzłów lub linie komunikacyjne uległy awarii. Przezroczystość migracji: Umożliwienie przenoszenia zasobów danych do innych miejsc bez wpływu na pracę użytkowników.

Czy przezroczystość jest osiągalna? Zapewnienie wszystkich form przezroczystości jest dużym wyzwaniem technicznym. Wiele form przezroczystość jest zrealizowana w ramach technologii CORBA. Przezroczystość położenia danych, współbieżności i fragmentacji jest zrealizowana w rozproszonych BD. Przezroczystość jest podstawą funkcjonowania sieci P2P. Przezroczystość jest tematem (prawie) nieobecnym w Web Services i .NET. Wkrótce będzie... Przezroczystość wymaga ustalenia standardów: API dostępu do danych i usług, kanonicznych modeli danych i usług, oraz odpowiednich protokołów komunikacyjnych.

Interoperacyjność Temat mniej istotny przy budowie gridu metodą top-down (nowy projekt od zera) i zakładającego jednorodną platformę implementacyjną. Krytyczny problem dla projektu bottom-up, czyli systemu integrującego istniejące (spadkowe) niekompatybilne (heterogeniczne) dane i usługi. Interoperacyjność na poziomie transportu (transport-level interoperability) jako podstawa wyższych form interoperacyjności. Chodzi o umożliwienie fizycznej komunikacji pomiędzy danymi i usługami, np. na gruncie TCP/IP, HTTP, wspólnej pamięci, itp.

Interoperacyjność kontra przezroczystość Konieczność poszukiwania „wspólnego mianownika”: Jeżeli serwery porównamy do mianowników 4, 6 i 12, to wspólnym mianownikiem jest 12, czyli programista ma łatwo. Jeżeli porównamy do mianowników 7, 11 i 13, to wspólnym mianownikiem jest 1001, czyli programista ma trudniej. Ta analogia ilustruje problem heterogeniczności: Łatwo: Dla danej populacji serwerów istnieje prosty model kanoniczny; musimy wtedy napisać wrappery i problem jest rozwiązany. Na tym założeniu opiera się CORBA. Trudno: Jeżeli rozbieżności pomiędzy serwerami są duże, to informacja o zawartości poszczególnych serwerów musi być doprowadzona do świadomości programisty i do modelu kanonicznego. Jest on wtedy złożony i nieprzezroczysty.

Fragmentacja Najpopularniejszym modelem jest fragmentacja pozioma, oznaczająca, że każdy serwer ma ten sam schemat danych, ale inną populację danych. Sumowanie zbiorów danych w taki sposób, że informacja o serwerach jest zbędna dla programisty/użytkownika. Fragmentacja pionowa: podział obiektów na fragmenty przechowywane w różnych miejscach. Musi być zapewniony sposób „sklejenia” całości obiektu z fragmentów (np. NIP dla obywateli RP). Przy integracji zasobów heterogenicznych mogą pojawiać się wyrafinowane kombinacje fragmentacji poziomej, pionowej i replikacji (redundancji).

Przykład fragmentacji poziomej Radom Klasa Pracownik Obiekty Pracownik są przechowywane zgodnie z geograficznym położeniem pracodawcy. Pracownik Nowak Pracownik Kowalski ... Sieć Kalisz Pracownik Styka Malina ... Klasa Pracownik Kielce Klasa Pracownik Pracownik Malasa Pracownik Zagórny. ...

Przykład fragmentacji pionowej Radom Klasa danych osobistych Nowak dane osobiste Kowalski ... Sieć Kalisz Klasa danych o ocenach Nowak dane o ocenach Kowalski ... Kielce Klasa danych o zatrudnieniu Nowak dane o zatrud. Kowalski ...

Replikacje Replikacja jest kopią danych i usług na innym serwerze. Replikacje mają na celu zwiększenie dostępności danych i usług oraz ich ochronę przed zniszczeniem. Przy integracji bottom-up replikacje (= redundancje) są często cechą nieuchronną i niepożądaną. Może występować redundancja danych o dowolnym stopniu skomplikowania. Grid musi wykorzystać pożądane replikacje i mitygować niepożądane redundancje. Replikacje i redundancje stanowią poważny problem dla przezroczystości i operacji aktualizacji danych.

Osłony,mediatory, perspektywy Pojęcia oznaczające moduły oprogramowania, których celem jest wirtualne sprowadzenie danych i usług do „wspólnego mianownika”. Osłona (wrapper): w wiekszości bezstanowe (funkcyjne) odwzorowanie API1 na API2. Mediator: podobny do osłony, ale bardziej „inteligentny”. Np. może agregować dane lub wnioskować o podobieństwie danych. Perspektywa (view): odwzorowanie obiektów zapamiętanych na obiekty wirtualne, bez ograniczeń koncepcyjnych lub obliczeniowych. Porównanie perspektywy i mediatora: Perspektywa jest napisana w języku zapytań Perspektywa jest własnością bazy danych, a nie aplikacji Perspektywa jest bytem programistycznym pierwszej kategorii Perspektywa zakłada pewien kanoniczny model danych (np.obiektowy)

Aktualizowalne perspektywy Celem jest doprowadzenie do pełnej przezroczystości, przy której obiekty wirtualne są nieodróżnialne od obiektów zapamiętanych. Problem, znany od 1974 roku, zaowocował w wiele nieudanych pomysłów i pseudo-rozwiązań. Rozwiązaniem problemu są relacyjne perspektywy oparte na trygerze instead of. Nasze rozwiązanie jest znacznie bardziej uniwersalne i opiera się o procedury dynamicznie przeciążające operatory aktualizujące obiekty wirtualne (prace H.Kozankiewicz i innych). Aktualizowalne perspektywy będą podstawą objaśnionej dalej koncepcji.

Cześć II Architektura Przykłady ilustrujące podejście Dyskusja nad kierunkami działań Motyw naczelny podejścia: Najpierw opanujmy koncepcję od strony jej uniwersalności. Potem zabierzmy się za optymalizację i specjalizację dla szczególnych przypadków. Odwrotna kolejność nieodmiennie prowadzi do koncepcyjnych przepaści.

Architektura gridu ... ... Organizator gridu Klient globalny 1 Schemat globalny Globalny wirtualny skład obiektów i usług Aktualizowalne perspektywy Protokół komunikacyjny Organizator gridu Schemat lokalny A Schemat lokalny B Skład lokalnych obiektów i usług Serwer lokalny A Skład lokalnych obiektów i usług Serwer lokalny B Informacja kontrybucyjna ...

Objaśnienie architektury (1) Linie ciągłe grube: związki między oprogramowaniem w run-time (zapytania, zlecenia, odpowiedzi). Linie i strzałki przerywane: związki definicyjne (podczas tworzenia oprogramowania). Klient globalny: program aplikacyjny wykorzystujący globalny wirtualny skład. Globalny wirtualny skład obiektów i usług: skład, do którego adresowane są zapytania i zlecenia ze strony klienta globalnego; w rzeczywistości nie istnieje. Schemat globalny: definicje obiektów i usług wirtualnych wykorzystywane (głównie) przez programistów podczas tworzenia klientów globalnych.

Objaśnienie architektury (2) Aktualizowalne perspektywy: oprogramowanie, którego celem jest wytworzenie globalnego wirtualnego składu. Protokół komunikacyjny: zestaw funkcji działających na odległych serwerach używanych do definicji perspektyw. Organizator gridu: osoba, zespół osób lub program definiujący perspektywy na podstawie schematów lokalnych, sch.globalnego i i informacji kontrybucyjnej. Schemat lokalny: informacja katalogowa o obiektach i usługach udostępnianych przez serwer lokalny (IDL, WSDL, ODL, ...) Serwer lokalny: jednostka sprzętowa/programowa identyfikowana przez system rozproszony.

Informacja kontrybucyjna Określa w jaki sposób poszczególne serwery kontrybuują do globalnego wirtualnego składu obiektów. Określa redundancje w danych trzymanych na poszczególnych serwerach. Określa replikacje. Określa sposoby aktualizacji danych. Określa zależności pomiędzy poszczególnymi serwerami. Jest podstawą definicji odpowiednich perspektyw.

Przykład: fragmentacja pozioma Prac NIP Nazwisko Zar Stan Schemat globalny: Informacja kontrybucyjna: Jednoznacznym identyfikatorem pracowników jest NIP. Nie występują powtórzenia NIPu w lokalnych bazach danych. Globalna baza danych jest wirtualną sumą lokalnych baz danych. Schematy lokalne: Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Kalisz Radom Kielce

Zabieg formalny (w modelu M0) Dane lokalnego serwera będziemy uważać za pojedynczy obiekt. Nazwę lokalnego serwera będziemy uważać za nazwę tego obiektu. Nazwie tej odpowiada identyfikator fizyczny serwera, np. adres IP lub URI. Perspektywy będziemy konstruować w taki sposób, jakby wszystkie obiekty lokalnych serwerów były w naszej przestrzeni adresowej. Perspektywy będą odwoływać się do nazw serwerów, ale powstałe w ich wyniku obiekty wirtualne nie będą miały takich odwołań.

Lokalna baza danych w tej konwencji Prac NIP Nazwisko Zar Stan Radom Nazwisko: ”Nowak” Prac NIP: 4556435643 Zar: 3000 Stan: ”radca” Nazwisko: ”Bilski” NIP: 9324596336 Zar: 4000 Stan: ”referent” Nazwisko: ”Kolski” NIP: 2343432567 Zar: 2000 Stan: ”asystent”

Integrująca perspektywa create view MoiPracDef { virtual objects MoiPrac { return ((Kalisz as m) join (m.Prac as p))  (((Radom as m) join (m.Prac as p))  (((Kielce as m) join (m.Prac as p)) } on_retrieve do { connect (m); return p.(deref(NIP) as NIP, deref(Nazwisko) as Nazwisko, deref(Zar) as Zar, deref(Stan) as Stan) }; on_delete do { connect (m); remoteDelete (p) }; ... Ewentualnie dalsze części definicji perspektywy... } Ziarno obiektów wirtualnych ma postać dwóch binderów: struct{ m(adres serwera), p(OID obiektu na tym serwerze)} Nazwy Kalisz, Radom i Kielce są niewidoczne dla klientów; posługują się oni tylko nazwą MoiPrac i nazwami atrybutów, np. (MoiPrac where Nazwisko = ”Kolski”).NIP

Przykład: fragmentacja pozioma z replikacją Schemat globalny: Prac NIP Nazwisko Zar Stan Informacja kontrybucyjna: .... jak poprzednio.... Radom i Kielce zawierają te same dane. Użytkownik powinien używać tej repliki, do której ma szybszy dostęp. Aktualizacja danych w Radomiu spowoduje tę samą aktualizację danych w Kielcach. Użytkownik nie może aktualizować danych w Kielcach. Schematy lokalne: Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Kalisz Radom Kielce

Integrująca perspektywa create view MoiPracDef { virtual objects MoiPrac { int czasDoRadomia := 1000000; int czasDoKielc := 1000000; if alive(Radom) then czasDoRadomia := checkAccessTime(Radom); if alive(Kielce) then czasDoKielc := checkAccessTime(Kielce); if min(bag(czasDoRadomia, czasDoKielc)) > 100 then { exception(CzasRealizacjiJestNieakceptowalny); return ;} return ((Kalisz as m) join (m.Prac as p))  if czasDoRadomia < czasDoKielc then ((Radom as m) join (m.Prac as p)) else ((Kielce as m) join (m.Prac as p)) } on_retrieve do { ...jak poprzednio... }; on_delete do { if serverName(m) = ”Kielce” then { connect(Radom); remoteDelete (Prac where NIP = (p.NIP))} else { connect (m); remoteDelete (p) } } } alive, checkAccessTime, serverName, connect, remoteDelete, ... – funkcje protokołu

Przykład: fragmentacja pozioma, pionowa, heterogeniczność, replikacje, redundancje Informacja kontrybucyjna: Jednoznacznym identyfikatorem pracowników jest NIP. Nazwisko jest zależne od NIP; Kielce ma niepełną replikę bazy danych w Radomiu; obie dotyczą pracowników z Radomia i Kielc. Aktualizacja danych w Radomiu spowoduje tę samą aktualizację danych w Kielcach, z wyjątkiem danej Zar. Użytkownik nie może aktualizować danych w Kielcach. Kalisz ma dane tylko o pracownikach z Kalisza. Olsztyn ma informację o wszystkich pracownikach z Olsztyna i Kalisza, przy czym nie ma tam Nazwiska i Zar, za to jest Stan i ZarNetto. Schemat globalny: Prac NIP Nazwisko[0..1] Stan Wiek[0..1]] ZarNetto Schematy lokalne: Prac NIP Nazwisko Zar DataUr Prac NIP Nazwisko Stan Zar Prac NIP Nazwisko Stan Prac NIP Stan DataUr ZarNetto Kalisz Radom Kielce Olsztyn

Perspektywa integrująca Dla przypadku z poprzedniego slajdu definicja perspektywy będzie znacznie dłuższa. Będzie wymagać rozstrzygnięcia wszystkich redundancji, replikacji, ujednolicenia informacji w różnych formatach (Wiek/RokUr) i różnych znaczeniach biznesowych (Zar/ZarNetto), sprawdzania czasów dostępu, możliwości aktualizacji, itd. Niemniej przy założeniu uniwersalności SBQL, uniwersalności środków definicji perspektywy oraz uniwersalności funkcji protokołu dostępu do odległych serwerów można będzie ją napisać.

Problemy do rozwiązania (1) Zaimplementowanie aktualizowalnych perspektyw. Ustalenie i zaimplementowanie zestawu funkcji protokołu komunikacyjnego, które są niezbędne dla definicji perspektyw. Opracowanie precyzyjnego języka informacji kontrybucyjnej (termin jest ad hoc). Pełna formalizacja tego języka, wraz z formalizacją globalnego i lokalnych schematów, umożliwiłaby automatyczną generację perspektyw. Przypisania informacji kontrybucyjnej do pojedynczych serwerów i automatyczne uzupełnianie perspektyw na jej podstawie stworzyłoby coś w rodzaju szyny CORBA lub sieci P2P. Opracowanie systemu rejestracji danych i usług (trading service, UDDI, ...)

Problemy do rozwiązania (2) Optymalizacje W przedstawionej koncepcji całość przetwarzania zapytań jest po stronie klienta. Trzeba to przetwarzanie przesunąć na stronę serwera, np. poprzez przesłanie tam odpowiednich części stosów i (pod-) zapytań. Obecna koncepcja nie zakłada równoległości przetwarzania. Przesunięcie przetwarzania na stronę serwera i analiza postaci zapytania stwarzają szansę na równoległość (jest to dość łatwe dla fragmentacji poziomej, trudniejsze w ogólnym przypadku). Dekompozycja zapytań przy fragmentacji pionowej. Wykorzystanie scenariuszy dynamicznych, w których wynik przetwarzania na jednym serwerze jest wykorzystany do optymalizacji przetwarzania na innym serwerze. Obiekty i usługi „proxy” ulokowane wewnątrz perspektywy. Przezroczyste indeksy zasobów globalnych wykorzystywane automatycznie przez klientów i/lub perspektywy. ..... wiele innych optymalizacji...

Cześć III Wprowadzenie do P2P Materiał pochodzi z: http://www.networld.pl/artykuly/21614.html

Geneza Peer-to-peer pojawiło się na pierwszych stronach gazet w związku z kontrowersjami wokół internetowych serwisów wymiany plików (głównie muzycznych) i sprawą ochrony praw autorskich. W cieniu Napstera pozostają tworzone dla użytkowników korporacyjnych narzędzia oparte na technice komputerów równorzędnych. Zdaniem niektórych analityków peer-to-peer może wiele zmienić, tak jak zrobiły to pecety w latach 80-tych, czy Web w latach 90 Takie prognozy napotykają jednak na sceptycyzm specjalistów IT, którzy uważają sieci peer-to-peer za mało bezpieczne, nieskalowalne i trudne w zarządzaniu.

Stary pomysł, nowe możliwości Peer-to-Peer (P2P) w Internecie to nie jest nowy pomysł. P2P to również np. poczta komputerowa lub sieci IRC. P2P nie rozpowszechniło się jednak wcześniej ze względu na ograniczone możliwości techniczne. Pojawienie się narzędzi katalogowych, takich jak Lightweight Directory Access Protocol (LDAP), moc przetwarzania, przepustowość sieci i pojemność pamięci masowych, zarządzanie połączeniami stworzyły bazę techniczną.

P2P w biznesie P2P zyskało potężnych sojuszników. Sun promuje P2P przez projekt JXTA. Ma on umożliwić współpracę na zasadach równorzędnych platformom komputerowym wszystkich typów i rozmiarów. Intel utworzył organizację Peer-to-peer Working Group mającą opracowywać standardy. Do organizacji należą, obok mniejszych producentów oprogramowania, także HP i IBM. Firma chwali się, że zaoszczędziła w ciągu 10 lat 500 mln USD wykorzystując przy projektowaniu układów scalonych oparte na technice P2P rozwiązanie Netbatch .

Dwa modele peer-to-peer

Model JXTA

Budowa wirtualnego superkomputera Najbardziej spektakularne zastosowania sieci P2P polegają na wykorzystywaniu wolnych zasobów w komputerach PC i skumulowaniu ich w jeden wirtualny superkomputer. Taka platforma może obsługiwać potężne aplikacje, które da się prowadzić równoległymi wątkami, po podzieleniu ich na małe kawałki i rozdzieleniu na pojedyncze maszyny. Z zastrzeżeniami co do możliwości dekompozycji niektórych zadań. Ok. 50% mocy obliczeniowych w firmie jest wolnych, w tym na mocno obciążonych serwerach i hostach. Kiedy weźmiemy pod uwagę tylko komputery personalne, to liczba ta jest dużo wyższa. Jest to motyw dla hasła grid computing, o którym było poprzednio. Przy masowym rozproszeniu danych P2P i grid computing są w istocie tą samą koncepcją.

Dystrybucja treści, współdzielenie plików i współpraca Często jest tak, że interesujące nas materiały znajdują się nie na jednym, ale na wielu komputerach w sieci. W dodatku najczęściej w firmowych sieciach większość plików znajduje się na pecetach, a nie serwerach. Technika p2p może zmienić wszystkie te zasoby pamięci w jedną rozproszoną przestrzeń plików. Przekształca ona firmowy web w bardziej spersonalizowane środowisko, w którym każdy może współdzielić informację na specjalnych warunkach.

Przykład skutecznego zastosowania Brytyjski gigant farmaceutyczny GlaxoSmithKlein jest jedną z pierwszych wielkich firm, które zdecydowały się na wykorzystanie aplikacji p2p ułatwiających współpracę pracowników. Zdecydowano się na oprogramowaniem Groove. Informatycy GlaxoSmithKline, dysponującej ponad 100 tys. stanowisk Lotus Notes, chcieli zbudować dodatkowa platformę współpracy. Zdecydowano się na 10 tys. licencji Groove. W firmie oprogramowanie ma być wykorzystywane przez różne działy. Dział prawny chce przy jego użyciu opiniować i wydawać dokumenty prawne, dział informatyczny chce dzięki niemu stworzyć kontrolowane środowisko do testów oprogramowania, kadra menedżerska chce współdzielić informacje z kontrahentami itp.

P2P w wydaniu Groove Networks

Jak działa Groove Groove ( www.groove.net ) wykorzystuje pocztę elektroniczną lub instant messaging do wystosowania "zaproszenia" dla użytkowników komputerów, by dołączyli do współdzielonej "przestrzeni", składającej się z twardych dysków lokalnych pecetów. Oprogramowanie pozwala użytkownikom komunikować się i współpracować za pomocą głosu, wiadomości tekstowych, podzielonych na wątki dyskusji, narzędzi do edytowania tekstu, rysowania oraz współdzielenia plików. Można pracować także offline - zmiany są automatycznie buforowane, a uaktualnienia są dokonywane w obydwu kierunkach, gdy strony ponownie się łączą.

Inny przykład zastosowania W rządzie federalnym USA dział zajmujący się statystykami zdecydował się na platformę NXT3 firmy NextPage ( www.nextpage.com ), aby połączyć zawartość 60 portali, oddzielnie zarządzanych przez agencje federalne. Zajmująca się rozwiązaniami dla tzw. sieci informacji (Content Networks) firma stworzyła platformę peer-to-peer NXT3, pozwalającą na łączenie zawartości rozproszonych serwerów korporacji. Oprogramowanie pozwala użytkownikom na zaawansowane wyszukiwanie dokumentów na innych komputerach i wirtualną centralizację informacji.

NXT 3 Zamiast fizycznie centralizować zasoby informacji NXT 3 pozwala zarządzać rozproszonymi treściami - użytkownicy widzą je, jakby pochodziły z jednego źródła. Znaczniki XML w połączeniu z HTML i architekturą P2P pozwalają NXT3 ściągać fragmenty rozproszonej zawartości i - konwertując je "w locie" - tworzyć nowe dokumenty.

Charakterystyka NXT 3 Oprogramowanie składa się z siedmiu współpracujących modułów. Content Server odpowiada za dostęp do treści, niezależnie od ich formatu i lokalizacji. Content Syndicator zarządza rozproszonymi treściami. Trzy następne moduły - ODBC Adapter, URLContent Adapter i File System Adapter - odpowiadają za obsługę wielu różnych formatów. Search Engine pozwala na bardzo wyrafinowane definiowanie kryteriów wyszukiwania. Security Services obsługuje uwierzytelnianie, autoryzację i statystyki użytkowników. NXT 3 obsługuje serwery Windows NT, Windows 2000 i Solaris. Produkt nie jest jednak tani - licencja dla 25 użytkowników kosztuje 25 000 USD, dla 250 - 85 000 USD.

Intel i Share and Learn Intel wykorzystuje P2P do swobodnego przepływu rozproszonego materiału wykorzystywanego w szkoleniu pracowników. Dział informatyczny firmy nie chciał, by pracownicy ściągali olbrzymie multimedialne pliki szkoleniowe z centralnego serwera, więc programiści stworzyli aplikację nazwaną Share and Learn i uruchomili ją na każdym desktopie. Kiedy użytkownik kliknie na jednym z wyszczególnionych szkoleń, aplikacja rozpoczyna lokalne przeszukiwanie, stopniowo powiększając krąg poszukiwań. Jeśli jakiś pracownik chce ściągnąć dany materiał, to aplikacja zna najbliższe miejsce, z którego może to zrobić. Dzięki tworzeniu efektywnych pamięci podręcznych na komputerach użytkowników, którzy ściągnęli pliki jako pierwsi, udało im się znacznie ograniczyć obciążenie sieci.

Klasyfikacja P2P

Perspektywy Zdaniem firmy Frost & Sullivan do roku 2007 liczba użytkowników korporacyjnych rozwiązań peer-to-peer wzrośnie z ok. 60 tys. obecnie do 6,2 mln. Wartość tego rynku w tym samym czasie ma osiągnąć 4,53 mld USD, wobec 42,8 mln USD obecnie. Analitycy F&S zwracają uwagę na fakt czynnego zainteresowania wielkich firm, takich jak Sun, technologią peer-to-peer, co powinno zaowocować wzrostem zaufania do opartych na niej rozwiązań.

Problemy z bezpieczeństwem W P2P kwestie zarządzania stają się znacznie trudniejsze, a kwestie prywatności i bezpieczeństwa bardzo się komplikują. Niektórzy analitycy twierdzą, że należy przestać myśleć o ochronie komputerów, a zacząć o ochronie informacji. W przyszłości, gdy miliony użytkowników palmtopów będą miały dostęp do różnego rodzaju informacji, potrzebne będą zapory ogniowe niemal na poziomie poszczególnych dokumentów. Sprawy bezpieczeństwa są podstawowym problemem przy upowszechnianiu się P2P. Wewnątrz firmy i w ekstranecie są różne systemy bezpieczeństwa i trudno zmusić je do współdziałania.

Technologie zapewnienia bezpieczeństwa Standardy bezpieczeństwa, takie jak Kerberos i certyfikaty X.509. Jednak np. dla techniki grid computing, w której rozdziela się zasoby i buduje luźne związki często "w locie", Kerberos jest zbyt scentralizowaną technologią, nie za bardzo skalującą się w środowisku rozproszonym. Podobnie Secure Sockets Layer (SSL) i X.509 nie pozwalają na pojedyncze rejestrowanie się czy delegowanie uprawnień. Grupa zajmująca się w ramach Global Grid Forum bezpieczeństwem zaproponowała standard, który pozwoliłby jednemu użytkownikowi P2P uwierzytelniać innego przez zdalne delegowanie uprawnień. Produkty p2p służące do współpracy, takie jak Groove czy Magi firmy Endeavors Technology ( www.endtech.com ), spełniają wymogi środowiska korporacyjnego przez implementowanie silnego szyfrowania i technik uwierzytelniających - .infrastrukturę klucza publicznego (PKI).

Podsumowanie Stan obecny p2p przypomina początki WWW przed niemal 10 laty. To bardzo wczesne stadium technologii i wiele z rozwiązań teraz stosowanych na pewno nie przetrwa. Niektóre jednak przyjmą się i mogą spowodować duże zmiany. Zasoby internetowe:www.openp2p.com - bardzo rozbudowana strona O'Reilly & Associates, zawierająca m.in. analizy i przykłady rozwiązań p2p. www.p2ptracker.com - wiadomości i dane o p2p, w tym ocena aplikacji. www.peer-to-peerwg.org - m.in. informacje o standaryzacji p2p. www.peerintelligence.com - zastosowanie p2p w biznesie. www.gridforum.org - organizacja zajmująca się grid computing. www.intel.com/eBusiness/products/peertopeer/index.htm - strona Intela o p2p.