Чем делать рейд?

[playnet]

Будет в общей сложности 8 дисков.
Пока надо 2 диска для отказоустойчивости. Чем вообще лучше создавать, dmraid, mdraid, LVM?
В вариантах 0, 1, 10 рейдов.

[BIgAndy]

Будет в общей сложности 8 дисков.
Пока надо 2 диска для отказоустойчивости. Чем вообще лучше создавать, dmraid, mdraid, LVM?
В вариантах 0, 1, 10 рейдов.

При помощи LVM райды не делают.
Софтрайды - моветон. Проще наладить нормальное резервное копироваие.

А в остальном - ни dmraid'ом ни mdraid'ом, ,а, например так: http://market.yandex.ru/search.xml?text=ra...4&srnum=658

Диски должны быть SAS.

[playnet]

Будет в общей сложности 8 дисков.
Пока надо 2 диска для отказоустойчивости. Чем вообще лучше создавать, dmraid, mdraid, LVM?
В вариантах 0, 1, 10 рейдов.

При помощи LVM райды не делают.
Софтрайды - моветон. Проще наладить нормальное резервное копироваие.

Моветон 5 и 6 софт. В 90% случаев 0, 1, 10 на софт работают не хуже, а часто даже лучше аппаратных (если там батарейки нет).
Да и норм контроллеры стоят от 15к. Денег просто не дадут, да и не нужно оно.
А резервное копирование есть, но рейдов оно не отменяет. Когда в офисе работа встает из-за выпавшего диска, никого не волнует, что где-то все данные есть.

А в остальном - ни dmraid'ом ни mdraid'ом, ,а, например так:

Интересует именно программное.
Будь у меня возможность, я бы все на zfs собрал так, как нужно. Но линь с zfs пока несовместимы. А fuse это вообще смешно для продакшена.

Диски должны быть SAS.

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

И потом. Зачем файлопомойке сас? И в данном случае оно тут потому что "так модно", "это круто", "чтоб было"...? Почему не SSD? Я использую X25-E, но осознанно. По иопсам оно сажает в глубокую Ж как сата, так и 15к сас.

Задача - убрать 4 самосборных серверка и файлопомойку на 1 железку. Хотел на 2, но там политические проблемы. Может, еще финансов к весне-лету выбью.

[anonymous.ru]

При помощи LVM райды не делают.

Почему?

Софтрайды - моветон.

Почему?

Проще наладить нормальное резервное копироваие.

Одно другое не заменяет. RAID и backup решают разные задачи.

Диски должны быть SAS.

SAS это если 27х7
А если 8x5 то SATA вполне подойдет.

http://market.yandex.ru/search.xml?text=ra...4&srnum=658

Фигня. Лучше так: http://hp.com/go/p9000


Если серьезно, то все зависит от конкретной задачи.

[playnet]

SAS это если 27х7
А если 8x5 то SATA вполне подойдет.

27... прикольный денёк
Вообще, есть и 24х7 решения на сата. Файлопомойки, мало и среднезагруженные веб сервера... Вон у хецнера сотни, если не тысячи, компов в аренду.. Все на сата дисках. Хотя там остстой какой-то ставят, у одного знакомого 4 диска, все с бэдами.
А так, есть Enterprise серия у WD, и даже WD RE серия для рейдов (Raid Edition). Что как бы намекает.

САС может иметь смысл там, где скорость важнее емкости, в плане надежности black серия почти не отличается от sas.

[rm_]

Моветон 5 и 6 софт.

Отнюдь.
Рекомендации лучших рейдоводов: http://louwrentius.blogspot.com/2009/07/20...e-based-on.html

[BIgAndy]

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

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

[rm_]

Потому что меньше нагрузку на ЦП создают

За те деньги, что стоит плата с поддержкой RAID6 на 8-12-16 дисках, можно просто купить шести-восьми-двенадцатиядерный CPU, и не беспокоиться, что какое-то из его ядер будет заниматься расчётами для RAID'а.

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

Никто не мешает использовать программные средства для того же самого, и в частности mdadm RAID6 именно это и делает (при наличии повреждения данных на одном из дисков, оно обнаруживается и исправляется).

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

SATA тоже hotswappable на современных контроллерах, а по безопасности - это вопрос к используемым корзинам/шасси.

Потому что SAS диски дешевле твердотельных

С твердотельными здесь никто не сравнивает, вопрос был НЖМД SAS против НЖМД SATA.

Потому что если контроллер DM накроется и у вас нет точно такой же платы, то свои данные без бубна не вытащите.

Контроллер простите чего накроется?
Вообще-то привязка к какому-либо контроллеру - есть недостаток как раз рекомендуемого вами аппаратного RAID'а, а не mdadm.

если бы мне админ предложил

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

[BIgAndy]

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

Я уже вышел за те рамки, когда административные задачи выполнял лично и сейчас оцениваю не только по замороченности решения, а по соотношению цена/качество/стоимость содержания.
Поверьте, софтверные райды были испытаны и в хвост и в гриву. Но наиболее устойчивые промышленные решения реализуемы только на нормальных raid' котроллерах. Ну, то есть на нормальных аппаратных средствах. И стоимость их ничтожна по сравнению с последующей стоимостью обслуживания/стоимостям отказа.
Да и для вас как админа будет меньше суеты. В mdadm вам придется руками прикручивать скрипты оповещения об отказах, а в поставляемх с RAID контроллерами|NAS данный функционал обычно реализован искаропки. Ну, конечно, если у вас не развернута какя-нть Tivoli Enterprise.


PS. Если вам нужна только файлопомойка, то посмотрите в сторону качественного NAS. На 4-5 хостах создает реальную экономию.

[KiWi]

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

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

Рейд с батарейкой стоит примерно как 4, если не больше дисков.
Учитывая, что SATA вполне спокойно работает годами в 24x7, то в соотношение цена/качество/стоимость содержания -- они побеждает.

[SLEDopit]

для отказоустойчивости

В вариантах 0

ну-ну (:

[playnet]

Потому что меньше нагрузку на ЦП создают

Простите, может я что-то не понимаю... Каким образом 0, 1, 10 будут создавать высокую загрузку? Там команды уровня "этот блок считать оттуда, этот отсюда". Еще раз, ускорение дает только для 5, 6 - там специализированный XOR процессор, который для нижних рейдов нужен меньше чем никак.

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

Внутри контроллера тоже есть прошивка, это софт... то есть программно, но на отдельной железке. Что мешает сделать тоже самое на основной?

Потому что если контроллер DM накроется и у вас нет точно такой же платы, то свои данные без бубна не вытащите.

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

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

А что есть опасная замена?
Есть у корзины хот свап - есть и горячая замена.

Потому что SAS диски дешевле твердотельных, и, на самом деле, по совокупности факторов надежнее.

А сата дешевле чем сас. И что?
Про надежность... на SLC уже надежнее, плюс у них из смарта можно вычитать Mean time before failure - сколько диску еще жить. У сас такого нет - ну откуда он может узнать, что у него поверхность изношенная?

Кеширование на аппартном контроллере сводит на нет преимущества скорости rw твердотельных накопителей

Почитайте уже тесты чтоли.Например, 16 SSD выдали 3.4гб/с (не гбит, а гб)

...далее по списку

Ждем список..

[anonymous.ru]

27... прикольный денёк

Да. у меня была тяжелая неделя и еще более тяжелая пятница. 27 часов в сутках это не предел

Вообще, есть и 24х7 решения на сата.

Я не точно выразил свою мысль. SATA скорее всего очень быстро посыпятся (год-полтора?), если их на них читать/писать (активно использовать) 100% времени в сутки. Это субъективное впечатление У меня статистики на этот счет нет.

rm_ +100500

[playnet]

SATA скорее всего очень быстро посыпятся (год-полтора?), если их на них читать/писать (активно использовать) 100% времени в сутки.

У ентерпрайз сата дисков MBTF заявлено около 1 млн часов, что сопоставимо с сас и явно больше года-двух.
У меня есть диски в нагруженных веб серверах, года 3-4 им уже.

А что по теме вообще?
Я просто только фрю знаю, но сейчас и линь надо подтянуть..

ну-ну (:

Я знаю, что это чередование и минус надежности ) Но делать надо тоже уметь.

[anonymous.ru]

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

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

Кеширование на аппартном контроллере сводит на нет преимущества скорости rw твердотельных накопителей

Для случайного ввода вывода эффективность кеширования может быть крайне низкой. Его можно оценить например как отношения объема кеша к объему хранимых данных. Так, что иногда (например при 100% случайном чтении) всё всё равно упирается в скорость дисков ( а кеш в этих случаях могут вообще рекомендовать не использовать)

[playnet]

Еще момент: есть сас 7200рпм, которые от своих сата аналогов отличаются только разъемом и программной частью (прошивкой), а механика - полная копия.

[anonymous.ru]

Еще момент: есть сас 7200рпм, которые от своих сата аналогов отличаются только разъемом и программной частью (прошивкой), а механика - полная копия.

не знал, мне всегда казалось, что технология производства дорожек и головок, у SAS и SATA отличается.
Сейчас погуглю.

[playnet]

Потому что SAS диски дешевле твердотельных, и, на самом деле, по совокупности факторов надежнее. Кеширование на аппартном контроллере сводит на нет преимущества скорости rw твердотельных накопителей

Пока было время, нашел ту статью...
http://www.thg.ru/storage/intel_x25-e_raid0_lsi/print.html

Еще момент: есть сас 7200рпм, которые от своих сата аналогов отличаются только разъемом и программной частью (прошивкой), а механика - полная копия.

не знал, мне всегда казалось, что технология производства дорожек и головок, у SAS и SATA отличается.
Сейчас погуглю.

Головки одинаковые. Обкатают на бытовых - и в серверные. А дорожки... это про сервометки чтоли?
Про 15к не знаю, может там и больше избыточной информации пишут, а вот в 7200 одинаковое, насколько мне известно.

http://www.regard.ru/catalog/tovar25729.htm пример диска сас на 2тб.

[playnet]

и еще маленькая ссылочка:
http://habrahabr.ru/blogs/hardware/73009/

[playnet]

Так, что иногда (например при 100% случайном чтении) всё всё равно упирается в скорость дисков ( а кеш в этих случаях могут вообще рекомендовать не использовать)

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

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

[anonymous.ru]

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

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

[playnet]

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

Ну про нее я тоже сказал. Если батарейка есть - хуже не будет.

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

Поподробнее пожалуйста. Какой вред будет от _кэша_? Даже при нулевой эффективности хуже быть не может.

лучше этот кеш отдать другим лунам.

Контроллер о лунах не знает, он с блоками работает. Тут записать, там считать.

[anonymous.ru]

Поподробнее пожалуйста. Какой вред будет от _кэша_? Даже при нулевой эффективности хуже быть не может.

Про политику опережающего чтения, Вы уже сказали.
Частный случай - это когда размер блока, которым читает хост меньше размера блока, который кеширует массив. Например хост читает блоками по 512 байт, а массив кеширует блоки по 8192. Тут как бы отдельной политики "предвыборки" нет, но фактически она происходит.
Но даже если размеры блоков совпадают, в случае использования кеша, алгоритм будет примерно такой:
1) поискать блок в кеше
2) если его там нет, проверить наличие свободного места в кеше
3) если в кеше нет свободного места , поискать блоки, которые безболезненно можно удалить из кеша
4) прочитать и кешировать блок
5) отдать блок хосту

Контроллер о лунах не знает, он с блоками работает. Тут записать, там считать.

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

[playnet]

Про политику опережающего чтения, Вы уже сказали.

Только это функция не кэша, а контроллера..

Частный случай - это когда размер блока, которым читает хост меньше размера блока, который кеширует массив. Например хост читает блоками по 512 байт, а массив кеширует блоки по 8192. Тут как бы отдельной политики "предвыборки" нет, но фактически она происходит.

Основное время - поиск сектора, позиционирование. Например, за 10мс мы нашли блок и потратили 0.01мс на чтение. А чтобы считать еще 15, мы затратим не 15*(10+0.01), а 15*0.01, 0.15мс. На общей производительности при честном рандоме скажется почти никак, а вот шанс найти в кэше блок в предвыборке все-таки отличен от нуля, хоть и мал. (на диске 1Гб примерно 2*10^-7, честный рандом это когда может достаться даже тот же блок)
И я не могу представить случаев, когда в продакшене будет полный случайный рандом. На реальных задачах от кэша даже в 128мб польза есть, а на 512мб да с предвыборкой..
В любой оси кстати тоже есть кэши. Можно их все отключить в том же лине и наблюдать замедление работы может даже на порядки.
Ну и про NCQ-TCQ не забываем.

Но даже если размеры блоков совпадают, в случае использования кеша, алгоритм будет примерно такой:
1) поискать блок в кеше
2) если его там нет, проверить наличие свободного места в кеше
3) если в кеше нет свободного места , поискать блоки, которые безболезненно можно удалить из кеша
4) прочитать и кешировать блок
5) отдать блок хосту

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

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

Может, контроллеры и такое умеют? Напишите в саппорт разных компаний, вдруг кто давно реализовал такое..

[BIgAndy]

Мда. Я бы задумался бы, взять ли такого админа.....

Это про меня? Я бы к такому ночальнегу и не пошел бы..

а вот и не подеретесь (:

Нет, конечно. ЧСВ - одна из составляющих моей профессии и должности.
Просто удивляет количество "ёжиков и кактусов" на единицу населения. Я рассуждаю с позиции стоимости потенциальных убытков от потери данных, стоимости их регенерации и стоимости обслуживания. Иные - из соображения минимизации (мнимой) первичных затрат.

По форуму куча толковых тем на предмет "softwara/hardware dm/md raid'ы". Как бы история применения их раскрыта достаточно хорошо.
Я, даже не ввязывюсь в дискуссию, хотя топикстартеру мог бы привести кучу идиотских решений, которые применяли наши админы и именно при помощи software raid. Помимо технической составляющей, (тема которой, кстати до сих пор топикстартером не рассмотрена всеоббъемлюще) есть эще технико-экономическая.

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

[KiWi]

Мда. Я бы задумался бы, взять ли такого админа.....

Это про меня? Я бы к такому ночальнегу и не пошел бы..

а вот и не подеретесь (:

Просто удивляет количество "ёжиков и кактусов" на единицу населения. Я рассуждаю с позиции стоимости потенциальных убытков от потери данных, стоимости их регенерации и стоимости обслуживания. Иные - из соображения минимизации (мнимой) первичных затрат.

Странно рассуждаете:
- если умрёт железка, то в случае mdadm -- нужна машина с Linux и достаточным количество мест под диски, в случае железки -- нужна новая железка
- SATA дешевле в расчёте на ГБ информации
- вылетает оно достаточно редко(если, конечно, поддерживать комфортную температуру в помещении с оборудованием) -- есть >1000 дисков, в месяц меняем 1-2 диска
- мифические кеши контроллера тоже ни о чём -- имея достаточно памяти, всё и так будет в кешах системы, более того, памяти в системе может быть ГОРАЗДО больше, чем памяти в контроллере -- 24ГБ, например
- RAID0,1,10 -- простые рейды с точки зрения процессора и не требуют отдельного процессора, более того, имея 16 ядер (2 процессора по 4 ядра с HT) -- даже если вдруг mdadm займёт одно ядро -- это не вызовет никаких проблем

Так что оправданность хардварного рейда и SAS сильно ограничена -- лишние деньги без видимого profitа.

P.S.: если что -- речь идёт о стабильных дата-центрах, в которых внезапно ничего не отключается.

[strah]

BIgAndy, а ты, случаем, не путаешь software RAID с fake-RAID?

[anonymous.ru]

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

Ок. Бог с ним с этим случайным чтением.
Давай посмотрим влияния кэша на последовательную запись большого объема информации.
Вот цитата из инструкции к одному дисковому массиву:

В обоих режимах управления кэш-памятью в случае отказа одно­го из контроллеров поддерживает­ся автоматическое переключение по схеме «активный-активный». Для каждого дискового тома по умолчанию задействуется режим отложенной записи, но его можно отключить. Данные при сбое элек­тропитания не теряются благода­ря резервному энергоснабжению с помощью высокоемкостных кон­денсаторов. Этот режим подхо­дит для большинства приложений. Скорость обмена данными при зер­кальном копировании кэш-памяти контроллеров зависит от пропуск­ной способности их шины обмена данными (Backend bandwidth), по­этому при записи больших непре­рывных фрагментов данных (на­пример, при обработке видеодан­ных, в телеметрии или при журнализации) схема со сквозной записью обеспечивает существен­ное (в ряде случаев до 70%) увели­чение производительности. Поэ­тому, если к данному тому не пред­полагается доступ в произвольном порядке, можно попробовать от­ключить отложенную запись.

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

Может, контроллеры и такое умеют?

Ты не поверишь. Все дело только в стоимости решения.

[watashiwa_daredeska]

есть >1000 дисков, в месяц меняем 1-2 диска

1000/2 = 500 месяцев. 500/12 >41 года жизни винчестера. В среднем. Не верю.

[Davinel]

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