RAID 10 w serwerach VPS: jak działa i czy jest bezpieczny

Czym jest RAID 10 i dlaczego dostawcy VPS go stosują

RAID 10 to układ pamięci masowej najczęściej wykorzystywany przez dostawców VPS w środowiskach zwirtualizowanych na dyskach NVMe (non-volatile memory express). Polega on na dublowaniu każdego dysku na dysk partnerski, a następnie rozpraszaniu danych (striping) pomiędzy tak utworzonymi parami. Awaria jednego dysku nie powoduje zatrzymania macierzy, a proces naprawy polega na bezpośrednim kopiowaniu danych z działającego partnera, zamiast na przeliczaniu sum kontrolnych z pozostałych dysków w zestawie.

RAID oznacza nadmiarową macierz niezależnych dysków (redundant array of independent disks). Jego jedynym zadaniem jest utrzymanie ciągłości pracy serwera w trakcie awarii lub wymiany dysku. Zadaniem tym jest zapewnienie dostępności, a dostępność nie jest tożsama z bezpieczeństwem danych.

RAID replikuje operacje zapisu. rm -rf /srv jest operacją zapisu. Obie połowy lustra usuwają katalog w tej samej milisekundzie, a macierz po tej operacji nadal raportuje stan jako poprawny.

Należy zapamiętać to zdanie. Pozostała część tej strony omawia odporność poszczególnych poziomów RAID oraz koszt wydajnościowy każdej operacji zapisu. Ostatnie sekcje zawierają polecenia służące do odczytu stanu macierzy na własnym serwerze oraz opis awarii, przed którymi RAID nie chroni.

Poziomy RAID, z którymi faktycznie spotyka się nabywca hostingu: 1, 5, 6 oraz 10

Strona z ofertą podaje liczbę i na tym kończy. Liczba ta odpowiada na dwa pytania: ile dysków może ulec awarii oraz jaki jest koszt każdego zapisu.

RAID 1 to lustrzane odbicie. Dwa dyski przechowują identyczne bloki. Każdy zapis trafia na oba. Każdy z dysków może obsłużyć odczyt. Jeden dysk może ulec awarii bez utraty danych, a do użytku pozostaje połowa pojemności surowej. Brak sum kontrolnych (parity) skraca ścieżkę zapisu.

RAID 5 to striping z jednym blokiem sumy kontrolnej na każdy pasek. Przy n dyskach otrzymuje się pojemność n-1 z nich, a macierz przetrwa dokładnie jedną awarię. Suma kontrolna nie znajduje się na jednym dedykowanym dysku. Rotuje ona pomiędzy wszystkimi dyskami, więc każdy z nich przechowuje zarówno dane, jak i sumy kontrolne.

RAID 6 dodaje drugi, niezależny blok sumy kontrolnej do każdego paska, zazwyczaj oznaczany jako P i Q. Przetrwa on jednoczesną awarię dowolnych dwóch dysków. Ma to większe znaczenie, niż mogłoby się wydawać, ponieważ druga awaria najczęściej występuje w trakcie odbudowy po pierwszej.

RAID 10 to striping z lustrzanych odbić. Dyski są łączone w pary lustrzane, a dane są rozpraszane pomiędzy tymi parami. Użytkowa pojemność to połowa sumy surowej, podobnie jak w RAID 1, z dodatkową zaletą w postaci równoległości stripingu.

Można również spotkać się z zapisem RAID 1+0, który jest uczciwym opisem: najpierw lustro, potem striping pomiędzy lustrami. RAID 0+1 to odwrotna kolejność: najpierw striping, a potem lustrzane odbicie dwóch pasków. Jest to rozwiązanie gorsze, ponieważ awaria jednego dysku wyłącza z pracy cały pasek, a naprawa wymaga skopiowania całej drugiej strony.

Linux stanowi szczególny przypadek, o którym warto wiedzieć. Jądro systemu posiada raid10, który jest pojedynczą strukturą, a nie dwiema nałożonymi na siebie warstwami. Dzięki temu działa on na nieparzystej liczbie dysków i posiada układy (near, far, offset), których zagnieżdżona konfiguracja nie jest w stanie odwzorować. Dlatego linia statusu na maszynie z systemem Linux wyświetla 2 near-copies zamiast wskazywać dwie macierze.

[
  {
    "label": "RAID 1 (four mirrored pairs)",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  },
  {
    "label": "RAID 5",
    "usable_tb": 7,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 1
  },
  {
    "label": "RAID 6",
    "usable_tb": 6,
    "worst_case_drives_lost": 2,
    "best_case_drives_lost": 2
  },
  {
    "label": "RAID 10",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  }
]

Osiem dysków 1 TB daje 7 TB przestrzeni użytkowej w RAID 5 oraz 4 TB w RAID 10. Ta różnica to realne pieniądze i dlatego wciąż proponuje się rozwiązania oparte na sumach kontrolnych. RAID 6 przetrwa 2 awarie w dowolnym układzie. RAID 10 gwarantuje jedynie 1, ponieważ niebezpieczna druga awaria to taka, która dotknie partnera dysku, który już uległ uszkodzeniu. Przetrwa on do 4 awarii, jeśli żadne dwie z nich nie dotkną tej samej pary, co jest jednak kwestią szczęścia, a nie cechą konstrukcyjną.

Koszt każdej operacji zapisu na poszczególnych poziomach

Zapis w macierzy typu mirror wymaga dwóch operacji zapisu, wykonywanych jednocześnie dla obu członków. Zapis w pasie parzystości jest bardziej złożony, ponieważ istniejący blok parzystości dla tego pasa staje się nieaktualny i wymaga ponownego obliczenia.

Kontroler nie jest w stanie przeliczyć parzystości wyłącznie na podstawie nowego bloku. Wymaga najpierw odczytania starego bloku danych oraz starego bloku parzystości. W rezultacie pojedynczy, niewielki zapis losowy w RAID 5 przekłada się na operacje: odczyt, odczyt, zapis, zapis. RAID 6 wymaga utrzymania dodatkowej sumy kontrolnej, więc ten sam zapis wymaga operacji: odczyt, odczyt, odczyt, zapis, zapis, zapis.

[
  {
    "label": "RAID 1 (2 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  },
  {
    "label": "RAID 5 (8 drives)",
    "write_ops_per_host_write": 4,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 6 (8 drives)",
    "write_ops_per_host_write": 6,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 10 (8 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

Niewielki zapis losowy kosztuje 6 operacji urządzenia w RAID 6 oraz 2 w RAID 10. Liczby te nie oddają w pełni różnicy w opóźnieniach. Dwa zapisy w mirrorze odbywają się równolegle, więc system gościa oczekuje na zakończenie wolniejszej z tych operacji. Ścieżka parzystości zawiera odczyt, który musi zostać zakończony przed obliczeniem nowej parzystości, co oznacza, że system gościa czeka najpierw na odczyt, a następnie na zapis. Na obciążonym hoście ten odczyt trafia do kolejki za operacjami I/O innych procesów.

Istnieje istotny wyjątek. Zapis wystarczająco duży, aby wypełnić cały pas, nie wymaga starych danych, ponieważ każdy blok w pasie jest zastępowany. Parzystość obliczana jest na podstawie danych znajdujących się już w pamięci, a koszt operacji ogranicza się do jednego dodatkowego zapisu. Dlatego RAID 5 wypada dobrze w testach sekwencyjnych, ale zachowuje się nieefektywnie przy mieszanym obciążeniu wieloma małymi zapisami od wielu użytkowników. Należy testować wzorce odpowiadające rzeczywistemu obciążeniu: poprawne testowanie wydajności dysku VPS oznacza operacje I/O losowe przy realistycznej głębokości kolejki, a nie pojedynczy duży dd.

Dlaczego przebudowa jest ryzykownym etapem

Przebudowa parzystości wymaga odtworzenia brakującego dysku na podstawie wszystkich pozostałych, co oznacza odczyt 7 działających dysków od pierwszego do ostatniego bloku. Przebudowa RAID 10 odczytuje 1: tylko partnera lustrzanego uszkodzonego dysku i nic więcej.

Wynikają z tego dwa obciążenia. Pierwszym jest czas, ponieważ przebudowa jest ograniczona przez najwolniejszy działający dysk oraz dodatkowe obliczenia parzystości. Drugim jest obciążenie. Każdy dysk w zestawie parzystości jest zajęty przez cały czas trwania operacji, więc każda maszyna wirtualna na tym węźle odczuwa wyższe opóźnienia aż do zakończenia procesu. W RAID 10 zajęta jest tylko jedna para, a pozostałe działają z normalną prędkością.

W tym samym czasie istnieje ryzyko utraty spójności danych. Macierz RAID 5 z jednym uszkodzonym dyskiem nie posiada już redundancji, więc każdy nieczytelny sektor na pozostałych dyskach staje się niemożliwy do odzyskania. Przebudowa jest operacją, która odczytuje każdy sektor, w tym te, do których nikt nie odwoływał się od roku. Dane techniczne producentów określają wskaźnik błędów nie do odzyskania dla konsumenckich dysków twardych na poziomie jednego na 10^14 odczytanych bitów, a dla dysków NVMe klasy enterprise na poziomie jednego na 10^17 lub lepszym. Są to specyfikacje producenta, a nie pomiary, ale ta proporcja wyjaśnia, dlaczego dawne ostrzeżenie o niepowodzeniu przebudowy RAID 5 dotyczyło dużych dysków talerzowych i dlaczego jest znacznie mniej istotne w przypadku NVMe. Argument dotyczący obciążenia pozostaje aktualny dla każdego nośnika.

Wykrywaj ukryte błędy przed przebudową za pomocą operacji scrubbing. Systemy Debian i Ubuntu oferują okresowe sprawdzanie macierzy md, a mechanizm różni się w zależności od wydania, więc sprawdź używaną wersję, a następnie uruchom proces ręcznie.

systemctl list-timers --all | grep -i mdcheck
ls -l /etc/cron.d/mdadm
echo check | sudo tee /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt

sync_action wraca do idle po zakończeniu przebiegu, a mismatch_cnt powinno wskazywać 0. Wartość powyżej zera w macierzy lustrzanej oznacza, że obie połowy nie są zgodne, a jądro nie jest w stanie stwierdzić, która jest poprawna, ponieważ żadna kopia nie posiada sumy kontrolnej. Niektóre niezgodności są nieszkodliwe, a ich częstym źródłem są partycje wymiany: jądro może zapisać stronę, która zmienia się w trakcie operacji. Rosnąca liczba błędów w macierzy danych oznacza konieczność wymiany dysku.

Dlaczego dostawcy VPS standaryzują RAID 10 dla NVMe

Węzeł hiperwizora nie obsługuje jednego obciążenia. Uruchamia dziesiątki niezależnych systemów gości, a ich operacje wejścia/wyjścia docierają jako przeplatany strumień małych zapisów bez lokalności danych. Jest to dokładnie ten wzorzec, w którym cykl odczytu-modyfikacji-zapisu z parzystością generuje najwyższe koszty, a współdzielony węzeł doświadcza go przez cały czas.

Jeśli uwzględni się zachowanie podczas odbudowy, wybór staje się oczywisty. Awaria dysku w węźle z parzystością spowalnia każdego gościa na serwerze przez wiele godzin. Awaria dysku w węźle RAID 10 spowalnia tylko jedną parę, a kopiowanie odbywa się sekwencyjnie z prędkością dysku. Dostawcy sprzedają opóźnienia, które nie wykazują skoków, więc kupują je kosztem pojemności: połowa surowej przestrzeni NVMe jest przeznaczana na lustrzane odbicie.

Rozmiary dysków wymuszają to samo podejście. W miarę wzrostu pojemności dysków czas odbudowy się wydłuża, a w przypadku parzystości jest to okres, w którym wszystko działa wolno, a dane nie są chronione. Z tego samego powodu wdrożenia ZFS dla wirtualizacji wykorzystują pule lustrzanych vdev zamiast szerokich raidz: resilvering lustra kopiuje tylko bloki faktycznie używane, na jednej parze.

Nic z tego nie czyni RAID 10 rozwiązaniem uniwersalnym. Cel dla kopii zapasowych jest zapisywany długimi sekwencjami i rzadko odczytywany, więc RAID 6 jest tam lepszym wyborem. Przetrwa dwie awarie i pozwala odzyskać większość pojemności. O wyborze decyduje obciążenie, a nie liczba. W przypadku planu wybieranego dzisiaj, nośnik zazwyczaj ma większe znaczenie niż układ na nim zastosowany, a przeskok z SATA SSD na NVMe jest większy niż jakakolwiek różnica wynikająca z typu RAID na obu tych nośnikach.

Jak odczytywać /proc/mdstat

Uruchom poniższe polecenia na maszynie, na której zarządzasz macierzą: serwerze dedykowanym, domowym komputerze lub VPS z dwoma podłączonymi wolumenami, które samodzielnie skonfigurowałeś. Przeanalizuj własne dane wyjściowe. Poniższe bloki to przykłady, przygotowane tak, aby można było dopasować je do wyglądu otrzymywanych informacji.

cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

Sprawna macierz RAID 10 złożona z czterech dysków wyświetla dane zbliżone do poniższych.

Personalities : [raid1] [raid10]
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

Każdy element tego zapisu zawiera istotne informacje.

• Personalities wymienia moduły md załadowane w działającym jądrze. Pojawienie się raid10 oznacza jedynie, że kod jest dostępny.
• md0 : active raid10 to urządzenie macierzy, jego stan oraz poziom RAID.
• Nazwy po tym wpisie to elementy składowe. Liczba w nawiasach kwadratowych to indeks urządzenia w metadanych macierzy, a nie jego pozycja w linii czy fizyczny slot.
• Po wymianie dysku nowy element zazwyczaj otrzymuje wyższy indeks niż slot, który zajmuje, więc nvme4n1p3[4] może znajdować się w slocie 2. mdadm --detail wyświetla rzeczywisty slot w kolumnie RaidDevice, dlatego należy korzystać z tej wartości, gdy różnica ma znaczenie.
• (F) po elemencie oznacza awarię. (S) oznacza dysk zapasowy (spare): obecny, bezczynny, oczekujący na awarię innego elementu.
• 3906764800 blocks super 1.2 to użyteczny rozmiar w blokach 1 KiB, a następnie format metadanych.
• 512K chunks 2 near-copies to rozmiar fragmentu (chunk size) oraz układ RAID 10, który w tym przypadku przechowuje dwie kopie każdego bloku obok siebie.
• [4/4] to liczba elementów oczekiwanych przez macierz, a następnie liczba aktualnie zsynchronizowanych.
• [UUUU] to jeden znak na slot, w kolejności slotów. U oznacza slot działający i zsynchronizowany. _ oznacza slot, w którym nic nie działa.
• bitmap: to mapa bitowa intencji zapisu (write intent bitmap). Rejestruje ona regiony, w których trwał zapis, dzięki czemu element, który wypadł i powrócił, synchronizuje tylko te regiony zamiast całego dysku.

Co oznaczają [4/3] oraz [UU_U] w przypadku awarii

Zdegradowana macierz wygląda następująco.

md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2](F) nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]

Odczytuj oba nawiasy łącznie. [4/3] informuje, że jeden z czterech slotów nie uczestniczy w pracy. [UU_U] wskazuje który, ponieważ znak podkreślenia jest trzecim znakiem, a sloty są numerowane od zera, więc slot 2 jest wyłączony. Flaga (F) wskazuje urządzenie tylko wtedy, gdy uszkodzony dysk jest nadal podłączony. Po fizycznym usunięciu dysku z maszyny nazwa znika z linii, podczas gdy znak podkreślenia pozostaje.

Macierz kontynuuje pracę mimo tych problemów, a w przypadku RAID 10 często działa z niemal pełną prędkością, przez co awaria bywa niezauważalna podczas codziennego użytkowania. System musi powiadomić administratora.

grep -i mailaddr /etc/mdadm/mdadm.conf
sudo mdadm --monitor --scan --oneshot --test
systemctl list-units --all | grep -i md

Pakiet mdadm instaluje demona monitorującego, który odczytuje MAILADDR z /etc/mdadm/mdadm.conf. Nazwa jednostki zmieniała się między wydaniami, więc należy ją odnaleźć za pomocą ostatniego polecenia, zamiast zgadywać. Uruchomienie --test wysyła natychmiast jedną wiadomość na macierz. Pusta skrzynka odbiorcza po tym działaniu oznacza, że ścieżka pocztowa jest uszkodzona, więc istotne powiadomienia również nie dotrą do adresata.

Gdy trwa odbudowa po wymianie dysku, pod macierzą pojawia się linia postępu.

md0 : active raid10 nvme4n1p3[4] nvme3n1p3[3] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [==>..................]  recovery = 12.4% (242012928/1953382400) finish=63.1min speed=452000K/sec

recovery to odbudowa na dysk zastępczy. resync to pierwszy przebieg sprawdzający spójność nowo utworzonej macierzy. check to proces scrub wywołany wcześniej. Para w nawiasach to postęp w blokach 1 KiB względem całkowitej pojemności urządzenia, a finish to szacowany czas zakończenia według jądra przy obecnej prędkości. Prędkość ta jest ograniczona przez /proc/sys/dev/raid/speed_limit_min oraz speed_limit_max; limity te istnieją, aby odbudowa nie wyczerpywała zasobów I/O dla aplikacji produkcyjnych.

/dev/md0:
           Version : 1.2
     Creation Time : Tue Mar 10 09:14:22 2026
        Raid Level : raid10
        Array Size : 3906764800 (3.64 TiB 4.00 TB)
     Used Dev Size : 1953382400 (1.82 TiB 2.00 TB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Wed Aug  5 11:02:41 2026
             State : clean, degraded, recovering
    Active Devices : 3
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 1

            Layout : near=2
        Chunk Size : 512K

    Rebuild Status : 12% complete

              Name : storage:0
            Events : 4184

    Number   Major   Minor   RaidDevice State
       0     259        3        0      active sync set-A   /dev/nvme0n1p3
       1     259        7        1      active sync set-B   /dev/nvme1n1p3
       4     259       11        2      spare rebuilding    /dev/nvme4n1p3
       3     259       15        3      active sync set-B   /dev/nvme3n1p3

Wymiana dysku w posiadanej macierzy składa się z czterech poleceń, a ostatnie z nich służy do weryfikacji.

sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstat

Linia odzyskiwania powinna pojawić się w ciągu sekundy lub dwóch. Partycja zastępcza musi być co najmniej tak duża jak Used Dev Size z mdadm --detail; partycja nawet nieznacznie mniejsza zostanie odrzucona z komunikatem w formacie not large enough to join array. Przed dodaniem nowego dysku należy go spartycjonować tak, aby odpowiadał staremu.

Co można, a czego nie można zobaczyć z wnętrza VPS

Większość systemów gości nie ma wglądu w macierz RAID hosta i jest to rozwiązanie celowe. Hypervisor udostępnia użytkownikowi jeden wirtualny dysk. To, czy dysk ten został wydzielony z puli RAID 10 opartej na nośnikach NVMe, czy znajduje się na pojedynczym napędzie, jest właściwością hosta i nie jest widoczne z poziomu systemu gościa.

systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstat

systemd-detect-virt wyświetla kvm w przypadku gościa KVM, typ kontenera, taki jak lxc w przypadku kontenera, oraz none na serwerze typu bare metal. W systemie gościa KVM zazwyczaj widoczny jest pojedynczy vda lub sda w lsblk, natomiast w /proc/mdstat nie widać żadnych macierzy, ponieważ wewnątrz systemu gościa one nie istnieją.

W przypadku VPS opartego na kontenerach odczyty nie są wiarygodne. Kontenery współdzielą jądro systemu hosta, a części /proc nie są objęte przestrzeniami nazw (namespacing), dlatego odczytane tam informacje mogą opisywać hosta, a nie przydzielony użytkownikowi wycinek zasobów. Żadnej z tych informacji nie należy traktować jako faktu dotyczącego własnej pamięci masowej. W razie potrzeby należy zapytać dostawcę o architekturę systemu i uzyskać odpowiedź na piśmie.

Z wnętrza systemu można sprawdzić zachowanie przydzielonego dysku. Sprawdzanie, czy dysk VPS faktycznie jest typu NVMe zawiera polecenia raportujące rzeczywiste parametry, a co faktycznie zawiera VPS z dyskiem SSD opisuje, co w rzeczywistości oznacza etykieta na stronie oferty.

Czy należy stosować RAID wewnątrz VPS?

Zazwyczaj nie, a powodem są domeny awarii. Jeśli podłączysz dwa wolumeny do jednego VPS i utworzysz z nich lustro za pomocą mdadm, oba wolumeny mogą znajdować się w tej samej macierzy fizycznej, na tym samym węźle i być zasilane z tego samego zasilacza. Podwoisz koszt każdego zapisu w zamian za redundancję, którą już posiadasz, a mimo to stracisz obie kopie w przypadku wystąpienia kluczowej awarii.

Stosowanie RAID ma sens, gdy dostawca dokumentuje, że wolumeny znajdują się w oddzielnych domenach awarii lub gdy korzystasz z serwera dedykowanego z dyskami, którymi możesz zarządzać. W przeciwnym razie nakład pracy lepiej przeznaczyć na tworzenie kopii zapasowych, które opuszczają daną maszynę.

Przed czym RAID nie chroni

RAID zabezpiecza przed jednym zdarzeniem: awarią dysku. Każda operacja zapisu jest uznawana za poprawną, więc macierz wykonuje ją na wszystkich kopiach i zgłasza stan gotowości.

• Usunięcie danych. rm -rf w niewłaściwym katalogu lub skrypt wdrażający z niezdefiniowaną zmienną w ścieżce. Macierz traktuje to jako poprawne polecenie zapisu i wykonuje je dwukrotnie.
• Ransomware. Szyfrowanie to operacja zapisu. Sprawna macierz zapisuje zaszyfrowaną wersję na obu połowach lustra.
• Błędne działanie aplikacji. Błąd, który zapisuje nieprawidłowe dane w bazie, powiela te same uszkodzenia na dysku nadmiarowym.
• Awaria całego węzła. Awaria hosta lub omyłkowe zawieszenie konta. Macierz może być w pełni sprawna, pozostając jednocześnie niedostępną.
• Błąd użytkownika. Plik usunięty w poniedziałek znika ze wszystkich dysków w tym samym momencie. Jedynie kopia wykonana wcześniej pozwala na jego odzyskanie.

Migawki (snapshots) na tym samym nośniku również nie stanowią rozwiązania. Pomagają w przypadku usunięcia plików, ale giną wraz z macierzą, na której się znajdują. Cechą definiującą kopię zapasową jest jej przechowywanie w innej lokalizacji. Szyfrowane kopie zapasowe poza serwerem z użyciem restic stanowią drugą część tego zagadnienia: macierz zapewnia ciągłość pracy w przypadku awarii dysku, a restic pozwala odzyskać dane, gdy uszkodzenie wynikało z operacji zapisu, którą macierz wykonała zgodnie z instrukcją.

FAQ

Czy RAID 10 oznacza, że nie potrzebuję kopii zapasowych?

Nie. RAID 10 chroni przed awarią dysku. Każdy poprawny zapis jest wykonywany na obu połowach lustra, więc usunięcie danych lub działanie oprogramowania typu ransomware natychmiast dotyka również dysku nadmiarowego. Macierz zgłasza się jako sprawna, ponieważ z jej punktu widzenia nie wystąpiła żadna awaria sprzętowa. Nadal wymagane są kopie zapasowe przechowywane poza maszyną oraz okresowe testy przywracania danych w celu weryfikacji ich poprawności.

Dlaczego dostawcy VPS wybierają RAID 10 zamiast RAID 5 lub RAID 6?

Istnieją dwa powody, oba związane z małymi operacjami zapisu losowego. Zapis parzystości wymaga odczytania starych danych i starej sumy kontrolnej przed obliczeniem nowej, co oznacza, że mały zapis kosztuje 4 operacji w RAID 5 oraz 6 w RAID 6, w porównaniu do 2 w przypadku lustra. Odbudowa macierzy z parzystości wymaga odczytania wszystkich pozostałych dysków od początku do końca, co spowalnia pracę wszystkich maszyn wirtualnych na węźle przez wiele godzin. Odbudowa RAID 10 polega na skopiowaniu danych z jednego dysku na drugi, nie wpływając na pozostałe pary. Dostawcy płacą za to pojemnością: tracą połowę surowej przestrzeni NVMe.

Co oznaczają symbole [U_] lub [UU_U] w pliku /proc/mdstat?

Każdy znak reprezentuje jeden slot w macierzy, zgodnie z ich kolejnością. U oznacza, że w slocie znajduje się działający i zsynchronizowany element. _ oznacza, że slot jest nieaktywny. [U_] w przypadku dwudyskowej macierzy lustrzanej oznacza, że drugi slot jest wyłączony i brak jest nadmiarowości. Należy to interpretować w powiązaniu z całością, gdzie [4/3] informuje, że macierz oczekuje czterech elementów, a posiada trzy. Kolejność slotów odpowiada kolumnie RaidDevice w mdadm --detail, a nie kolejności nazw urządzeń w linii.

Ile dysków może utracić macierz RAID 10?

Jeden, niezależnie od konfiguracji. Powyżej tej liczby zależy to od tego, gdzie wystąpią awarie. Każda para lustrzana może utracić jeden ze swoich dwóch elementów, więc macierz ośmiodyskowa przetrwa do czterech awarii, jeśli żadne dwie nie dotyczą tej samej pary, ale ulegnie awarii przy dwóch uszkodzeniach, jeśli oba dotkną tej samej pary. Należy planować w oparciu o gwarantowaną liczbę, czyli jeden, a wszystko powyżej traktować jako szczęście, a nie ochronę.

Czy powinienem tworzyć lustro z dwóch wolumenów wewnątrz VPS za pomocą mdadm?

Zazwyczaj nie. Dwa wolumeny podłączone do jednego VPS często znajdują się na tej samej fizycznej macierzy na tym samym hoście, więc ich dublowanie podwaja koszt każdego zapisu i nie chroni przed niczym, czego nie pokrywa już RAID hosta. Warto to robić tylko wtedy, gdy dostawca dokumentuje, że wolumeny znajdują się w oddzielnych domenach awarii. W przeciwnym razie lepiej przeznaczyć ten wysiłek na kopie zapasowe przechowywane poza maszyną.