Как решить проблемы с производительностью массива RAID5?

У меня два сервера с аппаратьным массивом RAID 5.

Какие RAID-контроллеры используются?

Обычный программный RAID практически всегда работает лучше, чем аппаратный RAID на дешёвых контроллерах.

Но утилизациция на первом массиве просто зашкаливает. Второй по утилизации не показывает проблем.

Объясни: что ты подразумеваешь под «утилизацией»?

программный RAID практически всегда работает лучше

Интересно, как он может работать лучше, если дополнительно нагружает процессор и память? Плюс он очень опасен в плане того, что можно потерять все данные.

Поставь 3 диска с первого сервера на второй. Тогда поймешь есть ли с ними проблема.

Интересно, как он может работать лучше, если дополнительно нагружает процессор и память?

Современные процессоры уже давно достаточно быстры чтобы рвать дешёвые RAID-контроллеры как тузик тряпку по части скорости обработки данных. Да, ценой того, что CPU выполняет больше работы, чем хотелось бы.

Если бездумно заменить программный RAID на аппаратный, то общая производительность может упасть просто засчёт того, что боттлнек переедет в RAID-контроллер.

Плюс он очень опасен в плане того, что можно потерять все данные.

Лично я коду в ядре доверяю многократно больше, чем коду, который работает на «аппаратном» RAID-контроллере.

Плюс, я ни разу лично не видел чтобы линуксовый программный RAID терял данные не по вине юзера. А вот потерю данных на аппаратных RAID видел неоднократно. Один раз - на ънтерпрайзной дисковой полке, правда не лично, а по переписке коллег в почте.

А восстановление данных при умершем контроллере - это отдельная страшная история.

Не используй RAID5. Не используй «аппаратный» RAID, если не уверен, что именно он тебе нужен.

CPU выполняет больше работы, чем хотелось бы

Ты видел аппаратный RAID? Например одна плата может поддерживать до 255 дисков, а теперь прикинь чем будет занят основной процессор при таком числе дисков, если будет гонять все данные через свою память?

$500 - это дорогой контроллер?

коду в ядре доверяю многократно больше, чем коду, который работает на «аппаратном» RAID-контроллере

дело не в коде, а в батерейке кеша. Если у тебя ядро зависнет, ФС может быть порушена, про что я слышал неоднократно.

восстановление данных при умершем контроллере

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

А что ты хочешь? В первом 3 диска, во втором 4.
Т.е. первый массив уже медленнее второго и у него будет бОльшая утилизация.
А если еще и контроллер на первом сервере менее мощный, то это еще более усугубит различие.

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

Да ладно? Т.е. если у вас мрет, мать, память - вы тоже только из бэкапа?

Если у тебя ядро зависнет, ФС может быть порушена, про что я слышал неоднократно.

Батарейка тут никак не поможет.

Если у тебя ядро зависнет

Я много раз видел, как зависает ядро контроллера при нештатных ситуациях.

Ты видел аппаратный RAID?

Да.

Например одна плата может поддерживать до 255 дисков, а теперь прикинь чем будет занят основной процессор при таком числе дисков, если будет гонять все данные через свою память?

Вот это как раз тот самый редки случай, когда аппаратный RAID может иметь смысл. Но вряд ли в виде просто контроллера. Скорее полка с доступом по FC или Ethernet. И то, можно посмотреть куда-нибудь в сторону Ceph вместо этого всего.

А теперь ещё раз внимательно прочитай первое сообщение в теме, и увидь, что у автора темы максимум четыре диска в рейде. Не 255. Для четырё аппаратный RAID-контроллер нафиг не нужен. Исключение - если нужно выдавить лишние полпроцента производительности из системы. Но такое нужно исключительно редко.

$500 - это дорогой контроллер?

На 255 дисков то? Чот дёшево...

дело не в коде, а в батерейке кеша.

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

Если у тебя ядро зависнет, ФС может быть порушена, про что я слышал неоднократно.

Батарейка от этого не поможет.

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

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

Для стороны хоста есть штуки типа dm-integrity и навороченных ФС со встроенным контролем целостности данных.

Плюс можно писать контрольные суммы для всего на уровне приложений.

Только из бекапа, который дает гарантию целостности.

Гарантия целостности бэкапа должна обеспечиваться теми же способами, что и гарантия целостности «живых данные». Как - я написал выше. Если это специально не делать, то гарантий никаких не будет. Даже если у тебя «полностью аппаратный» сторадж за 100500 денег.