RAID a JBOD: najlepsza opcja przechowywania danych dla kopii zapasowych hiperwizora
Podczas konfigurowania pamięci masowej na serwerach lokalnych lub urządzeniach typu Network Attached Storage (NAS) dwie najczęściej spotykane opcje to RAID i JBOD. Obie polegają na połączeniu wielu dysków w jeden wolumin, jednak znacznie różnią się pod względem sposobu rozdzielania, ochrony danych i uzyskiwania dostępu do nich. Wybór niewłaściwej konfiguracji może prowadzić do spadku wydajności lub utraty danych. W tym wpisie omówiono różnice między JBOD a RAID oraz wskazano optymalne typy pamięci masowej do wykonania kopii zapasowej i utworzenia magazynu danych dla maszyn wirtualnych.
RAID a JBOD: podstawowe różnice
RAID (Redundant Array of Independent Disks) łączy wiele dysków fizycznych w jedną jednostkę logiczną w celu uzyskania wydajności, nadmiarowości lub obu tych cech. Różne poziomy RAID oferują zróżnicowane kompromisy między szybkością a ochroną danych, dostosowane do różnych scenariuszy.
RAID 0 (striping) łączy dyski w celu uzyskania wydajności. Dane są dzielone na fragmenty, które są rozdzielane między dyski i odczytywane równolegle, co zwiększa prędkość odczytu i zapisu. Nie ma nadmiarowości — w przypadku awarii jednego dysku wszystkie dane zostaną utracone. Do konfiguracji RAID 0 wymagane są co najmniej dwa dyski.

RAID 1 (lustrowanie) to niezawodny poziom RAID zapewniający 100% nadmiarowości. Dane są duplikowane na dwóch dyskach; taka konfiguracja zapewnia wysoki poziom ochrony danych, ale pojemność magazynu ulega zmniejszeniu o połowę (na przykład, jeśli w macierzy RAID 1 zastosowano dwa dyski o pojemności 10 TB, pojemność użytkowa wynosi 10 TB). Do utworzenia macierzy RAID 1 wymagane są co najmniej dwa dyski.

RAID 10 (1+0) łączy wysoką wydajność ze 100% nadmiarowością. Pary dysków w trybie lustrzanym (1) są łączone w pasma (0), dzięki czemu ten poziom doskonale nadaje się do serwerów. Do utworzenia macierzy RAID 10 wymagane są co najmniej 4 dyski. Macierz jest tworzona w następującej kolejności:
RAID 1 tworzy kopie lustrzane → RAID 0 rozkłada kopie lustrzane w paskach.

RAID 5 (rozłożenie w paskach + parzystość) zapewnia równowagę między wydajnością, pojemnością i nadmiarowością. Dane są rozkładane w paskach na wielu dyskach wraz z informacjami o parzystości, które mogą być wykorzystane do Odzyskiwania danych i odbudowy macierzy. Konfiguracja ta została zaprojektowana tak, aby wytrzymać awarię jednego dysku dzięki rozproszonej parności — jednego dysku równoważnego dyskowi parnościowemu w przypadku RAID 5 i dwóch w przypadku RAID 6. Do konfiguracji RAID 5 wymagane są co najmniej 3 dyski.

RAID 6 jest podobny do RAID 5, ale wykorzystuje podwójną parność, co teoretycznie pozwala macierzy przetrwać awarię dwóch dysków. Do konfiguracji macierzy RAID 6 wymagane są co najmniej 4 dyski.

JBOD (Just a Bunch of Disks) nie jest poziomem RAID. Termin ten opisuje konfigurację, w której wiele dysków działa niezależnie lub jest połączonych bez logiki RAID ani nadmiarowości.
Istnieją dwie formy JBOD:
- Niezależne dyski (prawdziwy JBOD): Każdy dysk jest widoczny osobno. Na przykład konfiguracja JBOD z trzema dyskami wygląda następująco:
- Dysk 1 (2 TB)
- Dysk 2 (4 TB)
- Dysk 3 (1 TB)
- Łączenie/konkatenacja : Wiele dysków jest łączonych w jeden duży wolumin logiczny (zwany również łączeniem dysków, trybem liniowym lub konkatenacją). W tym przypadku zestaw dysków o pojemnościach 2 TB + 4 TB + 1 TB pojawia się jako pojedynczy wolumin o pojemności 7 TB. Pliki na woluminie JBOD typu „spanning” wypełniają najpierw pierwszy dysk, a następnie przechodzą na następny. Ponieważ zapis w trybie „spanning” odbywa się sekwencyjnie, nowe pliki próbują zapełnić blok o najniższym dostępnym adresie logicznym.

To sekwencyjne zachowanie działa bez zarzutu w teorii, gdzie pliki wypełniają jeden dysk, zanim system przejdzie do następnego. W praktyce pliki są nieustannie tworzone, modyfikowane i usuwane, zwłaszcza na serwerach i w systemach poddanych dużemu obciążeniu. W rezultacie dane rzadko pozostają starannie ograniczone do jednego dysku w konfiguracji JBOD z rozszerzeniem.
Gdy plik zostaje usunięty, odpowiadające mu bloki są oznaczane w systemie plików jako wolne. Usunięcia te powodują powstanie luk między pozostałymi plikami. Nowe zapisy mogą wówczas ulec fragmentacji, a ich bloki mogą być rozrzucone po wielu dyskach woluminu JBOD z rozszerzeniem. Jeśli jeden z dysków w woluminie ulegnie awarii, każdy plik, którego bloki znajdują się na tym dysku, zostanie utracony — nawet jeśli pozostałe części znajdują się na sprawnych dyskach.
Podczas zapisywania nowego, dużego pliku jego pierwsza część może wypełnić lukę na dysku 1, podczas gdy pozostałe części mogą zostać rozdzielone między kolejnymi wolnymi obszarami na dysku 2 i dysku 3. Dane ulegają fragmentacji zarówno logicznej (w systemie plików NTFS), jak i potencjalnie fizycznej (na wielu dyskach). Nowe, mniejsze pliki mogą po prostu wypełnić lukę pozostałą po usunięciu pliku na jednym z istniejących dysków.
Uwaga: UWAGA : JBOD, LVM oraz woluminy NTFS rozciągnięte (rozszerzone) tworzą pojedynczy duży wolumin obejmujący wiele dysków, ale różnią się one warstwą abstrakcji, elastycznością, domeną awarii oraz możliwościami zarządzania. LVM, stosowany w systemach opartych na Linuksie, zapewnia bardziej zaawansowane, dynamiczne i elastyczne podejście. JBOD działa na poziomie systemu plików (na przykład NTFS), podczas gdy LVM wprowadza warstwę menedżera woluminów pomiędzy dyskami fizycznymi a systemem plików. Dzięki temu LVM obsługuje dynamiczne zmianę rozmiaru woluminów, zapisy niesekwencyjne oraz programowy RAID 1 (dźwiganie dysków).
Defragmentacja, obsługiwana przez system plików NTFS, może zmniejszyć fragmentację i zwiększyć szanse na odzyskanie plików z sprawnych dysków w woluminie JBOD, jeśli dysk ulegnie awarii po zakończeniu procesu defragmentacji. Jednak defragmentacja stanowi duże obciążenie dla wszystkich dysków i zajmuje sporo czasu w przypadku dużych woluminów. Jeśli dysk ulegnie awarii podczas defragmentacji, pliki mogą zostać utracone lub cały wolumin może przestać działać.
Uwaga: UWAGA : Defragmentacja dotyczy dysków twardych, ale nie dotyczy dysków półprzewodnikowych.
Główne różnice między JBOD a RAID to:
- RAID został zaprojektowany z myślą o nadmiarowości, wydajności lub obu tych aspektach. Konfiguracja jest bardziej złożona, a wymagania sprzętowe wyższe. W przypadku awarii dysku RAID potrzebuje czasu na odbudowę macierzy.
- JBOD zapewnia maksymalną pojemność użytkową i umożliwia łączenie dysków o różnych rozmiarach w jeden wolumin. Konfiguracja jest prosta, ale nie ma redundancji ani odporności na awarie.
Porównując RAID z JBOD, najbliższe podobieństwo występuje między RAID 0 a JBOD typu spanning, ponieważ żadne z nich nie zapewnia redundancji. W całym tym poście „JBOD” odnosi się do formy typu spanning/concatenation, o ile nie zaznaczono inaczej.
Porównanie wydajności tworzenia kopii zapasowych i odzyskiwania danych
JBOD nie poprawia wydajności, niezależnie od sposobu wykorzystania. Tylko RAID może zwiększyć prędkość.
W konfiguracji JBOD z rozłożeniem danych dane wypełniają jeden dysk przed zapisaniem na następnym:
- Plik przechowywany w całości na dysku 1 jest odczytywany i zapisywany z natywną prędkością dysku 1.
- Plik rozłożony na wielu dyskach jest ograniczony przez najwolniejszy dysk. Wydłużony czas wyszukiwania między dyskami i większe opóźnienia mogą sprawić, że JBOD będzie wolniejszy niż pojedynczy, samodzielny dysk.
JBOD zapewnia maksymalną pojemność bez żadnego wzrostu wydajności, równoległości ani rozłożenia danych.
Wydajność macierzy RAID zależy od skonfigurowanego poziomu (typu) RAID.
RAID 0 (striping) zapewnia najwyższą wydajność, ponieważ dane są rozdzielane na wiele dysków, a dostęp do nich odbywa się równolegle. Na przykład w przypadku dwóch dysków w macierzy RAID 0 sekwencyjny odczyt i zapis mogą osiągnąć prędkość nawet dwukrotnie większą niż w przypadku pojedynczego dysku. Jeśli używane są dwa dyski twarde o prędkości 200 MB/s, konfiguracja JBOD zapewnia prędkość do 200 MB/s, podczas gdy RAID 0 może osiągnąć prędkość do 400 MB/s.
RAID 1 (kopia lustrzana) przechowuje identyczne dane na dwóch dyskach. Operacje odczytu są często szybsze — kontroler może odczytywać dane z dowolnego dysku i w dobrze zaimplementowanych układach osiągać prędkość nawet dwukrotnie większą niż w przypadku pojedynczego dysku. Prędkość zapisu jest równa prędkości pojedynczego dysku, ponieważ każdy zapis musi trafić na oba dyski.
RAID 10 (lustrowanie w paskach) łączy RAID 1 i RAID 0, zapewniając doskonałą wydajność operacji wejścia/wyjścia na sekundę (IOPS).
- Odczyt: do N × prędkość dysku.
- Zapis: Zazwyczaj około połowy wydajności macierzy RAID 0 (ale nadal znacznie szybsza niż pojedynczy dysk).
Macierz RAID 10 oferuje najlepsze połączenie wydajności i nadmiarowości spośród wszystkich poziomów RAID i przewyższa konfigurację JBOD pod względem wszystkich wskaźników wydajności.
RAID 5 (striping + pojedyncza parzystość) ma wymagania dotyczące trzech lub więcej dysków. Wydajność odczytu i zapisu różni się:
- Odczyt: Szybki, choć nie tak szybki jak w przypadku RAID 0 (równoległość odpowiadająca N–1 dyskom).
- Zapis: Wolniejszy ze względu na obliczanie parzystości oraz „obciążenie związane z zapisem”.
Prędkości zapisu w macierzy RAID 5 wynoszą zazwyczaj około połowy prędkości macierzy RAID 0 przy tej samej liczbie dysków.
RAID 5 przewyższa JBOD w obciążeniach z intensywnym odczytem, ale w obciążeniach z intensywnym zapisem może działać wolniej niż RAID 0, a w niektórych przypadkach nieco wolniej niż JBOD.
RAID 6 (podwójna parzystość) działa podobnie jak RAID 5, ale wiąże się z jeszcze większym spowolnieniem zapisu:
- Odczyt: Porównywalny z RAID 5.
- Zapis: Zazwyczaj najwolniejszy spośród popularnych poziomów RAID.
Wydajność odczytu nadal przewyższa JBOD, choć wydajność zapisu może być niższa.
Podsumowując :
- RAID 0 zapewnia najwyższą wydajność surową.
- RAID 10 oferuje najlepszą równowagę między wydajnością a niezawodnością.
- JBOD nadaje się do dużych woluminów pamięci masowej, gdzie szybkość i nadmiarowość nie są priorytetami.
Należy pamiętać o tych cechach przy wyborze RAID lub JBOD jako pamięci źródłowej lub docelowej dla operacji tworzenia kopii zapasowych i odzyskiwania danych.
Uwaga: UWAGA : Należy unikać stosowania „fałszywego RAID” (fake RAID) — funkcji wbudowanej w płyty główne z portami SATA i konfigurowanej za pomocą ustawień UEFI/BIOS. Ta hybrydowa forma programowego RAID opiera się na Procesorze hosta. Fałszywy RAID nie działa w systemie Linux i wymaga specjalnych sterowników w systemie Windows. Nie zapewnia on niezawodności prawdziwego sprzętowego RAID, a podczas jego aktywacji nie ma dostępu do danych SMART. W razie wystąpienia problemów może dojść do utraty danych. Jeśli RAID sprzętowy nie wchodzi w grę, warto rozważyć alternatywne rozwiązania oparte na prawdziwym RAID-zie programowym, takie jak LVM w systemie Linux, mdadm lub ZFS.
Wydajność i niezawodność macierzy RAID
Wydajność ma znaczenie, ale niezawodność staje się równie ważna, gdy celem jest ochrona danych i ich odzyskiwanie. Każdy poziom RAID oferuje inny profil, przy czym na szczególną uwagę zasługują RAID 5 i RAID 6.
RAID 0 charakteryzuje się dużą szybkością odczytu, zapisu oraz przechowywania kopii zapasowych wykorzystywanych w operacjach odzyskiwania danych. Jednak w przypadku awarii jednego dysku wszystkie kopie zapasowe w macierzy zostaną utracone. To samo ryzyko dotyczy danych podstawowych przechowywanych w macierzy RAID 0, jeśli nie istnieje oddzielna kopia zapasowa.
Drugi scenariusz odzyskiwania polega na odbudowie macierzy na samych dyskach — bez przywracania danych z nośników zewnętrznych. Wszystkie poziomy RAID, z wyjątkiem RAID 0, zapewniają funkcje samonaprawy, które odtwarzają macierz na podstawie danych nadmiarowych lub parzystościowych przechowywanych na pozostałych sprawnych dyskach. Po wymianie uszkodzonego dysku proces odbudowy rozpoczyna się automatycznie.
RAID 1 z dwoma dyskami jest w stanie przetrwać awarię jednego dysku i charakteryzuje się wysoką niezawodnością. Odbudowa przebiega szybko, bez konieczności obliczania parzystości.
RAID 10 toleruje awarię dowolnego pojedynczego dysku, a nawet może przetrwać awarię dwóch dysków, pod warunkiem że uszkodzone dyski należą do różnych par lustrzanych. Niezawodność i odporność na awarie są wysokie, a odbudowa przebiega szybko, ponieważ nie jest wymagane obliczanie parzystości (w przeciwieństwie do RAID 5).

RAID 5 teoretycznie może przetrwać awarię jednego dysku, a RAID 6 – awarię dwóch dysków, jednak rzeczywista niezawodność tych poziomów jest niższa, niż się wydaje. Ryzyko całkowitej awarii macierzy znacznie wzrasta podczas procesu odbudowy. Szczególnie RAID 5 wymaga dokładnej analizy, pomimo deklarowanej nadmiarowości.
Macierz RAID 5 została opracowana w 1987 roku, kiedy pojemność dysków była niewielka (około 20 MB), a prawdopodobieństwo pomyślnej odbudowy po awarii jednego dysku było wysokie, biorąc pod uwagę ówczesną prędkość odbudowy. Współczesne dyski mają obecnie pojemność 30 TB i więcej. Chociaż pojemności wzrosły o rzędy wielkości, prędkości dysków mechanicznych nie nadążają za tym tempem — zwłaszcza w przypadku dysków HDD.
Gdy w macierzy RAID 5 ulegnie awarii jeden dysk, macierz przechodzi w stan uszkodzony. Zasadniczo dane pozostają dostępne po odbudowie macierzy. Ilość danych do odtworzenia jest równa pojemności jednego dysku, przy wykorzystaniu danych parzystości rozłożonych na pozostałych sprawnych dyskach. Podczas odbudowy wydajność dysków w macierzy znacznie spada, ponieważ kontroler musi wykonywać dodatkowe obliczenia parzystości i kontrole spójności.
Po wymianie uszkodzonego dysku kontroler RAID rozpoczyna odbudowę. Odczytuje pozostałe dane z dysków, które przetrwały, i na podstawie informacji o parzystości zapisuje odtworzoną zawartość na nowym dysku. Czas odbudowy jest często długi i zależy od liczby dysków, wydajności Procesora kontrolera, ilości danych w macierzy oraz podobnych czynników. Jeśli serwer nadal obsługuje obciążenia wymagające intensywnej obsługi wejścia/wyjścia podczas odbudowy, spada zarówno wydajność macierzy, jak i szybkość odbudowy, co dodatkowo wydłuża ten proces.
Ponieważ pojemności dysków podlegają skalowaniu, a prędkości dysków rosną szybciej (szczególnie w przypadku dysków HDD), czas odbudowy macierzy RAID 5 stale się wydłuża. Na przykład odbudowa macierzy RAID 5 składającej się z pięciu dysków twardych o pojemności 4 TB na obciążonym serwerze może zająć ponad jeden dzień, a w przypadku macierzy zbudowanych z dysków o pojemności 20 TB proces ten może się rozciągnąć na kilka dni. Wartości te należy pomnożyć jeszcze bardziej w przypadku dysków o pojemności 30 TB.
Podczas odbudowy macierzy RAID 5 macierz faktycznie działa bez nadmiarowości, podobnie jak w przypadku macierzy RAID 0. Nawet niewielka zakłócenie — błąd odczytu z dysku, zakłócenie sygnału, problem z kablem — może spowodować niepowodzenie odbudowy. Jeśli w tym czasie ulegnie awarii drugi dysk, wszystkie dane w macierzy zostaną utracone.
Wskaźnik błędów bitowych (BER) jest wykorzystywany przez dostawców do oszacowania niezawodności dysków. Wartość BER dla dysków klasy desktopowej wynosi 10^14, natomiast dyski klasy Enterprise osiągają poziom 10^15. Wartość 10^14 oznacza, że prawdopodobieństwo wystąpienia nieodwracalnego błędu odczytu nie przekracza 1 na 100 000 000 000 000 bitów (14 zer). 10^14 bitów odpowiada 11 TB danych. Oznacza to, że po odczytaniu około 11 TB z dysku twardego klasy desktopowej prawdopodobieństwo wystąpienia co najmniej jednego błędu odczytu na poziomie bitowym jest bliskie 100%. W praktyce dyski często ulegają awarii wcześniej, niż sugerowałby to ich teoretyczny średni czas do awarii (MTTF).
W przypadku dysków twardych klasy Enterprise sytuacja poprawia się o rząd wielkości: skumulowane prawdopodobieństwo błędu odczytu osiąga prawie 100% po odczytaniu około 110 TB danych. Biorąc pod uwagę, że dostępne na rynku w 2026 r. dyski twarde przekraczają pojemność 30 TB na dysk, wskaźnik BER wynoszący 10^15 nie wydaje się już szczególnie komfortowy w przypadku dużych macierzy. Prawdopodobieństwo awarii jest niższe w przypadku dysków o mniejszej pojemności, a wyższe w przypadku dysków o większej pojemności.
Należy pamiętać, że znaczna część danych przechowywanych w macierzach dyskowych to dane „zimne” — rzadko wykorzystywane, często nietknięte przez 1–2 lata. Ponieważ systemy nie skanują w sposób ciągły każdego sektora dysku pod kątem stanu i spójności, niektóre pliki mogą znajdować się w blokach, których nie da się już odczytać. To ukryte uszkodzenie pozostaje niewidoczne, dopóki nie ujawni go odbudowa macierzy RAID 5 — w tym momencie staje się ono fatalne w skutkach.
Nie zaleca się stosowania macierzy RAID 5, zwłaszcza w systemach produkcyjnych lub w przypadku danych o znaczeniu krytycznym dla działalności firmy. Jeśli jednak macierz RAID 5 jest nadal wymagana, nie należy łączyć jej z niedrogimi kontrolerami ani dyskami klasy konsumenckiej. Należy wybierać kontrolery RAID klasy Enterprise oraz dyski o wyższym wskaźniku niezawodności. RAID 6 radzi sobie nieco lepiej niż RAID 5, ale ryzyko utraty danych pozostaje znaczne.
Dane przechowywane w macierzy RAID 5 powinny zawsze być wykonane kopie zapasowe na zewnętrznym nośniku w celu zabezpieczenia przed awarią macierzy. Ta sama zasada dotyczy macierzy RAID 0 i pamięci masowej JBOD.
Niezawodność i wydajność macierzy JBOD
W konfiguracji JBOD typu „spanning”, jeśli jeden dysk ulegnie awarii, każdy plik zawierający bloki na uszkodzonym dysku staje się nieczytelny i niemożliwy do odzyskania. Potencjalnie można odzyskać jedynie pliki przechowywane w całości na sprawnych dyskach.
W niektórych konfiguracjach awaria pojedynczego dysku może spowodować awarię całego woluminu JBOD, nawet jeśli większość danych znajduje się na sprawnych dyskach, podobnie jak w przypadku macierzy RAID 0. Przyczyną są metadane systemu plików: jeśli krytyczne struktury, takie jak główna tabela plików (MFT), znajdują się na uszkodzonym dysku, system operacyjny nie może już mapować adresów logicznych na bloki fizyczne, co uniemożliwia dostęp do danych na sprawnych dyskach. Jeśli wzorzec zapisu w konfiguracji JBOD jest nieznany, należy traktować tę pamięć masową jako nieodporna na awarie.
Wydajność macierzy RAID dla VMware i Hyper-V
Pamięć masowa RAID zapewnia wyższą wydajność, ale nie każdy poziom RAID nadaje się do magazynów danych maszyn wirtualnych lub pamięci masowej maszyn wirtualnych.
RAID 0 jest szybki, ale nie jest bezpieczny. Awaria pojedynczego dysku powoduje przestój do momentu przywrócenia uszkodzonych maszyn wirtualnych z kopii zapasowej lub przełączenia ich na istniejące repliki maszyn wirtualnych. Użycie macierzy RAID 0 w magazynie danych maszyn wirtualnych wymaga solidnej strategii tworzenia kopii zapasowych i replikacji. Zdecydowanie odradza się stosowanie macierzy RAID 0 bez dodatkowych środków ochrony danych w środowiskach produkcyjnych. Może to być dopuszczalne w przypadku tymczasowych obciążeń, takich jak laboratoria i środowiska testowe.
RAID 1 sprawdza się dobrze w przypadku pamięci masowej maszyn wirtualnych w VMware, Hyper-V i innych platformach wirtualizacyjnych. Wydajność jest odpowiednia, a 100-procentowa redundancja danych zapobiega przestojom po awarii pojedynczego dysku podczas odbudowy macierzy. RAID 1 jest rozsądnym wyborem dla mniejszych środowisk wirtualnych z ograniczoną liczbą maszyn wirtualnych.
RAID 10 zapewnia najwyższą wydajność i niezawodność. Wysoka liczba operacji IOPS, niskie opóźnienia, szybki odczyt i zapis, solidna odporność na awarie oraz szybka odbudowa sprawiają, że jest to zalecany poziom RAID dla platform VMware, Hyper-V i innych platform wirtualizacyjnych w środowiskach produkcyjnych.
RAID 5 zapewnia umiarkowaną wydajność odczytu, ale wydajność zapisu jest niższa. Pomimo pewnej przewagi w zakresie odczytu podczas normalnej pracy, macierzy RAID 5 nie należy używać do przechowywania maszyn wirtualnych ani żadnych danych o znaczeniu krytycznym. Jak wspomniano wcześniej, ryzyko związane z odbudową jest wysokie, a spadek wydajności podczas odbudowy jest znaczny.
RAID 6 zapewnia wydajność odczytu podobną do RAID 5, ale wolniejszy zapis. Niezawodność jest nieco wyższa niż w przypadku RAID 5, jednak wszystkie jego słabe strony nadal pozostają aktualne. RAID 6 nie jest zalecany do przechowywania maszyn wirtualnych ani danych krytycznych.
Wydajność JBOD dla VMware i Hyper-V
W przeciwieństwie do pamięci masowej przeznaczonej do tworzenia kopii zapasowych, pamięć masowa dla maszyn wirtualnych ma znacznie bardziej rygorystyczne wymagania dotyczące wydajności. Obciążenia maszyn wirtualnych są bardzo wrażliwe na IOPS, opóźnienia i przepustowość. W tym kontekście macierze RAID i JBOD zachowują się zupełnie inaczej, a nawet wybór poziomu RAID znacząco wpływa na wydajność maszyn wirtualnych na danej macierzy.
Obciążenia maszyn wirtualnych generują wiele niewielkich operacji odczytu i zapisu oraz wymagają wysokiej liczby operacji IOPS, szczególnie w przypadku dysków wirtualnych obsługujących systemy operacyjne, bazy danych i serwery plików. Pliki wymiany, stronicowanie, migawki i dyski delta powodują znaczne wzmocnienie zapisu. Okresowe skoki operacji wejścia/wyjścia są powszechne podczas normalnej pracy maszyn wirtualnych.
Ponieważ JBOD jest jedną z najwolniejszych konfiguracji pamięci masowej, nie jest zalecany do stosowania z plikami maszyn wirtualnych VMware, Hyper-V ani innych, zwłaszcza w środowiskach produkcyjnych.
Kwestie związane z pamięcią masową w VMware i Hyper-V
Oba VMware i Hyper-V w dużym stopniu opierają się na wydajności i spójności pamięci masowej, ale różnią się sposobem uzyskiwania dostępu do pamięci masowej, optymalizacji obciążeń i ochronie danych.
VMware vSphere jest bardziej wrażliwy na wydajność pamięci masowej ze względu na sposób, w jaki VMFS, vMotion, migawki i DRS współdziałają z magazynami danych. Obsługiwane typy magazynów w VMware vSphere to:
- Sieć pamięci masowej (SAN): iSCSI, Fibre Channel, FCoE
- Sieciowa pamięć masowa (NAS): NFS v3/v4.1
- Pamięć masowa podłączona bezpośrednio (DAS): lokalny RAID, NVMe, SSD
- vSAN (pamięć masowa hiperkonwergentna)
- Chmurowe magazyny danych (vVols, udziały chmurowe NFS)
NFS zapewnia współdzieloną pamięć masową na poziomie plików, podczas gdy iSCSI i DAS działają na poziomie bloków.
Magazyny danych VMFS są najczęściej stosowanym typem pamięci masowej dla maszyn wirtualnych w środowiskach VMware vSphere ze względu na ich niezawodność, wygodę i łatwość konfiguracji. VMFS to klastrowy system plików, który umożliwia wielu hostom ESXi jednoczesny dostęp do tych samych magazynów danych, bloków i plików — co jest wymaganiem w konfiguracjach klastrowych. Do kluczowych cech magazynów danych VMware VMFS należą:
- Doskonałe rozwiązanie dla obciążeń wymagających wysokiej liczby operacji IOPS
- Obsługuje wiele hostów uzyskujących dostęp do tego samego magazynu danych
- Wymagania dotyczące przepustowości pamięci masowej zaplecza są duże
- Dostępne są opcje alokacji typu „thin” i „thick”
- Najlepszą wydajność zapewnia w połączeniu z macierzą RAID 10 podczas uruchamiania maszyn wirtualnych i operacji zapisu
Magazyny danych VMFS można tworzyć na dyskach lokalnych (w tym na lokalnych macierzach RAID za pośrednictwem DAS) lub na jednostkach LUN iSCSI udostępnianych przez urządzenia SAN i NAS w sieci. W obu przypadkach macierz RAID jest zazwyczaj konfigurowana na bazowym urządzeniu SAN lub urządzeniu NAS w celu zapewnienia wydajności i niezawodności. Macierz RAID może być również wykorzystywana do konfiguracji udziałów plików NFS na serwerze plików.
Obowiązują zasady wyboru poziomu macierzy RAID opisane wcześniej. Dyski SSD zapewniają najwyższą wydajność, natomiast dyski HDD są odpowiednie dla mniej wymagających obciążeń. RAID 10 jest optymalnym wyborem dla pamięci masowej maszyn wirtualnych VMware, a RAID 1 stanowi akceptowalną alternatywę. VMware ESXi obsługuje wyłącznie sprzętowy RAID dla lokalnie podłączonej pamięci masowej.
Microsoft Hyper-V wykorzystuje NTFS lub ReFS na woluminach współdzielonych w klastrze (CSV); jego zachowanie w zakresie pamięci masowej znacznie różni się od VMware vSphere. Typy pamięci masowej obsługiwane w Hyper-V to:
- DAS: macierze RAID (najczęściej spotykane)
- SAN: iSCSI/Fibre Channel
- SMB 3.0/3.02 (Scale-Out File Server — SOFS)
- Storage Spaces/Storage Spaces Direct (S2D)
- Pamięć masowa w chmurze oparta na platformie Azure
SMB to protokół udostępniania plików natywny dla środowisk Microsoft.
Hyper-V przechowuje VHDX pliki dysków wirtualnych na bezpośrednio podłączonych woluminach NTFS/ReFS, woluminach współdzielonych w klastrze (CSV) oraz udziałach plików SMB 3.0. Woluminy CSV umożliwiają wielu hostom jednoczesny dostęp do tego samego identyfikatora LUN, co jest wymagane w konfiguracji klastra. Obsługa Hyper-V w systemie Windows Server obejmuje RAID sprzętowy, RAID symulowany oraz RAID programowy. Zalecenia dotyczące RAID dla Hyper-V są zgodne z zaleceniami dla VMware: RAID 10 jest najlepszą opcją dla hostów obsługujących obciążenia maszyn wirtualnych, a RAID 1 stanowi rozsądną alternatywę. Preferowaną implementacją pozostaje RAID sprzętowy.
Koszty magazynu i rozbudowa
RAID zazwyczaj zwiększa koszty magazynu, ponieważ nadmiarowość zmniejsza pojemność użytkową — płacisz za więcej sprzętu niż faktycznie uzyskujesz przestrzeni. Na przykład:
- RAID 0: Brak zmniejszenia pojemności
- RAID 1: 50% pojemności użytkowej (dwa dyski tworzą kopię lustrzaną)
- RAID 10: 50% pojemności użytkowej (lustrzane pasma)
- RAID 5: Utrata pojemności odpowiadającej jednemu dyskowi (N dysków → N−1 dysków użytkowych)
- RAID 6: Utrata pojemności odpowiadającej dwóm dyskom (N dysków → N−2 dysków użytkowych)
Aby uzyskać najlepszą wydajność i niezawodność, wymagany jest wysokiej jakości kontroler RAID (z baterią i pamięcią podręczną), który wiąże się z wyższą ceną.
JBOD jest najtańszą opcją, ponieważ nie wymaga dodatkowych dysków do zapewnienia nadmiarowości ani specjalnego sprzętu kontrolera. Można dodać dowolną liczbę dysków, aby utworzyć duży wolumin, w przeciwieństwie do macierzy RAID 1, która jest ograniczona do dwóch dysków. Konfiguracja JBOD działa również z dyskami mieszanymi — różnych dostawców, o różnej pojemności i prędkości — jednak ta elastyczność wiąże się z obniżeniem wydajności i niezawodności.
Rozbudowa to obszar, w którym te dwie konfiguracje znacznie się różnią. Większości konfiguracji RAID nie da się łatwo rozbudować lub obsługują one jedynie ograniczoną rozbudowę. Zazwyczaj konieczna jest wymiana wszystkich dysków w macierzy na dyski o większej pojemności, ale tej samej, lub skonfigurowanie oddzielnej macierzy RAID, co wymaga wolnych portów na kontrolerze RAID lub nawet dodatkowego kontrolera. Zaawansowane kontrolery RAID umożliwiają rozbudowę macierzy RAID 10 poprzez dodawanie par dysków. Macierze RAID 5 i RAID 6 można rozbudowywać poprzez dodawanie dysków, ale proces ten jest ryzykowny i czasochłonny.
JBOD oferuje największą elastyczność i najprostszą ścieżkę rozbudowy. Dysk można dodać w dowolnym momencie, niezależnie od producenta, pojemności, modelu czy innych parametrów. Nowe dyski stają się dostępne natychmiast, bez konieczności odbudowy macierzy ani obliczania parzystości.
Optymalizacja wydajności tworzenia kopii zapasowych za pomocą NAKIVO
JBOD może służyć jako niedroga, rozszerzalna pamięć masowa do tworzenia kopii zapasowych. Prędkość tworzenia kopii zapasowej jest zazwyczaj ograniczona przez połączenie sieciowe, a dodatkowe obciążenie wynika z kompresji i szyfrowania, co oznacza, że ograniczenia prędkości surowej macierzy JBOD rzadko stanowią wąskie gardło. Mimo to należy pamiętać o Zasada tworzenia kopii zapasowej 3-2-1 i utrzymywać dodatkowe kopie zapasowe, które mogą uratować sytuację w przypadku awarii głównego magazynu kopii zapasowych.
Nawet w przypadku niezawodnych poziomów RAID, takich jak RAID 1 i RAID 10, dane na tych macierzach nadal wymagają wykonania kopii zapasowej. RAID 1 toleruje awarię jednego dysku, a RAID 10 może przetrwać awarię dwóch dysków, pod warunkiem że uszkodzone dyski należą do różnych par lustrzanych. Jednak nadmiarowość nie stanowi zabezpieczenia przed każdym rodzajem awarii. Przypadkowe usunięcie danych, ataki oprogramowania ransomware, uszkodzenie oprogramowania oraz katastrofy fizyczne mogą zniszczyć dane lub sam serwer. RAID lustrzany stanowi formę nadmiarowości, a nie substytut właściwego strategia tworzenia kopii zapasowych.
Rozwiązanie NAKIVO Backup & Replication oferuje szeroki zakres funkcji zaprojektowanych z myślą o zapewnieniu szybkiej, bezpiecznej, niezawodnej i wygodnej ochrony danych.
- Tworzenie kopii zapasowych maszyn wirtualnych bez agentów dla platform VMware vSphere, Microsoft Hyper-V, Proxmox VE i Nutanix AHV. Do wykonania kopii zapasowych danych na poziomie hosta wykorzystywane są natywne interfejsy API hiperwizora.
- Transfer danych bez sieci LAN : Technologia NAKIVO Backup & Replication automatycznie wybiera optymalny tryb transferu danych, taki jak tryb Hot Add lub Direct SAN Access, aby zmniejszyć obciążenie sieci i przyspieszyć tworzenie kopii zapasowej.
- Przyspieszenie sieciowe : Dane są kompresowane przed wysłaniem przez sieć do docelowej pamięci masowej kopii zapasowej, co poprawia prędkość transferu i zmniejsza ilość zajmowanego miejsca.
- Planowanie i automatyzacja tworzenia kopii zapasowych : Elastyczne planowanie i utrzymanie klientów opcje umożliwiają automatyczne uruchamianie zadań tworzenia kopii zapasowej, co pozwala zaoszczędzić czas.
- Wsparcie dla urządzeń deduplikacyjnych : Wykorzystanie obsługiwanych urządzeń deduplikacyjnych oraz ich natywnych protokołów transferu danych pozwala zmaksymalizować prędkość tworzenia kopii zapasowych i zminimalizować wykorzystanie przestrzeni dyskowej przeznaczonej na kopie zapasowe. Obsługiwane urządzenia to między innymi EMC Data Domain (DD Boost), HPE StoreOnce (Catalyst) oraz NEC HYDRAstor (Universal Express).
- Kopie zapasowe przyrostowe : Przesyłane są wyłącznie dane, które uległy zmianie od ostatniej pełnej kopii zapasowej lub kopia zapasowa przyrostowa , co pozwala zaoszczędzić czas i poprawić wydajność w porównaniu z kopiami zapasowymi wyłącznie pełnymi.
- Natywne śledzenie zmian dla VMware i Hyper-V : System śledzenia zmienionych bloków VMware (CBT) oraz Hyper-V Resilient Change Tracking (RCT) przyspieszają tworzenie kopii przyrostowych.
- Wykluczenie danych wymiany : Pliki wymiany i partycje przechowują tymczasowe dane systemu operacyjnego i niepotrzebnie zwiększają objętość kopii zapasowych. Funkcja NAKIVO Backup & Replication je wyklucza, zwiększając szybkość tworzenia kopii zapasowych i oszczędzając miejsce na nośniku.
- Obcinanie dziennika : Systemy baz danych tworzą pliki dzienników, aby zapewnić spójność transakcji i umożliwić odzyskiwanie danych. Pliki te mogą osiągać duże rozmiary. Funkcja obcinania dziennika pozwala zachować mniejszy rozmiar kopii zapasowych.
Wnioski
Pomimo niskich kosztów i skalowalności pamięć masowa typu JBOD nie nadaje się do przechowywania danych krytycznych ani do obciążeń wymagających wysokiej wydajności. Awaria pojedynczego dysku może prowadzić do utraty danych. Pamięć JBOD może służyć jako pamięć kopii zapasowych, ale tylko wtedy, gdy co najmniej jedna dodatkowa kopia zapasowa znajduje się na oddzielnej pamięci masowej. W przypadku ważnych danych należy unikać macierzy RAID 5 i RAID 6. Najbardziej niezawodnymi opcjami pozostają macierze RAID 10 i RAID 1, przy czym macierz RAID 10 zapewnia najwyższą wydajność, co czyni ją idealnym rozwiązaniem do przechowywania maszyn wirtualnych z pełną redundancją. Nawet przy zastosowaniu najlepszego poziomu RAID należy wykonać kopię zapasową danych z macierzy, ponieważ wiele sytuacji prowadzących do utraty danych ma miejsce bez żadnej awarii samej macierzy.
Często zadawane pytania
Jaka jest różnica między JBOD a RAID?
RAID łączy wiele dysków w jedną jednostkę logiczną przy użyciu rozłożenia danych, dublowania lub parzystości w celu poprawy wydajności, zapewnienia nadmiarowości lub obu tych cech. JBOD (Just a Bunch of Disks) łączy dyski w jeden wolumin bez stosowania żadnego z tych mechanizmów. RAID wymaga użycia identycznych dysków i kontrolera; JBOD pozwala na stosowanie dysków różnego typu bez konieczności stosowania specjalnego sprzętu. RAID zapewnia ochronę przed awarią dysku (z wyjątkiem RAID 0); JBOD nie oferuje odporności na awarie.
Czy JBOD nadaje się do przechowywania kopii zapasowych?
Konfiguracja JBOD może służyć jako niedroga pamięć masowa do tworzenia kopii zapasowych, ponieważ prędkość tworzenia kopii zapasowych jest zazwyczaj ograniczona przez sieć, a nie przez wydajność dysków. Jednak awaria nawet jednego dysku może spowodować utratę plików rozproszonych na wielu dyskach. Jeśli używasz konfiguracji JBOD do tworzenia kopii zapasowych, postępuj zgodnie z zasadą 3-2-1 i przechowuj co najmniej jedną dodatkową kopię zapasową na oddzielnym nośniku.
Który poziom RAID najlepiej sprawdza się w przypadku maszyn wirtualnych VMware i Hyper-V?
RAID 10 to zalecany poziom dla pamięci masowej maszyn wirtualnych zarówno w środowisku VMware, jak i Hyper-V. Łączy on rozkładanie danych (striping) i tworzenie kopii lustrzanych (mirroring), zapewniając wysoką liczbę operacji IOPS, niskie opóźnienia, szybką odbudowę oraz pełną nadmiarowość. W mniejszych środowiskach dopuszczalny jest poziom RAID 1. Należy unikać stosowania poziomów RAID 5 i RAID 6 w przypadku obciążeń maszyn wirtualnych ze względu na powolny zapis, wysokie ryzyko związane z odbudową oraz spadek wydajności podczas odzyskiwania danych.
Dlaczego nie zaleca się stosowania macierzy RAID 5 do przechowywania danych produkcyjnych?
Macierz RAID 5 została zaprojektowana w 1987 roku z myślą o dyskach o niewielkiej pojemności. W przypadku współczesnych dysków o pojemności przekraczającej 30 TB czas odbudowy macierzy wydłuża się do kilku dni. Podczas odbudowy macierz działa bez nadmiarowości. Pojedynczy błąd odczytu, problem z kablem lub awaria drugiego dysku w tym okresie skutkuje całkowitą utratą danych. Kontrolery i dyski klasy Enterprise zmniejszają to ryzyko, jednak macierz RAID 10 pozostaje bezpieczniejszym wyborem.
Czy macierz JBOD może być wykorzystywana jako magazyn danych w środowiskach VMware lub Hyper-V?
Konfiguracja JBOD nie jest zalecana jako pamięć masowa dla maszyn wirtualnych. Obciążenia maszyn wirtualnych wymagają wysokiej liczby operacji IOPS, niskiego opóźnienia oraz stałej przepustowości. Konfiguracja JBOD nie zapewnia żadnego wzrostu wydajności w porównaniu z pojedynczym dyskiem, nie oferuje równoległości przetwarzania ani odporności na awarie. Awaria dysku w woluminie JBOD może spowodować wyłączenie działających maszyn wirtualnych, a jedyną możliwością odzyskiwania danych jest odtworzenie z kopii zapasowej.