Systemy pamięci masowych coraz trudniej odróżnić od platform serwerowych. Za kilka lat całe centrum danych będzie zbiorem kart usługowych w jednej obudowie.

Rzut oka na ogłaszane ostatnio nowości i zapowiedzi w dziedzinie systemów pamięci masowych nie pozostawia wątpliwości - macierze dyskowe w tradycyjnym rozumieniu, czyli dedykowany kontroler ściśle zintegrowany z szafą na dyski, zaczyna przechodzić do historii. Powodów zmiany architektury, a bardziej nawet filozofii projektowania systemów pamięci masowych, jest zbyt wiele, by trzymać się dotychczasowych konstrukcji.

Pierwszy powód to skalowalność systemów pamięci masowych jako urządzeń zapewniających wydajny, współdzielony dostęp do danych. Zaraz po skalowalności wypada wskazać na potrzebę spójnego zarządzania danymi pomimo wzrostu ich objętości, wydłużenia czasu ich przechowywania i niedostatecznej skalowalności systemów istniejących. Trzecim powodem jest pojawienie się całkiem nowych potrzeb narzędziowych i aplikacyjnych związanych z przechowywanymi danymi.

Zwłaszcza ten ostatni trend zmienia oblicze rozwiązań pamięciowych. Kontroler przestaje być jedynie wysoce wyspecjalizowaną "czarną skrzynką", zajmującą się wyłącznie udostępnianiem danych aplikacjom, a staje się pełnoprawną platformą aplikacyjną. W konsekwencji do oceny wydajności i użyteczności systemów pamięci masowych zaczynają stosować się te same reguły, co w przypadku serwerów wykorzystywanych do uruchamiania aplikacji biznesowych.

Prościej, ale nie prymitywniej

Ograniczeniem wydajności macierzy z punktu widzenia sprzętowego jest wydajność dysków twardych oraz koordynacja wewnętrznych połączeń między kontrolerami, pamięcią buforową a dyskami. Szybkość procesorów kontrolerów wpływa na wydajność procesów związanych z przetwarzaniem dużych ilości danych tylko w niewielkim stopniu. Liczy się wewnętrzna konstrukcja macierzy, dostosowanie jej wewnętrznej topologii do typu aplikacji, jak również właściwe dopasowanie do niej logiki oprogramowania zarządzającego.

Sercem typowego kontrolera macierzowego jest obecnie coraz częściej nie rozbuchany funkcjonalnie egzotyczny układ ASIC jak niegdyś, lecz popularne procesory Intela, AMD i IBM współpracujące z prostymi modułami wykonującymi jedynie kilka specyficznych operacji. Zmiana architektury wynika stąd, że nowe potrzeby funkcjonalne zbyt szybko pojawiają się i zbyt szybko ulegają zmianom, by większą część oprogramowania kontrolera pisać w asemblerach.

Kod w językach wyższego poziomu nie jest już tak wydajny jak kod asemblerowy, ale lepsze to niż duże opóźnienia we wprowadzaniu nowych funkcji. Poza tym programistów asemblerowych w stosunku do tych, którzy specjalizują się choćby w C/C++ jest relatywnie mało. Niedobór kadr znających się na asemblerze to coś, z czym producenci macierzy muszą się realnie liczyć w dłuższym okresie.

Spadek wydajności w branży nastawionej na jej ciągłe podwyższanie nie wchodzi w grę, dlatego stopniowe odchodzenie od asemblerów prowadzi do konieczności zmiany architektury macierzy dyskowych. Zamiast jednego czy kilku wysoce wydajnych kontrolerów "do wszystkiego", producenci dążą obecnie w kierunku architektury opartej na znacznie większej liczbie kontrolerów o prostszej konstrukcji.

Podobnie jak wielkie serwery SMP, duże macierze będą ulegać modularyzacji. Ponieważ zwiększenie liczby kontrolerów w systemie utrudnia ich wzajemną koordynację, zachowanie pełnej synchroniczności w takiej macierzy nie ma większego sensu. Analogicznie do domen sprzętowych w serwerach SMP, kontrolery macierzowe funkcjonować będą coraz częściej jako niezależne węzły komunikujące się ze sobą w trybie asynchronicznym.

Luźne związki, bliska współpraca

Dążenie do rozproszenia architektury bardzo dobrze widać na przykładzie najnowszego systemu operacyjnego dla serwerów NAS firmy Network Appliance. Przejęta w 2003 r. przez NetApp firma Spinnaker specjalizowała się w systemach plików dla klastrów obliczeniowych. Fakt, że efekt tego przejęcia widzimy dopiero teraz, świadczy o tym jak głęboka jest zmiana architektury i ile wysiłku wymaga nawet od firmy, która nie zajmuje się niczym innym poza projektowaniem systemów pamięci masowych.

Nowy system operacyjny Data OnTap GX niweluje to, co było dotychczas największą bolączką systemów NetApp, czyli słabą skalowalność - i to na wiele sposobów. Jeden system operacyjny widoczny z zewnątrz za pośrednictwem jednej globalnej przestrzeni nazw zarządza ok. 24 węzłami (12 szaf) zawierającymi po dwa kontrolery FAS3000 (4 x Xeon 2,8 GHz) lub FAS6000 (4 x Opteron 2,6 GHz). Łącznie pozwala to stworzyć macierz logiczną zawierającą do 2016 dysków (Fibre Channel lub SATA, do 12 zdwojonych pętli na kontroler) i do 128 GB pamięci buforowej.

Dzięki nowoczesnej architekturze rozwiązania NetApp dorównały (teoretyczną) skalowalnością najlepszym produktom z branży. Dla porównania, monolityczne macierze EMC Symmetrix DMX-3 umożliwiają instalację 2400 dysków i mają 128 GB pamięci buforowej, zaś macierze Hitachi Data Systems HDS TagmaStore USP1100 (a więc także najwyższej klasy macierze oferowane przez HP i Sun Microsystems) mają możliwość zainstalowania do 1152 napędów i 256 GB pamięci buforowej. Największe macierze z serii IBM TotalStorage DS8000 mieszczą do 640 dysków.

W tym samym kierunku idą rozwiązania HP RISS (do 250 węzłów po 1,7 TB każdy, przy czym zastosowania są tu archiwizacyjne, a nie transakcyjne), jak również Sun Microsystems. To droga obrana także przez wiele młodszych firm działających na rynku pamięci masowych i oferujących świeże architektonicznie rozwiązania, jak 3Par czy Pillar Data Systems.

Inteligencja zamiast szybkości

Droga ku postępowi w dziedzinie wydajności i skalowalności wiedzie nie tylko przez optymalizację architektury. Co najmniej tak samo ważna jest optymalizacja oprogramowania narzędziowego i algorytmów. Przekonać się o tym mogą użytkownicy macierzy HDS TagmaStore USP lub ich odpowiedników w ofercie HP i Sun Microsystems, decydujący się na wymianę oprogramowania firmware na nową wersję, którą producent opublikował pod koniec maja.

Jest się nad czym zastanawiać. Nowy firmware bez jakiejkolwiek zmiany w warstwie sprzętowej umożliwia uzyskanie pasma operacji I/O na poziomie ok. 25% wyższym niż dotychczas, a więc ok. 2,5 mln operacji na sekundę! Ta ścieżka doskonalenia systemów pamięci masowych uchodziła dotychczas uwagi zarówno producentów, jak i klientów. Na tym nie koniec. Okazuje się, że drobna zmiana zasad zrównoleglenia operacji znaczy dla wydajności usługi więcej niż wymiana procesora na wydajniejszy.

Wymiana dotychczasowego oprogramowania replikacyjnego TrueCopy na nowe - Universal Replicator - pozwala wykonywać zdalną replikację trzykrotnie szybciej, co stało się możliwe m.in. dzięki obsłudze wolumenów logicznych z 64-kilobajtowymi blokami (mniej czasu potrzebnego na potwierdzanie operacji w komunikacji zdalnej, efektywniejsza multipleksacja ze względu na większy udział danych w całości transmisji itp.).

Kolejne, tym razem czterokrotne, przyspieszenie uzyskano przy operacjach replikacji lokalnej, tzn. między macierzami wymieniającymi dane w ramach jednej serwerowni. Tutaj zmiana polegała na poprawie obsługi wielowątkowości kodu. Zamiast 32 jednoczesnych operacji replikacji lokalnej, macierz może ich wykonać 128. W przypadku TagmaStore jest to szczególnie ważne, ponieważ HDS oferuje swoje macierze jako rozwiązania zarządzające danymi także na innych macierzach.

Nowy firmware kosztuje, ale czym jest wydatek kilkudziesięciu tysięcy dolarów wobec wymiany macierzy na nowszą i towarzyszącą temu migrację danych? Optymalizacja kodu, badanie granic wielowątkowości systemu operacyjnego macierzy, poszukiwanie sprawniejszych algorytmów dla masowo wykonywanych operacji - to czynności, które będą w najbliższym czasie zajmować producentów macierzy.

Powyższy opis niczym nie różni się od wysiłków podejmowanych na co dzień przez producentów systemów operacyjnych dla serwerów, serwerów baz danych, platform integracyjnych, rozwiązań BI, systemów indeksujących dane, mechanizmów do masowego przetwarzania wsadowego (szyfrowanie, kompresja, multipleksacja, logowanie zdarzeń itp.). I nic dziwnego - wszystkie te funkcje będą wkrótce lub już są elementami systemów pamięci masowych.

Bez zbędnych ruchów

Liczba i stopień skomplikowania aplikacji/usług działających bezpośrednio w systemach pamięci masowych będą w najbliższym czasie rosnąć. Jak bowiem w inny sposób mają konkurować ze sobą dostawcy rozwiązań NAS? Walka na skalowalność zdarza się w praktyce tylko przy kontraktach z największymi, najbardziej wymagającymi klientami. Takimi, którzy mają kadrę zdolną ocenić rzeczywiste możliwości rozwiązań, rozsądnie sformułować zapytania ofertowe i... mają szansę rzeczywiście sięgnąć granic skalowalności. W pozostałych przypadkach konkurowanie między producentami odbywa się na zasadzie wypełniania pól w tabelkach funkcjonalności.

W najbliższych latach w systemach pamięci masowych znajdziemy połączenie zarządzania dostępem do danych z zarządzaniem plikami (SRM), zarządzaniem treścią, wersjami dokumentów, wyszukiwaniem i analizą danych. Nie ma powodu, aby funkcje te realizowane były poza systemami pamięciowymi, bowiem gdy danych przybywa, kopiowanie ich między macierzami a serwerami nie wnosi zbyt wiele do efektywności całego procesu. Można uznać, że będzie to odpowiednik zastosowania serwerów terminalowych udostępniających zdalnie jedynie zrzuty ekranowe, bez kopiowania większych ilości danych do modułu klienckiego przez sieć WAN.