Прелюдия:
Я - обезьяна кода, которая все чаще берет на себя обязанности 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 должна была иметь дело с этим?
- Как я могу предотвратить воздействие одного диска с неправильным поведением на весь массив?
- Я что-то пропустил?