Прелюдія:
Я мавпа з кодом, яка все частіше покладається на обов'язки SysAdmin для моєї невеликої компанії. Мій код - це наш продукт, і ми все частіше надаємо той же додаток, що і SaaS.
Близько 18 місяців тому я перемістив наші сервери від висококласного постачальника хостингу, який продається в центральному центрі обробки даних IV рівня. (Буквально через дорогу.) Цей настрій ми робимо набагато більше - такі речі, як мережа, зберігання та моніторинг.
Як частина великого кроку, щоб замінити наше орендоване пряме приєднане сховище від хостингової компанії, я створив 9-ти ТБ двовузловий NAS на базі шасі SuperMicro, 3ware RAID-карти, Ubuntu 10.04, два десятки SATA-дисків, DRBD та. Це все з любов'ю задокументовано в трьох публікаціях блогу: Створення та тестування нового 9 ТБ SATA RAID10 NFSv4 NAS: Частина I , Частина II та Частина III .
Ми також налаштовуємо систему контролю Cacit. Останнім часом ми додаємо все більше точок даних, як-от значення SMART.
Я не міг би зробити все це без дивовижних Boffins в ServerFault . Це був веселий та навчальний досвід. Мій начальник радий (ми зберегли вантажі відра $$$) , наші клієнти раді (витрати на зберігання знижені) , я задоволений (весело, весело, весело) .
До вчорашнього дня.
Відключення та відновлення:
Через деякий час після обіду ми почали отримувати повідомлення про мляві показники роботи від нашої програми, поточної медіа CMS на вимогу. Приблизно в той же час наша система моніторингу кактусів надіслала хуртовину електронних листів. Одним з найбільш відомих сповіщень був графік іостату очікування.
Продуктивність настільки погіршилася, що Pingdom почав надсилати сповіщення "вниз сервера". Загальне навантаження було помірним, руху руху не було.
Після входу на сервери додатків, клієнтів NFS NAS, я підтвердив, що майже все переживає дуже переривчасті та шалено тривалі очікування вводу-виводу. І як тільки я перескочив на сам основний вузол NAS, такі ж затримки були помітні при спробі орієнтуватися у файловій системі проблемного масиву.
Час провалитись, це минуло добре. Протягом 20 хвилин все було підтверджено, що резервне копіювання та функціонування ідеально.
Пост-Мортем:
Після будь-яких системних збоїв я виконую посмертний випадок, щоб визначити причину відмови. Перше, що я зробив - повернути назад у вікно і почати перегляд журналів. Це було в автономному режимі, повністю. Час поїздки в центр обробки даних. Скидання обладнання, резервне копіювання та запуск.
У /var/syslogI знайшла хижих запис:
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]:
Тож я пішов перевірити графіки Кактусів на диски в масиві. Тут ми бачимо, що так, диск 7 вислизає так само, як каже syslog. Але ми також бачимо, що помилки читання SMART для читання диска 8 коливаються.
Повідомлення про диск 8 в syslog немає. Більш цікавим є те, що коливальні значення для диска 8 безпосередньо корелюються з високим часом очікування IO! Моє тлумачення таке:
- Диск 8 має незвичайну технічну несправність, яка призводить до переривчастого тривалого часу роботи.
- Якимсь чином ця несправність на диску блокує весь масив
Можливо, є більш точний або правильний опис, але чистим результатом було те, що один диск впливає на продуктивність всього масиву.
Питання (и)
- Як один диск в апаратному масиві SATA RAID-10 може привести весь масив до осяяння?
- Чи я наївно вважаю, що RAID-карта повинна була мати справу з цим?
- Як я можу запобігти впливу одного диска, який не поводиться, на весь масив?
- Я щось пропускаю?