wtorek, 11 lutego 2014

Dysk klasyczny, czy macierz SSD?

Dobrze znany nam dysk klasyczny można opisać za pomocą trzech parametrów: pojemności, wydajności w MB/s i szybkości wyrażonej w ilości operacji wejścia/wyjścia na sekundę (IOPS). 
W zależności od zastosowanej technologii, ostatni z parametrów jest rzędu 100 IOPS dla SATA i 250 dla SCSI. Dla porównania: dyski SSD oferują parametry na poziomie 10-40 tys. IOPS w zależności od modelu i typu obciążenia. Bazując na już tym parametrze łatwo stwierdzić że dyski SSD będą nieocenione dla wszelkich aplikacji transakcyjnych, gdzie zapisujemy niewielkie paczki danych, ale za to często i jak najszybciej. Zaś im bardziej strumieniowy jest zapis, oraz im rzadziej sięgamy do danych - tym bardziej wystarczające są dyski klasyczne, które w rozwiązaniach archiwizacyjnych są wręcz “szybkim” buforem dla taśm.

Komputer dyskowy
Wróćmy do poziomu macierzy dyskowej, która jest architektonicznie rzecz biorąc specjalizowanym komputerem z dużą liczbą dysków. W takim “komputerze” każda zapisana informacja musi przejść przez jej procesor i pamięć RAM (czyli cache) by być potem zapisaną na dyski w stosownej liczbie kopii i z zapewnieniem określonego poziomu ochrony dla danych. Taka macierz może dysponować wyłącznie dyskami SSD lub bardziej złożoną kombinacją dysków klasycznych i SSD. W pierwszym przypadku ograniczeniem wydajnościowym jest sam kontroler macierzy - bo dodając nowe dyski półprzewodnikowe możemy dziś osiągnąć wydajności wręcz “kosmiczne”. W takim przypadku można zadać pytanie, czy kontroler macierzy jest wręcz potrzebny - wtedy zarządzanie pamięcią masową przesuwa się na poziom aplikacji i jest jej immanentną częścią. (Przykładem takiego rozwiązania jest ExaStorage, który możemy znaleźć w Oracle Super Cluster i Oracle Exadata). Ale jeśli aplikacja nie ma takiej funkcjonalności, wtedy macierz jako “generyczny” worek na dane jest nieoceniona. Stosowanym wtedy najczęściej rozwiązaniem są konfiguracje hybrydowe buforujące dane na kilku poziomach składowania: ultra szybkim - cache, bardzo szybkim - SSD i tym “zwykłym” - na dyskach klasycznych. 
Takie architektury obsługiwane są przez złożone mechanizmy i algorytmy potrafiące na podstawie analizy aktywności systemu “zgadnąć”, które dane w którym buforze trzeba “przytrzymać" lub “dociągnąć” by system był wydajny i szybki. Przykładem takiego mechanizmu jest Hybrid Storage Pool rozwijany na potrzeby systemów ZS Storage. Można też pójść jeszcze dalej i stworzyć mechanizm, w którym macierz nie musi “zgadywać”, a dowiaduje się “a priori” co się wydarzy i jakie bloki będą potrzebne - nie na zasadzie prawdopodobieństw, ale jako zapytanie wyprzedzające. Przykładem takiego protokołu jest intensywnie rozwijany OISP (Oracle Inteligent Storage Protocol).

Dla każdego coś odpowiedniego
Po tym całym wywodzie można wreszcie odpowiedzieć na postawione na początku pytanie, przy pomocy odpowiedzi najbardziej technicznie możliwej: to zależy...
  • Jeśli używana jest JEDNA aplikacja z kosmicznymi wymaganiami, to zbuduj na jej potrzeby równie kosmiczny system dyskowy oparty na SSD. Lub przebuduj aplikację.
  • Jeżeli masz KILKA systemów o dużych wymaganiach i kilka innych - macierz z SSD może być tym czymś czego Ci potrzeba.
  • A jeżeli chcesz archiwizować dane i zapewnić rozsądny dostęp do swych danych - zbuduj raczej system archiwizacji oparty o taśmy i wsparty buforem dyskowym. 
Reasumując: im krótsze i częstsze (i powtarzające się) są zapytania aplikacji - tym bardziej przydadzą się dyski SSD. Im bardziej sekwencyjna i wysokoprzepływna jest natura transportu danych - tym bardziej wszelkie bufory są przeszkodą i kłopotem. Uzbrojeni w taką wiedzę oraz świadomi faktu, że dyski SSD wciąż tanieją i rosną pojemnościowo, możemy podjąć jedynie słuszną technicznie decyzję, bez obawy że zrujnuje ona nasz budżet.

O autorze
Zbigniew Swoczyna, szef Zespołu wsparcia sprzedaży Oracle Hardware w Oracle Polska.

Brak komentarzy:

Prześlij komentarz