amarao Jun 21 2011 at 20:00

shared hotspare для mdadm

4 min

14K

Configuring Linux*

+63

Comments 28

giner Jun 21 2011 at 21:25

Не в давался раньше в тонкости настройки mdadm, т.к. обычно использовал железный рейд и узнать что mdadm тоже может shared hot-spare очень полезно. Спасибо!
Это третья статья из серии «я бы продонейтил».

amarao Jun 22 2011 at 00:01

Мы тоже до определённого момента использовали железные рейды. Больше — спасибо, не надо.

umraf Jun 22 2011 at 07:56

Я могу конечно придумать, почему лучше пользоваться софтовым рейдом и почему плох железный.
Но хотелось бы услышать ваш реальный опыт до «определённого момента» и после.

odessky Jun 22 2011 at 08:01

Сдох контроллер, а их уже не выпускают, а резервные мы не купили.

datacompboy Jun 22 2011 at 11:38

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

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

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

В-4ых, многие «аппаратные» это выносной калькулятор, без драйверов бесполезная вещь.

amarao Jun 22 2011 at 12:37

Одно из хранилищ облака — два сбоя рейда до запуска в продакт (адаптек пятой серии), один сбой в продакте. Второй рейд (собирали второе хранилище) — просто феерическое количество глюков.

Софтовые рейды — опыта сбоев не было (используется на остальных хранилищах облака).

Мне даже трудно скзать про «реальный опыт» — какой может быть реальный опыт, если проблем не возникает? :)

umraf Jun 23 2011 at 13:20

Спасибо. Всем. За развёрнутые мнения.

Сам пользуюсь и софтовыми и аппаратными решениями. Не являюсь сторонником какого-то одного лагеря =)

Всё-таки про плюсы аппаратного решения:

— В жёстких требованиях по производительности выигрывает всё-таки честный аппаратный RAID на быстрых винтах. Покрайней мере наш отдел билинга так считает.

— Vmware ESXi умеет ставится только на аппаратный RAID. Софтварный RAID в инсталяторе не предусмотрен.

amarao Jun 23 2011 at 14:16

А нафига VMWare вообще рейд? Не знаю, как у ESXi, а XCP позволяет умигрировать виртуальные машины с узла, на котором умер жёсткий диск, так что мы вполне себе живём без рейдов на хостах виртуализации. За это время сдохло два диска — ни одна виртуальная машина не пострадала.

easy_john Jun 28 2011 at 18:33

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

DmZ Jun 21 2011 at 21:38

Получается что этот способ не работает если массив был собран модулем при загрузке ядра (поиск/автоопредление)?
А для того чтобы получить hot-spare для root раздела нужно массив собирать руками в initramfs?

DmZ Jun 21 2011 at 21:42

Или достаточно запустить массив модулем, но описать его в mdadm.conf чтобы демон потом за ним следил?

amarao Jun 22 2011 at 00:05

Нужно чтобы массив был запущен на момент чтения mdadm'ом конфига. Хотя, наверное, --scan опция включит слежение и за выключенными массивами.

Я говорил про ситуацию «собрали ручками после загрузки» — в таких случаях монитор нужно перезапустить (или запустить свой).

DLag Jun 21 2011 at 23:11

Одно плохо в софт-рейде.
Варианты:
1. Сдох контроллер диска и завесил в момент прерывания ядро
2. Побилась пластина, но не выдает ошибок, а просто дико тормозит и плюет местами левыми данными
В них он не спасает.

Доходит до того что не получается исключить сбойнувший винт из массива, т.к. у mdadm срывает крышу, потому как глючит пол системы из-за сбоя.
Лечится только загрузкой rescuecd и ребилдом без монтирования.

amarao Jun 22 2011 at 00:04

1. Решается адекватными контроллерами (например, SAS контроллер и SAS корзина с SATA дисками)
2. Для кого SCT придумали, а? Или вы про проблемы desktop'ных винтов? Так не используйте их в рейде. Для рейдов есть нормальные винты, у которых с STC всё хорошо.

Куда веселее, когда срывает крышу у фирмвари железного рейда и он херит содержимое write cache'а.

DLag Jun 22 2011 at 10:37

1. Решается нормальными RAID-контроллерами
2. Seagate Constellation, WD RE 4

Для SAS использовать софтовый рейд — кощунство.

amarao Jun 22 2011 at 12:41

А теперь давайте без религиозно-мистических интонаций, какие бонусы даёт использование аппаратного рейда по сравнению с софтовым в случае SAS? Я знаю только один — bus saturation для PCI-E, но мой опыт говорит, что его в продакте не достигнуть (т.к. там идут рандомные операции).

Когда вы говорите «нормальные рейд-контроллеры», то мне даже становится странно. Я знаю, что из вендоров остались Arcea, Adaptek и LSI. Кто из них по-вашему мнению «нормальный»?

Я ни разу не встречал указанной проблемы (с дисками, которые бы блокировали работу mdadm). Точнее, встречал. На одном из тупых адаптековских HBA, вставление в хотплажную корзину винта на две минуты фризило систему — забраковали.

DLag Jun 22 2011 at 12:54

Сам недавно столкнулся с такой проблемой на Intel SR1600UR и SATA дисками WD RE4.
Решилось только rescuecd, в горячем режиме mdadm не работал.

Если вы не видите преимуществ хард-контроллеров, то о чем можно еще говорить?
BBU, read/write cache, оптимизация очередей…
Действительно какие преимущества…

То что у ваш опыт еще не включает таких случаев не значит что их не бывает.

amarao Jun 22 2011 at 13:03

SATA напрямую были воткнуты? Вот тут, я думаю, и причина. В случае SAS инфраструктуры отказ конкретного диска совершенно ни на что не влияет. В крайнем случае, его можно отключить средствами backplane'а.

Оптимизацию очередей линукс делает куда лучше аппаратных рейдов (BIO coalesing — в linux magazine про это довольно много писали), read cache у нас в системах хранения такой, что хардварные рейды уписаются от зависти (слабо аппаратный рейд с сотней гигов кеша найти?), с write cache'ем — у нас kyuubei пока не задеплоен, хотя планируется — и там с этой «проблемой» более чем хорошо.

BBU прекрасно заменяется микроупсами для сервера.

Итак, помимо этих «преимуществ», что ещё нам хорошего могут предложить аппаратные рейды? Ах, да, лимит на количество иопсов (тот же адаптек официально признаёт, что больше 10к IOPS они не выдержат).

DLag Jun 22 2011 at 13:19

Есть платформа с HS, та же картина.

amarao Jun 22 2011 at 13:33

М… я такого не видел. Причём не только у себя в облаке (допустим, несколько сотен жёстких дисков не репрезентативная выборка), но и по дата-центрам (тут уж выборка точно репрезентативная). В указанном списке я не работал с Intel'ом, ок, спасибо, учту на будущее (viva supermicro?)