Прелюдия:

Я - обезьяна кода, которая все чаще берет на себя обязанности SysAdmin для моей маленькой компании. Мой код - это наш продукт, и мы все чаще предоставляем то же приложение, что и SaaS.

Около 18 месяцев назад я перевела наши серверы от поставщика хостинга премиум-класса к стойке для barebone-серверов в центре обработки данных уровня IV. (Буквально через улицу.) Этот процесс делает намного больше нас самих - таких как сетевое взаимодействие, хранение и мониторинг.

В рамках большого шага, чтобы заменить арендуемое нами хранилище с прямым подключением у хостинговой компании, я построил двухузловое NAS-хранилище объемом 9 ТБ на основе шасси SuperMicro, карт RAID 3ware, Ubuntu 10.04, двух дюжин дисков SATA, DRBD и. Все это с любовью задокументировано в трех статьях : Создание и тестирование нового NAS-хранилища SATA RAID10 NFSv4 объемом 9 ТБ: Часть I , Часть II и Часть III .

Мы также настроили систему мониторинга Cacit. В последнее время мы добавляем все больше и больше точек данных, таких как значения SMART.

Я не мог бы сделать все это без удивительных гробов на ServerFault . Это было весело и познавательно. Мой начальник доволен (мы сэкономили кучу долларов) , наши клиенты довольны (затраты на хранение снижаются) , я счастлив (весело, весело, весело) .

До вчерашнего дня

Отключение и восстановление:

Через некоторое время после обеда мы начали получать отчеты о медленной работе нашего приложения, CMS потокового мультимедиа по требованию. Примерно в то же время наша система мониторинга Cacti отправила множество писем. Одним из наиболее ярких предупреждений был график ожидания iostat.

Производительность настолько ухудшилась, что 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 ускользает, как говорит системный журнал. Но мы также видим, что SMART Read Erros диска 8 колеблется.

Сообщений о диске 8 в системном журнале нет. Более интересно то, что флуктуирующие значения для диска 8 напрямую связаны с временем ожидания высокого ввода-вывода! Моя интерпретация такова:

• На диске 8 происходит странная аппаратная ошибка, которая приводит к прерывистому длительному времени работы.
• Каким-то образом это условие сбоя на диске блокирует весь массив

Возможно, есть более точное или правильное описание, но в результате получается, что один диск влияет на производительность всего массива.

Вопросы)

• Как один диск в аппаратном массиве SATA RAID-10 может привести к полной остановке всего массива?
• Я наивен, чтобы думать, что карта RAID должна была иметь дело с этим?
• Как я могу предотвратить воздействие одного диска с неправильным поведением на весь массив?
• Я что-то пропустил?

Я ненавижу говорить "не используйте SATA" в критических производственных средах, но я видел эту ситуацию довольно часто. Диски SATA обычно не предназначены для рабочего цикла, который вы описываете, хотя в вашей конфигурации вы использовали специальные диски, рассчитанные на работу в режиме 24x7 . Мой опыт показывает, что диски SATA могут выходить из строя непредсказуемым образом, часто затрагивая весь массив хранения, даже когда вы используете RAID 1 + 0, как вы уже сделали. Иногда приводы выходят из строя таким образом, что может остановить всю шину. Стоит отметить, используете ли вы в своих настройках расширители SAS. Это может повлиять на то, как на остальные диски повлиял сбой диска.

Но, возможно, было бы разумнее использовать средние / ближние (7200 об / мин) диски SAS по сравнению с SATA. За SATA небольшая надбавка к цене, но диски будут работать / выходить из строя более предсказуемо. Исправление ошибок и отчетность в интерфейсе / протоколе SAS более устойчивы, чем набор SATA. Таким образом, даже с дисками , механика которых одинакова , различие в протоколе SAS могло бы предотвратить боль, которую вы испытали во время сбоя диска.

Как один диск может разрушить массив? Ответ заключается в том, что это не должно, но это зависит от того, что вызывает сбой. Если диск должен был умереть таким образом, он не должен был его сломать. Но вполне возможно, что он дает сбой в «крайнем случае», что контроллер не может обработать.

Вы наивно думаете, что этого не должно быть? Нет, я так не думаю. Подобная аппаратная карта RAID должна была справиться с большинством проблем.

Как это предотвратить? Вы не можете ожидать странных крайних случаев как это. Это часть того, чтобы быть системным администратором ... но вы можете работать над процедурами восстановления, чтобы они не влияли на ваш бизнес. Единственный способ исправить это прямо сейчас - это попробовать другую аппаратную плату (не то, что вы хотели бы сделать) или заменить ваши диски на диски SAS вместо SATA, чтобы проверить, является ли SAS более надежным. Вы также можете связаться с вашим поставщиком карты RAID и рассказать им, что произошло, и посмотреть, что они говорят; В конце концов, это компания, которая должна специализироваться на знании всех деталей электроники шаткого привода. У них может быть больше технических советов о том, как приводы работают, а также о надежности ... если вы можете связаться с нужными людьми для общения.

Вы что-то пропустили? Если вы хотите убедиться, что диск имеет сбой в крайнем случае, извлеките его из массива. Массив будет ухудшен, но у вас не должно быть больше странных замедлений и ошибок (кроме состояния ухудшенного массива). Вы говорите, что сейчас кажется, что он работает нормально, но если возникают ошибки чтения с диска, вам следует заменить диск, пока вы можете. Диски с большой емкостью могут иногда иметь ошибки URE (лучшая причина не запускать RAID 5, примечание стороны), которые не отображаются, пока другой диск не вышел из строя. И если вы испытываете крайнее поведение с этого одного диска, вам не нужно переносить поврежденные данные на другие диски в массиве.

Я не эксперт, но я собираюсь сделать дикий выстрел в темноте на основе моего опыта работы с RAID-контроллерами и массивами хранения.

Диски выходят из строя по-разному. К сожалению, диски могут выходить из строя или быть неисправными таким образом, что их производительность серьезно ухудшается, но RAID-контроллер не видит в этом сбой.

Если диск выходит из строя очевидным образом, любое программное обеспечение RAID-контроллера должно быть достаточно хорошим для обнаружения отсутствия ответа с диска, удаления его из пула и запуска любых уведомлений. Тем не менее, я предполагаю, что здесь происходит, что диск испытывает необычный сбой, который по какой-то причине не вызывает сбой на стороне контроллера. Поэтому, когда контроллер выполняет сброс записи или чтение с поврежденного диска, требуется много времени, чтобы вернуться, и, в свою очередь, зависает весь функционал ввода-вывода и, следовательно, массив. По какой-то причине этого недостаточно для того, чтобы контроллер RAID выдавал «ах, неисправный диск», возможно потому, что данные в конечном итоге возвращаются.

Мой совет: немедленно заменить неисправный диск. После этого я взглянул бы на конфигурацию вашей карты RAID (это 3ware, я думал, что они довольно хороши) и выяснил, что он считает неисправным диском.

PS Хорошая идея импортировать SMART в кактусы.

Вам нужны функции устройств хранения данных корпоративного класса. В частности, корпоративные диски WD RE 4 имеют две функции, необходимые для предотвращения такого поведения в RAID-массивах. Первая технология, перечисленная ниже, предотвращает вибрацию вращательной гармоники от ненужного износа механических компонентов жесткого диска. Вторая технология - то, что вызвало вашу проблему, протокол SATA не имеет этой функции. Чтобы получить эти функции, вам нужен SAS, и если вы настаиваете на дисках SATA, вы можете приобрести карты SAS для SATA Interposer, такие как LSISS9252.

Усовершенствованная технология RAFF Сложная электроника контролирует привод и корректирует линейную и вращательную вибрацию в режиме реального времени. Результатом является значительное улучшение производительности в условиях высокой вибрации по сравнению с приводами предыдущего поколения.

Специфичное для RAID, ограниченное по времени восстановление после ошибок (TLER) Предотвращает сбой диска, вызванный расширенными процессами восстановления после ошибок жесткого диска, общими для настольных дисков.

http://en.wikipedia.org/wiki/Error_recovery_control#Overview

Также, пожалуйста, смотрите ссылку ниже:

http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers

Также см. Документ Western Digital TLER, подробно объясняющий процесс устранения ошибок. Предотвращение сбоев при восстановлении на жестких дисках WD Caviar RAID Edition Serial ATA:

http://www.3dfxzone.it/public/files/2579-001098.pdf

Просто предположение: жесткие диски настроены для повторения попыток чтения, а не для сообщения об ошибке. Несмотря на то, что это желаемое поведение в настольном режиме, оно является контрпродуктивным в RAID (где контроллер должен перезаписать любой сектор, который не может прочитать с других дисков, чтобы диск мог переназначить его).

мой выстрел в темноте:

• диск 7 выходит из строя. у него есть несколько окон сбоя, где он недоступен.

• на диске 8 тоже есть «легкие» ошибки; исправлено повторением попытки.

• RAID10 обычно является «RAID0 из нескольких пар RAID1», являются ли диски 7 и 8 членами одной пары?

если это так, то, похоже, вы столкнулись с ситуацией «не должно случиться», когда произошел сбой двух дисков в одной и той же паре. почти единственное, что может убить RAID10. к сожалению, это может произойти, если все ваши диски принадлежат одной и той же партии, поэтому вероятность их одновременной гибели несколько выше.

Я предполагаю, что во время сбоя диска 7 контроллер перенаправил все операции чтения на диск 8, поэтому любая повторная попытка ошибки вызвала большие задержки, которые вызвали лавину замороженных задач, что на некоторое время снизило производительность.

вам повезло, что диск 8, кажется, еще не умер, так что вы сможете исправить без потерь данных.

Я бы начал с замены обоих дисков, и не забудьте проверить кабели. слабое соединение может вызвать это, и если оно не маршрутизируется, это может произойти в соседних дисках. Кроме того, некоторые многопортовые платы имеют несколько двухпортовых разъемов. Если накопитель 7 и накопитель 8 находятся на одном и том же устройстве, это может стать причиной вашей проблемы.

Карты SATA Interposer являются еще одним решением.

Я недавно испытал точно такую ​​же участь и нашел эту ветку. Общий принцип заключается в том, что протокол SAS лучше подходит для RAID, чем для SATA, поскольку в SATA отсутствуют функции. Вот почему те же физические диски оснащены контроллерами SAS, а затем продаются как Nearline SAS.

В поисках дальше я нашел:

http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx

Я расследую модернизацию одного из моих хранилищ с партией этих. Сейчас разница в цене между 3 ТБ SATA и SAS составляет 400% (цена ванили, тот же бренд, спецификации и магазин, Германия). Я, очевидно, не могу сказать, хорошо ли работает эта стратегия, но стоит попробовать.

Комментарии очень приветствуются :-)

Я видел, как диск SATA со сломанной электроникой надежно блокировал инициализацию прошивки Areca 12, не было никакого способа получить доступ к BIOS, не говоря уже о загрузке машины с любого носителя, пока не был найден неисправный жесткий диск, извлекая диски в двоичном виде поиск моды.