Herezje w buforze

Wydajność podsystemu dyskowego macierzy można zwiększać za pomocą pamięci buforowej (cache). Bufor istotnie przyspiesza pracę głównie tych aplikacji, które często wykonują operacje zapisu, np. baz danych wykonujących wiele transakcji. Zamiast czekać, aż dane zostaną przesłane i zapisane na dyskach, macierz potwierdza zapis już w momencie zapisania danych w buforze. Rzeczywisty zapis danych na dyski odbywa się zaś asynchronicznie.

Zupełnie inaczej działa bufor w przypadku operacji odczytu. Tu jego rolą jest takie zarządzanie danymi, aby operacje I/O jak najrzadziej musiały odwoływać się do podsystemu dyskowego. Kluczem do rzeczywistego przyspieszenia odczytów są oczywiście algorytmy zaszyte w oprogramowaniu zarządzającym . Decydują one o tym, które dane pobrać z dysku, z jakim wyprzedzeniem i w jakiej kolejności. Im lepsze dostosowanie algorytmu do konkretnego typu aplikacji, tym większa wydajność odczytu danych. Inne wymagania będzie mieć pod tym względem baza danych, inne serwer plików, a jeszcze inne strumieniowa transmisja audio-wideo.

Gartner Group dzieli macierze na dwa typy: monolityczne i modularne, a czynnikiem odróżniającym je od siebie jest wykorzystanie pamięci buforowej. W macierzach monolitycznych pamięć ta jest współdzielona przez wszystkie kontrolery, co daje więcej możliwości konfiguracyjnych, nie musi jednak automatycznie przekładać się - jako takie - na wzrost wydajności. W macierzach modularnych (półki z dyskami) każdy kontroler ma własną pamięć podręczną - z reguły mniejszą niż macierze monolityczne, co nie oznacza jednak od razu mniejszej wydajności. W niektórych macierzach, np. Sun StorEdge 3900 i 6000, każda półka z dyskami posiada własny kontroler, co umożliwia skalowanie wydajności wraz ze skalowaniem pojemności macierzy.

Wielkość pamięci buforowej ma znaczenie dla wydajności, ale tylko do pewnego stopnia. Istotne zwiększenie wydajności obserwuje się zwykle przy zwiększaniu wielkości pamięci, powiedzmy z 1 do 2 GB/kontroler lub 2 do 4 GB/kontroler. Wielkości te są oczywiście nieco różne dla każdego modelu macierzy. Dalsze zwiększanie wielkości pamięci buforowej nie przynosi zazwyczaj istotnych przyrostów wydajności zapisu, a przyrost wydajności odczytów bywa zwykle nieopłacalny w stosunku do wydatków na dodatkową pamięć. Porównując wielkość pamięci buforowej, trzeba rozróżniać pamięć fizyczną od użytkowej - w większości macierzy jest ona bowiem dublowana z powodów bezpieczeństwa. Tak więc 16 GB "surowej" pamięci oznacza w praktyce "tylko" 8 GB. Co więcej, na dane przypada zwykle tylko 2/3 pamięci buforowej, 1/3 zaś to instrukcje i inne metadane.

Pamięć buforowa, bez względu na jej wielkość, jest zwykle dzielona na dwie części: do odczytu i do zapisu, co wynika z faktu, że każda z nich rządzi się zupełnie innymi prawami i jest zwykle oddzielnie zarządzana. Oczywiście, nie jest to podział fizyczny, lecz logiczny. Przyjmuje się, że w bazach danych wykonujących dużą liczbę transakcji stosunek wielkości pamięci zapisowej do odczytowej powinien kształtować się mniej więcej na poziomie 70/30. Niektóre macierze, np. większość macierzy Sun Microsystems czy macierze HDS Thunder i Lightning, mogą samodzielnie dostosowywać wzajemne proporcje wielkości obu obszarów w zależności od bieżących potrzeb aplikacji. Inne, np. EMC Clariion czy StorageTek D, umożliwiają ręczne dostrojenie algorytmów na podstawie wybranego typu aplikacji - np. baza danych, obróbka wideo, dane geograficzne itp. Jeszcze inne, np. HP EVA, dla zastosowań innych niż bazodanowe wymagają zainstalowania w tym celu dodatkowego oprogramowania firmware.

Konsekwencją podziału pamięci na zapisową i odczytową są dwie grupy kolejek I/O - jedna do odczytu, druga do zapisu. Przykładowo, macierze Symmetrix DMX 2000 oferują 32 równoległe kolejki I/O, macierze HDS Thunder i Lightning (oraz wywodzące się z nich HP XP1024 i Sun 9900V) a także systemy HP EVA5000/3000 mają ich po 96. W pierwszym przypadku macierzy HDS i pochodnych występują 32 kolejki I/O dla danych i 64 dla poleceń I/O. W systemach EVA jest dokładnie odwrotnie - 64 kolejki dla danych i 32 dla instrukcji. Macierze IBM ESS 800 wykorzystują 8 równoległych kolejek I/O. Liczba kolejek może, choć nie musi, mieć wpływ na wydajność. Znaczenie tego czynnika dla wydajności rośnie z reguły wraz ze wzrostem obciążenia macierzy.

Są jednak zastosowania, w których ani wielkość bufora, ani nawet fakt jego istnienia nie mają znaczenia dla wydajności. Przykładem może być przenoszenie danych z bazy produkcyjnej do hurtowni i ich obróbka, mająca na celu stworzenie raportów wielowymiarowych. Bazy hurtowni są zwykle tak duże, że w buforze mieści się zaledwie mały ich ułamek, co powoduje konieczność intensywnego korzystania z podsystemu dyskowego. Zastosowania analityczne są także z definicji bardzo obciążające dla podsystemu dyskowego macierzy, ponieważ raporty analityczne powstają w wyniku wieloetapowych obliczeń wymagających zapisania ogromnej masy wyników cząstkowych.

Innym przykładem jest kopiowanie danych pomiędzy dyskami w ramach tzw. klonowania wolumenów, przenoszenia danych z baz transakcyjnych do analitycznych lub też wykonywanie kopii bezpieczeństwa. W takim przypadku liczy się tylko to, co można "wycisnąć" z dysków.