Mechanizmów pozwalających na rozpraszanie informacji przy zachowaniu centralnego zarządzania wciąż przybywa, przy czym nie są to wyłącznie rozproszone systemy plików.

Przechowywanie danych na lokalnych dyskach komputerów nie jest najlepszym sposobem na zapewnienie im bezpieczeństwa i bynajmniej nie obniża kosztów obsługi informatycznej firmy. Cóż jednak zrobić, skoro rosnący odsetek pracowników korzysta z notebooków, pojawiając się w firmie sporadycznie? Różnie się takie problemy obchodzi, nie ulega jednak wątpliwości, że firmy cały czas dążą do utrzymania możliwie jak największej centralizacji - przynajmniej w odniesieniu do danych biznesowo istotnych.

Centralizacja, choć z pewnością słuszna, ma jednak swoją cenę. Dyski twarde są urządzeniami zawodnymi, co trzeba uwzględnić również przy projektowaniu scentralizowanych systemów do przechowywania danych. Powstają w ten sposób koszty, będące wypadkową faktu intensywnego wykorzystania dysków (wydajne i trwałe dyski), zapotrzebowania na wydajność (mechanizmy RAID) z potrzebą nadmiarowości wynikającą z tendencji do wykonywania coraz większej liczby kopii na potrzeby rosnącej liczby aplikacji (coraz liczniejsze kopie migawkowe).

Nie można też nie zauważyć, że od pewnej skali koszty centralizacji rosną lawinowo, co wiąże się z zakupem rozwiązań praktycznie unikalnych, które potrafi skonfigurować wąska grupa specjalistów. Rośnie też komplikacja środowiska i związane z tym koszty operacyjne. Z tego powodu mamy właśnie do czynienia ze zmianą trendów: odejściem od centralizacji fizycznej na rzecz centralnego zarządzania przy założeniu rozproszenia fizycznego zasobów.

Trochę historii

Najpopularniejszym sposobem przechowywania danych są serwery plików, czyli architektura Network Attached Storage (NAS). Dostępne rozwiązania dzielą się na systemy przenośne oraz zintegrowane rozwiązania sprzętowo-programowe. Historia tej architektury sięga 1983 r., kiedy to Novell wprowadził na rynek system NetWare z protokołem NCP. Rok później pojawiła się pierwsza wersja systemu plików NFS autorstwa Sun Microsystems. Oba opierały się na wywołaniach RPC, będących żądaniami wskazania nagłówków plików przechowywanych w sieci, NFS był znacznie bardziej skalowalny. NFS wciąż jest popularny, jednak głównie w rozwiązaniach z najwyższej półki i klasy średniej. Popularne rozwiązania NAS implementują Common Internet File System (CIFS) Microsoftu (zwykle w formie OEM-owych wersji Windows Storage Server 2003) lub Linuxowy protokół Samba. Jedynym poważnym wyjątkiem jest Network Appliance, którego systemy plików nie opierają się wewnętrznie ani na CIFS, ani na Sambie, choć "zewnętrznie" implementują i udostępniają zgodne z nimi usługi. Z punktu widzenia użytkownika NAS to po prostu pudełko podłączane do sieci, które po szybkiej konfiguracji może służyć do zapisywania plików.

Repozytoriami plików stają się współcześnie także rozwiązania wywodzące się z zupełnie innych technologii, działające zwykle w wyższej warstwie, np. rozwiązania portalowe, w których lokalizacja pliku to URI/URL na serwerze WWW. Podobnie teoretycznie można by użyć WebDav (rozszerzenia serwera HTTP). Z punktu widzenia użytkownika nie jest istotne, gdzie fizycznie portal zapisze plik.

Zastosowanie rozwiązań portalowych ma tę zaletę, że są one bardzo skalowalne i łatwo można za ich pomocą osiągnąć wysoką niezawodność. Na tym poziomie łatwo można zorganizować inne usługi "wokół" plików, jak: indeksowanie i przeszukiwanie treści, kategoryzację, reguły biznesowe itp. To coś znacznie bardziej wartościowego biznesowo niż proste zapisanie pliku przez pakiet biurowy.

Takie zabiegi są możliwe dzięki temu, że standardowe API systemu operacyjnego może być rozszerzane o interfejsy implementujące praktycznie dowolne repozytorium. Przykładem może być GmailFS - program, który w komputerze udostępniał załączniki do listów przechowywanych w serwisie Gmail jako dysk sieciowy.

Wróćmy jednak do wątku rozpraszania informacji. Na bazie CIFS Microsoft zbudował nową warstwę logiki, którą nazwał Distributed File Services (DFS). Pozwala ona definiować wirtualne drzewo wirtualnych folderów sieciowych i każdemu z nich przyporządkowywać jeden lub więcej fizycznych serwerów plików. Klient DFS łączy się z serwerem DFS, który jest de facto serwerem przestrzeni nazw, przekierowującym żądania do właściwych serwerów NAS fizycznie przechowujących dane. Użytkownik zapisuje plik, posługując się spójną przestrzenią nazw, a niezależna od niego infrastruktura decyduje, gdzie dane mają być fizycznie umieszczone.

Za pomocą Active Directory można określić topologię replikacji informacji pomiędzy redundantnymi "lokalizacjami" każdego wirtualnego foldera. W takim przypadku mogą pojawić się konflikty - usługi DFS korzystają z tzw. replikacji multi-master (w przypadku kłopotów powstaje np. nowy plik ze stosownym przyrostkiem w nazwie). Można też zdefiniować zasady rozdziału obciążenia, wybierając opcję naprzemienną (round robin) albo według bardziej skomplikowanych zasad, np. różnie dla różnych działów biznesowych.

Wysoka abstrakcja

Zarządzanie rozpraszaniem plików w warstwie wysokiej abstrakcji nie zawsze jest wygodne. W szczególności wtedy, gdy stawką jest wydajność przetwarzania ogromnych ilości danych. Z takiego założenia wyszli twórcy architektury Storage Area Network (SAN). W sieciach SAN dyski przechowujące dane znajdują się poza serwerem i komunikują się specjalnymi protokołami z urządzeniami NAS. Obecnie najczęściej jest tak, że architektura NAS jest niejako oknem sieci SAN na świat serwerów, aplikacji i użytkowników. W sieci SAN odbywa się ruch techniczny, zaś warstwa NAS to jedynie warstwa dostępowa.

W sieciach SAN serwer, a dokładnie karta o określonym adresie logicznym World Wide Name (WWN) żąda danych od innego urządzenia z kartą o innym logicznym numerze WWN. Współcześnie urządzenia WWN mogą być bytami wirtualnymi, najczęściej są to jednak urządzenia Fibre Channel, czyli de facto serial SCSI. Ponieważ Fibre Channel target to dysk, można w nim zdefiniować partycję dla bazy danych, a więc coś, co w rozwiązaniach NAS jest trudne lub niemożliwe.

Z uwagi na cenę rozwiązania Fibre Channel powstały także inne mechanizmy komunikacji z urządzeniami. Dużą popularność zyskał iSCSI zatwierdzony jako standard przez IETF w 2003 r. W takim rozwiązaniu polecenia SCSI są przesyłane w sieci TCP/IP. Dzięki temu można wykorzystać istniejące rozwiązania sieciowe do podłączenia zdalnego dysku. W porównaniu z FC jest to wolniejsze (narzut ok. 40 bajtów na żądanie). Realnie jednak, ponieważ gros ruchu iSCSI odbywa się w sieci lokalnej (ewentualnie jest to replikacja w dedykowanej sieci WAN), problemy raczej nie występują.

Fibre Channel nie jest technologią dobrą do rozpraszania danych, choćby ze względu na założoną komunikację punkt-punkt (między FC initiator i FC target). Do rozpraszania potrzeba tak naprawdę warstwy wirtualizacyjnej, a więc przełączników z odpowiednim oprogramowaniem. To samo dotyczy iSCSI, choć już w mniejszym stopniu, ponieważ ruch iSCSI można stosunkowo łatwo zwielokrotnić w warstwie przełączników/routerów.

Rozproszone pojemniki

W różnych firmach i na uniwersytetach trwają prace nad wykorzystaniem do przenoszenia danych blokowych w ramkach Ethernet, bez narzutu protokołów wyższego rzędu. Są też rozwiązania oparte na IP, lecz nie wykorzystujące narzutu, jak np. opracowane przez firmę Zetera rozwiązanie Storage over IP (SoIP), które zapewnia wirtualizację urządzeń bez dodatkowych agregatorów czy specjalizowanych kontrolerów.

W rozwiązaniu Zetera fizyczny dysk przypisywany jest do partycji i adresu IP. Można nawet budować RAID bez "fizycznych" urządzeń tego typu - łącząc odpowiednie adresy IP. Wykorzystywany jest mechanizm UDP z własnymi mechanizmami gwarantowanego dostarczenia. Warto też wspomnieć, że powstało rozwiązanie ATA over Ethernet przeznaczone do komunikacji z urządzeniami IDE. Na razie tylko jedna firma wspiera to rozwiązanie (Rocket Division Software).

Ciekawe efekty można uzyskać także stosując rozproszone "pojemniki", gdzie dane fizycznie umieszczone są w różnych miejscach sieci. Ciekawym, choć akademickim konceptem (nie rozwiązaniem, ponieważ nie istnieje na razie nawet wersja 1.0 implementacji) rozproszonego pojemnika na dane jest sieć Freenet. Jest to "dysk" działający w trybie peer-to-peer, gdzie każdy węzeł może zarówno zapisywać informacje do sieci, jak i służy za pojemnik dla innych użytkowników. Algorytm bazuje na routingu opartym na unikalnym kluczu jednoznacznie identyfikującym plik.

Celem koncepcji Freenet jest nie tyle zapewnienie niezawodności czy dużej skalowalności, tylko wysokiej anonimowości użytkowników. Nawet w porównaniu z innymi sieciami P2P jest to rozwiązanie raczej mało wydajne. Można je jednak traktować jako wielkie, i (z pewnym prawdopodobieństwem) niezawodne medium przechowywania informacji.

Gdy już mowa o P2P, warto zastanowić się nad zaprojektowanym przez Brama Cohena mechanizmem dystrybucji plików mechanizmem BitTorrent. Pierwsza implementacja protokół zakładała, że dostępny jest specjalny tzw. tracker, czyli serwer, który "pilnuje" klientów sieci i gromadzi informacje o tym kto wysyła i pobiera dane. Tracker nie przechowuje informacji o pliku, tylko pewne sumy kontrolne. Jest też odpowiedzialny za równoważenie obciążeń, w sensie zachowania proporcji między zapisami a odczytami. Przygotowanie pliku do dystrybucji polega na podzieleniu go na części i wygenerowaniu pliku indeksu (.torrent). Użytkownicy wymieniają się takim częściami - aż pobiorą pełny plik.

Powstało także rozszerzenie BitTorrent wykorzystujące odmianę algorytmów należących do grupy DHT (Distributed Hash Table), gdzie tracker nie jest potrzebny. Najczęściej wykorzystywany jest protokół Kademlia. W takim schemacie każdy klient jest de facto "lekkim" trackerem. Obecnie trwają prace nad PEX (peer exchange), rozszerzeniu protokołu pozwalającym wymieniać informację o znanych węzłach.

Ciekawostką jest fakt, że Microsoft Research opracował własny mechanizm przypominający BitTorrent o nazwie Avalanche. On także dzieli plik na porcje i każdy uczestnik ruchu może wysyłać swoją porcję do wielu odbiorców. Avalanche stosuje pewną nadmiarowość, tzn. pozwala na istnienie węzłów, które "odtworzą" brakujące kawałki plików, coś na kształt RAID w sieci. To rozwiązanie ma za zadanie obejść podstawowy problem sieci opartych na protokole BitTorrent, czyli brak w sieci choćby jednej pełnej kopii pliku.

W Avalanche każdy użytkownik koduje informacje jakie już posiada i je dystrybuuje do innych. W ten sposób wybierając odpowiednią funkcję kombinatoryczną (i jej parametry) można unikać opóźnień (czy potencjalnego "braku") źródła danego pliku. Gdy odbiorca otrzyma daną porcję może na jej podstawie pobrać to, co jest mu potrzebne. Dla porównania, BitTorrent czeka, aż otrzyma odpowiednią porcję wynikającą z wstępnego podziału pliku dokonanego przy tworzeniu indeksu. W ten sposób powstają obecnie zręby nowego medium dystrybucji plików, które być może z biegiem czasu znajdą zastosowanie w przy replikacji.