Architektura systemów pamięci masowych będzie ewoluować. Wraz z nią zmienią się także metody i narzędzia do zarządzania.

Systemy pamięci masowych, jakie znamy, będą powoli odchodzić do lamusa. Nowe zastosowania i związane z nimi nowe wymagania funkcjonalne wpłyną przede wszystkim na zmianę architektur składnic danych, a w konsekwencji także na sposoby ich interakcji z aplikacjami i ze sobą nawzajem. Wraz ze starymi konstrukcjami do historii przejdą także dotychczasowe sposoby zarządzania środowiskami przechowywania danych. Motorem zmian są głównie mało znane firmy, szukające nowych sposobów rozwiązywania starych problemów.

Nie ta skala, nie ta prędkość

Dobre zarządzanie zaczyna się od właściwej architektury - ta rozwiązuje wiele problemów natury podstawowej. Dotychczas wydawało się, że sposobem na efektywne zarządzanie systemami pamięci masowych jest ich konsolidacja. Ani chybi była to (i jest nadal) aberracja wynikająca z ograniczonej konkurencji i niechęci stosowania przez producentów otwartych standardów. Sytuacja zmienia się jednak w oczach - Linux w połączeniu z tanimi, wydajnymi platformami sprzętowymi otworzył nowe możliwości. Powstało kilka innowacyjnych firm, które napędziły stracha gigantom. Ukonstytuowała się specyfikacja SMI-S zapewniająca standardowe interfejsy dla aplikacji zarządzających. Otwarta pozostaje kwestia rzeczywistego poziomu kompatybilności między rozwiązaniami różnych producentów. Ale skoro specyfikacja powstała, podstawowy argument za centralizacją - spójne zarządzanie - traci moc.

Centralizacja systemów pamięci masowych była do tej pory powodowana także chęcią zwiększania wydajności aplikacji transakcyjnych. Duże macierze są pod tym względem atrakcyjne, ponieważ umożliwiają definiowanie wolumenów logicznych na relatywnie dużej liczbie dysków fizycznych. Dyski są najwolniejszym ogniwem systemów informatycznych, a więc, im więcej dysków pracujących równolegle, tym lepiej dla wydajności. Dodatkowym argumentem za dużymi macierzami była i jest możliwość zastosowania dużych pamięci buforowych, zwiększających wydajność zapisywania danych. Oczywiście, wygoda ta ma swoją cenę, liczoną zwykle w setkach tysięcy, a niekiedy milionach złotych.

Problem z monolitycznymi macierzami - oprócz wysokich cen - polega na tym, że nawet największe z nich mają ograniczenia wydajnościowe. Daje to o sobie znać zwłaszcza przy odczycie losowym, charakterystycznym dla baz danych (problem zapisów z powodzeniem rozwiązuje pamięć buforowa). Nawet najwydajniejsze macierze zawierające po kilkaset dysków nie są w stanie "wyrzucić z siebie" więcej niż 300-400 MB/s i to przy założeniu, że są wykorzystywane wszystkie porty Fibre Channel jednocześnie.

Dla jednej aplikacji 400 MB/s to dużo, ale jeśli wziąć pod uwagę to, że w środowisku scentralizowanym ta wydajność musi być dzielona pomiędzy dziesiątki aplikacji, może się okazać, że to wciąż za mało. Jeżeli z tego powodu miałoby się okazać, iż konieczne jest zakupienie dodatkowych macierzy, cała konsolidacja bierze w łeb - stare problemy powracają.

To samo można by zresztą powiedzieć o pojemności - tu też możliwości skalowania pojedynczej macierzy dowolnej klasy są ograniczone. Również dlatego że z troski o wydajność całkowite wypełnienie macierzy danymi nie wchodzi w rachubę.

Alternatywą dla konsolidacji pamięci masowych w jednym urządzeniu są nowe koncepcje architektury składnic danych. Nowe pomysły opierają się na rozproszeniu danych i przetwarzania (kontrolerów) w połączeniu ze spójną (ale również rozproszoną) warstwą logiki i zarządzania. Rozproszenie zasobów danych i mocy obliczeniowej ma na celu zrównoleglenie pozwalające na liniowe skalowanie zarówno pojemności, jak i wydajności. Daje też niezawodność. Wymagania wydajnościowe i dotyczące niezawodności wobec pojedynczego węzła nie są wygórowane. Podobnie jak w zwykłej macierzy dziś od pojedynczego dysku nie oczekuje się absolutnej niezawodności. Wydajny i niezawodny ma być system jako całość. Spójrzmy, jak może to wyglądać w praktyce.

Wydajność rozproszona

Niewielka amerykańska firma TerraScale oferuje rozwiązanie o nazwie TerraGrid, które może mieć fundamentalny wpływ na myślenie o systemach pamięci masowych w najbliższej przyszłości. System pamięciowy TerraGrid składa się z dwóch rodzajów węzłów: inicjujących i docelowych. Oba typy węzłów to standardowe komputery z 32-bitowymi procesorami Intela działające (na razie jedynie) pod kontrolą Red Hat Linux (wersje: 7.3, 8.0 i 9.0).

Węzły inicjujące stanowią bramy do stojących "za nimi" węzłów docelowych, oba węzły da się jednak uruchomić na jednym serwerze. Na węzłach inicjujących działa lokalny (a nie globalny!) system plików - nieco zmodyfikowany ext2 - dzięki któremu serwery aplikacyjne mogą sięgać do danych za pośrednictwem standardowych protokołów NFS lub Samba/CIFS. Węzły inicjujące komunikują się z docelowymi za pośrednictwem protokołu iSCSI wykorzystującego standardowe łącza Gigabit Ethernet lub sieci Myrinet. Z punktu widzenia węzłów inicjujących węzły docelowe to nic innego, jak dyski logiczne.

Usługi działające po stronie węzłów inicjujących dbają o to, by dane były równomiernie "rozrzucane" po wszystkich działających węzłach docelowych (programowy striping) i już to zapewnia wydajność losowego odczytu danych. W systemie TerraGrid nie jest wymagany żaden scentralizowany kontroler dbający o spójność danych i metadanych. Blokowaniem zapisów i spójnością na poziomie bloków rządzą... sterowniki kart sieciowych dostarczane przez TerraGrid.

Informacje o lokalnych zapisach są rozsyłane w sieci w trybie multicast - w postaci niewielkich plików. Tym samym zostaje zlikwidowane główne wąskie gardło - ograniczone możliwości skalowania kontrolerów.

Zapisem danych na węzłach docelowych i ich komunikacją z węzłami inicjującymi zarządza dedykowana usługa. Do fizycznego zapisu są wykorzystywane lokalne dyski węzłów docelowych (DAS, a jakże!). Dane mogą być zapisywane w trybie blokowym na lokalny dysk logiczny, do systemu plików albo też do pliku.

Według producenta TerraGrid skaluje się obecnie do 256 węzłów docelowych. Jeżeli na każdym z nich będzie działać system plików dysponujący dużą pamięcią RAM, odczyt może być naprawdę szybki. Testy przeprowadzone z 11 jednoprocesorowymi serwerami docelowymi i 12 jednoprocesorowymi serwerami inicjującymi z przełącznikiem Gigabit Ethernet dały rezultat rzędu 100 MB/s stałego transferu (odczytu) na pojedynczy węzeł inicjujący. Zakładając, że teoretyczna wydajność łącza gigabitowego wynosi 125 MB/s, to wynik godny uwagi - o ile dane te potwierdzą się u większej liczby klientów.

Archiwum bardzo równoległe

Rozproszenie leży u podstaw także innych rozwiązań, np. systemów archiwizacyjnych firmy Archivas. Ta nieduża firma doszła do wniosku, że lansowana przez EMC koncepcja Content Addressed Storage (CAS) to świetny pomysł na biznes, ale dopiero wtedy gdy klient może archiwizować dane bez konieczności integracji aplikacji za pośrednictwem dedykowanych interfejsów API, przywiązujących go raz na zawsze do jednego dostawcy. Rozwiązanie ArC umożliwia więc dostęp do archiwów za pośrednictwem standardowych protokołów NFS, CIFS, a także po HTTP.

Inżynierowie Archivas uznali też, że klient nie musi płacić wygórowanych cen za standardowy sprzęt, i stworzyli rozwiązanie programowe mogące działać na każdym komputerze z system Linux. Przede wszystkim jednak zaproponowali nowatorską architekturę, dzięki której dane są przechowywane zgodnie z założonymi regułami i automatycznie zabezpieczane przed awarią.

Tu również, podobnie jak w przypadku TerraScale, mamy do czynienia z rozproszeniem danych, metadanych i mocy obliczeniowej pomiędzy wiele węzłów o dużym stopniu autonomii (architektura RAIN - Redundant Array of Independent Nodes). Różnica polega m.in. na tym, że Archivas wykorzystuje samodzielnie opracowany system plików (FCFS - Fixed Content File System), zaś TerraScale - praktycznie standardowy ext2.