MD (Multiple Device) — это технология в Linux, которая позволяет объединять несколько физических дисков в один логический накопитель с помощью различных схем RAID (Redundant Array of Independent Disks). mdXXX (далее md disk) — это одино из устройств, созданных с использованием этой технологии. Для определения влияния проверки состояния (checking) массива md disk на производительность системы необходимо рассмотреть несколько аспектов.
Проверка состояния массива (MD Check)
Проверка состояния (или md check) — это процесс, при котором Linux проверяет целостность и согласованность данных на всех дисках массива.
Это может включать:a) Проверку и восстановление целостности данных.
б) Выравнивание (resync) данных между зеркальными (mirrored) дисками.
г) Перераспределение данных для RAID 5/6.
Влияние на производительность
Проверка состояния массива может значительно влиять на производительность системы.
Вот несколько ключевых моментов:а) I/O Операции: Проверка массива вызывает интенсивные операции чтения и записи, что может замедлить доступ к данным на этих дисках для других процессов.
б) Использование CPU: Процесс проверки состояния использует ресурсы процессора для вычислений и управления I/O операциями.
в) Задержки: Высокие задержки в доступе к дискам могут влиять на приложения, работающие с данными на этих дисках.
Управление влиянием проверки на производительность
Чтобы минимизировать влияние проверки состояния на производительность, можно применить следующие методы:
Настройка sysctl параметров:
dev.raid.speed_limit_min и dev.raid.speed_limit_max : Эти параметры позволяют ограничить минимальную и максимальную скорость проверки и выравнивания массива. Например:
Посмотреть текущие настройки можно следующим способом:
сat /proc/sys/dev/raid/speed_limit_min
cat /proc/sys/dev/raid/speed_limit_max
поулченные результат это Кбит/секунда
соответственно запишем для минимальной скорости 500Мб/сек
и максимальной 2000Мб/сек
для проверки в наименее нагруженное время увеличиваем или уменьшаем для перриода с наибольшей нагрузкой
echo 500000 > /proc/sys/dev/raid/speed_limit_min
echo 2000000 > /proc/sys/dev/raid/speed_limit_max
3.1. Планирование проверки: Выполняйте проверки в периоды низкой нагрузки на систему (например, ночью или в выходные).
3.2 . QoS (Quality of Service): Используйте QoS механизмы для управления приоритетами I/O операций.
3.1.1 Планирование проверки Укакзать время выполение проверки через CRON :
0 3 * * 0 /usr/share/mdadm/checkarray --all
3.1.2 Или средствами Systemd Timer :
Создайте файл таймера:
sudo nano /etc/systemd/system/mdcheck.timer
Добавьте в файл следующее содержимое:
[Unit]
Description=Run RAID check every Sunday at 3 AM
[Timer]
OnCalendar=Sun 03:00:00
Persistent=true
[Install]
WantedBy=timers.target
Создайте файл службы, который будет запускаться таймером:
sudo nano /etc/systemd/system/mdcheck.service
Добавьте в файл следующее содержимое:
[Unit]
Description=Check RAID arrays
[Service]
Type=oneshot
ExecStart=/usr/share/mdadm/checkarray --all
Перезагрузите systemd конфигурацию и активируйте таймер:
sudo systemctl daemon-reload
sudo systemctl enable --now mdcheck.timer
3.2.QoS (Quality of Service)
Использование Quality of Service (QoS) для управления нагрузкой на дисковую систему во время проверки состояния RAID массива может помочь минимизировать влияние этих операций на производительность. В Linux можно использовать такие инструменты, как ionice и cgroups для управления приоритетами ввода-вывода (I/O).
3.2.1 Использование ionice
ionice позволяет задавать приоритеты ввода-вывода для процессов в Linux.
Пример использования ionice :
Определите класс и уровень приоритета для проверки состояния массива. Например, можно использовать класс idle, чтобы проверка выполнялась только тогда, когда система не занята другими операциями:
ionice -c 3 /usr/share/mdadm/checkarray --all
Здесь:
-c 3 указывает, что процесс должен использовать класс idle , то есть выполнять I/O операции только тогда, когда другие процессы не активны.
Включите ionice команду в ваше cron задание или systemd службу.
Пример с Cron :
0 3 * * 0 ionice -c 3 /usr/share/mdadm/checkarray --all
Пример с Systemd Service :
[Unit]
Description=Check RAID arrays
[Service]
Type=oneshot
ExecStart=/usr/bin/ionice -c 3 /usr/share/mdadm/checkarray --all
3.2.2. Использование cgroups
Cgroups (Control Groups) — это механизм, который позволяет ограничивать и контролировать ресурсы, используемые группами процессов. Можно использовать cgroups для ограничения использования I/O ресурсов.
Пример использования cgroups :
Создайте новый cgroup для проверки RAID массива:
sudo cgcreate -g blkio:/raid_check
Установите лимиты ввода-вывода для этого cgroup . Например, можно ограничить скорость чтения/записи для устройств:
sudo cgset -r blkio.throttle.read_bps_device="8:0 1048576" raid_check
sudo cgset -r blkio.throttle.write_bps_device="8:0 1048576" raid_check
Здесь:
8:0 — это идентификатор вашего устройства (можно узнать с помощью команды lsblk или
ls -l /dev/disk/by-id) .
1048576 — это лимит скорости в байтах в секунду ( 1 МБ/с ).
Запустите проверку состояния массива в контексте нового cgroup:
sudo cgexec -g blkio:raid_check /usr/share/mdadm/checkarray --all
Включите эту команду в ваше cron задание или systemd службу.
Пример с Cron:
0 3 * * 0 sudo cgexec -g blkio:raid_check /usr/share/mdadm/checkarray --all
Пример с Systemd Service:
[Unit]
Description=Check RAID arrays
[Service]
Type=oneshot
ExecStart=/usr/bin/cgexec -g blkio:raid_check /usr/share/mdadm/checkarray --all
Вместо Заключения
Проверка состояния массива md disk в Linux может значительно повлиять на производительность системы , особенно в периоды интенсивного использования дисков. Однако, путем настройки параметров скорости проверки и планирования выполнения этих операций можно минимизировать негативное воздействие на производительность.
Использование QoS с помощью ionice и cgroups позволяет гибко управлять нагрузкой на систему во время проверки состояния RAID массива. ionice предоставляет простой способ управления приоритетами I/O, тогда как cgroups предлагает более детальный контроль и возможность ограничения различных ресурсов. Выбор подходящего метода зависит от конкретных требований и возможностей системы.