Schizma w architekturze

Zagadnieniem mającym istotny wpływ na wydajność macierzy jest ich wewnętrzna organizacja. Chodzi zwłaszcza o możliwości zrównoleglenia przepływu danych między dyskami a ich kontrolerami, między kontrolerami dysków a pamięcią buforową, a także między nią a jej kontrolerami. Na rynku są obecnie dostępne trzy architektury: z szyną równoległą (bus), przełącznikiem krzyżowym (crossbar) oraz wprowadzony niedawno przez EMC system DMX - Direct Matrix.

Szyna równoległa występuje we wszystkich macierzach klasy podstawowej i średniej. Wydajność tego rozwiązania kończy się mniej więcej na 1,5 GB/s - nominalną wydajność tego rzędu osiągnęły wychodzące powoli z oferty EMC macierze z serii Symmetrix 8000 oraz systemy IBM ESS Shark. Architektura oparta na przełącznikach krzyżowych jest znacznie wydajniejsza - jej nominalna wydajności sięga kilku, kilkunastu GB/s, choć w praktyce nie przekracza 2-3 GB/s. Przełączniki są stosowane w macierzach klasy najwyższej, np. HDS Thunder 9500V i Lightning, StorageTek V2X.

Architektura Direct Matrix to rozwiązanie opracowane przez EMC, stosowane jedynie w najnowszych macierzach Symmetrix DMX. Każdy kontroler pamięci buforowej jest w niej bezpośrednio połączony z każdym kontrolerem dyskowym. Podawana przez EMC wydajność tej architektury wynosi 64 GB/s. Jest to jednak wydajność teoretyczna wynikająca z zsumowania przepustowości wszystkich ścieżek danych. Niestety, ich jednoczesne zapełnienie nie jest w praktyce możliwe. Bardziej bliska rzeczywistości, choć zapewne także teoretyczna, jest liczba 16 GB (maksymalnie 32 obszary cache x 0,5 GB/s). Niezależnych testów wydajności macierzy DMX wciąż brak.

Pokuta dla programisty

Znakomita większość aplikacji biznesowych powstaje w oderwaniu od sposobu komunikacji z systemami pamięci masowych. Twórcy aplikacji zwykle milcząco zakładają, że problem wydajności leży w konfiguracji bazy danych i poniekąd jest w tym sporo racji. Nawet jednak zgrubne - w sensie algorytmicznym i budowie struktur danych - dostosowanie aplikacji do pewnego z góry zdefiniowanego typu środowiska pamięci masowych mogłoby znacząco podnieść wydajność działania każdej niemal aplikacji.

Jeszcze lepsze efekty można zwykle osiągać, wykorzystując w aplikacjach dostarczane przez producentów macierzy interfejsy API. Jednym z przykładów może być oprogramowanie stworzone wspólnie przez EMC i Oracle, dzięki któremu macierz może "świadomie" dbać o to, by otwarte pliki log bazy danych zawsze były przechowywane w pamięci buforowej. Rozwiązanie o podobnej funkcjonalności, noszące nazwę FlashAccess, jest standardowo dostarczane wraz z macierzami HDS Thunder i Lightning. Interfejsy API macierzy można też wykorzystać do definiowania zasad QoS dla komend I/O pochodzących od różnych aplikacji (np. systemów w wersji produkcyjnej i testowej) lub różnych wątków tej samej aplikacji.

Producenci macierzy twierdzą, że większość aplikacji nie potrafi "wycisnąć" z ich urządzeń więcej niż 30% wydajności. Pole do udoskonaleń jest więc potencjalnie ogromne.