Прелюдия:
Я code-monkey, который все чаще берет на себя обязанности системного администратора для своей небольшой компании. Мой код — это наш продукт, и все чаще мы предоставляем то же приложение как SaaS.
Около 18 месяцев назад я переместил наши серверы от поставщика услуг премиум-хостинга в базовый сервер в дата-центре уровня IV. (Буквально через дорогу.) Теперь мы делаем гораздо больше сами — такие вещи, как сетевое взаимодействие, хранение данных и мониторинг.
В рамках большого шага, чтобы заменить наше арендованное хранилище с прямым подключением от хостинговой компании, я построил двухузловой NAS на 9 ТБ на базе шасси SuperMicro, карт RAID 3ware, Ubuntu 10.04, двух десятков дисков SATA, DRBD и . Все это любовно задокументировано в трех сообщениях в блоге:Сборка и тестирование нового NAS-накопителя SATA RAID10 NFSv4 емкостью 9 ТБ:Часть 1,Часть IIиЧасть 3.
Мы также настраиваем систему мониторинга Cacti. В последнее время мы добавляем все больше и больше точек данных, таких как значения SMART.
Я бы не смог сделать все это безпотрясающий ученые в ServerFault. Это был веселый и познавательный опыт. Мой босс счастлив(мы сэкономили кучу $$$), наши клиенты довольны(затраты на хранение снизились), Я счастлив(веселье, веселье, веселье).
До вчерашнего дня.
Сбой и восстановление:
Некоторое время после обеда мы начали получать отчеты о медленной производительности нашего приложения, CMS потокового мультимедиа по запросу. Примерно в то же время наша система мониторинга Cacti разослала шквал писем. Одним из наиболее показательных оповещений был график iostat await.
Производительность настолько упала, что Pingdom начал отправлять уведомления о "сервере не работает". Общая нагрузка была умеренной, всплесков трафика не было.
После входа на серверы приложений, NFS-клиенты NAS, я подтвердил, что почти все испытывало очень прерывистое и безумно долгое время ожидания ввода-вывода. И как только я перешел на сам основной узел NAS, те же задержки были очевидны при попытке навигации по файловой системе проблемного массива.
Время для отработки отказа, все прошло хорошо. В течение 20 минут было подтверждено, что все восстановлено и работает отлично.
Вскрытие:
После любого системного сбоя я провожу вскрытие, чтобы определить причину сбоя. Первое, что я сделал, это подключился по ssh обратно к коробке и начал просматривать журналы. Он был полностью офлайн. Пора ехать в центр обработки данных. Аппаратный сброс, резервное копирование и работа.
В /var/syslogя нашел эту пугающую запись:
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1 Short offline Completed: read failure 90% 6576 3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2 Short offline Completed: read failure 90% 6087 3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3 Short offline Completed: read failure 10% 5901 656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4 Short offline Completed: read failure 90% 5818 651637856
Nov 15 06:49:45 umbilo smartd[2827]:
Итак, я пошел проверить графики Cacti для дисков в массиве. Здесь мы видим, что, да, диск 7 ускользает, как и говорит syslog. Но мы также видим, что ошибки чтения SMART диска 8 колеблются.
В syslog нет сообщений о диске 8. Еще интереснее то, чтоколеблющиеся значения для диска 8 напрямую коррелируют с высоким временем ожидания ввода-вывода! Моя интерпретация такова:
- На диске 8 возникла странная аппаратная ошибка, которая приводит к периодическому увеличению времени работы.
- Каким-то образом эта неисправность на диске блокирует весь массив.
Возможно, существует более точное или правильное описание, но в конечном итоге один диск влияет на производительность всего массива.
Вопросы)
- Как один диск в аппаратном массиве SATA RAID-10 может привести к полной остановке всего массива?
- Наивен ли я, думая, что RAID-карта должна была с этим справиться?
- Как предотвратить влияние одного неисправного диска на весь массив?
- Я что-то пропустил?
решение1
Ненавижу говорить "не используйте SATA" в критических производственных средах, но я видел такую ситуацию довольно часто. Диски SATA обычно не предназначены для описанного вами рабочего цикла, хотя вы и указалидиски, специально рассчитанные на круглосуточную работув вашей настройке. Мой опыт показывает, что диски SATA могут выходить из строя непредсказуемым образом, часто влияя на весь массив хранения, даже при использовании RAID 1+0, как вы сделали. Иногда диски выходят из строя таким образом, что могут заблокировать всю шину. Следует обратить внимание на то, используете ли вы расширители SAS в своей настройке. Это может повлиять на то, как оставшиеся диски будут затронуты отказом диска.
Но, возможно, имело бы больше смысла пойти сSAS-диски средней/ближней линии (7200 об/мин)по сравнению с SATA. Есть небольшая надбавка к цене по сравнению с SATA, но диски будут работать/выходить из строя более предсказуемо. Исправление ошибок и отчетность в интерфейсе/протоколе SAS более надежны, чем в наборе SATA. Так что даже с дискамимеханика которых одинакова, разница в протоколе SAS могла бы предотвратить неприятности, которые вы испытали во время отказа диска.
решение2
Как один диск может вывести из строя массив? Ответ в том, что не должен, но это зависит от того, что вызвало сбой. Если бы диск умер так, как он себя вел, это не должно было бы вывести его из строя. Но возможно, что он выходит из строя в "пограничном случае", с которым контроллер не может справиться.
Вы наивны, думая, что этого не должно быть? Нет, я так не думаю. Аппаратная RAID-карта вроде этой должна была бы справиться с большинством проблем.
Как это предотвратить? Вы не можете предвидеть странные крайние случаи, подобные этому. Это часть работы системного администратора... но вы можете работать над процедурами восстановления, чтобы это не повлияло на ваш бизнес. Единственный способ попытаться исправить это прямо сейчас — либо попробовать другую аппаратную карту (вероятно, это не то, что вы хотели бы сделать), либо заменить диски на диски SAS вместо SATA, чтобы посмотреть, более ли надежен SAS. Вы также можете связаться с поставщиком карты RAID и рассказать ему, что произошло, и послушать, что он скажет; в конце концов, это компания, которая должна специализироваться на знании тонкостей неисправной электроники дисков. У них могут быть дополнительные технические советы о том, как работают диски, а также о надежности... если вы сможете связаться с нужными людьми, с которыми можно поговорить.
Вы что-то упустили? Если вы хотите убедиться, что диск имеет пограничный случай отказа, извлеките его из массива. Массив будет деградирован, но у вас не должно быть больше странных замедлений и ошибок (кроме статуса деградированного массива). Вы говорите, что сейчас он, кажется, работает нормально, но если у него есть ошибки чтения диска, вам следует заменить диск, пока вы можете. Диски с большой емкостью иногда могут иметь ошибки URE (лучшая причина не запускать RAID 5, примечание), которые не проявляются, пока другой диск не выйдет из строя. И если вы испытываете пограничное поведение этого диска, вы не хотите, чтобы поврежденные данные были перенесены на другие диски в массиве.
решение3
Я не эксперт, но я собираюсь сделать рискованный шаг, основываясь на своем опыте работы с RAID-контроллерами и массивами хранения данных.
Диски выходят из строя по-разному. К сожалению, диски могут выходить из строя или быть неисправными, при этом их производительность серьезно страдает, но RAID-контроллер не видит в этом отказа.
Если диск выходит из строя очевидным образом, любое программное обеспечение RAID-контроллера должно быть довольно хорошо способно обнаружить отсутствие ответа от диска, удалить его из пула и запустить любые уведомления. Однако я предполагаю, что здесь происходит, что диск испытывает необычный сбой, который по какой-то причине не вызывает сбой на стороне контроллера. Поэтому, когда контроллер проводит сброс записи или чтение с затронутого диска, требуется много времени, чтобы вернуться, и, в свою очередь, зависает вся работающая система ввода-вывода и, следовательно, массив. По какой-то причине, этого недостаточно, чтобы RAID-контроллер сказал "ах, сбойный диск", вероятно, потому, что данные в конечном итоге возвращаются.
Мой совет — немедленно заменить неисправный диск. После этого я бы посмотрел на конфигурацию вашей RAID-карты (это 3ware, я думал, они довольно хороши) и выяснил, что она считает неисправным диском.
P.S. Хорошая идея импортировать SMART в кактусы.
решение4
мой выстрел в темноте:
Диск 7 выходит из строя. У него есть некоторые окна сбоя, когда он недоступен.
На диске 8 также есть несколько «легких» ошибок; исправлено повторной попыткой.
RAID10 обычно представляет собой «RAID0 из нескольких пар RAID1». Являются ли диски 7 и 8 членами одной пары?
Если так, то, похоже, вы столкнулись с «недолжным» случаем отказа двух дисков в одной паре. Это практически единственное, что может убить RAID10. К сожалению, это может произойти, если все ваши диски из одной партии поставки, поэтому вероятность их одновременного выхода из строя немного выше.
Полагаю, что во время сбоя диска 7 контроллер перенаправил все операции чтения на диск 8, поэтому любая повторная попытка обработки ошибки вызывала большие задержки, которые вызывали лавину зависших задач, на некоторое время убивая производительность.
Вам повезло, что диск 8, похоже, еще не вышел из строя, так что вы сможете выполнить ремонт без потери данных.
Я бы начал с замены обоих дисков и не забыл проверить кабели. Причиной этого может быть ненадежное соединение, а если кабели не проложены надежно, то вероятность возникновения проблемы возрастает на соседних дисках. Кроме того, некоторые многопортовые карты имеют несколько двухпортовых разъемов. Если дисковод 7 и дисковод 8 находятся на одном разъеме, это может быть источником проблемы.