Pull to refresh

Comments 22

UFO just landed and posted this here
Видимо, в этот момент geom пытается понять, что произошло, и всё лочится. Такая же ситуация наблюдалась на разных raid'ах, так что это не специфично конкретно для geom. Главное в этот момент не пасть духом, решив, что всё пропало :)
UFO just landed and posted this here
По моему немного по другому:
определяем какой диск сломался; делаем atacontrol detach; потом отключаем физически этот накопитель
camcontrol/atacontrol от контроллера зависит, в моём случае использовался camcontrol. А camcontrol stop, пожалуй, действительно стоило сделать.
действительно, это зависит от контроллера, главное остановить, и не придется ожидать 30 секунд
А, я вспомнил. Не было однозначно понятно, какой диск физически какому da соответствует. Поэтому если бы я остановил один винт, а вытащил другой, ребут был бы обеспечен — диск-то системный.
Я все-таки использовал бы винчестеры разных производителей, у них вероятность отказа в одну и ту же неделю очень мала, в отличие от винчестеров из одной партии которые изготовлялись и транспортировались в одинаковых условиях (и будут эксплуатироваться в одинаковых тепловых / вибрационных условиях).
А за это время ко мне придет мейл с сообщением об ошибке и я поменяю нерабочий винт на новый ;-).
Резонное замечание. А у Вас в практике были случаи выхода из строя одновременно двух дисков из одной партии? Интересна статистика. И не становилось ли потом известно, что вся партия дисков была подвержена падучести (помню такие случаи)?
Режет глаза совместное употребление символа комментария и комманд-промта '#'.
Гм. Вообще, я там комментарии не "#" выделял, а командой шелла ":". Так что код целиком можно вставлять в шелл — будет работать.
Товарищи! Что же вы жесть то такую советуете?!
Определить какой винт сдох можно по логам или старым-добрым «на слух», записав серийник винта. Если сложно добраться — подсветите фонариком и используйте камеру в своём мобильном. Если определялись не по логам, а по серийному номеру, то делаем atacontrol list, смотрим какие винты вообще видны, далее, например для диска ad0 делаем atacontrol cap ad0 и видим серийник. Чтобы выкинуть диск из зеркала, нужно делать gmirror remove [-v] name prov ..., а не просто откидывать винт!
Серийник я узнать могу, выкинуть из зеркала тоже, но диск системный, если я выкину из зеркала один, а инжнер в ДЦ физически вытащит другой — хотсвоп не получится. Посмотреть же серийник на винте, который запечатан в корзину — ну я не знаю, телепатически? :)

Хотя я, конечно, согласен, что если точно известно, какой серийник куда в сервер физически воткнут, то остановить перед вытаскиванием его нужно. Сейчас добавлю в пост.
В статье упоминается, что заменить нужно ad0. «Если инженер в ДЦ вытащит другой — хотсвоп не получится». В общем меня терзает праведный гнев, уж простите :) То, что описано в статье — это жесть. Других слов у меня нет. Кто мешает подключить новый диск до того, как откидывать один из старых? Подключаем новый → программно выкидываем из массива ненужный → подкидываем нужный → говорим инженеру отключить ad0 → смотрим какой винт откинули. При таком раскладе риск хотя бы становится меньше, ибо какой диск не выйми — сервер не помрёт. Если в зеркале один винт мёртвый и при этом «инженер в ДЦ» выдернет из системы живой… Могу только посочувствовать.
Ну, не в сказке ведь живём =) Бывает так:

* третий диск вставить некуда;
* винт не мёртвый, но подозрения вызывает, хотя и работает.

Так что описываемый метод вполне может быть реальным решением, и нужно быть готовым к нюансам, которые могут возникнуть (пункт 4). А со всем написанным в Ваших комментариях я согласен, разумеется.
В любом случае, я не могу представить ситуации, при которой невозможно определить винт, который нужно отключить. Если это корзины, и даже если корзин всего две, то на них должны быть индикаторы обращения к винту. Следовательно: программно выводим из массива диск, вызывающий подозрения → отключаем диск в корзине без активности.
Проапгрейдил топик. Спасибо.
Всегда пожалуйста :) Кстати, при отключении неактивного, неиспользуемого SATA диска сервер, скорее всего, в кому впадать не будет.
А что может быть когда собираешь gmirror доходит синхронизация до каких то 20 — 50% и умирает полностью. После раздумия выводит:
gmirror status
Name Status Components
mirror/gm0 DEGRADED ad6

Возможно, один из дисков умер. Стоит SMART проверить.
Хотела бы так же отметить, что стоит собирать gmirror на слайсах, слайсы делать некоего усредненного размера, заведомо меньшего, чем объем любого диска коммерческого «размера» (не секрет, что часто даже у одного вендора диски 72 Gb и/или терабайт на самом деле разного размера, и разной геометрии )

Профит в том, что софт-зеркало можно собирать из винтов разных вендоров (или разных серий одного вендора).

На линухе тоже самое: в md стоит вставлять не sda и sdb, a sda1 и sdb1 нормализованного значения: теряете считанные гигабайты, а зато экономите себе и нервы, и деньги на запас самых разных ЗИП :)
Sign up to leave a comment.

Articles

Change theme settings