RAID5 - замена диска

RAID, я так понимаю, хардварный?

1. Как правило, да. Смотри документацию RAID-контроллера.
2. Да.

1. да
2. да

Но ничего хорошего из этого не выйдет.

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

Уточнение: главное, чтобы контроллер поддерживал данную модель диска. Могут быть различия на уровне firmware или даже размера сектора.

1. да 2. да

- лишнее место на более крупном диске будет потеряно - массив будет работать со скоростью самого медленного из дисков

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

больше половины выпавших из рейда дисков оказывались целыми, но требовали апдейта фирмвари

Хтонический ужас. Это были Seagate 7200 rpm?

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

А вобще, если диски настолько старые, что уже не купить, то может менять их все 4 штуки на новые?

разные серии сигейтов и максторов, 10 и 15к, scsi и sas

фишка в том что апдейт давно был доступен на сайте, люди просто не следили за своими серверами годами

Бывает, что совсем брендовый RAID-контроллер понимает диски только своего производителя.

Однако. «Железные» RAIDы не нужны!) Ничего они не дают, кроме полной *опы геморроя.

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

Они дают индикацию неисправного диска, что позволяет их менять без прав админа. И ещё они дают RAID5 с батарейкой.

Cервер подключенный двумя бп в два упса дает такой кеш записи что любой контроллер и близко не валялся. Это если говорить про те контроллеры которые в PCIE вставляются. Хардварный рейд имхо уместен на отдельных стораджах.

Они дают индикацию неисправного диска

mdadm --monitor --scan

что позволяет их менять без прав админа

... силами уборщиц и ночных сторожей. Сомнительное преимущество, как мне кажется.

И ещё они дают RAID5

Не нужен. Есть 6 и 10/50/60

с батарейкой

«Умный» УПС в той же стойке решает проблему сбоев питания гораздо более эффективно.

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

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

И ещё они дают RAID5

Не нужен. Есть 6 и 10/50/60

Raid 6 не решает проблему, известную как «RAID 5 write hole». А то, что для RAID 50 не нужен RAID 5 показывает глубину ваших познаний.

Raid 6 не решает проблему, известную как «RAID 5 write hole».

Проблема write hole в софтовом RAID5 решается средствами ФС (ext4 и XFS точно). Только не спрашивайте о подробностях, я их не знаю и просто доверяю автору mdadm %)

физическое наличие админа вблизи сервера не нужно

Справедливости ради, должен заметить, что не все рэйдконтроллеры это позволяют. К примеру, довольно не плохой LSI 9260-8i продолжает пищать после замены диска, пока админ не даст соответствующую команду через megaclisas.

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

Когда ОС работает с аппаратным RAID-контроллером ничто не запрещает её использовать ОЗУ для кеширования записи.

Батарейка RAID-контроллера работает в более щадящем режиме, чем батарея в UPS, что делает её поведение более предсказуемой. У неё считаются циклы заряда/разряда и можно заранее подготовится к её замене. Для меня поведение батареи в UPS плохо прогнозируемо, было несколько раз на различных APC Smart, что батарея проходила внутреннее тестирование, но практически сразу сдыхала под полной нагрузкой.

Нужны два UPS, два блока питания в серверах. И запас батареек к ним.

Совершенно согласен.

Raid 6 не решает проблему, известную как «RAID 5 write hole».

Основная проблема raid 5 - не write hole, которая, как выше было справедливо указано, решается средствами fs, а высокая нагрузка на диски в degraded mode, с безвозвратной потерей информации с массива в случае выхода из строя ещё одного hdd. raid 6 выдерживает потерю 2-х.

А то, что для RAID 50 не нужен RAID 5 показывает глубину ваших познаний.

XD

силами уборщиц и ночных сторожей.

в нормальных конторах, они в серверную доступа не имеют

в нормальных конторах, они в серверную доступа не имеют

И в очередной раз я убедился в необходимости использования тега [sarcasm].

Нужны два UPS, два блока питания в серверах. И запас батареек к ним.

В случае с аппаратным рейд нужны два котроллера, тк когда один контроллер сломается через три года, совсем не факт что его новая модель соберет ваш массив. За такие деньги как раз можно купить два дешевых SAS HBA и собрать софтовый рейд, подключив диски с multipath

Батарейка RAID-контроллера работает в более щадящем режиме, чем батарея в UPS, что делает её поведение более предсказуемой.

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

У неё считаются циклы заряда/разряда и можно заранее подготовится к её замене.

Только если батареи UPS можно менять находу, то в серверах которые я видел, батарейки весьма сложно сменить без остановки.

Вобщем я бы рассматривал BBU как последнюю надежду, которую покупать стоит уже когда два упса и резервируемые бп давно есть.

Киньте ссылку или это он вам сказал лично?

Я пока что нагуглил crc32 в ext4 для 3.5 ядер и утверждение NeilBrown'а, что при старте не синхронизированного, но и не деградировавшего софтового RAID5 в ходе его синхронизации write hole будет починена.

Нет, не лично. Но нагуглить тоже не выходит. Может, это и не он писал. Постараюсь найти.

crc32 в ext4 для 3.5 ядер

Точно не это.

 утверждение NeilBrown'а, что при старте не синхронизированного, но и не деградировавшего софтового RAID5 в ходе его синхронизации write hole будет починена

Вот это похоже. Совершенно точно помню, что там упоминались только ext4 и XFS (для меня осталось загадкой, почему ext3, reiserfs и jfs там не было).

В случае аппаратного рейда можно брать контроллер, формат метаданных которого понимает dmraid. Кроме того, если серверов несколько, то достаточно просто купить для них одинаковые (или совместимые по формату) контроллеры.

то в серверах которые я видел, батарейки весьма сложно сменить без остановки.

Берите Raid без батарейки, на кондесаторе типа Adaptec 5805Z.

Если денег не много, лучше уж один UPS, один блок питания в сервере и хороший аппаратный RAID с BBU, чем два UPS, два блока питания и софтовый RAID, который ещё как правило без корзины. Как я уже писал, старый АКБ в UPS может вести себя не предсказуемо. При половинной нагрузке всё может быть хорошо, при максимальной — тянет несколько секунд. В случае когда в сервер два БП, он равномерно распределяет нагрузку между ними, и каждый БП нагружен на половину, каждый UPS будет нагружен на половину, но если один из UPS будет выключен, на второй будет полная нагрузка и не факт, что он её выдержит (через 3-5 лет).

Хороший аппаратный RAID даёт хорошую производительность, но при этом не загружает CPU сервера расчётом XOR (для RAID5/6), позволяет загружать систему (boot) с RAID'а и в паре с корзиной позволяет упростить замену неисправных дисков.

В моей практике достаточно много винчестеров «умирало» в выключенном состоянии, если можно так сказать. То есть винчестер работал нормально, его шататно выключили, а включить уже не смогли. Поэтому далеко не факт, что выключая не дерградировавший RAID при включении будет получен не деградироваший RAID. Особенно для серверов, где винчестеры бывают работают годами. Винчестер может работает нормально, но блоки со служебной информации (читаемые при включении питания) уже испорчены и после сбоя по питанию винчестер уже не взлетит.

Более того, если я правильно понял высказывания автора mdadm http://board.issociate.de/thread/504881/RAID5-write-hole.html то в случаи деградации диска на не синхронизированном софтовом RAID-массиве, его нужно будет синхронизировать «ручками».

Более того, если я правильно понял высказывания автора mdadm http://board.issociate.de/thread/504881/RAID5-write-hole.html то в случаи деградации диска на не синхронизированном софтовом RAID-массиве, его нужно будет синхронизировать «ручками».

Правильно поняли. Там же и написано, почему так :)

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

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

каждый UPS будет нагружен на половину, но если один из UPS будет выключен, на второй будет полная нагрузка и не факт, что он её выдержит (через 3-5 лет).

Интересно как у UPS деградирует мощность по вашему? А по поводу емкости батарей - ну никто не мешает заранее посчитать нагрузку и установить столько емкости чтобы хватило с запасом, или мы тут говорим про лишь бы какой UPS лишь бы поставить?

но при этом не загружает CPU сервера расчётом XOR (для RAID5/6)

Уж очень сложно представить сколько у вас должно быть I/O чтобы хоть сколько нибудь нагрузить современный процессор расчетом XOR. Обычно на таких объемах уже используют внешний сторадж включенный по FC.

софтовый RAID, который ещё как правило без корзины.

Не вижу никакой связи между аппаратным рейд и бекплейном куда втыкаются диски. Лучше расскажите как сделать multipath, когда например SAS бекплейн поддерживает включение в два HBA сразу. Сделать софтовый рейд в таком случае нет проблемы, а как сделать железный? Или никак нельзя обойтись без даунтайма в случае умирания вашего железного raid контроллера?

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

Гугл смотрит на вас, ну сами знаете как.

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

Очевидно oracle и не подозревает о таком вашем опыте, и и не стесняется предложить софтварное зеркалирование в своем ASM, который суть софтрейд+lvm. Конечно для Ъ энтерпрайза есть режим «надеюсь на свой контроллер». Про ZFS в вашем Ъ энтерпрайзе тоже видимо не слышали.

массив будет работать со скоростью самого медленного из дисков

А откуда простите, это ваше утверждение? На чтении raid5 обычно быстрее одиночного диска, на последовательной записи тоже, пичаль то в рандомной записи.

Гугл смотрит на вас, ну сами знаете как.

гугл вообще работает иначе, и их методы к нормальному энтерпрайзному ДЦ никакого отношения не имеют

Очевидно oracle и не подозревает о таком вашем опыте, и и не стесняется предложить софтварное зеркалирование в своем ASM, который суть софтрейд+lvm. Конечно для Ъ энтерпрайза есть режим «надеюсь на свой контроллер». Про ZFS в вашем Ъ энтерпрайзе тоже видимо не слышали.

вы не различаете между «можно сделать» и «так делают» ? в венде тоже можно поднять софтрейд, даже в древней нетвари можно было, ну и что из того?

А откуда простите, это ваше утверждение? На чтении raid5 обычно быстрее одиночного диска, на последовательной записи тоже, пичаль то в рандомной записи.

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

гугл вообще работает иначе, и их методы к нормальному энтерпрайзному ДЦ никакого отношения не имеют

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

В энтерпрайзном DC стоят стораджи с сотнями дисков, а не нерезервируемые pcie raid контроллеры без multipath. Если вы считаете что реданданси экстентов в ASM никто не использует, а в ZFS raid запилен только лишь чтобы сказать что так «можно сделать», то наш с вами энтерпрайз явно разный.

В конце концов, есть уже решение которое позволит резервировать pcie рейд контроллер?

Мощность UPS определяется мощностью, отдаваемой батарей. Длительность, в течении которой UPS даёт заданную мощность определяется ёмкостью АКБ. Ёмкость АКБ величина условная, даже у нового АКБ она сильно зависит от разрядного тока. У старого АКБ с плохими пластинами всё может быть хуже, поэтому гарантировано определить ёмкость/работоспобосность старой АКБ можно только полным разрядом при максимальном допустимом токе.

В серьёзных UPS'а реализованы серьёзные схемы контроля, когда батарея состоит из нескольких паралельных ветвей и каждая ветвь тестируется отдельно. Но, это в серьёзных, а APC Smart, что на 1500 VA, что на 10 kVA ничего подобного нет и там тестирование АКБ так себе.

Но если вы так уверены в непогрешимости UPS, зачем используете журналируемые ФС?

Внешние стораджи (с SAS- или FC-свичём) как раз и используют, когда нужен multipath, а не собирают непойми что на SAS с двумя HBA. При этом производительность внешнего дискового массива делится на все работающие с ним сервера. И его используют из-за большой ёмкости и multipath, а не по причине высокого I/O на сервере.

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

Вот и докатились до ZFS. Пожалуй я свалю из этой темы.

Но если вы так уверены в непогрешимости UPS, зачем используете журналируемые ФС?

Я не уверен в непогрешимости UPS, однако таки считаю что два бп+два упса+софтрейд лучше чем true hw raid + bbu

Аппаратный RAID не обещает полное исключение даунтайма, он общает снижение даунтайма за счёт повышения отказоустойчивости дисковой подсистемы.

А софтварный нет? За эти же деньги две платы HBA обеспечивают большую надежность за счет резервирования, непойми что в вашей терминологии.

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

И его используют из-за большой ёмкости и multipath, а не по причине высокого I/O на сервере.

То есть по вашему количество дисков на IOPs не влияет и сторадж нужен только чтобы побольше кина сохранить? А я по старинке когда не хватает скорости, добавляю диски в рейдгруппы.

дело не в гуглевских данных, а в крупномасштабном подходе к стандартным задачам в ДЦ, особенно несколько лет назад, когда виртуализация еще не была воткнута в каждую дыру.

один из проектов в которых я участвовал еще джуниором очень показателен: задача: поднять ДЦ на 1600 серверов в рендер-ферме, 200 серверов с попарно реплицированными БД (собирать репорты), небольшой кластер шедулеров (24 хоста), плюс еще около 300 машин для обслуживания всей этой системы (DNS, DHCP, AD, Exchange, Nagios, SPLAT, DLP... ну короче стандартный набор, с высокой доступностью везде где можно и нельзя).

поднять это надо в рекордные сроки, бюджет тоже не идеален, но зато разложен на 5 лет вперед, то есть я могу потратить больше сразу если ROI будет высокий, или наоборот.

мы подсчитывали экономию на железе, если ставить софтрейд, и разница была просто смешной. зато: 1. серверы приходят по заказу от производителя с уже настроенным рейдом, то есть надо просто поставить их в стойки и запустить - дальше все сделает altiris (с паппетом тогда еще дела не имел к сожалению). 2. мониторинг дисков, с predictive failure автоматический, и на единой панели с алертами. плюс горячая замена мальчиком студентом который один (точнее трое их, посменно) может сидеть во всем этом ДЦ, и этого вполне достаточно чтоб мониторить железо и устранять самые простые и частые неполадки. 3. так как решение одно, от одного производителя, то и гарантия и обслуживание на весь ДЦ на пятилетку закрыты одним махом, причем поддержка серверов с рейд контроллерами намного легче чем с софтрейдом - вендорный саппорт знает что с ними делать и как их проверять, и не должен гоняться за софтовыми производителями, причем в данном зоопарке их было как минимум три разных.

если бы мы делали все на софте, сроки доставки растянулись бы не на одну неделю, и для поддержки этого ДЦ надо было бы держать людей способных на большее чем выдернуть диск у которого лампочка красная горит, и воткнуть другой, а это, в пересчете на кол-во железа и 5 лет, очень немалые деньги. Я даже не беру в рассчет то, что софтрейд не настолько автоматизирован как железный, и пересборка рассинхронизировавшегося массива обычно требует вмешательства админа - а это еще человекочасы, умноженные на 2000+ машин.

ну и еще - огромный плюс контроллеров в том что управление дисками уходит из OS, и о них не надо беспокоиться. в принципе, та же разница как в работе с апплаенсами vs софтовые решения - что лучше - сервер с iptables или asa? смотря для чего, конечно же, но в крупных ДЦ такой вопрос ведь даже не задают, верно? Вот и тут то же самое.