LINUX.ORG.RU
ФорумAdmin

Использование raid в Linux.

 , , ,


4

5

Пока пользуешься raid-1 и не волнует скорость, глубина всех труднострей плохо понятна. Ситуация сейчас такая:

raid10                   280 МБ/с запись, 380 МБ/с чтение.

dm-integrity + raid10    200 МБ/с запись, 280 МБ/с чтение.

dm-integrity + raid5     50 МБ/с запись, чтение даже не смотрел
                         (синхронизация падает до 20МБайт/с)

raid5                    какая-то приличная скорость, сравнимая с ZFS,
                         не помню деталей, такая конфигурация не интересна

ZFS                      < 140 МБ/с запись, синхронизация
                         с первой космической скоростью.

Неустраивает что медленно. Диски самые дешевые, SMR, на 5600об/с. Что не устраивали критику – сравнил с CMR на 7200 и не увидел заметной разницы, может процентов на 20 по скорости записи больших блоков и раза в два при записи кучи мелких. То что «raid на SMR не работает» – в значительной степени миф. Может на дисках WD и не работает, в данном случае Seagate.

Интересует в первую очередь скорость записи больших файлов, а не работа в качестве сервера СУБД (тогда CMR).

Во вторую очередь интересует контроль целостности записанных данных, ввиду понимания, что на сколько-нибудь большом объёме единичные ошибки это уже как правило, а не редкая случайность.

В чём проблема: применение dm-integrity сильно замедляет. Сравнивал без bitmap’а и без журнала, понимаю, они тормозят ещё больше. Конкретно raid5 замедляется катастрофически, и хуже того, я попробовал всё то же самое сделать на SSD и получил те же 50МБ/сек!!! Это полное фиаско!

Проблема не в дисках, проблема в самом линуксе! Скорость записи дисков порядка 160..80МБ/сек (снижается к концу диска) у SMR и 180..80 у CMR. SMR хуже ведут себя только на массе мелких записей, не фатально, раза в два всего.

Более того, я был шокирован, когда увидел, что изначально конструкция dm-integrity + raid10 работает быстрей, чем raid10 без ничего. Потыкался и сменил io scheduler с mq-deadline на bfq, скорость немного подрасла, и самое главное всё стало на свои места. raid10 без ничего всё же заметно быстрей, чем с dm-integrity. Но для raid5 ничего не помогает, он просто медленно пишет и совершенно непонятно где затык.

ZFS конечно всем хороша, но скорость записи у ней ограничена скоростью одного диска и через это не перепрыгнешь. Честно говоря, смотря на цифры raid10 без integrity понимаю, что хочу видеть что-то подобное, может процентов на 10 хуже, но никак не в разы.

Кроме того, в ZFS неудобно с шифрованием (zfs поверх четырех разделов dm-crypt – это какой-то идиотизм). В смысле с шифрованием все ок, но совершенно не ок с возможностью подмены данных (с обычным dm-crypt это невозможно, все развалится).

Кроме того, в ZFS нет writeback кеша на ssd. Только writethrough, что ограничивает скорость записи дисками (и нужно много памяти для самой zfs). Хотелось бы сверху всего иметь dm-cache.

Всё же видимо integrity и raid5 в linux катастрофически не совместимы и проще смириться и забыть оставшись с raid10. Может кто посоветует, как поднять скорость записи. Как я понимаю, в значительной степени проблема в том, что linux пишет прерывисто, когда работает с dm-integrity, есть лаг между окончанием предыдущей записи и началом следующей. При записи на сырой диск с помощью dd, при работе raid10 без integrity, такой проблемы нет. Странно, казалось бы проблема носит массовый характер, но в интернете мало об этом пишется. Каких-то толковых советов что подкрутить не нашел. Пробовал readahead увеличивать – без толку (правильно, тут же чистая запись), пробовал у raid5 stripe cache size увеличивать, ускоряет но лишь немного, и как я писал, смена io scheduler на bfq тоже несколько ускоряет.

В btrfs raid5 вроде ж не работает. Может стоит попробовать raid10 в btrfs? Там же вроде встроенная проверка целостности данных?

Может быть, имеет смысл разделить всё на два «раздела». Быстрый raid10 без integrity для часто изменяемых данных и медленный ZFS для остального. Но так неудобно.

Да и неудобство бэкапов с ext4. Снапшота нет, что там dump запишет – одному богу известно…


Прочитав сей монолог, так и не понял, а в чём вопрос?

Minona ★★☆
()

Но для raid5 ничего не помогает, он просто медленно пишет и совершенно непонятно где затык.

Посмотри iostat’ом, какие операции прилетают на диски.
Я никогда не юзал dm-integrity, но выглядит так, как будто он генерирует дополнительные iops, с которыми твои медленные диски уже не справляются.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)

У меня

[root@mark ~]# lsscsi 
[11:0:0:0]   disk    ATA      WDC WD20EARS-00J 0A80  /dev/sdb 
[root@mark ~]# dd if=/dev/zero of=/dev/sdb bs=1M count=4096 oflag=direct status=progress
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 36.417 s, 118 MB/s

dm-integrity без журнала:

[root@mark ~]# integritysetup format /dev/sdb --no-wipe
[root@mark ~]# integritysetup open /dev/sdb integ -D
[root@mark ~]# integritysetup status integ
/dev/mapper/integ is active.
  type:    INTEGRITY
  tag size: 4
  integrity: crc32c
  device:  /dev/sdb
  sector size:  512 bytes
  interleave sectors: 32768
  size:    3876612136 sectors
  mode:    read/write
  failures: 2
  journal: not active
[root@mark ~]# dd if=/dev/zero of=/dev/mapper/integ bs=1M count=4096 oflag=direct status=progress
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 39.8519 s, 108 MB/s

Разница в последовательной записи мегабайтными блоками около 10%.

Ты не пробовал сделать integrity поверх дисков, а поверх integrity уже raid5?

Надо выбрать оптимальный размер страйпа, чтобы при записи целого страйпа записывалось целое количество crc-секторов. Сектора на самом деле 4k, поэтому одному 4k crc-сектору соответствует 1024 сектора данных, т.е. 512k:

integritysetup format /dev/sdb
integritysetup format /dev/sdc
integritysetup format /dev/sdd
integritysetup open /dev/sdb integ1 -D
integritysetup open /dev/sdc integ2 -D
integritysetup open /dev/sdd integ3 -D
pvcreate /dev/mapper/integ1
pvcreate /dev/mapper/integ2
pvcreate /dev/mapper/integ3
vgcreate vg /dev/mapper/integ1 /dev/mapper/integ2 /dev/mapper/integ3
lvcreate -n data --type raid5 -L '100%' -i 3 -I 512k vg
iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Ты не пробовал сделать integrity поверх дисков, а поверх integrity уже raid5?

Именно так и имеет смысл, именно так и пробовал. Получается медленно. Может быть дело в том, что я добавлял «-s 4096» (sector size). Пробовал и -B, и -D, и разный интерлив, вот не 4096 сектор не пробовал. Но даже на SSD 50мбайт/сек. Сложилось впечатление вообще, что на стыке raid и integrity какой-то затык.

Сейчас собрал такую конструкцию:

     btrfs raid1  
----------------------
dm-crypt     dm-crypt
---------    ---------
lvm raid0    lvm raid0
---------    ---------
sda   sdb    sdc   sdd

И скорость порядка 260МБ/с запись и 360МБ/с чтение. Неплохо по сравнению со всеми прочими вариантами, лучше чем с dmraid и integrity, лучще чем ZFS (140МБайт/сек).

Создалось впечатление, что lvm raid работает лучше, чем raid0 из dmraid. :-/ И еще, что добавление слоя dm-crypt ускоряет рейд или integrity. Но впихнуть его между integrity и raid не выходит, хочется то такого:

                 btrfs
                --------
                dm-crypt
                --------
                 raid 5
------------------------------------------
integrity  integrity  integrity  integrity
---------  ---------  ---------  ---------
  sda         sdb        sdc        sdd

Тут видимо забыть до лучших времён или ZFS. Там ж ещё журнал непонятно куда писать (тот же диск, или SSD, но SSD тоже ж сломаться может). Или битмап с которым всё тормозит. Если бы оно хоть скорость одного диска как ZFS давало…

Ещё непонятая история с dm-cache. Вот по первой схеме между btrfs и 2 x dm-crypt включен dm-cache на ssd (2 кеша). Вроде и работает, и ускоряет. Но…

  1. скорость записи падает до 800МБайт/с (на сам ssd более 2ГБайт/с всегда).

  2. скорость чтения не поднимается выше 2ГБайт/сек, типично же плавает вокруг тех же 800МБайт/с.

  3. данные из кеша вылетают и заново постоянно считываются с диска (проверяется многократным перечитыванием 5-гбайтного файла), что вызывает постоянную ЗАПИСЬ на ssd (и трату ресурса впустую).

  4. сам кеш работает странно, нет логика в этом конечно есть, но итог печальный: он пытается одновременно читать со всех дисков в равных долях примерно. Отсюда и 800МБайт/сек. Было бы быстрей всё считать с SSD (он NVMe).

Пробовал переключать policy на mq, smq, cleaner. В последнем варианте пропала проблема #4. В остальном всё одинаково. Кеш для теста создавал через lvm с размерами metadata 1ГБ и данных 10ГБ. Хотя видимо долно быть порядка 9995.5МБ данных и 4.7МБ метадата. Может быть сильное несоответствие размера кеша и ОЗУ играет роль (ОЗУ сильно больше). :-/

Но всё равно и пункт 3 и пункты 1/2 намекают, что единственный возможный вариант сборки дискового массива в линуксе: быстрые HDD, raid10 или raid0 + dm-crypt + btrfs-raid-1 и попросту никаких кешей. Легко увеличить число дисков в два раза и SSD станет бессмысленным. Зачем такой кеш. :-(

Скорость измерял так: time sh -c ‘dd if=/dev/zero of=test-file bs=$((1024*1024)) count=5000; sync’. Потом на калькуляторе считал. Ибо dd sync не делает и показывает космические цифры.

Может кто-то подскажет простенький бенчмарк? Все используют fio, но все дают ему разные параметры и получают разные, не сравнимые, результаты. Какой спрашивается смысл…

fk0
() автор топика

Нужно в несколько потоков тестить программный раид, один поток последовательно работает увы.

naKovoNapalBaran
()
Последнее исправление: naKovoNapalBaran (всего исправлений: 1)
Ответ на: комментарий от fk0

У меня нет системы с тремя дисками для raid5 и nvme ssd для кеша, я твою конфигурацию воспроизвести не могу.

dd все умеет, и показ скорости без калькулятора, и sync. Надо просто внимательно ман прочитать. Для бенчмаркинга на мой взгляд больше подходит режим без кеширования oflag=direct, который я и использовал.

iliyap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.