[LostSoul]

1 час назад, jffulcrum сказал:

Я не сомневаюсь, что просматривая диск в HEX-редакторе можно определить версию, размер, и расположение суперблока, и там же и потереть, но мысли о троллейбусе из буханки в ходе процесса - не радуют. Это не индустриальный подход, это типичное красноглазое говно наколенное, "я задачу свою решил и высрал в Main, а вы - ебитесь". Какой миллион хомчков ЭТО вылизывал, каким местом?

 

не требуется для этого ничего смотреть в hex-редакторе.

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

например , где хранятся суперблоки у различных видов raid и fs и.т.п.

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

Для открытых решений все описано и разжевано.

Брать hex editor если и приходится, то как раз в случае какого-то редкого экзотического аппаратного решения про которое информации ноль.

И ещё и хрен отследишь как оно там работает и что читает в своем изолированном контроллере.

в отличии от софтовой реализации работу которой можно на любом участке наглядно отслеживать из ОС

 

 

 

1 час назад, jffulcrum сказал:

 

До конца не читаем, да? Просто в какой-то момент диск лочится, хотел бы написать, что от какого-то бага, но их же в Linux RAID нет... Хотя Ubuntu да, типа уже не Linux.

если у автора блокируется жесткий диск на ata-уровне , причем бы тут могла быть бага в mdraid?

mdraid тем и прекрасен , что он строго unixway и не занимается ничем кроме своего уровня.  Он никак не вдается в реализации ниже лежащих уровней блочного устройства.  ( кроме специфических модулей и настроек, выбираемых админом или инсталяционными скриптами , исходя из своих знаний о среде выполнения )

 

[straus]

3 часа назад, LostSoul сказал:

Ну это какие то ваши индивидуальные заморочки.

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

[straus]

3 часа назад, LostSoul сказал:

Оно обычно совмещено с дисковыми корзинами , имеет два дублированных бп , два контроллера и 2 вентилятора и зовется дисковой полкой. У меня такая от IBM даже дома стоит

Я покупал такие контроллеры отдельно - у меня дорого и богато. За каждый контроллер отдал целых 200 гривен, на то время это получалось почти 7.5 доллара за штуку. Mylex'ы DAC-960 в своё время я покупал что-то около 4 или 5 долларов за штуку, тоже дорого и богато, набрал сразу с запасом, чтобы в случае подыхания просто заменить и не морочиться, так и лежат запасные уже чёрт знает сколько лет.

 

Правда это всё SCSI, а вот SATA RAID нынче заметно дороже, это да. Но цена на них и на SATA HDD RAID Edition намекает, что иногда можно и б/у SCSI использовать. Заказчику такое не поставишь, а себе - аж бегом.

 

[alibek]

На программном решении я бы не рискнул использовать RAID, разве что кроме зеркала.

У меня личная статистика невелика, знаю только про три или четыре случая отказа RAID. В одном случае это был аппаратный контроллер и его восстановили успешно. В двух других случаях это были программные массивы и восстановить их не смогли; в одном случае вообще все пропало, в другом случае какие-то огрызки данных восстановили, но пользоваться этим все равно было нельзя и пришлось откатываться к последнему бэкапу.

[straus]

3 минуты назад, alibek сказал:

На программном решении я бы не рискнул использовать RAID, разве что кроме зеркала.

Даже зеркало не надо. Если ловим тот же BSOD в момент записи критичных данных - с высокой вероятностью можем получить рассинхронизацию.
 

[LostSoul]

1 час назад, straus сказал:

Заказчику такое не поставишь, а себе - аж бегом.

мой архив порнухи на SCSI не влезет.  пришлось дисковую полку на 12x3.5"  SAS/SATA ставить

 

 

1 час назад, alibek сказал:

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

у меня статистика примерно такая - ноль случаев рассыпания софтовых рейдов,  среди систем которые ставил я , несколько штук рассыпания среди моих знакомых , которые слышали что RAID5 это круто и поставили винду на какой-нибудь megaraid  -  приносили мне, я поднимал очень даже легко, просто собираешь в любой удобной программе типа UFX Explorer и готово.

 

Был несколько более сложный случай с аппаратными рейд и массивом на 18 дисков. основная проблема была как это все подключить с прямым доступом без рейд контроллера. Потом так же проблем с востановлением ноль.

 

Что это вообще за гипотетическая ситуация, когда при живых ( механически ) накопителях что-то там не удается востановить из рейда?  Рейд это по сути чередование /дублирование данных по разным накопителям известным обьявленным способом.

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

 

 

 

1 час назад, straus сказал:

Даже зеркало не надо. Если ловим тот же BSOD в момент записи критичных данных - с высокой вероятностью можем получить рассинхронизацию.

ну получилось рассинхронизация , и что ? Для тех областей которые в суперблоках не помечены как clean значит выполняется verify / rebuild.

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

 

[straus]

1 час назад, LostSoul сказал:

Что это вообще за гипотетическая ситуация, когда при живых ( механически ) накопителях что-то там не удается востановить из рейда?  Рейд это по сути чередование /дублирование данных по разным накопителям известным обьявленным способом.

Переадресую вопрос обратно: какая проблема с хардварными контроллерами? Всего то разница в том, как разные контроллеры маркируют винты, входящие в рэйд, как правило это первый абсолютный сектор, и остальные данные просто сдвинуты на этот сектор.

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

 

Почему-то тех, кто правильно понимает уровни отказоустойчивости, очень мало.

Есть понятие бесперебойности обслуживания при отказе диска. Эту часть реализуют уровни RAID.

Есть понятие бесперебойности обслуживания при отказах другого хардвара. Реализуется дублированием БП, дублированием RAID-контроллеров и т.д.

Есть понятие бесперебойности обслуживания после инцидента с выходом из строя диска. Реализуется хот-свапом.

Есть понятие бесперебойности обслуживания при восстановлении после выхода из строя БП. Реализуется хотсваповыми БП.

Есть понятие бесперебойности обслуживания при выходе из строя сервера (уровень SFT-III). Реализуется дублированием серверов, иногда географически разнесённых.

 

Основная задача RAID - не сохранение данных, это удел бэкапов. Задача RAID - непрерывность обслуживания. На какой-нибудь бирже остановка торгов на две минуты может стоить огромных денег. А если остановка коснулась только части брокеров, и самые выгодные предложения пролетели из-за этого - ещё хуже. И вот я ни разу не слышал, чтобы на биржах использовали софтовые рейды. В атомной энергетике тоже нет. В нефтехимии не попадалось. Было пару попыток использовать на транспорте, но быстро переиграли.
 

[straus]

1 час назад, LostSoul сказал:

ну получилось рассинхронизация , и что ? Для тех областей которые в суперблоках не помечены как clean значит выполняется verify / rebuild.

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

Теперь представим ситуацию на более низком уровне абстракции. Выполняется запись секторов. Во время остановки записи из-за критической ошибки ОС на разных дисках записывались сектора, относящиеся к разным блокам данных. Надеюсь не секрет, что процедура записи в RAID происходит не полностью синхронно? Итак на разных дисках, входящих в массив, у нас запись остановилась в разных местах. Отдельный хардварный контроллер всегда окончит отложенную запись, и сделает это для всех винтов, поскольку полная остановка системы на него вообще никак не влияет - у него свой процессор, своя память, своя внутренняя программа, иногда даже батарейка. А все процедуры софтового рэйда останавливаются вместе с крахом системы, в какой момент случилось - то и выгребайте.
 

[LostSoul]

22 минуты назад, straus сказал:

Переадресую вопрос обратно: какая проблема с хардварными контроллерами?

Да очень простая. Дергаешь случайно 2 диска одновременно из raid5 на горячую и все. Штатных способов восстановить не предусмотрено.

Посыпались в том же raid 5 на одном диске 200мб в начале диска , 200мбайт в конце на втором и 200мб с середине на третьем.

Как сказать вашему чудному аппаратному контроллеру , что я хочу обращаться к массиву , до такого то блока отключив доступ и расчитвая xor без накопителя 1 , после определенного блока исключив накопитель 2 , а среднюю область вообще не читать потому что там данные которые без проблем с другого узла реплицируются?

 

22 минуты назад, straus сказал:

Задача RAID - непрерывность обслуживания

Вот мне тут достался по наследству сервак intel sr какой то 1u с двумя сокетами  Xeon e54xx , двумя бп и крутейшим контроллером с 2гб кеша и толстой батарейкой.

Накатал на него debian , попытался с помощью smartctl атрибуты смарт вычитать. При попытке этого весь набор томов с этого контроллера отваливается по аварии и только ресет помогает.

Так вот и живет у меня непрерывность обслуживания - помечено красным smart не пытаться смотреть

 

24 минуты назад, straus сказал:

запасные контроллеры на случай выхода из строя

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

[LostSoul]

26 минут назад, straus сказал:

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

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

Они условно покупают как единицу хранения информации не отдельный диск а целую san с нужными ттх.

Для них софтовый рейд выглядит так как если бы офисный админ жесткий диск по компонентам покупал. Отдельно блины головки моторы и прошивку.

 

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

 

Если в вашем бизнесе ит и системы храгения это ваше ноу хау и конкурентное приемущество - то имеем в штате пряморуких спецов и делаем свои собственные программно аппаратные реализации на основе открытого кода mermaid ( к примеру )

Я лично на этом зарабатываю - на том что знаю и умею как установить и обслуживать софтовый рейд с на порядок более высокой готовностью чем аппаратный.

Если бы зарабатывал торгуя нефтью , то нанял бы или купил решения у такого поставщика как я , соответствующего мне по масштабу бизнеса. Крупный берет систему хранения у какого нибудь EMC с круглосуточной поддержкой. Мелкий торговец мелконефтью берет vps у небольшого но грамотного и трудолюбивого хостера с mdraid

 

24 минуты назад, straus сказал:

Итак на разных дисках, входящих в массив, у нас запись остановилась в разных местах

ну остановилась в разных и что?

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

 

 

28 минут назад, straus сказал:

А все процедуры софтового рэйда останавливаются вместе с крахом системы, в какой момент случилось - то и выгребайте.

Не совсем понятно , отчего вы крах на процессоре контроллера считаете менее вероятным событием чем крах на общем процессоре системы.

Софт рейд контролера отлаживали 3.5 индуса , производящие рефпкторинг доставшегося им от поедшественников грязного кода, в котором они понимают почти ничего.

Тот же mdraid постоянно допиливается и обкатывется миллионами инсталляций , массовость которых и не снилась ни одному крутому рейду с батарейкой

[straus]

34 минуты назад, LostSoul сказал:

Да очень простая. Дергаешь случайно 2 диска одновременно из raid5 на горячую и все. Штатных способов восстановить не предусмотрено.

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

 

38 минут назад, LostSoul сказал:

Как сказать вашему чудному аппаратному контроллеру , что я хочу обращаться к массиву , до такого то блока отключив доступ и расчитвая xor без накопителя 1 , после определенного блока исключив накопитель 2 , а среднюю область вообще не читать потому что там данные которые без проблем с другого узла реплицируются?

Зачем это всё делать? Указанная ситуация позволяет продолжать работу с RAID5 на чтение без всяких телодвижений. А использовать такой массив на запись - это сродни "после меня хоть потоп". Хотя вспоминается, что даже на запись такая ситуация может работать. Полного отказа какого-либо диска нет, парно-критичные блоки полностью не вылетели, будем продолжать работу без отказоустойчивости до момента замены дисков. И обычно есть Hot Spare, можно назначить его/их включение без полного отказа других дисков - сразу начнётся восстановление на них, правда массив уйдёт в состояние Degraded, но будет продолжать работать.
 

 

46 минут назад, LostSoul сказал:

только ресет помогает

А ведь Reset не затрагивает RAID-контроллер. Ищи проблему в другом месте.
 

[straus]

47 минут назад, LostSoul сказал:

Так вот и живет у меня непрерывность обслуживания - помечено красным smart не пытаться смотреть

Да, и кстати - SMART в дисках массива посмотреть в принципе невозможно. Поскольку массив представляется для ОС как один диск. Для этих целей существует к хардварным контроллерам родная утилита, которая ещё много всего полезного умеет.
 

 

49 минут назад, LostSoul сказал:

1 час назад, straus сказал:

запасные контроллеры на случай выхода из строя

Ну то есть предлагается выкинуть на свалку хороший годный сервер

Где-то потеряна логика.
 

[straus]

40 минут назад, LostSoul сказал:

Не совсем понятно , отчего вы крах на процессоре контроллера считаете менее вероятным событием чем крах на общем процессоре системы.

И в реале за десятки лет работы большого количества устройств случаев сбоев было просто ооочень мало. И теоретически возможностей заставить сбойнуть нет - это закрытая подсистема, процессор которой занимается только своим делом. Там нет ОС, нет стеков протоколов, она не смотрит в интернет... Случаи сбоев связаны с питанием, выходящим не только за рамки допусков, но и вообще до состояния "полная ж". Сами процессоры i960 тоже вылизаны неплохо, стоят в самолётах F-22 Raptor.
 

 

46 минут назад, LostSoul сказал:

Софт рейд контролера отлаживали 3.5 индуса , производящие рефпкторинг доставшегося им от поедшественников грязного кода, в котором они понимают почти ничего.

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

 

50 минут назад, LostSoul сказал:

Тот же mdraid постоянно допиливается

Это говорит только о том, что он постоянно сырой, и в нём есть, что допиливать. Это минус, а не плюс.
 

[maxlapshin]

14 hours ago, LostSoul said:

Ох уж мне эти сказки , ох уж эти сказочники.  Чему там в обычном рейде от kerbel panic разваливатся , так что оно потом не собралось? Отличие софтового рейда от фирменного закрытого как раз в том что миллионами хомячков все баги вылизаны 

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

 

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

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

 

Есть обсуждение на тему opensource vs vendor soft, но его тут попросту нет. Тут обсуждение с людьми у которых BSOD. На сервере. Не трогай =)

[naves]

On 12/29/2019 at 1:24 AM, straus said:

SMART в дисках массива посмотреть в принципе невозможно

Лет 10 как умеет smartmontools, это конечно зависит от конкретного контроллера, но обычно работает.

И вообще начали тут спорить, что круче, экскаватор или бульдозер. А на вопрос, как объединить 6-10 дисков для видео так и не ответили.

Raid 1 избыточен,

5 или нулевой фатален.

Остаётся или 6, или софтварное размазывание.

OverlayFS?

[straus]

49 минут назад, naves сказал:

Лет 10 как умеет smartmontools, это конечно зависит от конкретного контроллера, но обычно работает.

Перевожу свой посыл на русский язык - стандартного способа посмотреть SMART дисков хардварного RAID-массива нет. Это возможно сделать, только используя специальные функции соответствующего контроллера, которые зависят от производителя.
 

[naves]

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

Изменено 30 декабря, 2019 пользователем naves

[straus]

1 час назад, naves сказал:

И вообще начали тут спорить, что круче, экскаватор или бульдозер. А на вопрос, как объединить 6-10 дисков для видео так и не ответили.

Raid 1 избыточен,

5 или нулевой фатален.

Остаётся или 6, или софтварное размазывание.

OverlayFS?

Из дисков сделать несколько RAID0, чтобы обеспечить нужную скорость потока, и на них раскидать несколько потоков записи. Если необходима отказоустойчивость - собрать их в массивы RAID10. Ну или использовать RAID6. Но сходу такие задачи лучше не решать, а посидеть и посчитать.

29 минут назад, naves сказал:

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

 

Стандарт - это когда есть стандартизованный документированный API, не зависящий от хардвара. Если какая-то утилита знает много контроллеров - это НЕ стандарт. Я не предполагал, что такие вещи нужно объяснять на этом форуме.


 

[Shurhenchik]

6 часов назад, naves сказал:

А на вопрос, как объединить 6-10 дисков для видео так и не ответили.

Raid 1 избыточен,

5 или нулевой фатален.

Остаётся или 6, или софтварное размазывание.

OverlayFS?

Тут ведь еще и объем доступный для записи сильно меняется. Надо-то сколько?

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

Где-то может быть отказоустойчивость вообще не нужна.

А где реально нужна, то RAID-6 + Hot Spare + батарейка будет достаточно неплохим вариантом.

[LostSoul]

В 29.12.2019 в 01:12, straus сказал:

А ведь Reset не затрагивает RAID-контроллер. Ищи проблему в другом месте

Ну ну

 

В 29.12.2019 в 01:12, straus сказал:

Зачем это всё делать? Указанная ситуация позволяет продолжать работу с RAID5 на чтение без всяких телодвижений.

Если диск при попытке чтения поврежденной зоны уходит в оффлайн то ничего у вас не получится. Но даже если не уходит - продолжает разрушаться.

Выдергивание дисков происходит по ошибке как правило.

[LostSoul]

В 29.12.2019 в 01:24, straus сказал:

Где-то потеряна логика

Допустим я маленький предприниматель. Мне подарили старшие братья дорогой качественный сервер с аппаратным рейд. Но только один сервер ( 1шт ) , а другой такой взять мне негде и цена для меня неподьемна.

Как поступить правильно в такой ситуации? Очевидно - перешить контролер в hba режим , чтоб случае смерти сервера без проблем переставить набор дисков в изьятый у секретарши марьи Ивановны компьютер и идти по друзьям и знакомым ( ebay / avito ) медленно и печально искать запчасти или новый сервер.

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

[Shurhenchik]

1 минуту назад, LostSoul сказал:

Как поступить правильно в такой ситуации? Очевидно - перешить контролер в hba режим

Совсем не очевидно.

Подарили - используй его по назначению.

Просто надо бэкапы делать.

А так же их проверять после того как сделал.

[LostSoul]

В 29.12.2019 в 01:42, straus сказал:

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

Так у меня и на общем процессоре в случаях kernel panic никаких развалов не было.

Единственный подобный факап в моей жизни это развал zfs после установки плохо протестированной бу памяти. Пришлось данные копиррвать на новый раздел ( без потерь )

 

7 минут назад, Shurhenchik сказал:

Просто надо бэкапы делать

И что потом делать с этим бекапом то?

 

Работать дальше как?

[Shurhenchik]

31 минуту назад, LostSoul сказал:

И что потом делать с этим бекапом то?

 

Работать дальше как?

Давным давно я слышал слова, что-то вроде "план восстановления"

И я написал не только делать, но и восстанавливать их для проверки что восстановление возможно

[alibek]

Очевидно, говорят о некоем малом бизнесе, у которого нет ничего, кроме подаренного сервера.

Поэтому никаких планов восстановления и не имеется.

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

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