Плохое IO из-за заказа LUKS / Software RAID / LVM?

Я пытаюсь определить, должен ли я повторно настроить свой массив RAID из-за плохой производительности ввода-вывода. Прежде всего, система:

  • i7 920
  • 4 4TB WD 5400 Зеленые диски
  • Хост CentOS 6.3

Во-вторых, установка диска:

  • / dev / sda2, b2, c2, d2 индивидуально зашифрованы LUKS
  • / dev / mapper / a2, b2, c2, d2 – все это часть программного обеспечения RAID5 / dev / md1
  • / dev / md1 имеет LVM поверх этого
  • LVM используется для разделения /, / хранения и свопинга

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

Например, если я запускаю тяжелую процедуру декомпрессии в RAR-файле случайных данных, мой IO Wait увеличивается примерно до 25% и замедляет общую систему. Мне интересно, если все наборы инструкций каким-то образом создаются из-за всех процессов kcryptd.

Поэтому я рассматриваю возможность перехода на:

  • / dev / sda2, b2, c2, d2 помещаются в / dev / md1
  • / dev / md1 зашифровывается и отображается на / dev / mapper / 1
  • LVM поверх / dev / mapper / 1

Это опустится до одного процесса kcrpytd, который также может быть узким местом в его собственном праве. Кто-нибудь думает, что это поможет с моей проблемой ввода-вывода?

Ваше расслоение субоптимально, потому что наложение рейда 5 поверх шифрования означает, что вы увеличиваете количество операций шифрования / дешифрования на 25% – поскольку 4 * 4 ТБ зашифрованы.

При установке шифрования поверх рейда 5 зашифровывается только 3 * 4 ТБ.

Причиной этого является то, что вы не должны шифровать данные о четности (которые в вашем примере занимают 4 ТБ) зашифрованных данных, потому что это не увеличивает вашу безопасность.

Ваша презумпция в отношении нескольких процессов шифрования является именно такой. При принятии на него решений это преждевременная оптимизация, которая может иметь совершенно противоположный эффект. Ваш i7 довольно мягок, возможно даже включая некоторые специальные инструкции, которые помогают ускорить работу AES, а ядро ​​Linux включает в себя несколько оптимизированных вариантов криптографических примитивов, которые автоматически выбираются во время загрузки.

Вы можете проверить, используются ли оптимизированные подпрограммы для вашего процессора, просматривая /proc/cpuinfo (например, флаг там), /proc/crypto , lsmod (если только модули aes не скомпилированы в ядро) и журнал ядра.

Вы должны проверить пропускную способность kryptd без привлечения каких-либо медленных дисков, чтобы увидеть, что такое верхняя граница (т.е. на диске RAM с использованием iozone).

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

В дополнение к криптографической теме, RAID 5 включает в себя больше операций ввода-вывода, чем RAID 1 или 10. Так как хранилище является довольно дешевым, возможно, это возможность купить больше жестких дисков и использовать другой уровень RAID.

Я бы ответил рейдом 1 + 0 [a2, b2] + [c2, d2], затем LVM над LUKS.

пример

 $ sudo mdadm --create /dev/md0 -v --raid-devices=4 \ --level=raid10 /dev/sdb1 /dev/sdc1 /dev/sde1 /dev/sde1 

ПРИМЕЧАНИЕ. Структурирование этого способа создаст полосу зеркал, позволяющую свести максимум 2 диска (по одному в каждом зеркале max), и это даст вам общее / 2 места, в отличие от raid5, который равен сумме * ~ 0.75.

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

Вы также можете проверить шифр, хотя я думаю, что aes-cbc-essiv является стандартным и достаточно быстрым, но вы можете использовать aes-xts-plain, который должен быть быстрее.

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

Я принял другой подход; вместо того, чтобы сделать один большой RAID, я разбил диски на разделы и создал несколько меньших (например, 8x 250G разделов на диске 2 ТБ). Это означает, что 8 RAID-массивов вместо 1, 8 контейнеров LUKS и LVM связывают все это вместе в одном большом VG.

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

Я поддерживал эту настройку даже в моем новом окне Haswell, где шифрование не является проблемой вообще благодаря AES-NI. Я сделал это, потому что есть другие положительные побочные эффекты. Например, один дефектный сектор может вывести из массива только 250G часть диска, а остальные 1750G остаются избыточными; или если есть ошибка, подобная панике ядра RAID5 в 3.13.0, только один из RAID должен пересинсталлировать вместо всех из них.

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