“Как я с постоянными ребилдами 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.5K подписчиков

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

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

Мы здесь рады любым постам связанным с рабочей деятельностью специалистов нашей сферы деятельности.
Вы смотрите срез комментариев. Показать все
4
Автор поста оценил этот комментарий

Знаешь, я давно уже отказался от железных рейд решений. Тот же mdadm мне гораздо ближе. И пересобрать его проще, и не ругается почем зря, мониторится любыми средствами.

раскрыть ветку (28)
1
Автор поста оценил этот комментарий

У меня в хозяйстве и того и другого навалом. Тут есть еще один момент - железные рейд решения фактически устарели с ростом объема дисков. Прирост эффективности может дать только объединение уровней абстракции - фс+кеш+рапределение информации. Например raid-z от ZFS. Если ему подсунуть обратно выпавший диск он его очень быстро отресильверит и вернет в строй, я так понимаю благодаря журналу или чему-то подобному, а железный рейд и md будут его колбасить неприлично долго, посадив общую производительность системы. Кроме того там есть оч эффективный RAM-ARC и не самый эффективный SSD-LRU кеши (так называемый l2arc который, кстати ни разу не ARC, как оказалось - везде обман). Но и тот дает гигантский оверхед под нормальным linux, а переходить с debain я пока не готов.


Ну и да - для софтовых рейдов аналогично рекомендуется выручивать SCT ERC - по крайней мере для ZFS точно - HGST отваливались от него так же как железных рейдов.

раскрыть ветку (16)
Автор поста оценил этот комментарий

ZFS - это конечно очень круто, но пока "искаропки" не поддерживается. Поэтому пока что mdadm + LVM + XFS.

А функционала у mdadm за глаза, лично мне хватает на абсолютно все задачи. RAID5 + hot spare умеет и ладно. Главное - следить за состоянием бесперебойника. А железными решениями пусть пользуются те, кому не накладно купить про запас контроллер и серверные харды.

раскрыть ветку (15)
Автор поста оценил этот комментарий

Ну вообще zfs уже в jessie-backports, ставится полностью нативно


aptitude install -t jessie-backports zfs-dkms


Геморно апргрейдиться со старой репы - это да.

раскрыть ветку (14)
Автор поста оценил этот комментарий

бэкпорты - это бэкпорты, "искаропки" пока что все равно нет.

раскрыть ветку (13)
1
Автор поста оценил этот комментарий

Ой какие мы нежные ) В релизнутом надысь, 9.0 Stretch, он уже в основной репе https://packages.debian.org/stretch/zfs-dkms - или это не достаточно "из коробки" ? :)

раскрыть ветку (12)
Автор поста оценил этот комментарий

Ты бы стал использовать backports, на mission-critical задачах?

Вон, те же банки покупают Oracle'овые СХД, в которых нативно поддерживается ZFS.

За весьма неплохие деньги, к слову. Сопоставимые со стоимостью квартиры, чуть ли не в минимальной конфигурации. Потому-что, у oracle есть поддержка.

Для кровавого энтерпрайза - backports херовый вариант.

раскрыть ветку (10)
Автор поста оценил этот комментарий

Скажу тебе страшное, без него нашего продукта сейчас бы просто еще не было, а внедрили еще задолго до того как он в бекпорт переехал. Жуть правда? Дело в том что у ZOL был свой собственный deb репо, потом они в debian переехали со всеми цыганами и медведями. Видимо debian позвал а в намечающийся oldstable решили уже не пихать. Откровенных проблем с ним не было ни одной - больше неинтуитивность и тд - есть такой косяк у его утилит. Так что нет - не боюсь, и тебе не советую, тк это на самом деле не бекпорт давно - а стабильное проверенное временем решение.

Для ssd cache других адекватных вариантов не существует до сих пор. Точно нет - регулярно проверяю, у аналогов как минимум проблема в невозможности нескольких кеш девайсов, мы из-за этого сейчас собственную надстройку над ext4 в итоге пилим, благо ресурсы теперь есть и можем реализовать хотелики.

Насколько я знаю, oracle и пилит основную ветку ZFS, так что не удивительно. А то как принимаются решения в финансовых конторах вообще тема отдельного разговора. Люди надеются на чудо и платят за это огромные деньги, а в итоге все равно оказывается, что чудес не бывает.

раскрыть ветку (9)
1
Автор поста оценил этот комментарий

Вопрос не в том, стабильное оно, или нет. А в том, что кровавый энтерпрайз платит бабки за возможность оперативного решения проблем силами производителя, в случае проблем. Да и вообще, чтобы было кому предъявить, в случае чего. А случае не Oracle'ового ZFS - ты остаешься с проблемой один на один.

раскрыть ветку (8)
Автор поста оценил этот комментарий

зависит от уровня энтерпрайза на самом деле, лично я вообще XFS предпочитаю:)

раскрыть ветку (7)
Автор поста оценил этот комментарий

Ну, одни из крупнейших потребителей Oracle'ового железа и софта - это банки, например. Но Oracle тут - чисто в качестве примера.

Можно привести в пример RHEL\SLES, как дистрибутивы с платной поддержкой. Суть то не меняется. Зачастую крупный энтерпрайз платит за возможность привлечения инженеров вендора для решения проблем.

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

раскрыть ветку (6)
Автор поста оценил этот комментарий

Ну это примерно как LVM в убунте. Технически возможность есть, но надо пляски:)

Автор поста оценил этот комментарий
А еще очень мило, когда дохнет контроллер (особенно старый), который хрен где найдешь. Вот тут-то веселье просто прет волной. Я тоже, хоть и в основном по маздаю, но тоже в последние годы делаю в основном софтовый рейд. Ну, или биос-рейд (те же яйца, но криворукие китайцы бывают напортачат в прошивке).
раскрыть ветку (1)
Автор поста оценил этот комментарий

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

Софтовый рейд актуален только если он сделан средствами ОС, но никак не биоса.

Автор поста оценил этот комментарий

Ну значит у вас просто нет потребности в настоящем рейде. У нас сейчас стоят полки от Netapp на общее место в полтора петабайта, как такое собирать и как таким рулить через софтрейд даже думать не хочу. Кстати диски в Netapp тоже от HGST, правда настоящие серверные.

раскрыть ветку (8)
3
Автор поста оценил этот комментарий

Хм, а в чем проблема рулить софтовым рейдом? Хочешь - конфиг пиши, хочешь - через консоль командами, хочешь - через какой-нить вебмин админь. Для ценителей есть FreeNAS заточенный под хранение. Так что, вообще не наблюдаю проблемы. Хотя с такими объемами да, не сталкивался.

Просто вычислительные ресурсы любого процессора счас таковы, что нагрузка от рейда (любого) совершенно не ощущается. Единственное преимущество нормального хардрейда - это энергонезависимый буфер.

раскрыть ветку (1)
3
Автор поста оценил этот комментарий
Дожили. На Пикабу комментарии к техническим постам лучше чем на Хабре.
Автор поста оценил этот комментарий
Это сколько у тебя шпинделей? Пытаюсь на глаз прикинуть стоимость СХД.
раскрыть ветку (4)
Автор поста оценил этот комментарий

Именно в нетаппе где-то около тысячи.

раскрыть ветку (3)
Автор поста оценил этот комментарий

FAS8200/FAS9000? По моим прикидкам - ценник сильно зашкаливает за миллион баксов.

раскрыть ветку (2)
Автор поста оценил этот комментарий

Не скажу точный ценник, но да, стоит многамнога денег. Особенно учитывая что где-то пятая часть дисков - SSD.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Тот конфиг СХД, который покупал я, вернее готовил спеку на него на работе - стоил, емнип, порядка 55К$. Но там полезная емкость - была порядка 25 терабайт. И это на NL-SAS дисках, по большей части. На твоих объемах - это действительно будет сумма около миллиона баксов. Плюс, все еще зависит от использованного шасси, использования metrocluster, и еще кучи всего.

Были еще и цисковские блейды - но они к делу не относятся.

Автор поста оценил этот комментарий

Неттаппы - донельзя приятные железки. Но диски большого объема - будут неподъемными для ТС. Он за ценник одного диска, сможет купить 5 консьюмерских.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку