RAID0 zamiast RAID1 lub 5, czy to szalone?

Rozważam użycie konfiguracji RAID0 dla jednego z naszych klastrów SQL Server. Opiszę sytuację i szukam, dlaczego może to być zły pomysł. Również jeśli ktoś, kto ma przypadki użycia, białe księgi lub inną dokumentację, może wskazać mi ten temat, byłoby świetnie.

Mamy 3 serwery w 2 centrach danych, które są częścią klastra SQL. Wszystkie działają z programem SQL Server w grupie dostępności. Podstawowa ma replikę znajdującą się tuż obok niej, a drugą w innym centrum danych. Działają replikacji synchronicznej z automatycznym przełączaniem awaryjnym. Wszystkie dyski są dyskami SSD klasy korporacyjnej. Będą działać SQL Server 2017 lub 2019.

Sądzę, że korzystanie z nich na macierzach RAID0 przyniosłoby wiele korzyści w porównaniu z innymi metodami, z niewielkimi, jeśli w ogóle, istotnymi wadami. Jedynym minusem, który obecnie widzę, jest brak nadmiarowości na serwerze podstawowym, więc jego awaria wzrasta. Jako profesjonaliści:

1. Jeśli dysk ulegnie awarii, zamiast pracować w spowolnionym, zdegradowanym stanie, dopóki ktoś nie otrzyma powiadomienia o ręcznym działaniu na nim, serwer natychmiast przejdzie w stan awaryjny, utrzymując pełną zdolność operacyjną. Dodatkową korzyścią będzie powiadomienie nas o przełączeniu awaryjnym, abyśmy mogli wcześniej zbadać przyczynę.

2. Zmniejsza to ogólne ryzyko awarii na pojemność TB. Ponieważ nie potrzebujemy napędów parzystości lub dublowania, zmniejszamy liczbę napędów na macierz. Przy mniejszej liczbie dysków istnieje mniejsze całkowite prawdopodobieństwo awarii dysku.

3. To jest tańsze. Potrzebowanie mniejszej liczby dysków do uzyskania wymaganej pojemności oczywiście kosztuje mniej.

Wiem, że to nie jest konwencjonalne myślenie biznesowe, ale czy jest coś, czego nie rozważam? Chciałbym mieć jakikolwiek wkład zarówno za, jak i przeciw.

Nie próbuję tego robić w celu zwiększenia wydajności zapytań, ale jeśli są sensowne, możesz je wskazać. Moim głównym zmartwieniem jest to, że nie rozważałem ani nie rozwiązałem problemu z niezawodnością lub redundancją, o którym nie myślałem.

System operacyjny znajduje się na osobnym dysku lustrzanym, więc sam serwer powinien pozostać bezczynny. Jeden z tych dysków można wymienić i ponownie utworzyć kopię lustrzaną. Jest mały i nie ma na nim żadnych plików bazy danych innych niż systemowe bazy danych. Nie mogę sobie wyobrazić, że zajmie to więcej niż minuty. Jeśli jedna z tablic danych zawiedzie, wymieniamy dysk, odbudowujemy tablicę, przywracamy i ponownie synchronizujemy z AG. Z mojego osobistego doświadczenia, przywracanie było DUŻO szybsze niż przebudowywanie dysku RAID5. Nigdy nie miałem awarii RAID1, więc nie wiem, czy ta odbudowa będzie szybsza, czy nie. Przywracania będą pochodzić z kopii zapasowej i zostaną przeniesione do pierwotnego, więc wzrost obciążenia na serwerze podstawowym powinien być bardzo minimalny, synchronizując tylko kilka ostatnich minut dzienników z odzyskaną repliką.

Jest jeden bardzo ważny aspekt, który moim zdaniem brakuje w ocenie:

Jak planujesz odzyskać?

Kiedy raid5 straci dysk, będzie działał w stanie zdegradowanym, dopóki nie odzyska się automatycznie. (Przynajmniej jeśli masz pod ręką zapasowy zapas).

Kiedy raid0 traci napęd, nie może w ogóle się zregenerować. Oznacza to, że straciłeś nadmiarowość i aby go odzyskać, musisz odbudować swój RAID0 i skopiować wszystkie dane (nie tylko dane na uszkodzonym dysku) z powrotem z pomocniczego, który jest teraz obciążony produkcyjnie. Oznacza to, że zamiast pojedynczej zdegradowanej macierzy raid5, teraz cała konfiguracja produkcyjna ma wpływ na wydajność.

Jeśli kara za obniżenie wydajności raid5 (lub raid6) nie jest czymś, z czym można sobie poradzić, prawdopodobnie zamiast tego należy wykonać nalot 1 + 0 . Tak, kosztuje więcej, ale ceny dysków są takie, jakie są, będą to dobrze wydane pieniądze.

Może „aktywne monitorowanie stanu RAID5 i przeniesienie obciążenia z pierwotnego w przypadku awarii dysku” to rozwiązanie, które zapewnia większość korzyści bez żadnych wad? (Oprócz utraty chłód czynnik działa bez lokalnego redundancji, oczywiście). Jeśli dysk odzyskiwania RAID5 trwa o wiele dłużej niż pełnej synchronizacji danych w bazie, albo oprogramowanie RAID to dziwnie, albo trzeba poważnie dysków ponadwymiarowych, Pomyślałbym.

Tutaj należy wziąć pod uwagę awarię napędu.

Wyobraź sobie przez chwilę, że nasze dyski w danym dniu mają wskaźnik awarii 1/1000. Wyobraź sobie, że mamy 20 dysków w każdej z naszych 3 tablic.

Dlatego prawdopodobieństwo awarii jednego dysku w macierzy wynosi 20/1000 = 1/50. Szansa na awarię dwóch dysków w tej samej macierzy jest bliska 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000. Tak więc, przechodząc z RAID 0 na RAID 5, jesteśmy już znacznie mniej skłonni do zabicia jednej z naszych tablic.

Możemy więc pójść o krok dalej - jeśli szansa na awarię tablicy w ciągu dnia wynosi 1/50, wówczas prawdopodobieństwo awarii dwóch tablic w ciągu dnia wynosi 1 / (50 * 50) = 1/2500. Szanse na awarię dwóch identycznych macierzy RAID 0 są dwa razy większe niż awarii jednej macierzy RAID 5, przy założeniu tego samego zestawu dysków. Ten wykładniczy wzrost szans na awarię powinien cię dotyczyć, ponieważ znacznie zwiększa prawdopodobieństwo, że więcej niż jedna tablica ulegnie awarii jednocześnie.

Ponieważ te dyski prawdopodobnie będą miały długi okres użytkowania, możesz prawdopodobnie uruchomić liczby jak wyżej i bezpośrednio zobaczyć, jaki będzie to miało wpływ na niezawodność - jeśli możesz opublikować specyfikacje dysków, mogę dodać te obliczenia do tego postu. To, czy ryzyko jest wtedy akceptowalne, czy nie, należy do decyzji organizacji.

Inną kwestią, na którą należy zwrócić uwagę, jest to, że prawdopodobieństwo awarii dysku można zwiększyć, wykorzystując dyski SSD wyprodukowane w tej samej partii (ta sama fabryka, ten sam czas). Jeśli nie będziesz ostrożny, może dojść do awarii wszystkich 3 węzłów z powodu tego problemu.

Oświadczenie: Powyższe obliczenia zostały uproszczone - są one nadal stosunkowo dokładne.

Sądzę, że korzystanie z nich na macierzach RAID0 przyniosłoby wiele korzyści w porównaniu z innymi metodami, z niewielkimi, jeśli w ogóle, istotnymi wadami.

Jest to dość powszechna konfiguracja podczas uruchamiania AG z wewnętrznymi / podłączonymi bezpośrednio dyskami pamięci. Zwłaszcza w przypadku NVMe lub innych urządzeń pamięci flash opartych na PCI.

Sprowadza się to do traktowania awarii dysku jako awarii serwera. Przy małej liczbie dysków półprzewodnikowych tak naprawdę nie masz znacznie niższego MTBF dla dysków niż dla innych półprzewodnikowych komponentów serwera, więc po prostu traktujesz każdy dysk jako punkt awarii dla serwer i wymień / przebuduj serwer w przypadku awarii dysku.

Jestem zaintrygowany tym, co próbujesz osiągnąć? Wspominasz o sobie, że nie próbujesz uzyskać wzrostu wydajności dzięki tej konfiguracji, więc jaki zysk próbujesz uzyskać?

Uwaga na temat wydajności: jeśli używasz dysków SSD klasy Enterprise, czy obliczenia RAID są tak wąskim gardłem, że musisz je poprawić?

Biorąc swoje 3 profesjonalistów, nie sądzę, żebyś wystarczająco dobrze to przemyślał:

1. Czy SQL failover od razu? Co spowoduje automatyczne przełączenie awaryjne? Czy serwer przełączy dysk w tryb offline, gdy tylko ktoś go uderzy? Co jeśli to tylko zły sektor na jednym dysku? Jeśli SQL nie trafi w zły sektor, czy przejdzie w tryb failover? Nie jestem tego w 100% pewien.

2. Czy zmniejsza to ogólne ryzyko awarii na pojemność TB? Twoje myślenie wydaje się być mniejszą liczbą dysków oznacza mniej punktów awarii, ale nie sądzę, że tak jest. Szanse na awarię 1 dysku pozostają takie same, jeśli masz 1 dysk lub 10 dysków (lub 100 dysków), ale w przypadku RAID 0 oznacza to także katastrofalną awarię.

3. Czy jeden dodatkowy dysk SSD będzie kosztował zbyt wiele, aby uzyskać RAID5? Rozumiem, jak RAID1 OR 1 + 0 może zniszczyć budżet, ale 1 dodatkowy dysk?

Bez nadmiarowości, jeśli dysk ulegnie awarii, a RAID przejdzie w tryb offline, ten węzeł będzie w trybie offline, dopóki nie odbudujesz RAID i nie przywrócisz wszystkich baz danych od zera. Jak zamierzasz to zrobić? Nie możesz usunąć bazy danych z grupy dostępności, ponieważ zatrzyma to replikację do DR, ale jeśli nie podejmiesz żadnych działań, pozostałe dwa serwery nie będą mogły obciąć swoich plików dziennika. Czy to w porządku? Co się stanie, jeśli zawiedzie w piątkowy wieczór długiego weekendu? Czy to nadal w porządku? Czy Twoje pomocnicze instytucje poradzą sobie z gromadzeniem się takiej ilości danych?

Moje ostatnie pytania będą dotyczyły czasu odbudowy, o którym wspominasz, będzie szybsze. Czy jesteś w 100% pewien, że będzie szybciej? O ile szybciej?

Konfiguracja serwera Brent Ozar jest nadal moim przewodnikiem do konfigurowania nowych instancji SQL. Pierwszym punktem tego przewodnika jest sprawdzenie, czy nie używasz RAID0 dla żadnych dysków.

==== AKTUALIZACJA ====

Jeszcze jedna myśl, co się stanie, gdy twoje serwery dodatkowe nie będą zsynchronizowane z twoim głównym? Nawet w przypadku synchronicznej replikacji Twoje pomocnicze urządzenia mogą nadal automatycznie powracać do asynchronizacji, a gdy to zrobisz, utracisz możliwość automatycznego przełączania awaryjnego, ponieważ każde przełączenie awaryjne spowoduje utratę danych. Kilka przykładów, kiedy to może się zdarzyć:

1. Przebudowa bardzo dużego indeksu - replikacja może pozostawać w tyle w jednym lub w obu wtórnych
2. Awaria dysku na RAID0 podczas łatania dodatkowego. Serwer, który łatasz, może nie być w stanie wrócić do trybu online, ponieważ podstawowy jest offline.

Są to przypadki skrajne, ale mogą być katastrofalne w zależności od tego, co utracono w tamtych czasach.