Jeden Duzy RAID 10 – Nowy Standard w Przechowywaniu Danych na Serwerach

Pod koniec lat 90. standardową zasadą przy budowaniu nowego serwera było umieszczenie systemu operacyjnego na własnej, małej macierzy RAID 1 i oddzielenie aplikacji oraz danych do osobnej macierzy RAID 5. Robiono to z kilku powodów, z których wiele zatraciło się w mrokach historii. Głównymi czynnikami był wyjątkowo wysoki koszt pojemności pamięci masowej, małe rozmiary dysków, regularne uszkodzenia systemów plików oraz bardzo wysoki wskaźnik awarii fizycznych dysków twardych w porównaniu z innymi rodzajami usterek. Ludzie kierowali się potrzebą ochrony przed fizycznymi awariami dysków, ochrony przed uszkodzeniami systemu plików oraz zdobycia wystarczającej pojemności do spełnienia swoich potrzeb.

Dziś krajobraz pamięci masowej uległ zmianie. Systemy plików są niezwykle odporne, a uszkodzenia samego systemu plików są niemal niespotykane i – dzięki technologiom takim jak journalling – można je niemal zawsze szybko i skutecznie naprawić, chroniąc użytkowników przed utratą danych. Prawie nikt dziś nie martwi się o uszkodzenia systemu plików.

Nowoczesne systemy plików obsługują również znacznie większe pojemności niż dawniej. Pod koniec lat 90. i na początku 2000. nierzadko zdarzało się, że macierz dyskowa mogła być większa niż to, co dany system plików był w stanie obsłużyć. Dziś nie jest to realnym problemem, ponieważ wszystkie popularne systemy plików obsługują co najmniej wiele terabajtów, a często petabajty, eksabajty lub więcej danych.

Dyski twarde są znacznie bardziej niezawodne niż pod koniec lat 90. Wskaźniki całkowitych awarii dysków są bardzo niskie, nawet w przypadku tańszych modeli. Tak niskie, że awarie macierzy (utrata danych w całej macierzy RAID) dotyczą przede wszystkim problemów z samą macierzą, a nie awariami dysków twardych. Nie wymieniamy już dysków twardych bez opamiętania. Nie jest rzadkością, że duże macierze przez cały okres eksploatacji nie tracą ani jednego dysku.

Pojemności wzrosły dramatycznie. Zamiast dysków 4,3 GB instalujemy dyski 3 TB. Prawie tysiąc razy więcej pojemności na jednym wrzecionie w porównaniu z tym, co mieliśmy mniej niż piętnaście lat temu.

Te czynniki razem tworzą potrzebę diametralnie innego podejścia do projektowania pamięci masowej serwerów i zmiany „zasady kciuka” dotyczącej punktu wyjścia przy projektowaniu storage’u.

Stare podejście można zapisać jako RAID 1 + RAID 5. Przestrzeń RAID 1 była używana na system operacyjny, podczas gdy przestrzeń RAID 5 – znacznie większa – przeznaczona była na dane i aplikacje. Ten projekt rozdziełał dwa zagadnienia pamięci masowej, przykładając największą wagę do ochrony systemu operacyjnego (który był bardzo trudny do odtworzenia po awarii i od którego zależała dostępność danych) na wysoce niezawodnym RAID 1. Tańszy RAID 5, choć nieco bardziej ryzykowny, był zazwyczaj wybierany do danych, ponieważ koszt przechowywania ich na RAID 1 był w większości przypadków zbyt wysoki. Był to kompromis, który miał wówczas sens.

Dziś, z naszymi zupełnie innymi wymaganiami, potrzebne jest nowe podejście, znane jako „Jeden Duży RAID 10” – czyli jedna, duża macierz RAID 10, w której przechowywane są razem system operacyjny, aplikacje i dane. Oczywiście, to tylko uproszczenie – w systemie, który nie wymaga wydajności ani pojemności wykraczającej poza jeden dysk, powiedzielibyśmy „Jeden Duży RAID 1”, ale wielu ludzi zalicza RAID 1 do grupy RAID 10, więc łatwiej posługiwać się tym pierwszym terminem.

Dla wygody skracamy to do OBR10.

Ponieważ koszt pamięci masowej znacznie spadł i zamiast być dobrem deficytowym, jest dziś zazwyczaj dostępna w obfitości; ponieważ systemy plików są niezwykle niezawodne; ponieważ RAID 1 i RAID 10 mają podobne charakterystyki wydajnościowe; oraz ponieważ awarie macierzy wywołane czynnikami innymi niż awaria dysku przeszły z poziomu szumu tła do głównych przyczyn utraty danych – przejście na RAID 10 i eliminacja podziału macierzy stało się nowym standardem.

Z RAID 10 mamy teraz wysoce dostępną i odporną pamięć masową, która wcześniej zarezerwowana była wyłącznie dla systemu operacyjnego, a teraz dostępna dla wszystkich naszych danych. Zyskujemy korzyści płynące z lustrzanej wydajności RAID oraz dodatkowe wrzeciona dla wszystkich danych. Uzyskujemy lepsze wykorzystanie pojemności dysków i wydajność opartą na tym ulepszonym wykorzystaniu.

Nawet tradycyjny podział plików dziennika, normalnie stosowany w bazach danych (słynne podejście RAID 1 + RAID 5 + RAID 1), nie jest już potrzebny, ponieważ RAID 10 utrzymuje optymalne charakterystyki wydajnościowe dla wszystkich danych. Dzięki RAID 10 eliminujemy niemal wszystkie czynniki, które kiedyś skłaniały nas do dzielenia macierzy.

Jedynym istotnym czynnikiem, o którym nie wspomniano, za który tradycyjnie uważano podział macierzy za korzystny, jest rywalizacja o dostęp – sytuacja, gdy różne procesy potrzebują jednocześnie dostępu do różnych części dysku, powodując ruch głowicy dysku w mniej niż idealnym wzorcu i obniżając wydajność dysku. Rywalizacja o dostęp była poważnym problemem pod koniec lat 90., gdy powstawała stara zasada kciuka.

Dziś rywalizacja o dyski nadal istnieje, ale została znacznie złagodzona dzięki zastosowaniu dużych pamięci podręcznych RAID. Pod koniec lat 90. cache dysków wynosiły kilka megabajtów co najwyżej, a często nie istniały wcale. Dziś 256 MB to mały cache, a przeciętne serwery są wdrażane z 1-2 GB pamięci podręcznej samej karty RAID. Niektóre systemy zaczynają integrować dodatkowe pamięci podręczne oparte na dyskach SSD, dodając drugorzdną pamięć cache poza pamięcią cache kontrolera. Mogą one z łatwością dodać setki gigabajtów niezwykle szybkiej pamięci cache, która może buforować niemal każdą operację na wrzecionie bez konieczności martwienia się o rywalizację. Problem rywalizacji został więc rozwiązany w inny sposób, ale – jak inne zmiany technologiczne – skutecznie uwolnił nas od tradycyjnych obaw wymagających podziału macierzy.

Podobnie jak rywalizacja o macierze, innym, znacznie rzadszym powodem podziału macierzy pod koniec lat 90. było poprawienie wydajności magistrali komunikacyjnej ze względu na ograniczenia ówczesnych technologii SCSI i ATA. Również te przeszkody zostały wyeliminowane wraz z przejściem na szeregowe mechanizmy komunikacji, SAS i SATA, w nowoczesnych macierzach. Nie jesteśmy już ograniczeni pojemnością jednej magistrali dla każdej macierzy i możemy rozrastać się znacznie bardziej i z większą elastycznością niż wcześniej. Rywalizacja o magistralę została praktycznie wyeliminowana.

Jeśli istnieje potrzeba wydzelenia przestrzeni dla ochrony, na przykład ze względu na wzrost plików dziennika, można to osiągnąć przez partycjonowanie, a nie fizyczny podział macierzy. Zasadniczo warto minimalizować partycjonowanie, ponieważ zwiększa ono narzut i obniża możliwości auto-strojenia dysków, ale są przypadki, gdy jest to lepsze podejście. Nie wymaga jednak podziału fizycznej pamięci masowej, jak to robiło się tradycyjnie. Jeszcze lepszym rozwiązaniem niż partycjonowanie – gdy jest dostępne – jest zarządzanie wolumenami logicznymi (LVM), które pozwala na separacje podobne do partycji bez ich ograniczeń.

Zatem nową zasadą kciuka dla pamięci masowej serwerów jest „Jeden Duży RAID 10”. Koniec z RAID 5, koniec z podziałem macierzy. Chodzi o niezawodność, wydajność, łatwość zarządzania i umiarkowną opłacalność. Jak wszystkie zasady kciuka, nie dotyczy ona każdego przypadku z osobna, ale ma znacznie szersze zastosowanie niż stary standard. RAID 1 + RAID 5 jako standard był zawsze próbą „radzenia sobie” z czymś niepożądanym i wyciągania jak najlepszego z trudnej sytuacji. OBR10 nie jest takie. Nowy standard jest pożądanym standardem – to sposób, w jaki naprawdę chcemy działać, a nie coś, z czym jesteśmy „uwiązani”.

Projektując pamięć masową dla nowego serwera, zacznij od OBR10 i odójdź od niego tylko wtedy, gdy konkretnie nie spełnia Twoich potrzeb technologicznych. Nie powinieneś nigdy musieć uzasadniać używania OBR10 – jedynie uzasadniać nieuUżywanie go.