“Как я с постоянными ребилдами HGST под HP боролся” или “Чем отличается обычный диск от серверного и как это исправить”

Естественно, описанное здесь для некоторых окажется прописной истиной, которую они уже сто лет знают, но мне, пришедшему в проект изначально только писать код, и незаметно оказавшимся ответственным за парк числом более 50 машин, это все показалось тем еще квестом.


Не так давно я публиковал крик о помощи. pikabu.ru/story/postoyannyie_rebildyi_i_feylyi_hgst_pod_hp_5091296

Если кратко, меня, счастливого обладателя кучи HGST дисков и кучи рейдов и HBA-контроллеров от HP, замучили постоянные ребилды этого хозяйства.


В HGST support мне за полгода переписки ничем не помогли, стандартные - "попробуйте выключить-включить" и прочие "стекло протереть" и "по колесам постучать".


Многие рекомендовали сменить контролер - но на какой именно никто не решался сказать (даже HGST-шники на этом наставали - но непременно скукоживались после вопроса о конкретной модели).


Естественно, самые правоверные коллеги в комментариях сразу же возмутились, мол свечки-то купленные за воротами прихода и не должны работать. В смысле, что это все божья кара ниспосланная мне, грешнику, небесами ибо сотворил я ужасное - впав в ересь, осквернил священное железо HP дешевыми нечистыми дисками, цена которых в 3-4 раза ниже, освященных наклейкой священного же синода HP. И как ни странно, оказались частично правы. Слава Императору - только частично.


@ZaPusk был единственным, кто четко указал куда копать и как решать проблему. Огромное спасибо этому замечательному человеку. Собственно по его поручению и пилю данный пост.

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


1. повышенная наработка на отказ (часто иллюзорная, и в некоторых случаях излишне избыточная);

2. поведение при возникновении ошибок.


Вот во втором-то пункте и крылась причина моей столь затянувшейся серии приступов бессонницы.


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


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


Что будет если поставить обычный диск в рейд? Правильно, он будет регулярно строить из себя Д'Артаньяна и бесконечно тупить, за что его будут регулярно выкидывать из рейда на мороз.


Можно ли это поменять? Оказывается можно. Данная техника имеет два названия TLED (судя по всему уже устаревшее) и SCT ERC, и заключается в банальнейших внутридисковых таймаутах. ВСЕ современные диски ее поддерживают и соответственно ВСЕ они могут быть превращены в серверные. Отличие последних как раз и заключается в том, что у них эта опция включена по-умолчанию.


Теперь о печальном. Первое - далеко не все диски запоминают эту опцию и после перезагрузки/переподключения/замены необходимо ее перепрописывать снова и снова. Не за всякий контролер можно легко достучаться, в частности, для того что бы применить опции в hp-шному нужно ударить в бубен немного иначе:


lsscsi -g  # Находим, что наш контролер живет, например, на /dev/sg0


for i in {0..100}; do smartctl -l scterc,70,70 -d cciss,$i /dev/sg0; done 

# Выставляем для всех дисков c номерами 0-100 на этом контролере


Продолжаем о грустном. Судя по всему HP что-то напортачили с регистрами SCSI и эта команда выдаст ошибку.


Unexpected SCT status 0x0010 (action_code=0, function_code=0)

SCT (Set) Error Recovery Control command failed


Но расстраиваться не стоит - если изучить скрежали smartctl, станет понятно, что ошибка возникает уже ПОСЛЕ установки - при попытке считать эту опцию, именно по-этому не получится узнать текущее ее значение. Но при этом опция работает, что подтверждается спокойствием моего сна протяжении последних 2-х недель.


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


Вывод - все хороши:

1. HGST - за никакущую поддержку (про SCT ERC там никто не слышал, из-за видимо заткнутых в уши 100-долларовых купюр).

2. HP - за кривую реализацию SCSI.

3. Маркетологи - за очередную победу бабла над разумом.

Лига Сисадминов

1.5K постов17.6K подписчик

Добавить пост

Правила сообщества

Мы здесь рады любым постам связанным с рабочими буднями специалистов нашей сферы деятельности.

Вы смотрите срез комментариев. Показать все
DELETED
Автор поста оценил этот комментарий
Чтобы посмотреть таймауты используем команду smartctl -l scterc /dev/sdX

Для установки, соответственно, указываем значения через запятую после scterc: smartctl -l scterc,120,60 /dev/sdX (величина указывается в десятых долях секунды, то есть 120 соответствует 12 секундам, первое число — чтение, второе — запись). 0 означает «до победного конца», то есть неограниченно долго.

https://geektimes.ru/post/92701/
раскрыть ветку (2)
Автор поста оценил этот комментарий

Рекомендуемое значение 7 сек - соответственно 70. В tler по-дефолту 8 сек (80). Больше скажу, некоторые диски умеют только 7 секунд. Даже smartctl если у него не получается установить, говорит ставь 70,70 или 0,0 и не выпендривайся.


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

Автор поста оценил этот комментарий
Путь для обращения к дискам - разный, в зависимости от вендора контроллера. Подробности - в man smartctl
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку