Горячие резервы ZFS против большей четности

Я немного новичок в ZFS, но я поднимаю новый пул хранения с 12 физическими дисками.

Мой текущий план состоит в том, чтобы иметь RAIDZ2 на 10 дисках и двух горячих резервах.

Но мне интересно, не было бы лучше с RAIDZ3 на всех 12 дисках и без горячего резерва.

Причина в том, что горячее резервирование - это, в основном, включенные бездействующие диски. Могут пройти месяцы или годы, прежде чем они будут приняты на вооружение, и тогда я мог бы узнать, что они нежизнеспособны. Если бы они были частью полосы RAID, я мог бы хотя бы получить обратную связь о том, хороши они или нет.

Я не видел большого обсуждения этого в сети. Есть у кого-нибудь совет?

raid zfs

О горячих запасах

Для горячего резерва установлено конкретный бассейн, но может быть прикреплен к любой vdev пула автоматически в случае сбоев. Если у вас есть только один vdev, состоящий из всех ваших дисков, вам лучше напрямую подключить диски (за исключением случаев, когда у вас уже есть RAIDZ3 и еще есть диски).

Кроме того, перенос обновлений требует времени и происходит в уязвимом (RAIDZ1, двусторонние зеркала) или в состоянии пониженной производительности (RAIDZ2, RAIDZ3, трехсторонние зеркала), чего бы не произошло, если бы вы уже подключили устройство к vdev.

В основном горячее резервирование - это вещь для больших массивов. Если у вас есть 27 дисков, разделенных на 3 vdev по 9 дисков в RAIDZ3, вы можете добавить 3 горячих резерва, чтобы уменьшить количество моментов «Сейчас 2 часа ночи и 3 диска разбились, теперь мне нужно встать и исправить этот беспорядок» (при условии, что 32 система отсеков для дисководов). В меньших системах обычно не хватает дисков, чтобы дойти до ситуации «2+ vdevs и Z2 / Z3». Исключением являются зеркала (например, 6 x 2), где сбои гораздо ближе к фатальным для пула (и у вас недостаточно дисков, чтобы сделать их 6 x 3).

Оптимальная планировка бассейна

Несколько советов от Блог Nex7 по планировке бассейна:

Не используйте raidz1 для дисков размером 1 ТБ или больше.

Для raidz1 не используйте менее 3 дисков и не более 7 дисков в каждом vdev (и опять же, они должны иметь размер менее 1 ТБ, предпочтительно менее 750 ГБ) (5 - типичное среднее значение).

Для raidz2 не используйте менее 6 дисков и не более 10 дисков в каждом vdev (обычно 8 дисков).

Для raidz3 не используйте менее 7 дисков и не более 15 дисков в каждом vdev (обычно 13 и 15 дисков).

Зеркала почти всегда козыри рейдз. Потенциал операций ввода-вывода в секунду для зеркального пула намного выше, чем для любого пула raidz при равном количестве дисков. Единственным недостатком является избыточность - raidz2 / 3 безопаснее, но намного медленнее. Единственный способ, который не снижает производительность ради безопасности, - это трехсторонние зеркала, но они приносят в жертву тонну пространства (но я видел, как клиенты поступают так - если этого требует ваша среда, затраты могут окупиться).

Для дисков размером> = 3 ТБ 3-сторонние зеркала становятся все более привлекательными.

Это означает, что в вашем случае у вас будут следующие варианты:

Можно использовать 9 дисков: (Z3 с 9 + 3)
Можно использовать 8 дисков: (Z2 с 4 + 2) ++ (Z2 с 4 + 2)
Можно использовать 5 дисков: (2-зеркала) * 5 ++ (горячий резерв) * 2
Можно использовать 4 диска: (3-зеркала) * 4

Я бы ранжировал их (по убыванию) как:

По полезной площади: 1, 2, 3, 4
По безопасности: 1, 2/4, 3
По скорости: 4, 3, 2, 1
По возможности расширения / добавления дисков: 3, 4, 2, 1

Я бы не стал использовать RAIDZ1 независимо от размера, потому что вы, возможно, захотите позже заменить их на диски большего размера, и тогда появятся проблемы (это означает, что вы не захотите обновляться таким образом и, возможно, не сможете увеличить пространство для хранения без добавления дополнительных дисков. ).

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

Моя установка:

2x Intel Xeon L5640 CPU @ 2,27 ГГц (всего: 12 ядер; HT отключен)
ОЗУ 96 ГБ DDR3 @ 1333 МГц
Контроллер Adaptec 5805Z, экспортирующий все диски как JBOD (с включенным кешем записи, благодаря энергонезависимой памяти контроллера с питанием от батареи)
12 дисков SAS 15kRPM 146GB (Seagate ST3146356SS)
на-дисковая репликация DRBD (протокол C) через IP-over-Infiniband (20 Гбит / с Mellanox MT25204)
ZFS 0.7.6 на Debian / Stretch
zpool create -o ashift = 12 ... / dev / drbd {...} (Примечание: DRBD работает с размером "единицы" репликации 4 КиБ)
zfs create -o recordsize = 128k -o atime = off -o compress = off -o primarycache = metadata ... (последние два используются только для целей тестирования)

Ниже приведены результаты bonnie ++ для всех возможных интересных комбинаций RAIDz2 и RAIDz3 (в среднем за 5 прогонов из 12 синхронизированных процессов bonnie ++):

TEST: # data bandwidth
      bonnie++ -p <threads>
      for n in $(seq 1 <threads>); do
        bonnie++ -r 256 -f -s 1024:1024k -n 0 -q -x 1 -y s &
      done
      # create/stat/delete operations
      bonnie++ -p <threads>
      for n in $(seq 1 <threads>); do
        bonnie++ -r 256 -f -s 0 -n 128:0:0:16 -q -x 1 -y s &
      done

CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=278273, RW=150845, RD=487315
 ops/s: SCr=132681, SDl=71022, RCr=133677, RDl=71723

CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=276121, RW=158854, RD=480744
 ops/s: SCr=132864, SDl=71848, RCr=127962, RDl=71616

CASE: 1*RAIDz2(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=260164, RW=151531, RD=541470
 ops/s: SCr=137148, SDl=71804, RCr=137616, RDl=71360

CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=269130, RW=184821, RD=672185
 ops/s: SCr=134619, SDl=75716, RCr=127364, RDl=74545

CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=255257, RW=135808, RD=509976
 ops/s: SCr=136218, SDl=74684, RCr=130325, RDl=73915

CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=379814, RW=225399, RD=586771
 ops/s: SCr=120843, SDl=69416, RCr=122889, RDl=65736

DATA: WR  = Sequential Write
      RW  = Sequential Rewrite
      RD  = Sequential Read
      SCr = Sequential Create
      SDl = Sequential Delete
      RCr = Random Create
      RDl = Random Delete

Что касается выступлений:

2 * RAIDz2 (4d + 2p + 0s) - лучший вариант для сбалансированной производительности чтения / записи
1 * RAIDz3 (8d + 3p + 1s) для максимальной производительности чтения (как ни странно)

Что касается того, как интерпретировать / объяснить эти результаты; мои 1 пенни:

8 дисков с данными точно делят размер записи 128 КБ, это может объяснить (?), Почему они всегда превосходят по производительности 9 или 10 дисков с данными (учитывая, что тест выполняется с размером блока 1024 КБ, который точно выравнивается на всех дисках)
Я ожидал, что RAIDz3 будет работать хуже, чем RAIDz2, но случай 1 * RAIDz3 (8d + 3p + 1s) очень странно противоречит этому
значительно меньший размер VDEV в случае 2 * RAIDz2 (4d + 2p + 0s) может объяснить (?), почему он работает значительно лучше при записи

ИЗМЕНИТЬ 1

В ответ на комментарий @AndrewHenle ниже приведены дополнительные тесты с различными размерами "блоков". К сожалению, Бонни ++ не допускает размеров фрагментов, отличных от степени 2; поэтому я вернулся к (5 усредненных прогонов) из дд: PS: помните, кеш чтения ZFS (ARC) есть отключен

TEST: # WR: Sequential Write
      rm /zfs/.../dd.*
      for n in $(seq 1 <threads>); do
        dd if=/dev/zero of=/zfs/.../dd.${n} bs=<chunk> count=<count> &
      done
      # RD: Sequential Read
      for n in $(seq 1 <threads>); do
        dd of=/dev/null if=/zfs/.../dd.${n} bs=<chunk> count=<count> &
      done

CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  418.64   (n/a)  434.56  404.44  361.76
        RD  413.24   (n/a)  469.70  266.58   15.44

CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024    1024    1024   10240  327680(32768 for RD)
 MiB/s: WR  428.44  421.78  440.76  421.60  362.48
        RD  425.76  394.48  486.64  264.74   16.50

CASE: 1*RAIDz3(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024    1024    1024   10240  327680(32768 for RD)
 MiB/s: WR  422.56  431.82  462.14  437.90  399.94
        RD  420.66  406.38  476.34  259.04   16.48

CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  470.42   (n/a)  508.96  476.34  426.08
        RD  523.88   (n/a)  586.10  370.58   17.02

CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  411.42   (n/a)  450.54  425.38  378.38
        RD  399.42   (n/a)  444.24  267.26   16.92

CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  603.64   (n/a)  643.96  604.02  564.64
        RD  481.40   (n/a)  534.80  349.50   18.52

Что касается моих 1 пенни:

Очевидно, что ZFS достаточно разумно оптимизирует запись (даже для блоков размером меньше размера записи) и / или (?) контроллер Adaptec (энергонезависимый, 512MiB) в этом значительно помогает кэш
Очевидно, опять же, отключение кэша чтения ZFS (ARC) очень вредно для размеров фрагментов, близких или меньших размера записи; и кажется, что кэш контроллера Adaptec (что удивительно?) не используется для чтения. Итог: отключение ARC для целей тестирования позволяет получить представление о «сырой, низкоуровневой» производительности, но не рекомендуется для производственного использования (за исключением конкретных случаев, таких как редко используемая библиотека больших файлов)
Появится настройка размера блока в соответствии с размером VDEV. не играть положительную роль [НЕПРАВИЛЬНОЕ ПРЕДПОЛОЖЕНИЕ; см. РЕДАКТИРОВАТЬ 2]

РЕДАКТИРОВАТЬ 2

О RAIDz и размере блока (ashift) и размере записи (файловая система ZFS):

RAIDz заполняет нижележащие устройства блоками данных / четности, размер которых определяется размером смещения
записи (не блоки) являются «базовой единицей» операций контрольной суммы и копирования при записи.
в идеале, размер записи файловой системы ZFS должен делиться на количество (D) дисков с данными в VDEV (но поскольку он должен быть степенью двойки, этого может быть трудно достичь)
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzHowWritesWork
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzHowWritesWorkII
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSLogicalVsPhysicalBlockSizes

И ПРЕДУПРЕЖДЕНИЕ:

горячий запчасти могут не работать, если не очень тщательно настроен и функциональность проверено
https://www.reddit.com/r/zfs/comments/4z19zt/automatic_use_of_hot_spares_does_not_seem_to_work/

НИЖНЯЯ ГРАНИЦА (подтверждая то, что уже было сказано в других ответах)

(Чередование) меньшие VDEV - с меньшим количеством дисков данных - работают лучше, чем большие; вычисление / проверка четности, очевидно, является дорогостоящей операцией, которая становится хуже, чем линейно по количеству дисков с данными (см. случаи 8d <-> 2 * 4d)
VDEV одинакового размера с большим количеством дисков с контролем четности работают лучше, чем с меньшим количеством дисков с контролем четности и горячим резервом, и обеспечить лучшую защиту данных
Используйте «горячие» резервы, чтобы решить проблему «не будите меня посреди ночи», если у вас все еще есть диск (и) в запасе после того, как вы выбрали диски с четностью [ВНИМАНИЕ! см. РЕДАКТИРОВАТЬ 2]

ПОСТ СКРИПТУМ

Мой возможный вариант использования - размещение (долгосрочной) базы данных временных рядов (постоянные записи среднего размера и потенциально очень большие спорадические чтения), для которой у меня очень мало подробной документации по шаблонам ввода-вывода (за исключением «оптимизированного для SSD »), я лично выберу 1 * RAIDz2 (8d + 3p + 1s): максимальная безопасность, немного меньшая емкость, (2-е) лучшие характеристики

Моя рекомендация:

2 x 5-дисковых RAIDZ1 + два запасных

или

3 x 3-дисковых RAIDZ1 + запасные части

или

10-дисковые зеркала RAID

или 2 x RAIDZ2 по 5 или 6 дисков с запасными частями или без них

Это зависит от типа используемого диска. Если 7200 об / мин диски более 2 ТБ, перейдите к RAIDZ2. Если 2 ТБ и пользователь, RAIDZ1 в порядке.