Дисковая подсистема - одно из самых частых мест возникновения сбоев в сервере (по причине механической организации систем хранения) и при этом одно из самых важных (в связи с тем, что там хранится самое важное - информация). Очевидно, что выход диска из строя на площадке хостинг-провайдера, расположенного в другой стране - ситуация фактически фатальная, так как для ремонта диска его нужно передать в соответствующую компанию (что уже само по себе крайне нетривиально) и даже в случае успешной передачи - это крайне дорогостоящая операция и нередко шанса на успех просто нету. Поэтому болезнь лучше предупреждать, чем лечить.
Профилактических мероприятий тут два: RAID массивы (с резервированием - raid - 1, 5, 6 10, raid-0 и его производные защиты от потери данные не дает) и самостоятельное слежение за здоровьем дисков посредством различных средств.
Защита данных посредством RAID
RAID массив является панацеей от подавляющего числа проблем с дисками, так как в случае его использования отказ 1 из дисков (я здесь о самом простейшем из RAID 1, зеркало) чреват лишь тем, что его надо будет заменить физически и пересобрать массив. Данные при этом потеряны не будут.
Но опять же, за массивом требуется следить. Так как он совершенно спокойно может перейти в состояние DEGRADED (то есть, один из его дисков отказал и массив работает в аварийном режиме), в котором сбой единственного оставшегося диска с данными чреват потерей всей информации. То есть, за массивом также нужно следить, а не просто "поставил и забыл".
Контроль состояния soft raid
Состояние soft-raid можно посмотреть командой:
Если же один из дисков откажет, то вместо [UU] будет [U_] либо [_U], это означает, что нужно написать в поддержку и указать на отказ одного из дисков и проблемы с RAID массивом. Вам должны будут заменить диск и, возможно, еще собрать массив.
Как же это автоматизировать? Не каждый же день дергать эту команду! Вообще, лучше каждый день. Потеря 1 секунды в сутки намного менее фатальна, чем отказ диска с информацией за годы. Конечно, есть способы автоматизации в виде mdadm monitor, но они упираются в электронную почту, которая никогда ни гарантией получения уведомления не отличалась. Так что если у Вас есть соответствующие знания, то пожалуйста, иначе - лучше руками.
Дает ли RAID гарантию от потери данных по механическим причинам?
Если же за RAID массивом следят и он всегда в состоянии ACTIVE, то я могу быть совершенно спокоен за данные? Да вот совершенно нет, кстати. Почему же? Во-первых, отказать могут сразу два диска (случай почти нереальный, но тем не менее согласно теории надежности имеющий место быть), может отказать электроника на одном из дисков, которая перестанет диагностировать ошибки чтения / записи (ввода-вывода) и на рабочий диск будет сдублирован мусор в итоге в лучшем случае немного повредится файловая система (обычно, лечится fsck), а в худшем будут потеряны данные. В своей практике я сталкивался с таким случаем и что-либо сделать в этом случае было нельзя.
Как защититься от форс-мажорных проблем c RAID
Для защиты от такого рода ошибок существует механизм само-тестирования массива. Когда система (по крону) раз в неделю запускает посекторное сравнение дисков массива и если находит отличия, сразу сообщает о них. Более подробно, об этом можно прочесть здесь: http://phpsuxx.blogspot.com/2010/04/warning-mismatchcnt-is-not-0-on-devmd2.html
Теперь немного о самих жестких дисках.
Мониторинг физического состояния жестких дисков
Проблемы с жестким диском можно определить двумя способами - напрямую (через систему самодиагностику жесткого диска именуемую SMART) и косвенно (ага, по потере данных, отказу сервера или же по ошибкам в dmesg).
S.M.A.R.T мониторинг жестких дисков
С мониторингом SMART посложнее, для его контроля используется пакет smartmontools (в CentOS его ставить: yum install -y smartmontools, в Debian: apt-get install -y smartmontools), в составе которого идет утилита smartctl, которая позволяет получить информацию от SMART подсистемы жестких дисков следующим образом:
Также в самом низу выдачи есть блоки "SMART Error Log Version: 1" - там могут быть большие записи (с кучей 16-ричных адресов), повествующие об отказе какой-либо из частей диска; если же диск в норме - там все должно быть пусто - "No Errors Logged". Кроме него, есть еще блок "SMART Self-test log structure revision number 1", в который пишутся результаты диагностических само-тестов диска. В нормальных условиях он выглядит так:
Если какой-либо из тестов FAILED, то это повод идти к оператору Дата Центра и запрашивать замену сбойного диска.
Косвенный мониторинг состояния жесткого диска
Самый очевидный вариант - когда жесткий диск был выброшен из RAID массива по причине FAULTY (то есть возникла ошика ввода вывода и диск был отключен). Также косвенным показателем отказа дисков являются разнообразные ошибки (например I/O error) в выдаче команды dmesg.
Это также говорит о подтвержденном сбое с заданным жестким диском и должна быть осуществлена его замена.
Если с RAID и SMART все в порядке, могу ли я быть спокоен за данные?
И снова нет. Для полной защиты необходим последний штрих - бэкапы на внешнем носителе.
Бэкапы
Многие очень часто ошибаются, утверждая, что RAID дает гарантию от потери данных. От механических причин он, конечно же, спасет. А вот от деструктивных действий хакеров или ошибки администратора - навряд ли. Поэтому всегда крайне обязательно иметь на удаленном сервере полную актуальную копию всех важных данных.
Профилактических мероприятий тут два: RAID массивы (с резервированием - raid - 1, 5, 6 10, raid-0 и его производные защиты от потери данные не дает) и самостоятельное слежение за здоровьем дисков посредством различных средств.
Защита данных посредством RAID
RAID массив является панацеей от подавляющего числа проблем с дисками, так как в случае его использования отказ 1 из дисков (я здесь о самом простейшем из RAID 1, зеркало) чреват лишь тем, что его надо будет заменить физически и пересобрать массив. Данные при этом потеряны не будут.
Но опять же, за массивом требуется следить. Так как он совершенно спокойно может перейти в состояние DEGRADED (то есть, один из его дисков отказал и массив работает в аварийном режиме), в котором сбой единственного оставшегося диска с данными чреват потерей всей информации. То есть, за массивом также нужно следить, а не просто "поставил и забыл".
Контроль состояния soft raid
Состояние soft-raid можно посмотреть командой:
cat /proc/mdstatесли все хорошо, то выдано там будет примерно следующее:
cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sda3[0] sdb3[1]
20972736 blocks [2/2] [UU]
md1 : active raid1 sda2[0] sdb2[1]
2104448 blocks [2/2] [UU]
md0 : active raid1 sda1[0] sdb1[1]
4200896 blocks [2/2] [UU]
Если же один из дисков откажет, то вместо [UU] будет [U_] либо [_U], это означает, что нужно написать в поддержку и указать на отказ одного из дисков и проблемы с RAID массивом. Вам должны будут заменить диск и, возможно, еще собрать массив.
Как же это автоматизировать? Не каждый же день дергать эту команду! Вообще, лучше каждый день. Потеря 1 секунды в сутки намного менее фатальна, чем отказ диска с информацией за годы. Конечно, есть способы автоматизации в виде mdadm monitor, но они упираются в электронную почту, которая никогда ни гарантией получения уведомления не отличалась. Так что если у Вас есть соответствующие знания, то пожалуйста, иначе - лучше руками.
Дает ли RAID гарантию от потери данных по механическим причинам?
Если же за RAID массивом следят и он всегда в состоянии ACTIVE, то я могу быть совершенно спокоен за данные? Да вот совершенно нет, кстати. Почему же? Во-первых, отказать могут сразу два диска (случай почти нереальный, но тем не менее согласно теории надежности имеющий место быть), может отказать электроника на одном из дисков, которая перестанет диагностировать ошибки чтения / записи (ввода-вывода) и на рабочий диск будет сдублирован мусор в итоге в лучшем случае немного повредится файловая система (обычно, лечится fsck), а в худшем будут потеряны данные. В своей практике я сталкивался с таким случаем и что-либо сделать в этом случае было нельзя.
Как защититься от форс-мажорных проблем c RAID
Для защиты от такого рода ошибок существует механизм само-тестирования массива. Когда система (по крону) раз в неделю запускает посекторное сравнение дисков массива и если находит отличия, сразу сообщает о них. Более подробно, об этом можно прочесть здесь: http://phpsuxx.blogspot.com/2010/04/warning-mismatchcnt-is-not-0-on-devmd2.html
Теперь немного о самих жестких дисках.
Мониторинг физического состояния жестких дисков
Проблемы с жестким диском можно определить двумя способами - напрямую (через систему самодиагностику жесткого диска именуемую SMART) и косвенно (ага, по потере данных, отказу сервера или же по ошибкам в dmesg).
S.M.A.R.T мониторинг жестких дисков
С мониторингом SMART посложнее, для его контроля используется пакет smartmontools (в CentOS его ставить: yum install -y smartmontools, в Debian: apt-get install -y smartmontools), в составе которого идет утилита smartctl, которая позволяет получить информацию от SMART подсистемы жестких дисков следующим образом:
smartctl --all /dev/sdXГде sdX имя интересующего Вас жесткого диска (список имеющихся жестких дисков при использовании soft-raid можно посмотреть в команде cat /proc/mdstat). Тут в первую очередь стоит обращать внимание на параметр reallocated sectors, если он больше 20-30, то значит диск, скорее всего, скоро выйдет из строя и таже нужно написать в поддержку с просьбой его заменить.
Также в самом низу выдачи есть блоки "SMART Error Log Version: 1" - там могут быть большие записи (с кучей 16-ричных адресов), повествующие об отказе какой-либо из частей диска; если же диск в норме - там все должно быть пусто - "No Errors Logged". Кроме него, есть еще блок "SMART Self-test log structure revision number 1", в который пишутся результаты диагностических само-тестов диска. В нормальных условиях он выглядит так:
# 1 Short offline Completed without error 00% 26274 -# 2 Short offline Completed without error 00% 26248 -# 3 Short offline Completed without error 00% 26226 -# 4 Short offline Completed without error 00% 26200 -# 5 Short offline Completed without error 00% 26178 -# 6 Short offline Completed without error 00% 26151 -# 7 Short offline Completed without error 00% 26127 -# 8 Extended offline Completed without error 00% 26062 -
Но эти самые тесты нужно запускать либо вручную либо силами того же smartmontools'а (путем правки /etc/smartd.conf).
Вручную запуск ускоренного теста осуществляется вот так:
smartctl -t short /dev/sdX
Запуск расширенного теста:
smartctl -t long /dev/sdXЧерез некоторое время после запуска (несколько минут для короткого и до получаса-часа для длинного) поле "SMART Self-test log structure revision number 1" будет заполнено и будет добавлена информация о завершении теста.
Если какой-либо из тестов FAILED, то это повод идти к оператору Дата Центра и запрашивать замену сбойного диска.
Косвенный мониторинг состояния жесткого диска
Самый очевидный вариант - когда жесткий диск был выброшен из RAID массива по причине FAULTY (то есть возникла ошика ввода вывода и диск был отключен). Также косвенным показателем отказа дисков являются разнообразные ошибки (например I/O error) в выдаче команды dmesg.
Это также говорит о подтвержденном сбое с заданным жестким диском и должна быть осуществлена его замена.
Если с RAID и SMART все в порядке, могу ли я быть спокоен за данные?
И снова нет. Для полной защиты необходим последний штрих - бэкапы на внешнем носителе.
Бэкапы
Многие очень часто ошибаются, утверждая, что RAID дает гарантию от потери данных. От механических причин он, конечно же, спасет. А вот от деструктивных действий хакеров или ошибки администратора - навряд ли. Поэтому всегда крайне обязательно иметь на удаленном сервере полную актуальную копию всех важных данных.
Для диагностики лучше смотреть smartctl -x /dev/sdX, там ещё и лог ошибок будет.
ReplyDeleteЕщё хорошо бы проверить, что диск SCT поддерживает, а то вдруг хостер сэкономить решил. :-)