Рейтинг:2

Как увеличить скорость RAID 5 с помощью mdadm + luks + lvm

флаг cn

Я думаю, что немного потерялся с моей текущей настройкой сервера. Это HP Proliant dl160 gen 6, и я поставил 4 вращающихся диска с настройкой, в которой есть mdmadm + luks + lvm, а поверх него btrfs (может быть, я зашел слишком далеко?), и он действительно страдает от скорости ввода-вывода, которую он читает 50 МБ/с, а пишет около 2 МБ/с, и у меня такое чувство, что я что-то напутал.

Одна из вещей, которые я заметил, это то, что я настроил mdadm на блочном устройстве (sbd), а не на разделах (sdb1), повлияет ли это на что-то?

Здесь вы можете увидеть вывод fio fio --name=randomwrite --rw=randomwrite --direct=1 --bs=16k --numjobs=128 --size=200M --runtime=60 --group_reporting когда от машины почти нет толку.

randwrite: (groupid = 0, jobs = 128): err = 0: pid = 54290: вторник, 26 октября, 16:21:50 2021
  запись: IOPS=137, BW=2193 КБ/с (2246 КБ/с) (131 МБ/61080 мс); 0 сброс зоны
    clat (мсек): мин.=180, макс.=2784, среднее=924,48, стандартное отклонение=318,02
     широта (мсек): мин.=180, макс.=2784, среднее=924,48, стандартное отклонение=318,02
    clat процентили (мс):
     | 1.00=[405], 5.00=[542], 10.00=[600], 20.00=[693],
     | 30.00=[ 760], 40.00=[ 818], 50.00=[ 860], 60.00=[ 927],
     | 70.00=[ 1011], 80.00=[ 1133], 90.00=[ 1267], 95.00=[ 1452],
     | 99,00=[2165], 99,50=[2232], 99,90=[2635], 99,95=[2769],
     | 99,99=[ 2769]
   bw (КиБ/с): мин. = 3972, макс.
   IOPS: мин. = 132, макс. = 295, среднее = 248,40, стандартное отклонение = 0,26, выборки = 8224.
  широта (мс): 250 = 0,04%, 500 = 2,82%, 750 = 25,96%, 1000 = 40,58%, 2000 = 28,67%
  широта (мсек): >=2000=1,95%
  процессор: usr=0,00%, sys=0,01%, ctx=18166, majf=0, minf=1412
  Глубина ввода-вывода: 1=100,0%, 2=0,0%, 4=0,0%, 8=0,0%, 16=0,0%, 32=0,0%, >=64=0,0%
     отправить: 0=0,0%, 4=100,0%, 8=0,0%, 16=0,0%, 32=0,0%, 64=0,0%, >=64=0,0%
     завершено: 0=0,0%, 4=100,0%, 8=0,0%, 16=0,0%, 32=0,0%, 64=0,0%, >=64=0,0%
     выпущено rwts: всего=0,8372,0,0 коротко=0,0,0,0 удалено=0,0,0,0
     задержка: цель = 0, окно = 0, процентиль = 100,00%, глубина = 1

Выполнить группу состояния 0 (все задания):
  ЗАПИСЬ: bw=2193 КБ/с (2246 КБ/с), 2193 КБ/с-2193 КБ/с (2246 КБ/с-2246 КБ/с), io=131 МБ (137 МБ), run=61080-61080 мс

Обновление 1 последовательной записи с помощью dd

root@hp-proliant-dl160-g6-1:~# dd if=/dev/zero of=disk-test oflag=direct bs=512k count=100
100+0 записей в 100+0 записей на выходе 52428800 байт (52 МБ, 50 МБ) скопировано, 5,81511 с, 9,0 МБ/с

Ядро: 5.4.0-89-универсальный

ОС: Ubuntu 20.04.3

мдадм: 4.1-5ubuntu1.2

lvm2: 2.03.07-1ubuntu1

выходной сигнал

/dev/mapper/dm_crypt-0: UUID="r7TBdk-1GZ4-zbUh-007u-BfuP-dtis-bTllYi" TYPE="LVM2_member"
/dev/sda2: UUID="64528d97-f05c-4f34-a238-f7b844b3bb58" UUID_SUB="263ae70e-d2b8-4dfe-bc6b-bbc2251a9f32" TYPE="btrfs" PARTUUID="494be592-3dad-4600-b1824-e29b
/dev/sdb: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="4aeb4804-6380-5421-6aea-d090e6aea8a0" LABEL="ubuntu-server:0" TYPE="linux_raid_member"
/dev/sdc: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="9d5a4ddd-bb9e-bb40-9b21-90f4151a5875" LABEL="ubuntu-server:0" TYPE="linux_raid_member"
/dev/sdd: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="f08b5e6d-f971-c622-cd37-50af8ff4b308" LABEL="ubuntu-server:0" TYPE="linux_raid_member"
/dev/sde: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="362025d4-a4d2-8727-6853-e503c540c4f7" LABEL="ubuntu-server:0" TYPE="linux_raid_member"
/dev/md0: UUID="a5b5bf95-1ff1-47f9-b3f6-059356e3af41" TYPE="crypto_LUKS"
/dev/mapper/vg0-lv--0: UUID="6db4e233-5d97-46d2-ac11-1ce6c72f5352" TYPE="swap"
/dev/mapper/vg0-lv--1: UUID="4e1a5131-cb91-48c4-8266-5b165d9f5071" UUID_SUB="e5fc407e-57c2-43eb-9b66-b00207ea6d91" TYPE="btrfs"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/sda1: PARTUUID="fa30c3f5-6952-45f0-b844-9bfb46fa0224"

кошка /proc/mdstat

Личности: [raid6] [raid5] [raid4] [линейный] [многопутевой] [raid0] [raid1] [raid10]
md0 : активный raid5 sdb[0] sdc[1] sdd[2] sde[4]
      5860147200 блоков super 1.2 level 5, чанк 512k, алгоритм 2 [4/4] [UUUU]
      растровое изображение: 2/15 страниц [8 КБ], фрагмент 65536 КБ

неиспользуемые устройства: <нет>

lshw -c диск

  *-диск
       описание: Диск SCSI
       продукт: ДТ 101 Г2
       производитель: Кингстон
       физический идентификатор: 0.0.0
       информация о шине: scsi@0:0.0.0
       логическое имя: /dev/sda
       версия: 1.00
       серийный номер: хххххххххххххххххх
       размер: 7643 МБ (8015 МБ)
       возможности: съемный
       конфигурация: ansiversion=4 logicalsectorsize=512 размер_сектора=512
     *-Средняя
          физический идентификатор: 0
          логическое имя: /dev/sda
          размер: 7643 МБ (8015 МБ)
          возможности: gpt-1.00 разделенный на разделы разделенный на разделы:gpt
          конфигурация: guid=6c166e3e-27c9-4edf-9b0d-e21892cbce41
  *-диск
       описание: Диск ATA
       продукт: ST2000DM008-2FR1
       физический идентификатор: 0.0.0
       информация о шине: scsi@1:0.0.0
       логическое имя: /dev/sdb
       версия: 0001
       серийный номер: хххххххххххххххххх
       размер: 1863 ГБ (2 ТБ)
       возможности: съемный
       конфигурация: ansiversion = 5 logicalsectorsize = 512 размер сектора = 4096
     *-Средняя
          физический идентификатор: 0
          логическое имя: /dev/sdb
          размер: 1863 ГБ (2 ТБ)
  *-диск
       описание: Диск ATA
       продукт: ST2000DM008-2FR1
       физический идентификатор: 0.0.0
       информация о шине: scsi@2:0.0.0
       логическое имя: /dev/sdc
       версия: 0001
       серийный номер: хххххххххххххххххх
       размер: 1863 ГБ (2 ТБ)
       возможности: съемный
       конфигурация: ansiversion = 5 logicalsectorsize = 512 размер сектора = 4096
     *-Средняя
          физический идентификатор: 0
          логическое имя: /dev/sdc
          размер: 1863 ГБ (2 ТБ)
  *-диск
       описание: Диск ATA
       продукт: WDC WD20EZBX-00A
       производитель: Вестерн Диджитал
       физический идентификатор: 0.0.0
       информация о шине: scsi@3:0.0.0
       логическое имя: /dev/sdd
       версия: 1A01
       серийный номер: хххххххххххххххххх
       размер: 1863 ГБ (2 ТБ)
       возможности: съемный
       конфигурация: ansiversion = 5 logicalsectorsize = 512 размер сектора = 4096
     *-Средняя
          физический идентификатор: 0
          логическое имя: /dev/sdd
          размер: 1863 ГБ (2 ТБ)
  *-диск
       описание: Диск ATA
       продукт: WDC WD20EZBX-00A
       производитель: Вестерн Диджитал
       физический идентификатор: 0.0.0
       информация о шине: scsi@4:0.0.0
       логическое имя: /dev/sde
       версия: 1A01
       серийный номер: хххххххххххххххххх
       размер: 1863 ГБ (2 ТБ)
       возможности: съемный
       конфигурация: ansiversion = 5 logicalsectorsize = 512 размер сектора = 4096
     *-Средняя
          физический идентификатор: 0
          логическое имя: /dev/sde
          размер: 1863 ГБ (2 ТБ)

Видите ли вы что-нибудь, что может быть не так в настройках? Как вы думаете, было бы полезно добавить nvme с картой PCI и использовать ее для кэширования?

флаг us
Вы не должны использовать RAID5, если вам нужна надежность. Когда один диск ломается, вероятность поломки второго диска во время повторного использования достаточно высока. Когда второй диск ломается, все ваши данные теряются.
флаг br
+1 к Tero - R5 практически мертв уже более десяти лет - друзья не позволяют друзьям использовать R5 :)
флаг cn
Эй, ребята, что бы вы предложили для более быстрого доступа, большего размера и все еще избыточного? Я был готов использовать 1 жесткий диск, чтобы получить 6 ТБ и при этом быть в безопасности на один
Рейтинг:1
флаг ca

Плохие записанные выступления связаны с разными факторами:

  • механические диски просто очень плохо справляются со случайным чтением/записью ввода-вывода. Открывать как плохо они могут быть, просто добавьте --синхронизация=1 на ваш фио команда (рассказ: они невероятно плохо, по крайней мере, по сравнению с правильными RAID-контроллерами BBU или твердотельными накопителями с защитой от потери питания);

  • RAID5 имеет неотъемлемый штраф за запись из-за чтения/изменения/записи чередования. Более того, настоятельно рекомендуется избегать это на механических дисках емкостью несколько ТБ из соображений безопасности. Имея 4 диска, серьезно рассмотрите возможность использования RAID10;

  • LUKS, обеспечивающий программное шифрование всего диска, неизбежно оказывает (значительную) нагрузку как на чтение, так и на запись;

  • при использовании BTRFS LVM совершенно не нужен. Хотя толстый том на основе LVM сам по себе не ухудшит производительность каким-либо значимым образом, вы, тем не менее, вставляете еще один уровень ввода-вывода и подвергаете себя (большему количеству) проблем с выравниванием;

  • наконец, сама BTRFS не особенно быстра. В частности, ваши медленные последовательные чтения могут быть отслежены до ужасной фрагментации BTRFS (из-за того, что это CoW и обеспечение детализации 4K - для сравнения, чтобы получить хорошую производительность от ZFS, обычно следует выбирать записи 64K-128K при использовании механических дисков).

Чтобы сравнить базовую производительность, я настоятельно рекомендую переделать ваш стек ввода-вывода, измеряя случайную и последовательную скорость чтения/записи на каждом этапе. Другими словами:

  • создайте массив RAID10 и запустите дд и фио на необработанном массиве (без файловой системы);

  • если действительно нужно полное шифрование диска, используйте LUKS для создания зашифрованного устройства и повторного запуска дд + фио на необработанном зашифрованном устройстве (опять же, без файловой системы). Сравните с предыдущими результатами, чтобы иметь представление о том, что это означает с точки зрения производительности;

  • пытаться обе XFS и BTRFS (под управлением обычного дд + фио quick Bench), чтобы понять, как ведут себя две разные файловые системы. Если BTRFS работает слишком медленно, попробуйте заменить его на lvmthin и XFS (но помните, что в этом случае вы потеряете контрольную сумму пользовательских данных, для чего нужен еще один слой — dmintegrity - сам по себе имеет значительный успех в производительности).

Если все это кажется беспорядком, что ж, это действительно так. Делая все вышеперечисленное, вы просто снижаете производительность хранилища: нужно было учитывать реальное поведение приложения (а не полностью последовательное дд или чистый рандом фио результаты), коэффициент попаданий в кэш, выравнивание шаблонов ввода-вывода и т. д. Но эй — немного намного лучше, чем ничего такого, так что давайте начнем с чего-то основного.

флаг cn
Итак, что бы вы сказали о том, чтобы иметь luks, а затем lvm со старым добрым ext4 и убрать все причудливые вещи, будет ли это лучше при последовательной записи и чтении? У меня есть пара приложений, которые используют базы данных sqlite, а также записывают локальные файлы метаданных: например, raidr, sonarr, readarr и plex, но все эти чтения сильно сказываются на всей системе. У меня также было много проблем с запуском таких команд, как kubectl get pod, поскольку он создает много небольших файлов для кэширования, поэтому для этого я просто смонтировал tmpfs в эту папку, но делаю это, поэтому в конечном итоге мне не хватит памяти, даже работая с этим типом эфемерный
флаг cn
Я имею в виду, я понятия не имею, почему я использовал lvm, прежде чем я использовал luks с mdadm и ext 4.
shodanshok avatar
флаг ca
без LVM вы теряете моментальные снимки на уровне блоков; если ваша файловая система изначально не поддерживает их (например, ext3/4, xfs и т. д.), вы не сможете делать снимки. Только вы можете оценить, насколько важны (или нет) потери моментальных снимков. btrfs, с другой стороны, имеет встроенные моментальные снимки, поэтому ему не нужен LVM, но я обнаружил, что его производительность довольно низкая для всего, кроме простого файлового сервера.
флаг cn
Большое спасибо! Я изменил его на рейд 10 и использовал luks + lvm + ext, и при записи он достиг 150 МБ / с.
Рейтинг:1
флаг ng

Краткая версия: я думаю, что ваша проблема, вероятно, в том, что ваш тест использует случайные записи, которые намного меньше размера вашего блока RAID.

Замечали ли вы проблемы с производительностью при использовании системы? Или просто результаты тестов выглядят плохо? Этот тест случайной записи 16 КБ приближается к наихудшему случаю для этого RAID 5 с большим куском 512 КБ.

RAID 5 имеет блок четности, который необходимо обновлять вместе с данными. Если бы у вас была последовательная рабочая нагрузка, которую ядро ​​могло бы разделить на записи по 512 КБ, вы бы просто вычисляли новую информацию о четности, а затем записывали блок данных и блоки четности. Одна запись в переводе на две записи.

Но с записью 16 КБ, которая намного меньше размера блока, вы должны сначала прочитать старые данные и старую четность, затем вычислить новую информацию о четности, а затем записать новые данные и четность. Это чтение-чтение-запись-запись. Одна операция записи преобразуется в четыре ввода-вывода. При случайной записи даже самый лучший RAID-контроллер на планете не может предсказать, какие фрагменты следует кэшировать.

Если вы используете массив для хранения больших файлов, то вам повезло: вы просто используете неправильный тест для оценки его производительности. Если вы измените рандом просто записывать в вашем бенчмарке, чтобы записи были последовательными, должно стать намного лучше!

Но если ваша рабочая нагрузка действительно состоит из более случайных небольших операций записи, вам придется что-то изменить в массиве. Вам лучше подойдет 4-дисковый RAID 10. Но, тем не менее, это вращающийся носитель. Это не потрясет ваш мир. Я полагаю, что производительность RAID 10 должна быть в 2-3 раза больше, чем у вас сейчас, примерно от 275 до 400 IOPS, может быть, от 4 МБ/с до 6 МБ/с в этом тесте?

Что касается использования SSD для кэширования, возможно, с чем-то вроде bcache вы устраните избыточность. Рассмотрите возможность использования RAID 1 из двух SSD для кэширования? Вам определенно не нужен NVMe, учитывая скорость этих дисков. SATA подойдет.

(Кстати, не парьтесь о разделах и необработанных устройствах. Это не имеет значения. Лично я не использую разделы.)

флаг cn
Привет, Майк, большое спасибо за ответ! Проблема с производительностью, которую я заметил, была при использовании системы. Сначала я провел простой тест dd, записав последовательную запись 0, и, тем не менее, он не был близок к скорости этого sata. Итак, просто чтобы показать вам, что я переделал это и использовал сайт блокировки рейда, чтобы вы могли видеть, как это происходит. ``` root@hp-proliant-dl160-g6-1:~# dd if=/dev/zero of=disk-test oflag=direct bs=512k count=100 100+0 записей в 100+0 записей 52428800 байт (52 МБ, 50 МБ) скопировано, 5,81511 с, 9,0 МБ/с ``` я хотел рейд 5, чтобы я мог использовать больше spc и все еще иметь безопасность в случае сбоя
Nikita Kipriyanov avatar
флаг za
... избыточность SSD-кэша можно легко восстановить, используя *два* SSD, создав из них массив RAID1 и используя *этот массив* в качестве устройства кэширования.
Mike Andrews avatar
флаг ng
@JaysonReis, вау... это медленно. Пара идей: во-первых, просто для проверки работоспособности исключите возможность остановки дисков. Когда вы делаете этот тест, попробуйте `dd`, а затем повторите его сразу после этого. Возьмите хронометраж со 2-го прогона. Кроме того, то, что @shodanshok описал ниже, является хорошим советом: профилируйте RAID напрямую, а затем добавляйте слои. Посмотрите, сможете ли вы выяснить, какой слой вызывает проблему.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.