Mam ten sam problem, który ma większość ludzi: jak stworzyć niezawodne rozwiązanie do przechowywania danych osobistych, ponieważ:

1. Dyski twarde ulegają awarii z alarmującą regularnością. Utrata plików jest niedopuszczalna.
2. Od czasu do czasu kupię nowy dysk twardy. Nieuchronnie najlepsza cena / GB ma inny rozmiar niż ostatni zakup dysku twardego.

3. 2 oznacza, że ​​z czasem mam heterogeniczną kolekcję dysków. Chcę ich wszystkich używać, a uszkodzone dyski będą na ogół zastępowane większymi dyskami.

4. Integralność i niezawodność danych jest dla mnie ważniejsza niż szybkość.

Dlatego po kilku dniach uderzania głową w ten problem (a przez lata w tył głowy) proponuję następujące rozwiązanie. Opiszę rozwiązanie, które przetestowałem w oparciu o natywny Linux ZFS, który jest dostępny w Ubuntu PPA , ale LVM, MD i btrfs mogą być użyte do osiągnięcia tego samego. W tym celu użyję RAID1 (vdevs ZFS mirror).

1. Biorąc pod uwagę zestaw napędów, zgrupuj je w dwa zestawy dysków, tak aby pojemność każdego zestawu była jak najbardziej zbliżona do drugiego.
2. Podziel większe dyski na partycje, aby partycja miała dokładnie taki sam rozmiar jak jeden z mniejszych dysków w drugiej grupie.
3. Twórz lustrzane pliki vdev, tak aby każdy dysk miał swoje lustro na innym dysku.

Weźmy na przykład zestaw dysków nowego napędu 2 TB, starszego napędu 750 GB, 2 starszych napędów 400 GB i jednego starszego napędu 500 GB. Optymalne partycjonowanie lustrzane ma 2 TB powierzchni użytkowej i jest opisane na poniższym schemacie, gdzie „:” oddziela partycje od „|” oddziela dyski:

+------------------------------------------------------------------+
| 2TB (sda1)        : (sda2)       : (sda3)       : (sda4)         |
+------------------------------------------------------------------+--+
| 750 GB (sdb)      | 400 GB (sdc) | 400 GB (sdd) | 500 GB (sde1)  :XX|
+---------------------------------------------------------------------+

Utwórz swój zpool jako

zpool create archive mirror /dev/sda1 /dev/sdb mirror /dev/sda2 /dev/sdc mirror /dev/sda3 /dev/sdd mirror /dev/sda4 /dev/sde1

To tworzy 4 dublowane vdevs. Jeśli jeden z dysków ulegnie awarii, można go wymienić (dysk o dowolnym rozmiarze) i podzielić na partycje, aby odtworzyć brakujące partycje. Ważne jest, aby vdevs ZFS można dodawać do puli, ale nie można ich usuwać . Więc jeśli to w ogóle możliwe, kiedy kupujesz nowy dysk, chcesz zmienić rozmieszczenie istniejących vdevów. Powiedzmy, że następnym zakupem był dysk 3 TB. Optymalna konfiguracja pozwala na użycie 3,5 TB, jak opisano na poniższym schemacie. To jest teraz 5 par vdev. Można to osiągnąć przez odpowiednie partycjonowanie i sukcesywne awarie i partycjonowanie dysków.

+--------------------------------------------------------------+-------------+
| 3 TB (sdf1)       : (sdf2)      : (sdf3)      : (sdf4)       | 500GB (sde) |
+--------------------------------------------------------------+-------------+-+
| 2TB (sda1)        | 400GB (sdb) | 400GB (sdc) | 750GB (sdd1) : (sdd2)      :X| 
+------------------------------------------------------------------------------+

Utrzymanie tej pary lustrzanych dysków można również wykonać za pomocą LVM lub MD RAID, przy czym celem jest upewnienie się, że każdy dysk ma zawsze dysk lustrzany lub partycję. Ponieważ wszystko jest dublowane, możemy dowolnie uszkadzać dyski i zmieniać kolejność parowania podczas dodawania lub usuwania dysków. Za pomocą LVM lub MD można by usunąć dyski i, w razie potrzeby, zmniejszyć macierz kosztem mniej zaawansowanych narzędzi do odzyskiwania w ZFS w porównaniu do BTRFS.

Wszelkie uwagi dotyczące tej procedury? Dobry skrypt może poradzić sobie z bezstratną alokacją i rearanżacją dysków. Jakieś komentarze na temat LVM vs. MD vs. ZFS? Wszelkie uwagi na temat wydajności wynikowej dziwnie podzielonej na partycje tablicy? Czy rozmieszczenie danych na wielu partycjach na tym samym dysku spowoduje nadmierne poszukiwanie głowy i wczesną awarię?

BTRFS devs: wszyscy tego chcą, a LVM lub MD nie są technicznie konieczne (i moim zdaniem nieoptymalne). Ułatwienie utrzymania nadmiarowej tablicy heterogenicznej byłoby zabójczą funkcją btrfs. To jest hack na LVM / MD / ZFS. Minimalizacja resliver / resync jest bardzo pożądana.

Tak, to oczywiście Drobo biedaka. Nie trzeba do tego dedykowanego sprzętu ...

Przetestowałem to z ZFS i wydajność zapisu jest o połowę mniejsza niż powinna, ponieważ ZFS rozdziela odczyty i zapisy na wszystkie pliki vdev (dzieląc we / wy do kilku miejsc na tym samym dysku). Dlatego prędkość jest ograniczona prędkością dysku z największą liczbą partycji. Szybkość odczytu wydaje się być równa przepustowości dysku. Uwaga: para partycji ZFS na dwóch dyskach ma w przybliżeniu podwojoną prędkość odczytu na jednym dysku, ponieważ może czytać z dysków równolegle.

Użycie tablic MD LINEAR lub LVM do utworzenia dwóch połówek powoduje dwukrotne zwiększenie wydajności zapisu w porównaniu z powyższą propozycją ZFS, ale ma tę wadę, że LVM i MD nie mają pojęcia, gdzie przechowywane są dane. W przypadku awarii lub aktualizacji dysku jedna strona tablicy musi zostać całkowicie zniszczona i ponownie zsynchronizowana / ponownie uruchomiona, a następnie druga strona. (np. resync / resliver musi skopiować 2 * (rozmiar tablicy))

Wydaje się zatem, że optymalnym rozwiązaniem jest utworzenie jednego lustrzanego vdev ZFS na dwóch urządzeniach LVM lub MD LINEAR, które łączą dyski w równe „połówki”. Ma to w przybliżeniu dwa razy większą przepustowość odczytu niż jeden dysk, a przepustowość zapisu jest równa przepustowości poszczególnych dysków.

Korzystanie z BTRFS raid1 zamiast ZFS również działa, ale ma połowę przepustowości odczytu, ponieważ ZFS rozdziela swoje odczyty, aby podwoić przepustowość, podczas gdy wydaje się, że BTRFS nie (według moich testów). Zaletą BTRFS jest to, że partycje można zmniejszyć, podczas gdy nie można tego zrobić w ZFS (więc jeśli po awarii masz dużo pustej przestrzeni, w BTRFS można odbudować mniejszą nadmiarową tablicę, zmniejszając system plików, a następnie przestawiając dyski).

Jest to żmudne, aby zrobić to ręcznie, ale łatwe z kilkoma dobrymi skryptami.