Предложение по резервному гетерогенному хранилищу ZFS или LVM или MD

Question

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

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

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

4. Целостность и надежность данных для меня важнее, чем скорость.

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

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

Например, рассмотрим набор дисков с новым диском объемом 2 ТБ, старым диском емкостью 750 ГБ, двумя старыми дисками емкостью 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. Если какой-либо из дисков вышел из строя, его можно заменить (на диск любого размера) и разбить на разделы, чтобы воссоздать отсутствующие разделы. Важно, чтобы ZFS vdevs можно было добавлять в пул, но не удалять. Поэтому, если это вообще возможно, когда кто-то покупает новый диск, вы хотите переставить существующие 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 против MD против ZFS? Есть какие-нибудь комментарии по производительности получающегося странно разделенного массива? Будет ли расположение данных между несколькими разделами на одном диске вызывать чрезмерный поиск головки и ранний отказ?

Разработчики BTRFS: все хотят этого, а LVM или MD не являются технически необходимыми (и, на мой взгляд, неоптимальными). Упрощение поддержки избыточного гетерогенного массива было бы убийственной функцией для btrfs. Это взломать LVM/MD/ZFS как есть. Минимизация Resliver / Resync является чрезвычайно желательным.

Да, это явно Drobo бедняка. Для этого не нужно специального оборудования ...

Answer 1

Я проверил это с ZFS и производительность записи примерно вдвое меньше, чем должна быть, потому что ZFS распределяет операции чтения и записи по всем vdevs (таким образом, разделяя ввод-вывод по нескольким местам на одном диске). Таким образом, скорость ограничена скоростью диска с большинством разделов. Скорость чтения кажется равной пропускной способности диска. Обратите внимание, что пара разделов ZFS на двух дисках имеет примерно удвоенную скорость чтения любого отдельного диска, потому что она может читать с дисков параллельно.

Использование массивов MD LINEAR или LVM для создания двух половин приводит к удвоенной производительности записи по сравнению с приведенным выше предложением ZFS, но имеет тот недостаток, что LVM и MD не имеют представления о том, где хранятся данные. В случае сбоя или обновления диска одна сторона массива должна быть полностью разрушена и повторно синхронизирована / восстановлена, а затем другая сторона. (например, для повторной синхронизации / восстановления необходимо скопировать 2 * (размер массива))

Поэтому кажется, что оптимальным решением является создание одного зеркала ZFS vdev для двух устройств LVM или MD LINEAR, которые объединяют диски в равные по размеру "половинки". Это примерно вдвое превышает пропускную способность чтения любого диска, а пропускная способность записи равна пропускной способности отдельных дисков.

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

Это утомительно делать вручную, но легко с некоторыми хорошими сценариями.