Предложение избыточного гетерогенного хранилища ZFS или LVM или MD


10

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

  1. Жесткие диски выходят из строя с пугающей регулярностью. Потеря файлов недопустима.
  2. Я буду покупать новый жесткий диск время от времени. Неизбежно, лучшая цена / ГБ отличается от последней покупки HDD.
  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 бедняка. Для этого не нужно специального оборудования ...

Ответы:


4

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.