У мене є та сама проблема, як у більшості людей: як створити надійне рішення для особистого зберігання з тим, що:

1. Жорсткі диски виходять з ладу з тривожною регулярністю. Втрата файлів неприйнятна.
2. Я час від часу купуватиму новий жорсткий диск. Неминуче найкраща ціна / ГБ - це інший розмір, ніж остання покупка жорсткого диска.

3. 2 означає, що з часом у мене є неоднорідна колекція дисків. Я хочу використовувати їх усі, а несправні диски, як правило, будуть замінені більшими дисками.

4. Цілісність та надійність даних для мене важливіші, ніж швидкість.

Тож після удару головою від цієї проблеми протягом декількох днів (а в потилиці роками) пропоную наступне рішення. Я опишу рішення, яке я протестував на основі нативного Linux Linux ZFS, який доступний в Ubuntu PPA , але для його досягнення можна використовувати LVM, MD та btrfs. Для цього я буду використовувати RAID1 (дзеркальне відображення ZFS vdevs).

1. Враховуючи набір накопичувачів, згрупуйте їх на два набори дисків, щоб місткість кожного набору була максимально близькою до іншої.
2. Розділіть великі диски таким чином, що в іншій групі є розділ точно такого ж розміру, як і один з менших дисків.
3. Створіть дзеркальний vdevs таким чином, щоб кожен диск мав своє дзеркало на іншому диску.

Наприклад, розглянемо набір дисків нового накопичувача на 2 ТБ, старого накопичувача на 750 ГБ, 2-х старших накопичувачів на 400 ГБ та одного старого накопичувача на 500 ГБ. Оптимальний дзеркальний розподіл має 2 ТБ корисного простору і описаний на наступній схемі, де ':' розділяє розділи та '|' розділяє диски:

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

Створіть свій zpool як

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

Це створює 4 дзеркальних vdevs. Якщо будь-який з дисків вийшов з ладу, його можна замінити (з диском будь-якого розміру) і розділити для відновлення відсутніх розділів. Важливо, щоб vdevs ZFS можна було додавати до пулу, але не видаляти . Тож якщо це взагалі можливо, коли ви купуєте новий накопичувач, ви хочете переставити існуючі vdevs. Скажімо, наступною покупкою став накопичувач на 3 ТБ. Ваша оптимальна конфігурація - 3,5 ТБ, як описано на наступній схемі. Зараз це 5 пар vdev. Цього можна досягти шляхом відповідного розподілу та послідовного виходу з ладу та перерозподілу накопичувачів.

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

Підтримка цього спарювання дзеркальних дисків також може бути виконана за допомогою LVM або з MD RAID, ідея полягає у тому, щоб кожен диск завжди мав дзеркальний диск або розділ. Оскільки все є дзеркальним, ми можемо виходити з ладу диски та переставляти розділи, коли диски додаються чи вилучаються. Використовуючи LVM або MD, за бажанням можна було б видалити диски та зменшити масив за рахунок менш складних інструментів відновлення в ZFS порівняно з BTRFS.

Будь-які коментарі до цієї процедури? Хороший сценарій може впоратися з розподілом та перестановкою приводів без втрат. Будь-які коментарі щодо LVM vs. MD vs. ZFS? Будь-які коментарі щодо продуктивності отриманого дивно розподіленого масиву? Чи спричинить розташування даних на кількох розділах на одному приводі надмірного пошуку голови та раннього виходу з ладу?

BTRFS devs: всі хочуть цього, а LVM або MD технічно не потрібні (і, на мою думку, недооптимальні ). Полегшення обслуговування надмірного гетерогенного масиву було б вбивчою особливістю для btrfs. Це злом на LVM / MD / ZFS, як є. Мінімізація реслівер / ресинхрон вкрай бажана.

Так, це очевидно бідолаха Дробо. Для цього не потрібно спеціального обладнання ...

Я перевірив це за допомогою ZFS, а продуктивність запису - це приблизно половина тієї, яка повинна бути, тому що ZFS поширює читання та запис по всіх vdevs (тому ділить введення-виведення на кілька місць на одному диску). Таким чином, швидкість обмежена швидкістю диска з більшістю розділів. Швидкість читання, здається, дорівнює пропускній здатності диска. Зауважте, пара розділів ZFS на двох дисках має приблизно подвоювати швидкість читання будь-якого одного диска, оскільки він може читати з дисків паралельно.

Використання масивів MD LINEAR або LVM для створення двох половинок призводить до подвійної продуктивності запису порівняно з вищезгаданою пропозицією ZFS, але має недолік, що LVM та MD не мають уявлення, де зберігаються дані. У разі виходу з ладу або оновлення диска одна сторона масиву повинна бути повністю знищена та відновлена ​​/ відновлена, а потім інша сторона. (наприклад, resync / resliver повинен копіювати 2 * (розмір масиву))

Тому здається, що оптимальним рішенням є створення єдиного дзеркала ZFS vdev через два пристрої LVM або MD LINEAR, які поєднують диски в однакові за розміром "половинки". Це приблизно вдвічі більше пропускної здатності для читання будь-якого одного диска, і пропускна здатність запису дорівнює окремій пропускній здатності диска.

Використання BTRFS raid1 замість ZFS також працює, але має половину пропускної здатності, оскільки ZFS розподіляє свої зчитування, щоб подвоїти пропускну здатність, в той час як BTRFS не (за моїми тестами). Перевага BTRFS полягає в тому, що розділи можна скорочувати, тоді як вони не можуть використовувати ZFS (тому якщо після відмови у вас є багато порожнього простору, з BTRFS можна відновити менший надлишковий масив, зменшивши файлову систему, потім переставляючи диски).

Це втомливо робити вручну, але легко з хорошими сценаріями.