3 Przykłady istniejących systemów i oprogramowania

3.1 Wprowadzenie
3.2 Przykłady istniejących systemów
3.3 Dostępne oprogramowanie
3.4 Podsumowanie

3.1 Wprowadzenie

Celem tego rozdziału jest przedstawienie kilku spośród istniejących obecnie systemów składowania danych (punkt 3.2) oraz pobieżny przegląd oprogramowania służącego do zarządzania systemami składowania danych³⁴ (punkt 3.3).

Nie będziemy tu jednakże omawiać wszystkich rozwiązań ani wchodzić w zbytnie szczegóły, ograniczymy się do:

omówienia niektórych systemów składowania danych podobnych do systemu V3, tzn. takich, które zawierają pewne elementy wspólne z systemem V3,
bardzo pobieżnej analizy dostępnego oprogramowania, mającej na celu jedynie jego klasyfikację oraz wyliczenie głównych funkcji przez nie realizowanych.

Spojrzenie na alternatywne systemy pozwoli nam pokazać odmienność i cechy charakterystyczne technologii wykorzystanej w systemie V3, zaś przegląd oprogramowania pozwoli ocenić, jakiego rodzaju funkcjonalność jest użytkownikom potrzebna.

3.2 Przykłady istniejących systemów

3.2.1 Wybór systemów do porównania

System V3 jest produktem dosyć unikatowym, w zasadzie nie ma bezpośredniej konkurencji. Wprawdzie istnieje wiele systemów składowania danych, również takich, które wykorzystują technologię klastrową, ale żaden z nich nie potrafi połączyć jednocześnie pięciu głównych zalet systemu V3:

System udostępnia wirtualne urządzenia poprzez sieć.
System jest rozproszony, i to w taki sposób, że zasoby systemu rozproszone są pomiędzy wiele węzłów, a dokładanie kolejnych elementów (węzłów lub dysków) zwiększa wydajność i/lub pojemność.
Wydajność wirtualnych urządzeń jest prawie równa wydajności fizycznych dysków (oczywiście chodzi tutaj o wydajność możliwą do uzyskania bez wykorzystania sprzętowych lub programowych implementacji RAID, stosowanie organizacji RAID w każdym rodzaju systemów pozwala zwiększyć wydajność).
System udostępnia całość swoich zasobów i funkcjonalność w ramach jednego, spójnego interfejsu.
System wykorzystuje tanią technologię klasy PC i posiada konkurencyjny do tradycyjnych systemów (tzn. z jednym serwerem, nie rozproszonych) systemów współczynnik wydajności do ceny.

Autorowi nie są znane żadne systemy realizujące wszystkie powyższe postulaty. Wiele systemów realizuje dwa pierwsze postulaty, ale kiepska wydajność ogranicza wykorzystanie tych systemów co najwyżej do archiwizacji danych, z pewnością nie do wykorzystania jako alternatywę dla fizycznych dysków. Praktycznie żaden z istniejących systemów nie realizuje trzeciego postulatu łącznie z pierwszym. Jedyne, co dotychczas osiągnięto w tej dziedzinie, to sieci zasobów (SAN), czyli wykorzystywanie dysków połączonych światłowodem. W takich sieciach faktycznie dane są dostępne poprzez sieć (lokalna sieć światłowodowa), wydajność jest doskonała (fizyczna wydajność dysków), system jest niewątpliwie rozproszony (zbiór dysków) i dokładanie kolejnych elementów (dysków) zwiększa pojemność przy nie zmienionej wydajności. Co więcej, możliwe są nawet pewne operacje admnistracyjne, takie jak przenoszenie danych bezpośrednio między dyskami. Ale sieć dysków nie może być traktowana jako spójny system. Każdy z dysków udostępnia własne zasoby, nie potrafi udostępniać zasobów zgromadzonych na innych dyskach. Aby uzyskać dostęp do zasobów, należy skierować żądanie do określonego dysku. Wszystkie funkcje takie jak organizacje RAID, replikacja między dyskami, nie wspominając o dodatkowej inteligencji w rodzaju schowków, wymagają zaangażowania klienta. W praktyce więc sieć zasobów bywa jedynie zapleczem, a prawdziwy interfejs systemu udostępniany jest przez jeden lub więcej tradycyjnych serwerów plików. Rozwiązania takie nie stanowią więc konkurencji lub alternatywy dla systemu V3, który stanowi nową, odrębną kategorię.

Najbardziej charakterystyczną cechą systemu V3 jest to, że przewidziano go jako alternatywę dla dysku lokalnego, możliwą do zastosowania w dowolnych rodzajach systemów. Nie można więc porównywać systemu V3 ani z serwerami plików, ani z wewnętrznymi podsystemami odpowiadającymi za składowanie danych w konkretnych rodzajach serwerów przeznaczonych do konkretnych zastosowań.

Spośród wielu dostępnych produktów wybrano do porównania jedynie te, które spełniają następujące cztery kryteria lub przynajmniej większość z nich (nazwiemy je systemami podobnymi do systemu V3):

wykorzystują tanie podzespoły, sieć komputerów klasy PC ze zwykłą magistralą PCI;
udostępniają dane za pośrednictwem sieci;
udostępniają wspólną, scentralizowaną pulę zasobów oraz umożliwiają scentralizowane zarządzanie całym zbiorem zasobów systemu;
udostępniają jakieś dodatkowe funkcje administracyjne (np. kopia z punktu w czasie, migracja danych itp.) realizowane w obrębie serwera przez węzły robocze bezpośrednio współpracujące ze sobą lub w jakiś inny sposób wykorzystują możliwość współpracy węzłów (międzywęzłowe organizacji RAID itp.).

Wybór kryteriów nie jest przypadkowy, autor brał pod uwagę następujące fakty:

System V3, zbudowany w technologii PC, z oczywistych powodów nie może konkurować z systemami, które wykorzystują drogie, dedykowane komponenty, wydajność tych rozwiązań zawsze będzie wyższa.
Nie można porównywać systemu V3 z rozwiązaniami takimi jak sieć zasobów, gdzie dyski z danymi dostępne są jednocześnie dla wielu węzłów serwera aplikacji. Udostępnianie danych poprzez sieć oraz za pośrednictwem wirtualnego interfejsu zawsze wprowadza dodatkowe opóźnienia i narzut, więc systemy udostępniające dane w taki sposób nie mogą konkurować z wydajnością dysków podłączonych bezpośrednio.
Nie można porównywać systemu klastrowego z systemami scentralizowanymi, gdzie zarówno zarządzanie, jak i realizacja operacji administracyjnych jest dużo prostsze. Nie można również porównywać systemu V3 z systemami, które wprawdzie wykorzystują architekturę wielowęzłową, ale nie potrafią wykorzystać jej w istotny sposób, zmuszając węzły do współpracy. System V3 jest rozproszony, a zarazem jest w spójny sposób zarządzany oraz w istotnym stopniu wykorzystuje fakt rozproszenia, umożliwiając m. in. wymianę danych między węzłami i udostępnianie wolumenów rozproszonych na wielu węzłach.

Systemy podobne do systemu V3, omówione krótko w dalszej części rozdziału, to:

System NetworkDisk firmy o tej samej nazwie, o architekturze rozproszonej, symetrycznej³⁵, w którym węzły robocze, działające w oparciu o Windows NT, mogą udostępniać dane klientom bezpośrednio za pośrednictwem szybkiego interfejsu sieciowego.
System NS2000 firmy Auspex o architekturze scentralizowanej, wykorzystującej jeden centralny serwer główny (ang. host node) zarządzający zbiorem węzłów roboczych (tzw. węzłów wejścia-wyjścia, ang. I/O nodes), przechowujących dane i udostępniających je klientom poprzez sieć. Możliwe jest skalowanie systemu przez dokładanie kolejnych węzłów roboczych, jak również operacje typu kopia z punktu w czasie³⁶ lub migracja danych odbywające się bez udziału węzła głównego (ale przez niego inicjowane i nadzorowane).

Żadne z tych dwóch rozwiązań (ani żadne inne ze znanych autorowi niniejszej pracy) nie umożliwia np. tworzenia wolumenów obejmujących wiele węzłów, nie ma wbudowanych kompleksowych rozwiązań zapewniających wysoką dostępność (a jedynie namiastkę, rozwiązującą drobą część problemów – np. możliwość wykonywania zdalnych kopii RAID1 czy archiwizacji w trakcie pracy systemu za pomocą funkcji kopia z punktu w czasie) ani zdolności do samozarządzania.

3.2.2 Niektóre szczegóły budowy wybranych systemów

3.2.2.1 System NetworkDisk

Architektura systemu przedstawiona jest na rys. 3.1³⁷.

Rys. 3.1 Architektura systemu NetworkDisk

System udostępnia dane zarówno poprzez szybką sieć lokalną (Gigabit Ethernet, Fibre Channel), jak i interfejs SCSI, jak większość zwyczajnych urządzeń. Węzły są połączone między sobą za pomocą szybkiej sieci, zaś współpraca między węzłami ogranicza się do realizacji następujących funkcji:

Międzywęzłowa kopia z punktu w czasie (czyli kopia wolumenu znajdującego się na jednym węźle systemu tworzona na innym węźle bez przerwy w udostępnianiu usług).

Replikacja danych na bieżąco, tj. utrzymywanie aktualnej kopii wolumenu na innym węźle, tak, jak dzieje się to w organizacji RAID1 z niesymetrycznymi węzłami, tj. z jednym węzłem głównym i jednym zapasowym (ang. remote mirroring).

Dzięki zastosowaniu samodzielnych jednostek PC na węzły możliwe było wbudowanie w ten system schowka, podobnie jak w systemie V3, jednak tutaj schowek nie jest kooperatywny³⁸ ani nie realizuje wyspecjalizowanych algorytmów (np. takich jak algorytm MQ w systemie V3, optymalizowany dla schowków drugiego poziomu).

System ten wykazuje bardzo duże podobieństwo do systemu V3 we wczesnej fazie rozwoju tego ostatniego. W porównaniu z obecną wersją systemu V3 wyraźnie brakuje tutaj spójności serwera jako zbioru węzłów. Wprawdzie możliwe są tutaj replikacja i archiwizacja (jako kopia z punktu w czasie, p. 3.3.3.2), jednak poszczególne węzły udostępniają tylko swoje własne zasoby, każdy z nich jest tu samodzielnym serwerem, każdy jest też osobno zarządzany.

Dość interesującą jest natomiast koncepcja udostępniania danych za pośrednictwem interfejsu SCSI, ale nie poprzez wyeksponowanie swoich dysków, ale poprzez udostępnienie interfejsu SCSI przez sam węzeł. Umożliwia to wykorzystanie systemu NetworkDisk jako alternatywy dla dysku lokalnego w dowolnych rodzajach serwerów, bez potrzeby wyposażania ich w specjalne dodatkowe komponenty (tak jak karty sieciowe Giganet i specjalny sterownik systemowy w systemie V3). Metoda ta zapewnia więc kompatybilność, nie wydaje się to jednak technologia przyszłościowa, ponieważ wyklucza podłączenie do systemu wielu klientów naraz.

3.2.2.2 System Auspex NS2000

Architektura systemu przedstawiona jest na rys. 3.2³⁹.

Rys. 3.2 Architektura systemu Auspex NS2000

Wprawdzie ten system pełni funkcję serwera plików, a nie serwera wirtualnych urządzeń blokowych, jednak wykazuje bardzo istotne podobieństwa architekturalne do systemu V3. System ten, podobnie jak V3, wykorzystuje grupę węzłów roboczych zbudowanych w oparciu o tanie podzespoły (klasy PC, z szyną PCI), do których podłączone są dyski i które udostępniają klientom dane zgromadzone na tych dyskach za pośrednictwem sieci.

Każdy węzeł systemu składa się z dwóch osobnych modułów: modułu odpowiedzialnego za odbieranie oraz interpretację żądań sieciowych (NP, ang. network processor) oraz modułu odpowiedzialnego za lokalne zasoby dyskowe i system plików (FSP, ang. filesystem processor).

Moduł NP jest jakby pośrednikiem, który rozumie szereg protokołów sieciowych i jest w stanie przekierować żądanie klienta pod właściwy adres. Jeśli jest to np. żądanie do systemu plików, wówczas moduł NP wysyła żądanie odczytu lub zapisu do odpowiedniego modułu FSP, bądź lokalnego, na tym samym węźle, bądź też zdalnego, na innym (zależnie od tego, który z węzłów odpowiada akurat za dany system plików). Moduł NP może więc przekierowywać żądania do innych węzłów. Może również kierować żądania (jeśli ich nie rozumie) do węzła kontrolującego, który realizuje np. funkcje nie wymagające wysokiej wydajności (którymi nie ma sensu obciążać węzłów roboczych).

Drugi moduł, FSP, jest jakby serwerem lokalnych zasobów węzła (systemy plików udostępniane przez węzeł, a zdefiniowane na lokalnych zasobach dyskowych) dla lokalnego, ale też dla zdalnych modułów NP. Jest też odpowiedzialny za wszelkiego rodzaju działania administracyjne, jak archiwizacja i reorganizacja danych.

Dzięki zdolności węzłów do wzajemnego przekierowywania między sobą żądań oraz do przekierowywania żądań, których nie rozumieją, do węzła kontrolującego, można traktować cały system nie tylko jako luźną grupę węzłów potrafiących w jakimś minimalnym zakresie przesyłać między sobą dane (tak można scharakteryzować system NetworkDisk opisany w poprzednim punkcie), ale jako w miarę spójny serwer udostępniający różne rodzaje zasobów, do którego można kierować żądania bez znajomości fizycznej lokalizacji tychże zasobów (umiejscowienia na konkretnych węzłach).

Węzeł kontrolujący, oprócz obsługi funkcji nie związanych z odczytem/zapisem plików, pełni także rolę jednostki zarządzającej całym systemem i koordynującej działania, np. procesy archiwizacji czy wszelkiego rodzaju czynności administracyjne.

Węzły robocze komunikują się między sobą oraz z węzłem kontrolującym za pomocą bardzo wydajnego łącza SCI (scalable cluster interconnect)⁴⁰, zapewniającego małe opóźnienie i pozwalającego osiągać bardzo dużą przepustowość przesyłu danych (rzędu 400MB/s).

W porównaniu z systemem NetworkDisk, system Auspex NS2000 cechuje się znacznie lepszą integracją węzłów. Można mówić tu już nie o kolekcji współpracujących serwerów, ale o rozproszonym serwerze zasobów. Jednak system ten nie umożliwia tworzenia abstrakcji wolumenów lub systemów plików opartych na danych zgromadzonych na różnych węzłach. O ile sens tworzenia międzywęzłowych wolumenów RAID0 nie jest w każdym przypadku (zastosowaniu) jednoznaczny i oczywisty, o tyle razi tu brak możliwości tworzenia np. wolumenów RAID1, szczególnie jeśli wziąć pod uwagę niezwykle wydajny mechanizm międzywęzłowej transmisji danych (o przepustowości trzykrotnie większej niż przepustowość sieci Giganet wykorzystanej w systemie V3).

System Auspex NS2000 jest interesujący ze względu na to, iż zastosowano tutaj jednocześnie dwa niejako przeciwstawne modele. W warstwie dostępu do danych (operacje na plikach) widzimy zbiór autonomicznych i równorzędnych węzłów-serwerów, tymczasem w warstwie zarządzania systemem mamy jednostkę centralną i zbiór zależnych od niej elementów, niezdolnych do samodzielnego funkcjonowania.

3.3 Dostępne oprogramowanie

3.3.1 Rodzaje dostępnych produktów

W chwili obecnej rynek oprogramowania wspierającego zarządzanie systemami składowania danych⁴¹ jest ubogi. Nieliczne spośród dostępnych rozwiązań realizują niektóre z postulatów wymienionych w punktach 2.2.1 i 2.2.3 (wysoka dostępność, skalowalna pojemność i wydajność, automatyczna rekonfiguracja i optymalizacja oraz spójna, globalna administracja), natomiast te najbardziej kompletne nie wspierają technologii klastrowej.

Produkty zbadane przez autora można podzielić na następujące podstawowe grupy:

Zarządcy wolumenów (pojęcie to opisane zostało w punkcie 2.3.4, zaś listę implementacji znalezionych przez autora i ich możliwości przedstawiono w punkcie 3.3.2).
Systemy monitorujące⁴², zajmujące się tylko i wyłącznie monitorowaniem zasobów, udostępniające różne statystyki, często także umożliwiające definiowanie (w oparciu o zbierane przez siebie statystyki) różnego rodzaju alarmów.
Systemy wspierające archiwizację, umożliwiające wykonywanie kopii bezpieczeństwa danych w systemie (ang. backup), często także kopii danych z określonego punktu w czasie oraz migrację danych.
Hierarchiczni zarządcy danych⁴³ (ang. Hierarchical Storage Managers, HSM), łączący szybkie (dyskowe) i wolne (taśmowe, roboty itp.) urządzenia w spójny system o dużej pojemności, realizujące ideę schowka opartego na systemie plików.
Aplikacje umożliwiające scentralizowane zarządzanie zasobami kontrolowanymi przez różnego rodzaju systemy, na ogół posiadające szereg interfejsów do najbardziej popularnych platform i aplikacji (np. SAMS Management Interface/Console firmy Sterling Software).
Różnego rodzaju aplikacje (najliczniejsza chyba grupa) udostępniające wygodny interfejs graficzny do zarządzania fizycznymi urządzeniami (np. Reliant Storage Manager firmy PROCOM Technology zarządzający kontrolerami RAID), niezbyt przyjaznymi dla użytkownika modułami istniejących produktów (np. nakładki na zarządcę wolumenów w systemie HP-UX firmy Back Bay Software), aplikacje do graficznego zarządzania zasobami dyskowymi dedykowane dla wybranych systemów/platform (np. SST-CenterStage firmy Softworks dla OS/390, StorageNetworks ManageRaQ itp.).

Z punktu widzenia niniejszej pracy najważniejsi są zarządcy wolumenów. Większość prac wykonanych przez autora w ramach projektu V3, jak również większość zagadnień przedstawionych w tej pracy w mniejszym lub większym stopniu łączy się właśnie z budową zarządcy wolumenów. Informacje o pozostałych rodzajach produktów można znaleźć w przypisach lub w literaturze.

Spotyka się również wiele systemów łączących w sobie kilka spośród wymienionych elementów. Najczęstsze są produkty realizujące ideę tzw. kompleksowego zarządzania zasobami danych przedsiębiorstwa (ang. enterprise storage management), obejmujące wyrafinowany interfejs graficzny do zarządzania fizycznymi zasobami, monitorowanie i zarządzanie archiwizacją, na ogół niestety dedykowane dla wybranych platform. Drugą popularną grupą produktów stanowią systemy do zarządzania sieciami SAN, również umożliwiające administrację fizycznymi zasobami za pomocą wygodnego graficznego interfejsu, proste monitorowanie oraz kopiowanie i migrację danych bez udziału serwera, wykorzystujące zdolność urządzeń w sieciach SAN do bezpośredniej wymiany danych. Również tych produktów nie będziemy omawiać, ponieważ nie zawierają interesujących rozwiązań programowych.

3.3.2 Zarządcy wirtualnych wolumenów

3.3.2.1 Dostępne produkty

Obecnie tylko jedno spośród oferowanych rozwiązań, VERITAS Volume Manager (VxVM), jest systemem ogólnego przeznaczenia, nakładką na system operacyjny dostępną w wersjach na kilka platform, włączając w to UNIX i Windows NT. Wszystkie pozostałe rozwiązania są integralnymi częściami konkretnych systemów operacyjnych: XVM Volume Manager w systemach IRIX firmy SGI, HP-UX LVM (Logical Volume Manager) w systemie HP-UX, AIX LVS (Logical Volume Storage) w systemach AIX firmy IBM, Digital UNIX LSM (Logical Storage Manager) w systemie Digital UNIX, jak również zarządca wolumenów wbudowany w Windows 2000 i LVM dla Linuxa, nakładka rozpowszechniana w systemie OpenSource. Dosyć prymitywnymi konstrukcjami tego rodzaju są jeszcze zarządca wolumenów firmy CrossStor (dla systemu operacyjnego CrossStor) oraz Solstice DiskSuite firmy SUN, ten ostatni dołączany do systemów Solaris.

Cechy poszczególnych produktów bardzo ogólnie podsumowuje tabelka 3.1.

Nazwa produktu	Główne cechy
VERITAS Volume Manager (VxVM)	Udostępnia wirtualne wolumeny zdefiniowane na lokalnych zasobach serwera. Jest tu duży wybór dostępnych organizacji wolumenów, także np. wolumeny wyższego rzędu. Serwer nie może być tu klastrowy, każdy węzeł jest osobnym serwerem i kontroluje własne zasoby. Zaimplementowano tutaj zaawansowane mechanizmy postępowania w sytuacjach awaryjnych, w tym wsparcie dla dysków z podwójnymi interfejsami SCSI (dwa lokalne kontrolery) i zarządzanie pulami zasobów. Zaimplementowano wiele funkcji administracyjnych, w tym migracja danych, kopia z punktu w czasie, rozszerzenie/zmniejszenie wolumenu, zmiana organizacji wolumenu. Wszystkie te operacje są dostępne na bieżąco (bez przerw w udostępnianiu usług). Produkt jest dostępny zarówno w wersji dla Windows NT, jak i dla systemów UNIX.
Zarządca wolumenów w systemie IRIX (XVM), firma Silicon Graphics	Funkcjonalność podobna jak VxVM. Lepsza możliwość wykorzystania klastrów, ale mniejsza elastyczność w tworzeniu skomplikowanych organizacji wolumenów oraz gorsze mechanizmy postępowania w sytuacjach awaryjnych. Jedyny produkt, który nie jest jednoznacznie gorszy od VxVM.
Zarządca wolumenów w systemie Windows2000	Nie ma tu dużego wyboru organizacji wolumenów, niewielkie są także możliwości radzenia sobie z awariami, brak monitorowania, brak mechanizmów optymalizacji wydajności. Dosyć wygodna administracja. Funkcjonalnie pod każdym względem gorszy od VxVM.
Digital UNIX Logical Storage Manager (LSM), firma Compaq	Mały wybór organizacji wolumenów (np. nie można tworzyć wolumenów RAID5), brak wsparcia dla klastrów.
AIX Logical Volume Manager, firma IBM	Są to zintegrowani zarządcy wolumenów w systemie UNIX (HP-UX, AIX), będący integralną częścią środowiska systemowego. Funkcjonalnie te produkty są bardzo podobne do siebie nawzajem i do IRIX XVM. Oba są prawie pod każdym względem wyraźnie gorsze od tego ostatniego, mniej nowoczesne, mniej wygodne w obsłudze i mniej elastyczne. Starsza, nie modernizowana technologia.
HP-UX Logical Volume Manager
Solstice DiskSuite	Standardowy komponent środowiska Solaris Operating Environment. Dostępność VxVM (VERITAS) na platformie Solaris 8 uczyniło ten produkt przestarzałym. Dostępna funkcjonalność całkowicie zawiera się w funkcjonalności VxVM.
CrossStor Volume Manager	Produkt istniejący na rynku przez bardzo krótki okres, obecnie już niedostępny z powodu przejęcia firmy CrossStor.
LVM (Logical Volume Manager) dla Linuxa (Heinz Muelschagen)	Witualne wolumeny na lokalnych dyskach systemowych. Nie udostępnia żadnych mechanizmów zwiększających odporność na awarie, nie daje żadnej automatyzacji, monitorowania, ale jako jedyny umożliwia rozszerzanie wolumenów w poziomie (przez konkatenację partycji) i na bieżąco. Wykorzystanie tej możliwości wymaga jednak zastosowania specjalnego systemu plików.

Tab. 3.1 Główne cechy wybranych zarządców wolumenów

Produkt firmy VERITAS jest obecnie najbardziej zaawansowanym produktem tego typu, praktycznie całkowicie zdominował swój segment rynku, dlatego będziemy traktować go dalej jako punkt odniesienia do porównań.

3.3.2.2 Funkcjonalność

W tabelce 3.2 autor zgromadził częściowe informacje na temat funkcjonalności udostępnianej przez różne implementacje zarządcy wolumenów.

Nazwa właściwości / funkcjonalności	VxVM	XVM	Win2K	LSM	AIX LVM	HP-UX	Solstice	CStor
Czynności administracyjne
Dostępne rodzaje czynności administracyjnych nie wykonywanych na bieżąco (bez udostępniania danych klientom)
Zmiana rozmiaru pasemka w wolumenach RAID0/RAID5	+	- (?)	- (?)			-
Rozszerzenie wolumenu skonkatenowanego (o nowe fragmenty)	+	+	+	+		+	+
Zmniejszenie rozmiarów wolumenu bez utraty danych				+		-
Zmiana organizacji wolumenu bez utraty danych	+	(+)	-	-				+
Przenoszenie grup dysków z wolumenami między serwerami, automatyczne rozpoznawanie ich i udostępnianie	+	+	-	+
Zdolność do współpracy z rozszerzalnymi systemami plików	+	+	(+)	(+)		+	+
Dostępne rodzaje czynności administracyjnych wykonywanych na bieżąco (w trakcie normalnego wykonywania żądań)
Dodanie kolejnej kopii danych i utworzenie wolumenu RAID1	+	+	+	+			+	+
Migracja danych dowolnego wolumenu							-
Migracja jednej z dwóch kopii RAID1							+
Resynchronizacja (uaktualnianie nowo dołączonej kopii RAID1)	+	+ (?)	+	+
Zmiana konfiguracji wolumenu bez konieczności blokowania systemu plików	+	+	(-)				-	+
Zmiana rozmiaru pasemka w wolumenach RAID0/RAID5	+	-	-			-	(-)
Zmiana organizacji wolumenu	+	(+)	(-)	-			-	+
Wykonywanie na bieżąco kopii z punktu w czasie	+	-	-	+			-	+
Rozszerzenie wolumenu sekwencyjnego przez zwiększenie partycji	- (?)	- (?)	+	+		-	-
Zamiana wolumenów sekwencyjnych na wolumen skonkatenowany							-
Rozszerzenie wolumenu skonkatenowanego (o nowe fragmenty)	+	+	+	+		-	+
Zmniejszenie rozmiaru wolumenu bez utraty danych				+		-	-
Odporność na awarie i wysokodostępność
Stosowane rodzaje zabezpieczeń zapobiegających awariom lub minimalizujących skutki ich wystąpienia
Zapisywanie na dyskach sygnatur umożliwiających automatyczne rozpoznawanie ich, formowanie w grupy i udostępnianie wolumenów, gdy zostaną dołączone do systemu	+	+	-	+
Utrzymywanie wielu kopii informacji o konfiguracji wolumenów (na tym samym lub na wielu nośnikach)	+	+	(-)	+	+
Powtarzanie kopii informacji o wolumenach pasemkowanych w zarezerwowanych obszarach na wszystkich dyskach z danymi	+	+	-	(+)	+
Możliwość dodatkowego zapisywania informacji o wykonywanych operacjach w trwałej pamięci lub na trwałych nośnikach w celu dodatkowego zabezpieczenia przed awariami	-	-	-	-
Dane nie są tracone, jeśli system ulegnie awarii w trakcie procesu zmiany organizacji wolumenu na bieżąco	+
Zmiany organizacji wolumenów zachowują redundancję danych w trakcie procesu, bezpieczeństwo danych nie jest mniejsze	+
Utrzymywanie puli wolnych zasobów do użycia przy awariach	+		-					+
Przechowywanie informacji o konfiguracji na innych komputerach, pozyskiwanie konfiguracji z sieci, jeśli lokalne kopie ulegną zniszczeniu	-		-	-
Automatyczne scenariusze awaryjne, możliwości samoczynnego usuwania skutków awarii przez system
Automatyczne odzyskiwanie informacji konfiguracyjnych z innych kopii, jeśli główna kopia zostanie zniszczona	+				+
Odzyskiwanie informacji z wielu kopii danych konfiguracyjnych przez uspójnianie (głosowanie większościowe)	+		-	-	+
Automatyczne odtwarzanie pierwotnej redundancji danych (kopia w RAID1, brakująca kolumna w RAID5) po awarii	+							+
Przełączanie się na wykorzystanie drugiego interfejsu po awarii kontrolera w dyskach z podwójnymi interfejsami SCSI	+	+
Automatyczna resynchronizacja wolumenów, na których wykonywane były zapisy po restarcie systemu	+			+				+
Automatyczne kontynuowanie wykonywanych na bieżąco zmian organizacji wolumenu i innych operacji administracyjnych po restarcie systemu, jeśli w trakcie procesu wystąpiła awaria i restart	+
Przełączanie się między kopiami RAID1 w przypadku awarii	+
Współpraca ze sprzętem i organizacja danych
Obsługa różnych specjalistycznych rodzajów sprzętu i sposób jego wykorzystania
Wolumeny wirtualne mogą być zdefiniowane na nośnikach takich jak dyski optyczne i taśmy magnetyczne	-	-	-
Zdolność do wykorzystania możliwości dysków z podwójnymi interfejsami SCSI	+	+
Wykorzystania dysków wkładanych na bieżąco (ang. hot-plug)		+
Zdolność do definiowana organizacji RAID w oparciu o dyski przyłączone do kilku różnych kontrolerów	+	+	+
Dostępne organizacje danych i zarządzania ich rozmieszczeniem na fizycznych urządzeniach
Spójne zarządzanie całością zasobów dyskowych w systemie: Możliwość jawnego lub automatycznego definiowania wirtualnych wolumenów, automatycznego utrzymywania pul wolnych zasobów itp. bez konieczności zarządzania poszczególnymi urządzeniami fizycznymi	+	+	-					+ (?)
Możliwość dowolnego tworzenia wolumenów nie tylko w oparciu fizyczne dyski, ale także o inne wirtualne wolumeny (wolumeny wyższego rzędu, bez ograniczeń)	+	+	-	-				-
Możliwość wydzielania podwolumenów w obrębie wolumenów	-	+	-	-				-
Możliwość definiowania wolumenów skonkatenowanych	+	+	+	+	+	+	+	+
Wolumeny RAID0 i RAID1	+	+	+	+		+		+
Wolumeny RAID0+1 (dane replikowane, a potem pasemkowane)	+	+	-	-				+
Wolumeny RAID1+0 (dane pasemkowane, a potem replikowane)	+	+	-	+				+
Wolumeny RAID4	-	-	-	-	-	-	-	+
Wolumeny RAID5	+	-	+	-			+	+
Możliwość wykorzystania wolumenów skonkatenowanych jako kolumn w wolumenach innych rodzajów (np. RAID0)	+	+	-	+
Możliwość konkatenacji wolumenów innych niż sekwencyjne	+	+	-	-			+
Możliwość konkatenacji wolumenów innych niż sekwencyjne, i w dodatku różnych rodzajów (np. konkatenacja wolumenu RAID1 zdefiniowanego na 2 dyskach z RAID5 opartym na 5 dyskach itp.)	+	+ (?)	-	-			+
Możliwość replikowania danych wolumenu na wolumen innego rodzaju (np. RAID0 zdefiniowanego na 3 dyskach na inny RAID0, zdefiniowany na 2 dyskach)			-	+
Dostępne wybrane wolumeny drugiego rzędu	+	+	-	-				+
Wolumeny RAID0 zdefiniowane na wolumenach RAID0	-	+	-	-
Możliwość tworzenia wolumenów na bazie fragmentów fizycznych nośników, nie tylko na bazie całych dysków	+	+	+	+	+
Specjalny rodzaj wolumenów zaprojektowany do użycia jako dziennik⁴⁵	+	+	-	+
Specjalny rodzaj wolumenów zaprojektowany do użycia w systemach czasu rzeczywistego	-	+	-	-
Wykorzystanie zarezerwowanych obszarów na dyskach do przechowywania dodatkowych informacji konfiguracyjnych, sygnatur wolumenów itp.	+	+		+	+
Zdalna replikacja wolumenu (ang. remote mirroring)	-	-	-	-	-	-		+
Optymalizowanie wydajności
Równoważenie obciążenia między kopiami w wolumenach RAID1	- (?)	+		+				+
Rozkładanie w czasie resynchronizacji i innych czasochłonnych działań wykonywanych w tle stosownie do bieżącego obciążenia systemu i względnego obciążenia kontrolerów dyskowych	+		-	-
Powstrzymanie się od resynchronizacji lub odzyskiwania danych wolumenów, do których nie było żądań				+
Zapamiętywanie numerów zmienianych bloków w trakcie pracy z jedną kopią RAID1 w celu przyśpieszenia resynchronizacji	+			+				+
Wykorzystanie dziennika dla przyśpieszenia RAID5⁴⁶	+		-	-
Równoważenie obciążenia pomiędzy kontrolerami w dyskach z wieloma interfejsami SCSI podłączonych do kilku kontrolerów naraz	+
Monitorowanie i tworzenie statystyk
Monitorowanie sprzętu na ewentualność wystąpienia awarii	- (?)	- (?)	-	-
Obliczanie statystyk wydajnościowych	-	+	(-)	+
Możliwość wykorzystania technologii klastrowej
Administracja całym systemem z każdego węzła serwera	-	+	+	-
Scentralizowany widok całych zasobów wielowęzłowego serwera	-	+		-
Dostęp każdego węzła do zasobów na innych węzłach serwera	-	(+)	(+)	-
Interfejs administratora, łatwość użycia
Zwykły interfejs tekstowy, możliwośc pisania skryptów	+	+	- (?)	+
Okienkowy interfejs graficzny	+	-	+	+				+
Kompleksowe zarządzanie współdzielonym dyskiem (sieciowym), logiczny widok konfiguracji i wykorzystania tego dysku na węzłach klastra, w tym monitorowanie wykonywanych zmian i działających na węzłach procesów, które korzystają z tego dysku	+	+ (?)		-
Powiadamianie pocztą elektroniczną o awariach i czynnościach naprawczych	+	-	-	-
Zintegrowanie z systemem operacyjnym, kompatybilność
Możliwość założenia głównego systemu plików (root) na wirtualnym wolumenie	-	+		(+)		+
Możliwość założenia pliku wymiany na wirtualnym wolumenie	-	+		(+)	+	+
Sterownik wirtualnych urządzeń w pełni zintegrowany z systemem	+	+	+	+	+			+

Tab. 3.2 Funkcjonalność udostępniana przez różne implementacje zarządcy wolumenów

Dane są bardzo niekompletne, autor miał możliwość korzystania jedynie z dokumentacji użytkowej dostępnej na stronach WWW⁴⁴, która zawiera jedynie bardzo skąpe informacje. Celem tego porównania nie jest jednak wskazanie różnic pomiędzy poszczególnymi produktami, a jedynie pokazanie, jakie rodzaje funkcji dostępne są w istniejących implementacjach oraz jakie funkcje uznano za krytyczne (pojawiają się w większości produktów), a jakie za mniej istotne.

Znaczenie użytych symboli jest następujące:

+	Funkcjonalność dostępna w danym produkcie
(+)	Funkcjonalność dostępna, ale tylko częściowo, w niepełnym zakresie
(-)	Funkcjonalność dostępna w stopniu minimalnym, prawie wcale, np. tylko w jednym określonym przypadku, dla wybranego zestawu parametrów etc.
-	Funkcjonalność w ogóle niedostępna
(?)	Autor nie jest pewien przedstawionej informacji, wykorzystana dokumentacja nie precyzuje tej kwestii w jasny sposób i jednoznacznie

W tabelce pominięto Linux LVM, gdyż produkt ten znajduje się dopiero w fazie rozwoju.

Z przedstawionego tutaj zestawienia płynie wniosek, że konkurencyjny produkt powinien być wyposażony w ściśle zintegrowanego z systemem operacyjnym zarządcę wolumenów, który:

umożliwia definiowanie podstawowych organizacji wolumenów (tzn. RAID0, RAID1, RAID5) w oparciu o dyski lub fragmenty dysków, niekoniecznie przyłączone do jednego kontrolera;
umożliwia również definiowanie wolumenów wyższego rzędu, w tym z obiektów różnego typu (np. RAID1 z wolumenu RAID0 i konkatenacji itp.), poprzez dowolne łączenie konkatenacji, replikacji (RAID1), pasemkowania i pasemkowania z bitem parzystości (RAID5);
potrafi optymalizować wydajność wolumenów RAID5 dzięki wykorzystaniu dziennika;
umożliwia wykonywanie na bieżąco takich czynności administracyjnych jak zmiana rozmiaru pasemka (w wolumenach RAID0/RAID5), zmiany organizacji wolumenu np. z RAID1 na RAID5, przekształcenia wolumenów sekwencyjnych w skonkatenowane i rozszerzania wolumenów skonkatenowanych o nowe fragmenty (nowe dyski, partycje zwiększające pojemność wolumenu), zwiększania rozmiarów partycji, w oparciu o które zdefiniowane są wolumeny, dodanie kopii do wolumenu i utworzenie RAID1;
współpracuje z rozszerzalnymi systemami plików i umożliwia zmniejszanie rozmiaru wolumenu;
zapisuje na dyskach sygnatury i dodatkowe dane konfiguracyjne umożliwiające swobodne przenoszenie dysków między serwerami, automatyczne wykrywanie ich, kojarzenie w grupy, odczytywanie zapisanych tam informacji konfiguracyjnych i automatyczne udostępnianie wolumenów zdefiniowanych na takich grupach dysków;
umożliwia migrację jednej z kopii RAID1, dzięki czemu istnieje jakaś możliwość migracji danych między nośnikami bez ryzyka ich utraty;
umożliwia archiwizację przez wykonanie kopii z punktu w czasie oraz zdalną replikację danych wolumenu na innym węźle lub serwerze;
potrafi przełączać się między dwoma kopiami RAID1, dokonywać resynchronizacji⁴⁷ wolumenów RAID1, i to w sposób inteligentny (tzn. powstrzymując się od resynchronizacji wolumenów, których dane nie były zapisywane, zapisując do dziennika informacje o operacjach zapisu po to, aby ograniczyć resynchronizację tylko do zmienianych obszarów itp.), potrafi równoważyć obciążenie między kopiami RAID1;
wykonuje wszelkie przekształcenia wolumenów i operacje administracyjne w taki sposób, aby proces nie był przerywany w trakcie awarii, dane w trakcie operacji były równie bezpieczne jak normalnie (wolumeny RAID1/RAID5), a wystąpienie awarii w trakcie procesu nie mogło doprowadzić do trwałej utraty danych;
przechowuje swoją konfigurację w wielu kopiach, na różnych fizycznych nośnikach, w tym również wraz z danymi, potrafi korzystać z dodatkowych kopii oraz uzupełniać niespójności pomiędzy różnymi kopiami dokonując głosowania;
zarządza całymi zasobami dyskowymi w sposób spójny i globalny, w szczególności utrzymuje pulę wolnych zasobów, z której potrafi automatycznie korzystać w razie awarii, np. aby uzupełnić brakujące kopie RAID1;
automatycznie przywraca po awarii taki stopień bezpieczeństwa danych, jaki był przed awarią, czyli np. uzupełnia kopie RAID1 oraz brakujące kolumny RAID5;
potrafi wykorzystywać dyski z podwójnymi interfejsami SCSI zarówno w celu optymalizacji wydajności (wyboru mniej obciążonego kontrolera), jak i przełączania się między kontrolerami w przypadku awarii jednego z nich;
potrafi korzystać z dysków wkładanych i wyjmowanych na bieżąco;
udostępnia specjalny rodzaj wolumenów zoptymalizowanym pod kątem użycia jako dziennik;
potrafi zarządzać wykonywanymi w tle czynnościami administracyjnymi, resynchronizacją itp. w taki sposób, aby dostosować intensywność tych procesów do bieżącego obciążenia systemu, w szczególności dostosowywanie do bieżącego obciążenia wolumenów, systemu jako całości, jak również poszczególnych dysków i kontrolerów;
monitoruje komponenty sprzętowe i własne moduły na ewentualność awarii (np. używa S.M.A.R.T.);
oblicza na bieżąco statystyki wydajnościowe;
w klastrze potrafi zarządzać zasobami w sposób scentralizowany;
umożliwia wykorzystywanie nawzajem swoich zasobów dyskowych przez węzły klastra;
udostępnia wygodny, okienkowy interfejs graficzny, ale również możliwość tworzenia skryptów;
potrafi wykorzystywać np. pocztę elektroniczną, serwisy SMS itp. do automatycznego powiadamiania administratora o awariach;
integruje się z lokalnym systemem, np. pozwala na przechowywanie również części lub całości danych systemu operacyjnego czy pliku wymiany na wirtualnych dyskach.

Oprócz tego pożądane (aczkolwiek bardzo rzadko lub w ogóle niedostępne w analizowanych implementacjach) byłyby następujące cechy:

możliwość migracji na bieżąco dowolnego rodzaju wolumenu na inną grupę dysków – bezpośrednio, tzn. bez konieczności tworzenia, specjalnie na tę ewentualność, dodatkowej kopii RAID1;
możliwość przechowywania konfiguracji na innych komputerach, nie tylko lokalnie, i pozyskiwania jej stamtąd w razie utraty lokalnych kopii;
możliwość współpracy z archiwami dysków optycznych i taśm oraz tworzenia wirtualnych wolumenów na takich nośnikach;
udostępnianie specjalnego rodzaj wolumenów dla systemów czasu rzeczywistego.

System V3 udostępnia jedynie małą cząstkę wymienionej funkcjonalności.

3.3.3 Systemy wspierające archiwizację

3.3.3.1 Dostępne produkty

Autor przeanalizował następujące produkty: MultiView Volume Manager firmy StoreAge (tu nazwa volume manager jest nieco myląca, gdyż tak naprawdę jest to wyłącznie system archwizacji), Transparent Data Migration Facility (TDMF) firmy Amdahl, XBM Enterprise Snapshot firmy BMC Software, StorageWorks Virtual Replicator firmy Compaq, ARCserveIT firmy Computer Associates, Data Manager firmy EMC oraz Snapshot i TDMF firmy StorageTek. Jest to tylko drobny procent wszystkich produktów tego typu dostępnych na rynku. Oprogramowanie wspierające archiwizację jest chyba najliczniejszą grupą spośród wszystkich wymienionych (p. 3.3.1). Zarazem wszystkie badane przez autora produkty nie wydają się istotnie różnić pod względem funkcjonalnym, podstawowe różnice dotyczą przede wszystkim wspieranych platform sprzętowych, współpracy z innym istniejącym oprogramowaniem, wykorzystania technologii typu SAN itp., ewentualnie rodzajami dostępnych nośników i sposobem ich wykorzystania (np. MultiView Volume Manager firmy StoreAge umożliwia łączenie nośników przeznaczonych do archiwizacji w formy przypominające organizacje RAID).

3.3.3.2 Funkcjonalność

Główne funkcje udostępniane przez wymienione wcześniej produkty:

Archiwizacja danych, tworzenie kopii zapasowych ważnych danych na innych nośnikach.
Kopia danych z punktu w czasie, operacja polegająca na udostępnieniu wersji danych aktualnej w pewnym określonym momencie t0, tzn. wersji uwzględniającej wszelkie zmiany, które dokonały się do chwili t0, a jednocześnie nie uwzględniającej żadnych zmian, które dokonały się później. W praktyce, ze względu na różnego rodzaju opóźnienia, na ogół nie jest możliwe otrzymanie wersji dokładnie z chwili t0 zadanej przez użytkownika, jednakże na ogół wystarcza, jeżeli możemy otrzymać kopię z pewnej chwili t, wprawdzie losowej, ale bardzo bliskiej t0.
Migracja danych, czyli przeniesienie danych z jednego nośnika lub grupy nośników na inny, zakończone zwolnieniem tego pierwszego i dołączeniem do puli wolnych zasobów.

Bardzo pożądaną własnością (nie we wszystkich produktach dostępną) jest możliwość wykonywania wyżej wymienionych operacji bez konieczności przerywania pracy serwera ani nawet zatrzymywania aplikacji intensywnie, na bieżąco korzystających z danych.

3.3.3.3 Sporządzanie kopii danych z punktu w czasie

W kontekście tworzenia kopii zapasowych warto zwrócić uwagę na istotną różnicę między tworzeniem kopii danych z punktu w czasie a zwykłą archiwizacją. Archiwizacja z definicji polega na utworzeniu pełnej, niezależnej od oryginału⁴⁸ kopii na osobnym nośniku. Operacja ta z natury rzeczy jest bardzo czasochłonna. Nawet jeżeli można ją przeprowadzać w trakcie działania systemu i bez blokowania dostępu do danych (co możliwe jest obecnie w niektórych komercyjnych systemach), to aktywne działanie aplikacji w trakcie przeprowadzania tej operacji powoduje, że różne części kopii będą wersjami z różnych, bliżej nieokreślonych chwil, co w wielu zastosowaniach może być niepożądane. Operacja tworzenia kopii danych z punktu w czasie posiada natomiast jasną semantykę – wszystkie fragmenty kopii pochodzą z tej samej chwili.

Kolejną ważną cechą kopiowania danych z punktu w czasie jest możliwość niemalże natychmiastowego udostępnienia kopii. Mimo, że utworzenie pełnej, niezależnej kopii, podobnie, jak w przypadku zwykłej archiwizacji, jest czasochłonne, częściowa kopia może wykorzystywać oryginalny nośnik do dostarczenia tych danych, które jeszcze nie zostały skopiowane.

Opisana własność implikuje jeszcze inną zaletę omawianej operacji: tworzenie kompletnej kopii danych nie jest konieczne. W zastosowaniach, gdzie kopia danych z danej chwili jest potrzebna tylko tymczasowo, do przeprowadzenia prostych obliczeń czy wyznaczenia jakichś statystyk, po czym przestaje być potrzebna, możemy pozostać przy częściowej kopii, wspomaganej oryginalnym nośnikiem, a gdy przestaje być potrzebna, zlikwidować ją bez wpływu na oryginalne dane. Najczęściej spotykanym w praktyce przykładem takiego zastosowania będzie przeprowadzanie różnego rodzaju testów, symulacji czy obliczanie statystyk z wykorzystaniem rzeczywistych danych, ale prowadzonych na osobnej wersji, dzięki czemu nie obciążają one głównej kopii i mogą być prowadzone niezależnie od normalnego funkcjonowania systemu, bez wpływu na wydajność.

3.4 Podsumowanie

W rozdziale tym wskazano na szereg cech, które wyróżniają system V3 wśród istniejących obecnie rozwiązań: udostępnianie poprzez sieć wirtualnych urządzeń o wydajności niemal identycznej z wydajnością dysków lokalnych, wykorzystanie taniej technologii PC zapewniającej konkurencyjny do tradycyjnych architektur współczynnik wydajności do ceny, udostępnienie całych zasobów serwera w ramach jednego, spójnego interfejsu ukrywającego fizyczną lokalizację danych, architektura rozproszona.

System V3 nie ma bezpośredniej konkurencji m. in. z uwagi na fakt, iż istniejące systemy dryfowały raczej w stronę wielofunkcyjnych serwerów plików i innych rodzajów usług związanych ze składowaniem danych, gdy tymczasem V3 jest próbą zastąpienia zwykłego dysku fizycznego, urządzenia blokowego potrafiącego zapisywać i odczytywać bloki danych. Jedyną znaną autorowi próbą realizacji takiego wirtualnego dysku, który może być używany w zastępstwie swojego fizycznego odpowiednika, jest NetworkDisk (opisany w pierwszej części rozdziału), system ten jest jednak raczej luźną kolekcją niezależnych jednowęzłowych serwerów, które potrafią współpracować w ograniczonym zakresie, niż jedną spójną całością.

Autor zaprezentował dwa przykłady systemów posiadających cechy wspólne z systemem V3, w tym m. in. system NetworkDisk oraz, nie będący wprawdzie serwerem wirtualnych urządzeń blokowych, ale rozproszony, zbudowany z niezależnych, autonomicznych węzłów udostępniających dane, a zarazem spójny (widziany, dzięki zdolności do przekierowywania żądań, jako jeden serwer zasobów) z perspektywy klienta system klastrowy Auspex NS2000. Ten drugi jest bardzo interesujący również ze względu na zastosowanie jednocześnie podejścia rozproszonego (składowanie i udostępnianie danych) i scentralizowanego (zarządzanie systemem).

Żaden z dwóch zaprezentowanych systemów nie dorównuje jednak systemom tradycyjnym (tzn. z jednym centralnym serwerem zarządzającym wielką liczbą dysków, lokalnych lub sieciowych) pod względem zdolności do zarządzania awariami i funkcjonalności. Zarazem wszelkie mechanizmy zapewniania wysokiej dostępności (np. organizacje RAID) i dostępne scenariusze awaryjne nie dotyczą systemu jako całości, nie wykraczają tu poza lokalny węzeł.

W drugiej części tego rozdziału sklasyfikowano istniejące oprogramowanie służące do zarządzania systemami składowania danych. Spośród kilku rodzajów produktów na szczególną uwagę zasługują systemy do archiwizacji i zarządcy wirtualnych wolumenów, przy czym te ostatnie na ogół także umożliwiają archiwizację, tyle, że nie są tak wygodne, funkcjonalne i uniwersalne jak te pierwsze, dedykowane do tego celu.

Obecnie istnieje kilka implementacji zarządcy wolumenów. Jeden produkt (VERITAS Volume Manager) jest nowocześniejszy i bardziej zaawansowany niż pozostałe. Podaliśmy najpierw krótką charakterystykę wszystkich produktów, a następnie szczegółowe zestawienie cech poszczególnych z nich. Z uwagi na wyraźną przewagę technologiczną produktu firmy VERITAS autor uznał za niecelowe dokonywanie kompleksowych porównań poszczególnych implementacji. Zebrano natomiast informacje na temat funkcjonalności poszczególnych produktów, aby sformułować listę niezbędnych funkcji, które musi realizować i cech, które musi mieć oprogramowanie, które mogłoby stanowić realną konkurencję dla istniejących. System V3 realizuje obecnie tylko nieliczne z wymienionych funkcji. Lista pozostałych może być traktowana jako zbiór wymagań i podstawa do planowania dalszej rozbudowy systemu.

³⁴ Chodzi nam tutaj wyłącznie o oprogramowanie związane z zarządzaniem procesem składowania danych (ang. storage management). Oprogramowanie takie stanowi odrębną, bardzo liczną grupę, a zagadnieniu wyposażania systemów w odpowiednie oprogramowanie tego typu poświęcone są całe czasopisma oraz konferencje. Ciekawe omówienie tego problemu zawiera pozycja [2], znajdziemy tam nie tylko definicję zarządzania zkładowaniem danych (w skrócie SRM, ang. storage resource management), ale także sporo informacji na temat rozwoju rynku pamięci masowych, pożądanej funkcjonalności, architektur itp. Nie zamierzamy tutaj, w szczególności, omawiać np. oprogramowania wspomagającego konstrukcję systemów w ogólności, takiego jak oprogramowanie do równoważenia obciążenia. Informacje na temat oprogramowania tego typu znajdują się też np. w [6], natomiast czytelnik zainteresowany oprogramowaniem ogólnego przeznaczenia do konstrukcji klastrów powinien zajrzeć do pracy [8], w której opisywany jest bardzo popularny system MOSIX.
³⁵ Bez jednej, wyróżnionej jednostki centralnej.
³⁶ Definicja tego pojęcia znajduje się w punkcie 3.3.3.2.
³⁷ Rysunek został sporządzony na podstawie [28], tam też znajduje się szczegółowy opis systemu.
³⁸ O schowku kooperatywnym mówimy wtedy, gdy schowki znajdujące się na poszczególnych węzłach tworzą jedną, wspólną przestrzeń (duży, wspólny, globalny schowek) lub przynajmniej współpracują ze sobą i mogą udostępniać sobie nawzajem miejsce, w zależności od wzajemnych potrzeb (obciążenia, łącznej obsługiwanej przestrzeni dyskowej itp.). Definicję i omówienie schowków kooperatywnych można znaleźć np. w [20].
³⁹ Rysunek pochodzi z [5].
⁴⁰ Omówienie tego interesującego i często wykorzystywanego mechanizmu komunikacji w klastrach znajduje się np. w pracy [34].
⁴¹ Patrz także komentarz we wstępie (3.1) i przypisy (34).
⁴² Przykładami tego rodzaju systemów są CA-ASTEX firmy Computer Associates, SRM Storage Manager firmy Highground, OMEGAMON Monitoring Agent firmy Candle Corporation oraz SpaceView, BEST/1 i PATROL firmy BMC Software. Informacje o tych produktach można znaleźć na stronach internetowych w/w firm.
⁴³ Przykładami tego rodzaju systemów są NetWorker XDSM HDM firmy LEGATO i DiskXtender firmy OTG, informacje o obydwu również można znaleźć na stronach internetowych w/w firm.
⁴⁴ Patrz np. [57], [1] i [22]. Wyjątkiem jest VERITAS VxVM, tu autor posłużył się dokumentacją w formie papierowej, załączaną razem z oprogramowaniem w pakiecie od producenta. Niestety, autor nie zdołał znaleźć tej dokumentacji w Internecie. W przypadku SGI XVM, zarządcy w Windows 2000, Digital UNIX LSM, AIX LVM, HP-UX LVM i Solstice DiskSuite, będących częścią systemu operacyjnego, autor wykorzystał dokumentację do systemu, znajdującą się bezpośrednio na witrynach producentów tychże systemów. Autor nie podaje dokładnych adresów w obrębie tych witryn, gdyż mogą się zmieniać. W przypadku firmy CrossStor witryna już została zlikwidowana (wraz z firmą).
⁴⁵ Słowo dziennik jest tutaj tłumaczeniem angielskiego terminu log file.
⁴⁶ Informacje na ten temat można znaleźć np. w [16].
⁴⁷ Resynchronizacja to czynność polegająca na uaktualnieniu kopii RAID1, która została ponownie dołączona do systemu. Po awarii jednej z kopii RAID1 dane zapisywane są tylko na jednej kopii, druga w tym czasie jest zamrożona, nie uaktualniana, zawiera starą wersję danych wolumenu, lub w ogóle zostaje zastąpiona nowym, czystym nośnikiem. Przywrócenie wolumenu RAID1 do stanu pełnej funkcjonalności wymaga, aby nowa kopia została uaktualniona, albo poprzez skopiowanie danych, albo samo tylko uzupełnienie o zmiany dokonane w międzyczasie. To drugie nazywamy inteligentną resynchronizacją. Wymaga to, aby sprawny węzeł zapisywał dokonywane przez siebie zmiany do dziennika.
⁴⁸ Niezależnej, tzn. nie wymagającej istnienia oryginalnego nośnika do odczytania danych.