Как проверить, что 'mdadm' СОВЕРШАЕТ РЕЙД при выполнении?

synclient TapButton1=1

работы для меня.

42
14.01.2017, 02:50
5 ответов

Точка RAID с дублированием - то, что это будет продолжать идти, пока это может, но очевидно это обнаружит ошибки, которые помещают его в ухудшенный режим, такой как сбойный диск. Можно показать текущий статус массива с mdadm -D:

# mdadm -D /dev/md0
<snip>
       0       8        5        0      active sync   /dev/sda5
       1       8       23        1      active sync   /dev/sdb7

Кроме того, статус возврата mdadm -D является ненулевым, если существует какая-либо проблема, такая как неудавшийся компонент (1, указывает на ошибку, которую компенсирует режим RAID, и 2 указывает на полный отказ).

Можно также получить быструю сводку всего состояния устройства RAID путем взгляда на /proc/mdstat. Можно получить информацию об устройстве RAID в /sys/class/block/md*/md/* также; посмотрите Documentation/md.txt в документации ядра. Некоторые /sys записи перезаписываемы также; например, можно инициировать полную проверку md0 с echo check >/sys/class/block/md0/md/sync_action.

В дополнение к этим выборочным проверкам mdadm может уведомить Вас, как только что-то плохо происходит. Удостоверьтесь, что Вы имеете MAILADDR root в /etc/mdadm.conf (некоторые дистрибутивы (например, Debian) настраивают это автоматически). Затем Вы получите уведомление по электронной почте, как только ошибка (ухудшенный массив) происходит.

Удостоверьтесь, что Вы действительно получаете почту, отправляют к корню на локальной машине (некоторые современные дистрибутивы опускают это, потому что они полагают, что вся электронная почта проходит внешних поставщиков — но получающий местную почту необходимо для любого серьезного системного администратора). Протестируйте это путем отправки корню почты: echo hello | mail -s test root@localhost. Обычно, надлежащая почтовая установка требует двух вещей:

  • Выполните MTA на своей локальной машине. MTA должен быть настроен, по крайней мере, для разрешения доставки местной почты. Все дистрибутивы идут с подходящим MTAs, выбирают что-либо (но не nullmailer, если Вы хотите, чтобы электронная почта была поставлена локально).
  • Почта перенаправления, идущая в системные учетные записи (по крайней мере, root) к адресу, который Вы регулярно читаете. Это может быть Вашей учетной записью на локальной машине или внешним адресом электронной почты. С большей частью MTAs адрес может быть настроен в /etc/aliases; у Вас должна быть строка как

    root: djsmiley2k
    

    для локальной доставки, или

    root: djsmiley2k@mail-provider.example.com
    

    для удаленной доставки. При выборе удаленной доставки удостоверьтесь, что MTA настроен для этого. В зависимости от Вашего MTA Вы, возможно, должны работать newaliases команда после редактирования /etc/aliases.

56
27.01.2020, 19:35
  • 1
    Можно ли объяснить, почему nullmailer не должен использоваться? Это из-за причин, упомянутых в unix.stackexchange.com/questions/1449 / …? Который MTA Вы рекомендовали бы? –  Cameron Martin 30.06.2015, 04:30
  • 2
    @CameronMartin Nullmailer только пересылает почту к удаленной машине, это не делает локальной доставки. Можно использовать его, если у Вас есть сервер SMTP где-нибудь, который принимает почту от Вашей машины, но не, если Вы поставляете почту локально. Я отредактировал свой ответ для разъяснения. –  Gilles 'SO- stop being evil' 30.06.2015, 04:33

Можно вызвать проверку целого массива, в то время как он онлайн. Например, для проверения массива /dev/md0, выполненный как корень:

echo check > /sys/block/md0/md/sync_action

У меня также есть задание крона, которое выполняет следующую команду один раз в месяц:

tar c /dir/of/raid/filesystem > /dev/null

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

Одно небольшое предупреждение состоит в том что, если Ваша файловая система является большой, то эта команда собирается занять много времени; моя система берет о 6hr/TiB. Я выполняю его использование ionice так, чтобы остальная часть системы не прекращала работу во время проверки диска:

ionice -c3 tar c /dir/of/raid/filesystem > /dev/null
20
27.01.2020, 19:35
  • 1
    Отметьте это ionice будет только работать, если Вы будете использовать CFQ (по умолчанию) планировщик ввода-вывода. –  Totor 02.11.2013, 19:48
  • 2
    Таким образом, это может быть очевидно для большинства, но это не мне - как делает запущение скрипта, вывод которого перенаправляется к devnull, на самом деле уведомляют Вас относительно чего-то? Имеет место это, что, если "tar" встречается с какими-либо ошибками, они будут распространены до mdadm демона, который (по-видимому), пошлет Вам электронное письмо? –  ljwobker 04.09.2015, 06:09
  • 3
    Мой вопрос Вам stharward, то, как Вы берете на ошибках tar, если он выполняется от задания крона? Где это производит? Я думал бы, что Вы добавите перенаправление для stderr в файл, который мог периодически контролироваться или хвост его распечатанный к консоли открытия окна терминала :) –  Madivad 13.11.2015, 18:31
  • 4
    @ljwobker Извините за восстановление старого потока. Я думаю, что намерение команды tar здесь состоит в том, чтобы попытаться считать все содержание объема. Это проверило бы, что весь объем все еще читаем, и дайте md шанс обнаружить дефектный диск. –  mikepj 23.05.2017, 19:54

Я использую эту простую функцию для проверки /proc/mdstat:

#Health of RAID array
raid() { awk '/^md/ {printf "%s: ", $1}; /blocks/ {print $NF}'  /proc/mdstat; }
8
27.01.2020, 19:35

пакет Debian и Ubuntu 'mdadm' содержит файл

/etc/cron.d/mdadm

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

/usr/share/mdadm/checkarray --cron --all --idle --quiet

, которая проверяет все ваши массивы для согласованности (если вы не установили для AUTOCHECK значение false в / etc / default / mdadm ). Отчет будет отправлен пользователю «root» (убедитесь, что вы получаете такие письма).

11
27.01.2020, 19:35

Я добавил это в приглашение, создав /etc/profile.d/raid _status.sh:

raid_prompt() { awk '/^md/ {printf "%s: ", $1}; /blocks/ {print $NF}'  /proc/mdstat | awk '/\[U+\]/ {print "\033[32m" $0 "\033[0m"}; /\[.*_.*\]/ {print "\033[31m" $0 "\033[0m"}'; }

Затем установите PS1 на:

PS1='$(raid_prompt)\n[\u@\h \W]\$ '

Это печатает имя массива и статус элемента зеленым цветом, если все элементы активны. Если элемент выходит из строя, он печатается красным цветом.

0
01.10.2020, 18:41

Теги

Похожие вопросы