Как увеличить скорость RAID 5 с помощью mdadm + luks + lvm
Кажется, я немного запутался в текущей настройке сервера. Это HP Proliant dl160 gen 6, и я поставил 4 вращающихся диска с настройкой, в которой есть mdmadm + luks + lvm, а поверх него btrfs (, может быть, я зашел слишком далеко? )и он действительно страдает от скорости ввода-вывода, он читает около 50 МБ/с и записывает около 2 МБ/с, и у меня такое чувство, что я что-то напутал.
Одна из вещей, которые я отметил, это то, что я настроил mdadm на блочном устройстве (sbd ), а не на разделах (sdb1 ), повлияет ли это на что-то?
Здесь вы можете увидеть вывод fio fio --name=randwrite --rw=randwrite --direct=1 --bs=16k --numjobs=128 --size=200M --runtime=60 --group_reporting, когда машина почти не используется.
randwrite: (groupid=0, jobs=128): err= 0: pid=54290: Tue Oct 26 16:21:50 2021
write: IOPS=137, BW=2193KiB/s (2246kB/s)(131MiB/61080msec); 0 zone resets
clat (msec): min=180, max=2784, avg=924.48, stdev=318.02
lat (msec): min=180, max=2784, avg=924.48, stdev=318.02
clat percentiles (msec):
| 1.00th=[ 405], 5.00th=[ 542], 10.00th=[ 600], 20.00th=[ 693],
| 30.00th=[ 760], 40.00th=[ 818], 50.00th=[ 860], 60.00th=[ 927],
| 70.00th=[ 1011], 80.00th=, 90.00th=[ 1267], 95.00th=[ 1452],
| 99.00th=[ 2165], 99.50th=[ 2232], 99.90th=[ 2635], 99.95th=[ 2769],
| 99.99th=[ 2769]
bw ( KiB/s): min= 3972, max= 4735, per=100.00%, avg=4097.79, stdev= 1.58, samples=8224
iops : min= 132, max= 295, avg=248.40, stdev= 0.26, samples=8224
lat (msec) : 250=0.04%, 500=2.82%, 750=25.96%, 1000=40.58%, 2000=28.67%
lat (msec) : >=2000=1.95%
cpu : usr=0.00%, sys=0.01%, ctx=18166, majf=0, minf=1412
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,8372,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=2193KiB/s (2246kB/s), 2193KiB/s-2193KiB/s (2246kB/s-2246kB/s), io=131MiB (137MB), run=61080-61080msec
Обновление 1 последовательной записи с помощью dd
root@hp-proliant-dl160-g6-1:~# dd if=/dev/zero of=disk-test oflag=direct bs=512k count=100
100+0 records in 100+0 records out 52428800 bytes (52 MB, 50 MiB) copied, 5.81511 s, 9.0 MB/s
Ядро :5.4.0 -89 -общий
ОС :Ubuntu 20.04.3
mdadm :4.1 -5ubuntu1.2
lvm2 :2.03.07 -1ubuntu1
blkid output
/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-b954-e2912e410b8b"
/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"
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid5 sdb[0] sdc[1] sdd[2] sde[4]
5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 2/15 pages [8KB], 65536KB chunk
unused devices: <none>
lshw -c disk
*-disk
description: SCSI Disk
product: DT 101 G2
vendor: Kingston
physical id: 0.0.0
bus info: scsi@0:0.0.0
logical name: /dev/sda
version: 1.00
serial: xxxxxxxxxxxxxxxxxxxx
size: 7643MiB (8015MB)
capabilities: removable
configuration: ansiversion=4 logicalsectorsize=512 sectorsize=512
*-medium
physical id: 0
logical name: /dev/sda
size: 7643MiB (8015MB)
capabilities: gpt-1.00 partitioned partitioned:gpt
configuration: guid=6c166e3e-27c9-4edf-9b0d-e21892cbce41
*-disk
description: ATA Disk
product: ST2000DM008-2FR1
physical id: 0.0.0
bus info: scsi@1:0.0.0
logical name: /dev/sdb
version: 0001
serial: xxxxxxxxxxxxxxxxxxxx
size: 1863GiB (2TB)
capabilities: removable
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
*-medium
physical id: 0
logical name: /dev/sdb
size: 1863GiB (2TB)
*-disk
description: ATA Disk
product: ST2000DM008-2FR1
physical id: 0.0.0
bus info: scsi@2:0.0.0
logical name: /dev/sdc
version: 0001
serial: xxxxxxxxxxxxxxxxxxxx
size: 1863GiB (2TB)
capabilities: removable
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
*-medium
physical id: 0
logical name: /dev/sdc
size: 1863GiB (2TB)
*-disk
description: ATA Disk
product: WDC WD20EZBX-00A
vendor: Western Digital
physical id: 0.0.0
bus info: scsi@3:0.0.0
logical name: /dev/sdd
version: 1A01
serial: xxxxxxxxxxxxxxxxxxxx
size: 1863GiB (2TB)
capabilities: removable
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
*-medium
physical id: 0
logical name: /dev/sdd
size: 1863GiB (2TB)
*-disk
description: ATA Disk
product: WDC WD20EZBX-00A
vendor: Western Digital
physical id: 0.0.0
bus info: scsi@4:0.0.0
logical name: /dev/sde
version: 1A01
serial: xxxxxxxxxxxxxxxxxxxx
size: 1863GiB (2TB)
capabilities: removable
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
*-medium
physical id: 0
logical name: /dev/sde
size: 1863GiB (2TB)
Вы видите что-нибудь, что может быть не так в установка? Как вы думаете, было бы полезно добавить nvme с картой PCI и использовать ее для кэширования?
Плохая записанная производительность связана с различными факторами:
механические диски просто очень плохо справляются со случайным чтением/записью ввода-вывода. Чтобы узнать, насколько плохими они могут быть, просто добавьте
--sync=1к вашейfioкоманде (short story:они невероятно плохие, по крайней мере, по сравнению с правильными RAID-контроллеры BBU или SSD-накопители с защитой от потери питания-);RAID5 имеет неотъемлемый штраф за запись из-за чтения/изменения/записи чередования. Более того, настоятельно рекомендуется избегать его на механических дисках с несколькими-ТБ по соображениям безопасности. Имея 4 диска, серьезно рассмотрите возможность использования RAID10;
LUKS, обеспечивающий программное-полное-шифрование диска, неизбежно оказывает (значительную)нагрузку как на чтение, так и на запись;
При использовании BTRFS LVM совершенно не нужен. Хотя толстый том на основе LVM-сам по себе не будет существенно снижать производительность, тем не менее, вы вставляете еще один уровень ввода-вывода и подвергаете себя (большему)проблемам с выравниванием;
Наконец, BTRFS сама по себе не особенно быстра. В частности, ваше медленное последовательное чтение может быть связано с ужасной фрагментацией BTRFS (, так как это CoWи , обеспечивающий гранулярность 4K -, для сравнения, чтобы получить хорошую производительность от ZFS, обычно следует выбирать 64K-. 128 КБ записей при использовании механических дисков).
Чтобы сравнить базовые показатели производительности,Я настоятельно рекомендую переделать ваш стек ввода-вывода, измеряя случайную и последовательную скорость чтения/записи на каждом этапе. Другими словами,:
создайте массив RAID10 и запустите
ddиfioна необработанном массиве (без файловой системы);если полное-шифрование диска действительно необходимо, используйте LUKS для создания зашифрованного устройства и повторно-запустите
dd+fioна необработанном зашифрованном устройстве (снова без файловой системы). Сравните с предыдущими результатами, чтобы понять, что это значит для производительности-;попробуйте как XFS, так и BTRFS (запустив обычный
dd+fioбыстрый стенд), чтобы понять, как ведут себя две разные файловые системы. Если BTRFS слишком медленный, попробуйте заменить его на lvmthin и XFS (, но помните, что в этом случае вы потеряете контрольную сумму пользовательских данных, для чего вам понадобится еще один слой-dmintegrity-со значительным снижением производительности).
Если все это кажется беспорядком, что ж, это действительно так. Делая все вышеперечисленное, вы просто снижаете производительность хранилища:, нужно было учитывать реальное поведение приложения (, а не полностью последовательные ddили чисто случайные fioрезультаты), коэффициент попаданий в кэш, выравнивание шаблонов ввода-вывода, и т. д. Но эй,-несколько намного лучше, чем ничего , так что давайте начнем с чего-нибудь простого.
Краткая версия:Я думаю, что ваша проблема, вероятно, заключается в том, что ваш тест использует случайные записи, которые намного меньше размера вашего RAID-блока .
Замечали ли вы проблемы с производительностью при использовании системы? Или просто результаты тестов выглядят плохо? Этот тест случайной записи 16 КБ приближается к наихудшему случаю для этого RAID 5 с большим куском 512 КБ.
RAID 5 имеет блок четности, который необходимо обновлять вместе с данными. Если бы у вас была последовательная рабочая нагрузка, которую ядро могло бы разделить на записи по 512 КБ, вы бы просто вычисляли новую информацию о четности, а затем записывали блок данных и блоки четности. Одна запись в переводе на две записи.
Но при записи 16 КБ, которая намного меньше размера фрагмента, вы должны сначала прочитать старые данные и старую четность, затем вычислить новую информацию о четности, а затем записать новые данные и четность. Это чтение-чтение-запись-запись. Одна операция записи преобразуется в четыре ввода/вывода. При случайной записи даже самый лучший RAID-контроллер на планете не может предсказать, какие фрагменты следует кэшировать.
Если вы используете массив для хранения больших файлов, то вам повезло,:что вы просто используете неправильный эталонный тест для оценки его производительности. Если вы измените randwriteна просто writeв своем тесте, чтобы записи были последовательными, все должно стать намного лучше!
Но если ваша рабочая нагрузка действительно состоит из более случайных небольших операций записи, вам придется что-то изменить в массиве. Вам лучше подойдет 4-дисковый RAID 10. Но, тем не менее, это вращающийся носитель. Это не потрясет ваш мир. Я полагаю, что производительность RAID 10 должна быть в 2-3 раза больше, чем у вас сейчас, примерно от 275 до 400 IOPS, может быть, от 4 МБ/с до 6 МБ/с в этом тесте?
Что касается использования SSD для кэширования, возможно, с чем-то вроде bcache, вы устраните избыточность. Рассмотрите возможность использования RAID 1 из двух SSD для кэширования? Вам определенно не нужен NVMe здесь,учитывая скорость этих дисков. SATA подойдет.
(Кстати, не парьтесь по поводу разделов и необработанных устройств. Это не имеет значения. Лично я не использую разделы.)