Historia podziału macierzy dyskowych

Duża część wiedzy rutynowej w branży IT, a zwłaszcza w sektorze SMB, powstała pod koniec lat 90. XX wieku na podstawie różnych czynników. Najważniejsze z nich były następujące: coraz mniejsze firmy zaczęły gwałtownie się komputeryzować, Microsoft doprowadził Windows NT 4 do takiego poziomu stabilności, że stał się standardową podstawą dla całego IT w sektorze SMB, era internetowa w końcu się ugruntowała, a Microsoft wprowadził swoje programy certyfikacyjne i szkoleniowe, które na nowo ukształtowały przepływ wiedzy w branży. Razem stworzyło to zarówno zapotrzebowanie na nowe szkolenia i najlepsze praktyki, jak i wywołało masową falę nowego myślenia, pisania, dokumentacji, szkoleń, najlepszych praktyk, reguł kciuka itp.

Przez kilka lat niemal cała branża była szkolona na tym samym, wąskim zasobie wiedzy, a wiele reguł kciuka stało się de facto standardami. Duża część ówczesnej wiedzy była przyswajana przez powtarzanie i przekazywana z mentora na stażystę w cyklu, który przeniósł wiele wiedzy technicznej z 1998 roku do niezakwestionowanych, skostniałych procesów z 2012 roku. W tamtym czasie było to skuteczne, bo praktyki były odpowiednie – ale to było piętnaście lat temu, a technologia, ekonomia, przypadki użycia i wiedza zmieniły się znacząco od tamtego czasu.

Jednym z najlepszych przykładów była słynna rekomendacja Microsoft SQL Server: RAID 1 dla systemu operacyjnego, RAID 5 dla plików bazy danych i kolejny RAID 1 dla logów. To ustawienie przetrwało przez niemal całe życie produktu i było tak dobrze promowane, że rozprzestrzeniło się na niemal wszystkie aspekty projektowania serwerów w sektorze SMB. Stosowanie RAID 1 dla systemu operacyjnego i RAID 5 dla danych jest tak powszechne, że jest często po prostu zakładane bez jakiegokolwiek zastanowienia się nad tym, dlaczego takie zalecenie pojawiło się w swoim czasie.

Przyjrzyjmy się historii i zobaczmy, dlaczego konfiguracja R1/5/1 była dobra w 1998 roku i dlaczego nie powinna dziś istnieć. Zachowajmy właściwą perspektywę – przepaść między momentem pierwszego pojawienia się tych rekomendacji (już w 1995 roku) a dzisiejszymi czasami jest ogromna. Cofnijmy się myślami do 1995 roku i pomyślmy o równoważnej różnicy z tamtych czasów. To byłoby jak korzystanie w epoce wczesnego internetu z rekomendacji opartych na potrzebach pierwszych właścicieli Apple ][! Era 8-bitowych komputerów domowych ledwo zaczynała się w 1978 roku. Commodore był jeszcze dwa lata od wydania swojego pierwszego komputera domowego (VIC-20), a przed 1995 rokiem miał przejść przez całą erę Commodore i Commodore Amiga, zbankrutować i zniknąć. Apple ][+ był jeszcze rok od premiery. Ludzie właśnie zaczynali używać analogowych napędów kasetowych jako pamięci masowej. COBOL i Fortran były jedynymi językami biznesowymi w użyciu. Mówiąc krótko – przepaść jest niewiarygodna. Rzeczy się zmieniają.

Najpierw musimy przyjrzeć się czynnikom, które istniały pod koniec lat 90. i stworzyły potrzebę naszego historycznego ustawienia.

1. Dyski były małe, bardzo małe. Duża macierz bazy danych mogła składać się z czterech dysków SCSI o pojemności 2,1 GB w macierzy R5, dając zaledwie ~6 GB użytecznej przestrzeni na jednej macierzy. Domena awarii dla parzystościowego RAID była niewielka (w porównaniu do np. wskaźników awarii URE).
2. Technologie połączeń dysków były równoległe i wolne. Dyski twarde tamtych czasów były tylko nieco wolniejsze niż dzisiejsze, ale technologie połączeń stanowiły znaczne wąskie gardło. Powszechne było dzielenie ruchu, aby zmniejszyć wąskie gardła magistrali.
3. Technologia dysków SCSI była jedyną stosowaną w serwerach. Użycie PATA (zwanego wówczas IDE) w serwerze było nie do pomyślenia.
4. Dyski były drogie w przeliczeniu na gigabajt, więc oszczędność kosztów przy zachowaniu pojemności była kluczową kwestią praktycznie dla wszystkich firm.
5. Systemy plików były kruche i ulegały awariom częściej niż same dyski.
6. Sprzętowy RAID był wymagany i dostępne były tylko podstawowe poziomy RAID 1 i 5. RAID 6 i RAID 10 były jeszcze wiele lat od bycia dostępnymi dla większości firm. RAID 0 jest pomijany, gdyż nie zapewnia redundancji.
7. Systemy pamięci masowej rzadko, jeśli w ogóle, były współdzielone między serwerami, więc dostęp był prawie zawsze dedykowany do pojedynczej kolejki żądań.
8. Pamięci podręczne storage’u były małe lub nie istniały, co powodowało, że ograniczenia dostępu do dysków bezpośrednio przekładały się na system operacyjny. Oznaczało to konieczność posiadania różnych macierzy o różnych charakterystykach, aby obsługiwać różne mieszanki odczytu/zapisu i dostępu losowego/sekwencyjnego.
9. Awarie dysków były powszechne i stanowiły główną troskę przy projektowaniu systemów pamięci masowej.
10. Często rozmiar macierzy dyskowej był ograniczony fizycznymi ograniczeniami, więc decyzje o podziale macierzy były podejmowane z konieczności, a nie z wyboru.
11. Kombinacja powyższych czynników oznaczała, że RAID 1 był najlepszy dla niektórych części systemu, gdzie mały rozmiar był akceptowalny, a dostęp był wysoce sekwencyjny lub intensywny pod względem zapisu, natomiast RAID 5 był lepszy dla innych, gdzie pojemność miała pierwszeństwo przed niezawodnością i gdzie dostęp był wysoce losowy i intensywny pod względem odczytu.

W ciągu niemal dwóch dekad od wydania pierwotnych rekomendacji wszystkie te czynniki uległy zmianie. W niektórych przypadkach zmiany mają charakter kaskadowy – przejście od ogólnego stosowania RAID 5 do ogólnego stosowania RAID 10 spowodowało, że dwa dotychczas popularne typy macierzy, RAID 1 i RAID 10, zaczęły mieć podobne charakterystyki dostępu, przez co potrzeba lub chęć używania jednego lub drugiego w zależności od rodzaju obciążenia zanikła.

1. Dyski są teraz ogromne. Zamiast walczyć o zmieszczenie tego, czego potrzebujemy, generalnie mamy nadmiar pojemności. Pojedyncze dyski o pojemności powyżej terabajta są powszechne, nawet w serwerach. Domeny awarii dla parzystości są ogromne (w porównaniu do np. wskaźników awarii URE).
2. Połączenia dysków są szeregowe i szybkie. Połączenia dysków nie stanowią już wąskiego gardła.
3. SATA jest teraz powszechny w serwerach, co zmienia potencjalne ryzyko URE w sposób, który wcześniej nie istniał.
4. Pojemność jest teraz tania, ale wydajność i niezawodność są teraz kluczowymi kwestiami dla wydawanych pieniędzy.
5. Systemy plików są dziś wysoce odporne, a awarie systemu plików to “szum tła” w szerszym kontekście niezawodności macierzy.
6. Sprzętowy RAID i programowy RAID są dziś oboma opcjami, a dostępne poziomy RAID obejmują wiele wariantów, ale – co najważniejsze – RAID 10 jest dostępny wszechobecnie.
7. Systemy pamięci masowej są powszechnie współdzielone, co sprawia, że dostęp sekwencyjny jest jeszcze mniej powszechny.
8. Pamięci podręczne storage’u są powszechne i często bardzo duże. Pamięci podręczne 512 MB i 1 GB są dziś uważane za normę, przez co wiele macierzy z 1995 roku mieściłoby się całkowicie w pamięci kontrolera RAID. Przy szybko rosnących pamięciach podręcznych w stosunku do pojemności storage’u oraz niedawnym dodaniu dysków solid state jako pamięci podręcznej L2 w storage’u w ciągu ostatnich dwóch lat, nie jest wykluczone, że nawet mała firma będzie mieć bazy danych i inne aplikacje wymagające wydajności działające całkowicie z pamięci podręcznej.
9. Awarie dysków są rzadkie i mają znikome znaczenie dla projektowania systemów pamięci masowej (w porównaniu do innych rodzajów awarii).
10. Rozmiar macierzy dyskowej jest rzadko ograniczony fizycznymi ograniczeniami.
11. Stosowanie RAID 1 i RAID 10 jako głównych typów macierzy dziś oznacza, że nie ma korzyści z używania różnych poziomów RAID do dostrajania wydajności.

Te czynniki pokazują, dlaczego system macierzy podzielonych z 1995 roku miał doskonały sens w tamtym czasie i dlaczego nie ma sensu dziś. OBR10, dzisiejszy standard, był wówczas niedostępny i zbyt kosztowny. RAID 5 był stosunkowo bezpieczny w 1995 roku, ale nie dziś. Niemal każdy czynnik zaangażowany w proces decyzyjny zmienił się dramatycznie w ciągu ostatnich siedemnastu lat i będzie nadal się zmieniać w miarę upowszechnienia się SSD, auto-tieringu, jeszcze większych pamięci podręcznych i czystych systemów pamięci masowej SSD.

Zmiana w projektowaniu storage’u na przestrzeni ostatnich dwóch dekad uwypukla również zagrożenia, z jakimi boryka się IT, gdy znaczna część branży uczy się – jak to jest powszechne w inżynierii – podstawowych “reguł kciuka” lub “najlepszych praktyk” bez niekoniecznie rozumienia podstawowych zasad, które napędzają te decyzje. Utrudnia to wiedzieć, kiedy nie stosować tych najlepszych praktyk lub, co ważniejsze, kiedy rozpoznać, że dana reguła już nie obowiązuje. W przeciwieństwie do tradycyjnej inżynierii mechanicznej lub lądowej, gdzie nowe postępy i znaczące zmiany czynników mogą nastąpić raz lub nigdy w ciągu kariery, IT wciąż zmienia się na tyle szybko, że całkowite “przemyślenia” podstawowych reguł kciuka są wymagane kilka razy w ciągu kariery. Może nie corocznie, ale raz na dekadę lub częściej jest prawie zawsze konieczne.

Obecne przejście od uniprocessingu do architektur wielowątkowych to kolejna podobna, znacząca zmiana wymagająca od branży IT całkowitej zmiany podejścia do projektowania systemów.