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 предлагает более детальный контроль и возможность ограничения различных ресурсов. Выбор подходящего метода зависит от конкретных требований и возможностей системы.
