Комментарии 66
Единственное, систему, как мне кажется, проще держать на RAID1 а не RAID6.
0
НЛО прилетело и опубликовало эту надпись здесь
Вопрос в том, что в случае слетания порядка дисков, выхода из строя произвольного и тд — система остаётся загрузочной.
Для установки системы под файлопомойку 1 гига за глаза, потому «экономии» никакой относительно RAID6 нет
Для установки системы под файлопомойку 1 гига за глаза, потому «экономии» никакой относительно RAID6 нет
+2
НЛО прилетело и опубликовало эту надпись здесь
vazir! реквестирую du -hs /* за вычетом точки монтирования непосредственно мегарейда.
По теме — система должна быть надёжной. Имея систему на 8*RAID1 мы получаем систему загружающуюся в любых позах, позволяющую воскрешать систему из любого состояния.
Имея 8*RAID6 имеем геморрой с подъёмом рейда не только основных данных, но и системы, не дай боже слетит. + Нужно альтернативные пути загрузки сервера.
Вообще, для файлопомойки я использовал загрузку по сети. Вот это — экономно, место не тратит, позволяет загрузить в любой позе, вплоть до удалённого рекавери.
А если уж система на дисках — то RAID1 более предпочтительный вариант.
По теме — система должна быть надёжной. Имея систему на 8*RAID1 мы получаем систему загружающуюся в любых позах, позволяющую воскрешать систему из любого состояния.
Имея 8*RAID6 имеем геморрой с подъёмом рейда не только основных данных, но и системы, не дай боже слетит. + Нужно альтернативные пути загрузки сервера.
Вообще, для файлопомойки я использовал загрузку по сети. Вот это — экономно, место не тратит, позволяет загрузить в любой позе, вплоть до удалённого рекавери.
А если уж система на дисках — то RAID1 более предпочтительный вариант.
0
НЛО прилетело и опубликовало эту надпись здесь
Флешки не такие надежные
0
НЛО прилетело и опубликовало эту надпись здесь
Смотря где использовать — в домашней файлопомойке, да. В критически важных корпоративных серверах не стоит. Эти выводы были сделаны коллегами, которые устали менять флешки по причине надежности.
0
Да, но когда дисков много, и они однотипные, както жаль что место пропадать будет, поскольку разделы нужно делать одинакового размера (можно и не одинакового, но рейд всеравно будет выровнен по наименьшему) — потому было сделано 1Гиг под систему — остальное данные. Соответственно этот гиг при разливке на 8 дисков уровня 6 (как к меня) — превращается в 6 гиг. В случае же RAID-1 мы получаем 1 гиг. Но зато грузиться можем с любого ;)
+1
Мой опыт говорит, что экономия места на современных HDD неоправдана — большинство дисков не способно обеспечить производительность пропорциональную ёмкости. Так что миррорить до самого «немогу».
+2
Можно и миррорить, но согласитесь, 8Т (миррор) или 14Т (рэйд 6) большая разница для бюджетного массива. А для мирроринга — тогда уже лучше кластер делать. Заодно будет и сетевой мирроринг. Мирроринг однозначно лучше если нужна производительность.
+1
Ну, я дома дёргался-дёргался, а потом плюнул и сделал обычные парные RAID1. Причина — чем меньше оно умничает, тем проще жить. Например, замена винтов на более ёмкие для RAID5/6 — это ад и погибель. Для raid1 эта операция на пять-семь строчек. При использовании неполностью заполненного LVM, даже без перерыва в обслуживании.
+2
Я мигрировал 8 дисков Raid 5 на 16 дисков Raid 6 с ресайзом ext3 7Т до Ext4 14T — Могу подтвердить — несколько стремно! Но тем не менее все прошло гладко. LVM в данном случае использовать не видел смысла — поскольку ресайз RAID добавит физического места по любому, но все равно нужен ресайз EXT3/4 — который использует собственный инструментарий.
0
Дело не в «стрёмно», а в том, что для ресайза рейда с 2Тб на 3Тб достаточно ДВУХ дисков по 3Тб, а для любых других комбинаций, нужно закупать диски в большем объёме — это во-первых дороже, во-вторых не всегда есть столько свободных SATA'шных дырок. Финт с 2Тб raid1 в 3Tb raid1 можно провести только с одной свободной дыркой. А для рискованных чуваков — даже без оной, просто вынимаешь диск на хотплаге, тыкаешь новый, вгоняешь в рейд, после ребилда повторяешь с другим диском из массива, потом --grow, pvresize, lvresize, xfs_growfs — всех дел 2 минуты, плюс время ребилда.
+6
К слову, с 2Тб на 3Тб можно перевести в условиях ограниченного бюджета даже с одним новым диском, если есть доп.дырка.
2Тб меняется на 3Тб, на свободном Тб создаётся раздел и зеркалится с половиной старого 2Тб диска.
2Тб меняется на 3Тб, на свободном Тб создаётся раздел и зеркалится с половиной старого 2Тб диска.
0
Совфтовыми методами буквально можно творить чудеса (в большинстве случаев)
0
Что такое «зеркалится с полоиной старого 2Тб диска»? Вы не сможете иметь миррор из 2Тб и 3Тб больше 2Тб в размере.
0
Например, замена винтов на более ёмкие для RAID5/6 — это ад и погибельНасколько мне известно, простая замена винтов на более емкие в софт-рейдах проблем не вызывает (во всяком случае, это верно для ZFS; в сети легко найти пошаговые инструкции). Куда сложнее добавить еще один диск в массив (желательно в онлайне). Та же ZFS вроде бы пока этого не умеет, к сожалению.
Хардварные рейд-контроллеры часто позволяют и то, и другое; например старшие 3ware точно. В процессе пересборки массива можно даже перейти с 5-го на 6-й уровень. Очень удобно. К сожалению, не могу прокомментировать, как с этим в GNU/Linux.
-2
См выше, проблема не в процессе, а в накладных расходах.
Для «добавить ещё один диск» никаких проблем нет, LVM для этого и создавали.
Для «добавить ещё один диск» никаких проблем нет, LVM для этого и создавали.
0
Да, действительно, судя по всему LVM умеет расширять массив на большее количество дисков. Полезная фича; в свое время отчасти из-за этого пришлось отказаться от ZFS в пользу 3ware.
Что же до накладных разходов (если я вас правильно понимаю), диски можно докупать постепенно, последовательно заменяя их все в массиве, после чего пул расширится «сам» — не дорого (т.к. размазано во времени), можно обойтись без даунтайма. Конечно, если место вдруг резко заканчивается, докупить еще один диск дешевле и быстрее, но 1) рано или поздно дисков может стать слишком много, а дырок и пропускной способности мало; 2) имхо стоит следить за свободным местом и планировать/выделять средства на покупку винтов заранее.
Что же до накладных разходов (если я вас правильно понимаю), диски можно докупать постепенно, последовательно заменяя их все в массиве, после чего пул расширится «сам» — не дорого (т.к. размазано во времени), можно обойтись без даунтайма. Конечно, если место вдруг резко заканчивается, докупить еще один диск дешевле и быстрее, но 1) рано или поздно дисков может стать слишком много, а дырок и пропускной способности мало; 2) имхо стоит следить за свободным местом и планировать/выделять средства на покупку винтов заранее.
0
Ой, расходов, конечно.
0
Вы про домашнюю систему говорите? Или про продакт-сервер? Планировать средства на расширение дискового пространства в домашнем компьютере… Нет ощущения, что в этой фразе что-то лишнее?
0
Скажем так: про нечто среднее. :-) Например, в моем случае это вскладчину купленный сервер для хранения «тяжелого» (и ценного) контента (lossless музыки, разнообразного софта, hd-видео, бэкапов, etc.) с количеством пользователей-«акционеров» ~4-5 человек. Это, конечно, далеко не продакшн, но место кончается катастрофически быстро, а свободные деньги на апгрейд, как водится, есть не у всех и/или не всегда. Приходится планировать.
0
можно подробнее — как на 3ware контроллере можно заменить один диск в RAID5 на более ёмкий?
с пошаговыми командами для tw_cli
с пошаговыми командами для tw_cli
0
Честно говоря, мне не доводилось настраивать эти контроллеры под *nix (отказ от ZFS как-то одновременно стал и отказом от FreeBSD/OpenSolaris в пользу Windows, которую администрировал уже не я и без tw_cli). На гугление ответа, я думаю, у нас с вами уйдет сравнимое время, не обессудьте. :-)
-1
Насколько я помню, более ёмкий диск просто будет использоваться не весь. Но нам вендор не советовал таким образом готовится к переезду на более ёмкий сторадж :)
0
Простите, что отвечаю спустя несколько месяцев: не пришла нотификация (т.к. вы ответили не на мою реплику), а за тредом я не уследил.
Я нигде вроде бы не утверждал, что замена одного диска в пятом рейде (в любой его реализации) позволит сразу задействовать весь его объем; это, разумеется, не так.
Я имел ввиду, что по крайней мере для ZFS единственным способом расширить существующий raidz пул — последовательно заменять диски на более емкие. Думаю, что и для тривари аналогично; впрочем, утверждать не стану, т.к. под *nix с этими контроллерами не работал. Просто из общих соображений мне кажется, что если уж ZFS не позволяет добавлять диски в пул (по утверждению разработчиков, это технически сложно (было?) реализовать), но позволяет последовательно заменять их на более емкие, то триварь, которая поддерживает добавление дисков, такую замену уж точно умеет.
Соскакивать никуда у меня и в мыслях не было. Есть хотите продолжить дискуссию, я только за, в том числе (даже в особенности), если в чем-то не прав.
Я нигде вроде бы не утверждал, что замена одного диска в пятом рейде (в любой его реализации) позволит сразу задействовать весь его объем; это, разумеется, не так.
Я имел ввиду, что по крайней мере для ZFS единственным способом расширить существующий raidz пул — последовательно заменять диски на более емкие. Думаю, что и для тривари аналогично; впрочем, утверждать не стану, т.к. под *nix с этими контроллерами не работал. Просто из общих соображений мне кажется, что если уж ZFS не позволяет добавлять диски в пул (по утверждению разработчиков, это технически сложно (было?) реализовать), но позволяет последовательно заменять их на более емкие, то триварь, которая поддерживает добавление дисков, такую замену уж точно умеет.
Соскакивать никуда у меня и в мыслях не было. Есть хотите продолжить дискуссию, я только за, в том числе (даже в особенности), если в чем-то не прав.
0
Согласен, даже шустрый zfs райдз2 начал тормозить на обычных дисках 4х1ТБайтных при 200 гб (пул был 1.7ТБ). Причем тормозить вплоть до полного зависания системы.
0
Вы юзаете ext файловые системы?! Что заставляет вас делать это когда есть xfs?! Рекаверить 16 терабайт ext это же несколько суток времени ждать!!!
+1
Лет эдак 10 назад, когда XFS еще не была в ядре и небыло даже ext3 — я ее использовал и нравилось… пока не стал очень часто сталкиваться с одним багом, который разработчики называют «фича»
— если файл открыт на запись, и падает питание, файл забивается нулями.
— если нет места на разделе — только при попытке открыть файл на запись — он обнулялся.
Я уверен что многое поменялось, многое изменили в современной XFS и многое пофиксили — но «осадок остался».
Далее рекавери на ext3/4 я проходил не раз, XFS — нет.
Иннерция если кратко. Хотя приходили мысли, и не раз, потестировать XFS снова, да вот както руки не дошли. А в таких случаях как ФС — лучше составить свое окончательное мнение.
— если файл открыт на запись, и падает питание, файл забивается нулями.
— если нет места на разделе — только при попытке открыть файл на запись — он обнулялся.
Я уверен что многое поменялось, многое изменили в современной XFS и многое пофиксили — но «осадок остался».
Далее рекавери на ext3/4 я проходил не раз, XFS — нет.
Иннерция если кратко. Хотя приходили мысли, и не раз, потестировать XFS снова, да вот както руки не дошли. А в таких случаях как ФС — лучше составить свое окончательное мнение.
+1
— если файл открыт на запись, и падает питание, файл забивается нулями.
— если нет места на разделе — только при попытке открыть файл на запись — он обнулялся.
эти баги уже давно давно исправили, а вот рекавери… как бы это сказать, на 20 терабайт xfs рекавери длится меньше минуты…
— если нет места на разделе — только при попытке открыть файл на запись — он обнулялся.
эти баги уже давно давно исправили, а вот рекавери… как бы это сказать, на 20 терабайт xfs рекавери длится меньше минуты…
+1
Не всегда, иногда идет и по часу когда что то серьезно крахнуло.
0
против нескольких дней на ext это ничто :)
0
НА ext4 вроде все тоже очень быстро, но в продакшене ещё не гонял.
0
нет, на экст4 все тоже самое, рекавери ооочень долгий (на больших массивах) по дурости завел один раз, после первого же вылета и рекавери вернулся на проверенный xfs
0
Я нашел классное решение по рекавери ext* дисков.
Открывается на винде с тупым ext драйвером, не умеющем читать даже журнал.
Копируются нужные данные, после чего винт в утиль.
То же самое с рейзером, кстати.
Рекавери пыхтело около 3х часов, полученную кашицу можно было только детям скармливать.
Слил тупым драйвером всё без проблем (ну 2 директории вылетели, но они были действительно неважные).
Открывается на винде с тупым ext драйвером, не умеющем читать даже журнал.
Копируются нужные данные, после чего винт в утиль.
То же самое с рейзером, кстати.
Рекавери пыхтело около 3х часов, полученную кашицу можно было только детям скармливать.
Слил тупым драйвером всё без проблем (ну 2 директории вылетели, но они были действительно неважные).
0
это решение если у вас есть куда скопировать скажем 16 терабайт :) ну и с lvm непонятно как под виндой быть :)
0
Если массив вышел из строя, а данные очень-очень нужны, то всё равно первое решение — собирается/поднимается новый массив, объёмом больше старого, куда, собственно, и копируется.
0
Читаете что я пишу? :) цитата: «это решение если у вас есть куда скопировать скажем 16 т» :)
+2
Читаю. Я к тому, что если данные нужны — то это «есть куда скопировать» либо есть, либо быстро откуда-нибудь да достаётся.
Всё остальное — это выиграть короткую передышку перед более грозным крахом — откуда не возвращаются.
Всё остальное — это выиграть короткую передышку перед более грозным крахом — откуда не возвращаются.
0
Бесценный опыт
0
А я тут намучился со сборкой элементарного JBOD (для хранения бэкапов).
Собираю массив, всё по науке, всё работает идеально.
Перезагружаюсь — массива нет, вместо него какой-то md127: из тех же дисков, но с другим UUID. При попытке смонтировать его ругается на отсутствие ФС.
Разбираем md127, собираем md0 автоматом — всё ОК… до следующей перезагрузки.
Что я только не делал! Я буквально бился с этой проблемой целый день, изнасиловал выдачу гугла по «mdadm md127».
Нашел десятки жалоб на аналогичную проблему, причем на всех дистрах: Ubuntu, Debian, Fedora, RHEL, Gentoo… Говорят, что такое случилось после обновления mdadm в ядре.
Но предлагаемые решения не устраняли неизвестную причину проблемы и, следовательно, были бесполезны. :(
Я уже два или три раза отчаивался, но потом возвращался к поискам решения. Под вечер моя девушка отменила свидание, и я в пресквернейшем настроении и без малейшей надежды изучал содержимое каждой ссылки гугла, уже странице на десятой…
… и нашел решение!
Нужно в mdadm.conf заменить «HOMEHOST » на «HOMEHOST vasya». То есть токен заменить на фактическое имя системы. И всё, mdadm перестает чудить!
Почему? Оказывается, на этапе загрузки initramfs система неспособна ресолвнуть токен из конфига. Из-за этого она считает диски принадлежащими к другой системе. И в соответствии с новой фичей mdadm, собирает их в массив с обратной нумерацией.
Зачем это нужно и почему массив при этом собирается битый, не понятно.
Баг на Launchpad.net.
Собираю массив, всё по науке, всё работает идеально.
Перезагружаюсь — массива нет, вместо него какой-то md127: из тех же дисков, но с другим UUID. При попытке смонтировать его ругается на отсутствие ФС.
Разбираем md127, собираем md0 автоматом — всё ОК… до следующей перезагрузки.
Что я только не делал! Я буквально бился с этой проблемой целый день, изнасиловал выдачу гугла по «mdadm md127».
Нашел десятки жалоб на аналогичную проблему, причем на всех дистрах: Ubuntu, Debian, Fedora, RHEL, Gentoo… Говорят, что такое случилось после обновления mdadm в ядре.
Но предлагаемые решения не устраняли неизвестную причину проблемы и, следовательно, были бесполезны. :(
Я уже два или три раза отчаивался, но потом возвращался к поискам решения. Под вечер моя девушка отменила свидание, и я в пресквернейшем настроении и без малейшей надежды изучал содержимое каждой ссылки гугла, уже странице на десятой…
… и нашел решение!
Нужно в mdadm.conf заменить «HOMEHOST » на «HOMEHOST vasya». То есть токен заменить на фактическое имя системы. И всё, mdadm перестает чудить!
Почему? Оказывается, на этапе загрузки initramfs система неспособна ресолвнуть токен из конфига. Из-за этого она считает диски принадлежащими к другой системе. И в соответствии с новой фичей mdadm, собирает их в массив с обратной нумерацией.
Зачем это нужно и почему массив при этом собирается битый, не понятно.
Баг на Launchpad.net.
+6
сталкивался с этим
-1
Для пересоздания через create вероятно нужен будет --assume-clean насколько я помню. Ну и версию суперблока надо использовать ту-же, именно так я потерял свой первый RAID )
0
Мы рекомендуем использовать зеркало для системы и 3 RAID6 (45HDD=3*15). Но лучше резервировать на уровне сервера, что правда сложнее и дороже, но это другая история bitblaze.ru
-7
Надеюсь, на картинке всё Optimus'ы SSD? :)
0
Почему бы и нет :-) Всего можно 6 штук под кэш поставить 2,5' Sata, если без контроллеров
-1
Простите, но вы вообще не в тему.
+4
>ранее также встал кулер на видеокарте этого же сервера
простите, а что это за мега-видеокарта на линуксовом сервере, да еще и с активным охлаждением? Для расчетов используете что ли?
простите, а что это за мега-видеокарта на линуксовом сервере, да еще и с активным охлаждением? Для расчетов используете что ли?
0
«Данные фалы содержат что-то похожее»
исправьте опечатку с ФАЛами
исправьте опечатку с ФАЛами
0
сколько времени у вас заняло восстановление (ребилд) рейда на оставшиеся два диска (на каких дисках, на какой системе, каком железе)?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программный RAID-6 под Linux: опыт восстановления массива 16Тб