LINUX.ORG.RU
Форум — Admin  

Правильная работа со сбоящими дисками?

 , ,


0

1

Тема не новая и, в чём-то, стандартная.

Имеется кластер из серверов Hadoop, на каждом сервере 15 дисков. Диски там - это RAID0 из 1 винта через контроллер HP Smart Array 420i (почему так через жопу и почему не HBA - тема отдельная), но в общем и целом это не важно. Каждый диск форматирован в XFS и смонтирован в отдельную директорию (в духе /data/XX) и юзается как HDFS Volume.

В какой-то момент один из винтов сдыхает и начинается веселье: 

kernel: sd 0:0:0:8: [sdi]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 0:0:0:8: [sdi]  Sense Key : Medium Error [current]
kernel: sd 0:0:0:8: [sdi]  Add. Sense: Unrecovered read error
kernel: sd 0:0:0:8: [sdi] CDB: Read(10): 28 00 00 00 52 10 00 00 10 00
kernel: end_request: critical medium error, dev sdi, sector 21008
...
kernel: XFS (sdi): metadata I/O error: block 0x5210 ("xfs_trans_read_buf") error 61 buf count 8192
kernel: XFS (sdi): xfs_imap_to_bp: xfs_trans_read_buf() returned error 61.
kernel: XFS (sdi): metadata I/O error: block 0x5210 ("xfs_trans_read_buf") error 61 buf count 8192
kernel: XFS (sdi): xfs_imap_to_bp: xfs_trans_read_buf() returned error 61.
При этом софт (в данном случае - HDFS Data Node) пытается читать\писать файлы усиленно генерируя данные ошибки тоннами и периодически залипая на I/O.

Что было сделано:

  • Сначала пытался убрать ноду из HDFS без его перезапуска, не вышло - процесс реконфигурирования залип.
  • Попытался закрыть дескриптор файла (он там был один) - не вышло, дебаггер gdb зависал при подключении к процессу.
  • Затем была попытка потушить HDFS штатно - не вышло, убил через kill -9 - процесс превратился в зомби но при этом продолжил усиленно насиловать этот диск
  • umount -f не прошло, umount -l выполнился, но это ничего не изменило - ошибки продолжали лезть и зомби мучил диск
  • Финально ребут сервера - тоже залип т.к. не смог отмонтировать все ФС и убить процессы (зомби то висит)
  • В итоге резет

Собсно вопрос - как (и можно ли) эту ситуацию решить *штатно*, без таких радикальных мер. Может это проблемы конкретно XFS что оно не возвращает нормально софту ошибку i/o? Или это проблемы Hadoop что он её штатно не обрабатывает? Если что - пока не экспериментировал.

Ось - центос 6.

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)

Ответ на: комментарий от Vsevolod-linuxoid

Я его потом перед ребутом отстрелил через /sys/block/sdi/delete - без толку. А физически его не вынуть - это HP Apollo, эдакий блейд, они не особо хотсвап.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Последний блейд, который я видел (MFSYS25) позволял чуть ли не сами лезвия на горячую перетыкать. Забивая их на место ногами. А уж винты менялись по кулдауну, ибо экономия на спичках (вместо 2.5" SAS закупили на eBay ящик ноутбучных SATA).

svr4 ☆
()
Последнее исправление: svr4 (всего исправлений: 1)
Ответ на: комментарий от svr4

Это не блейд как таковой. Это просто три сервера в одном 5U корпусе, которые забиваются дисками *сверху*, в выдвинутом состоянии. То бишь его для этого в моём случае нужно выключить т.к. проводка не обеспечивает запаса чтобы выдвинуть.

В любом случае, удаление диска не решает проблему - я его delete делал, он из системы пропадал, но зомбаку от этого лучше не становилось.

blind_oracle ★★★★★
() автор топика

kill -9 - процесс превратился в зомби но при этом продолжил усиленно насиловать этот диск

Да, было бы интересно узнать, как с этим бороться. Тоже бывало, что банальные команды связанные с I/O нельзя было убить даже из под рута. Причём не хотелось бы отмонтировать всю ФС вот так:

umount -f не прошло,

А тут пишут, что именно это должно было бы помочь. Неужели ядро противится прервать I/O?

Собсно вопрос - как (и можно ли) эту ситуацию решить *штатно*, без таких радикальных мер.

Если в xfs есть опция монтирования errors=read-only, то использовать её. Как превентивную меру.

gag ★★★★★
()
Ответ на: комментарий от gag

А тут пишут, что именно это должно было бы помочь.

Там речь про нфс в комменте, с ним может и помогло бы. В моем случае сразу выдавало ошибку в духе Resource busy или что-то такое.

Если в xfs есть опция монтирования errors=read-only, то использовать её. Как превентивную меру.

Я об этом сразу подумал и полез в ман - такой опции как у ext там нет. В рассылках нашел патчи на добавление похожего функционала для xfs в sysfs, но они от этого года, а пихать туда самое свежее ядро не очень безопасно думаю. Хотя переформатировать в ext4 и реплицировать 300тб тоже нет никакого желания :/

blind_oracle ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin