Pull to refresh

Comments 66

Единственное, систему, как мне кажется, проще держать на RAID1 а не RAID6.
UFO just landed and posted this here
Вопрос в том, что в случае слетания порядка дисков, выхода из строя произвольного и тд — система остаётся загрузочной.
Для установки системы под файлопомойку 1 гига за глаза, потому «экономии» никакой относительно RAID6 нет
UFO just landed and posted this here
vazir! реквестирую du -hs /* за вычетом точки монтирования непосредственно мегарейда.

По теме — система должна быть надёжной. Имея систему на 8*RAID1 мы получаем систему загружающуюся в любых позах, позволяющую воскрешать систему из любого состояния.
Имея 8*RAID6 имеем геморрой с подъёмом рейда не только основных данных, но и системы, не дай боже слетит. + Нужно альтернативные пути загрузки сервера.
Вообще, для файлопомойки я использовал загрузку по сети. Вот это — экономно, место не тратит, позволяет загрузить в любой позе, вплоть до удалённого рекавери.
А если уж система на дисках — то RAID1 более предпочтительный вариант.
UFO just landed and posted this here
UFO just landed and posted this here
Смотря где использовать — в домашней файлопомойке, да. В критически важных корпоративных серверах не стоит. Эти выводы были сделаны коллегами, которые устали менять флешки по причине надежности.
UFO just landed and posted this here
Это я про флешки писал ) А про зеркало и 6RAID это тема отдельная, на фкус и цвет, смотря кому что нужно. Спорить не буду
UFO just landed and posted this here
Да, но когда дисков много, и они однотипные, както жаль что место пропадать будет, поскольку разделы нужно делать одинакового размера (можно и не одинакового, но рейд всеравно будет выровнен по наименьшему) — потому было сделано 1Гиг под систему — остальное данные. Соответственно этот гиг при разливке на 8 дисков уровня 6 (как к меня) — превращается в 6 гиг. В случае же RAID-1 мы получаем 1 гиг. Но зато грузиться можем с любого ;)
Ну и куда эти 6 гиг?! Для файлопомойки даже гиг это слишком много.
Мой опыт говорит, что экономия места на современных HDD неоправдана — большинство дисков не способно обеспечить производительность пропорциональную ёмкости. Так что миррорить до самого «немогу».
Можно и миррорить, но согласитесь, 8Т (миррор) или 14Т (рэйд 6) большая разница для бюджетного массива. А для мирроринга — тогда уже лучше кластер делать. Заодно будет и сетевой мирроринг. Мирроринг однозначно лучше если нужна производительность.
Ну, я дома дёргался-дёргался, а потом плюнул и сделал обычные парные RAID1. Причина — чем меньше оно умничает, тем проще жить. Например, замена винтов на более ёмкие для RAID5/6 — это ад и погибель. Для raid1 эта операция на пять-семь строчек. При использовании неполностью заполненного LVM, даже без перерыва в обслуживании.
Я мигрировал 8 дисков Raid 5 на 16 дисков Raid 6 с ресайзом ext3 7Т до Ext4 14T — Могу подтвердить — несколько стремно! Но тем не менее все прошло гладко. LVM в данном случае использовать не видел смысла — поскольку ресайз RAID добавит физического места по любому, но все равно нужен ресайз EXT3/4 — который использует собственный инструментарий.
Дело не в «стрёмно», а в том, что для ресайза рейда с 2Тб на 3Тб достаточно ДВУХ дисков по 3Тб, а для любых других комбинаций, нужно закупать диски в большем объёме — это во-первых дороже, во-вторых не всегда есть столько свободных SATA'шных дырок. Финт с 2Тб raid1 в 3Tb raid1 можно провести только с одной свободной дыркой. А для рискованных чуваков — даже без оной, просто вынимаешь диск на хотплаге, тыкаешь новый, вгоняешь в рейд, после ребилда повторяешь с другим диском из массива, потом --grow, pvresize, lvresize, xfs_growfs — всех дел 2 минуты, плюс время ребилда.
К слову, с 2Тб на 3Тб можно перевести в условиях ограниченного бюджета даже с одним новым диском, если есть доп.дырка.
2Тб меняется на 3Тб, на свободном Тб создаётся раздел и зеркалится с половиной старого 2Тб диска.
Совфтовыми методами буквально можно творить чудеса (в большинстве случаев)
Что такое «зеркалится с полоиной старого 2Тб диска»? Вы не сможете иметь миррор из 2Тб и 3Тб больше 2Тб в размере.
Вот есть 2 диска: A(2T), B(2T), C(3T).
Исходные данные: A(/dev/sda,2T)+B(/dev/sdb,2T) = 2T
Меняем B на C. Получаем: A(/dev/sda, 2T)+C(/dev/sdc1, 2T)=2T
Подключаем B третьим диском, получаем:
A(/dev/sda, 2T)+C(/dev/sdc1, 2T)=2T
B(/dev/sdb, 2T)+C(/dev/sdc2, 1T)=1T
Итого: 3T зеркала.
Например, замена винтов на более ёмкие для RAID5/6 — это ад и погибель
Насколько мне известно, простая замена винтов на более емкие в софт-рейдах проблем не вызывает (во всяком случае, это верно для ZFS; в сети легко найти пошаговые инструкции). Куда сложнее добавить еще один диск в массив (желательно в онлайне). Та же ZFS вроде бы пока этого не умеет, к сожалению.

Хардварные рейд-контроллеры часто позволяют и то, и другое; например старшие 3ware точно. В процессе пересборки массива можно даже перейти с 5-го на 6-й уровень. Очень удобно. К сожалению, не могу прокомментировать, как с этим в GNU/Linux.
См выше, проблема не в процессе, а в накладных расходах.

Для «добавить ещё один диск» никаких проблем нет, LVM для этого и создавали.
Да, действительно, судя по всему LVM умеет расширять массив на большее количество дисков. Полезная фича; в свое время отчасти из-за этого пришлось отказаться от ZFS в пользу 3ware.

Что же до накладных разходов (если я вас правильно понимаю), диски можно докупать постепенно, последовательно заменяя их все в массиве, после чего пул расширится «сам» — не дорого (т.к. размазано во времени), можно обойтись без даунтайма. Конечно, если место вдруг резко заканчивается, докупить еще один диск дешевле и быстрее, но 1) рано или поздно дисков может стать слишком много, а дырок и пропускной способности мало; 2) имхо стоит следить за свободным местом и планировать/выделять средства на покупку винтов заранее.
Ой, расходов, конечно.
Вы про домашнюю систему говорите? Или про продакт-сервер? Планировать средства на расширение дискового пространства в домашнем компьютере… Нет ощущения, что в этой фразе что-то лишнее?
Скажем так: про нечто среднее. :-) Например, в моем случае это вскладчину купленный сервер для хранения «тяжелого» (и ценного) контента (lossless музыки, разнообразного софта, hd-видео, бэкапов, etc.) с количеством пользователей-«акционеров» ~4-5 человек. Это, конечно, далеко не продакшн, но место кончается катастрофически быстро, а свободные деньги на апгрейд, как водится, есть не у всех и/или не всегда. Приходится планировать.
можно подробнее — как на 3ware контроллере можно заменить один диск в RAID5 на более ёмкий?
с пошаговыми командами для tw_cli
Честно говоря, мне не доводилось настраивать эти контроллеры под *nix (отказ от ZFS как-то одновременно стал и отказом от FreeBSD/OpenSolaris в пользу Windows, которую администрировал уже не я и без tw_cli). На гугление ответа, я думаю, у нас с вами уйдет сравнимое время, не обессудьте. :-)
Насколько я помню, более ёмкий диск просто будет использоваться не весь. Но нам вендор не советовал таким образом готовится к переезду на более ёмкий сторадж :)
как бы да, но вот danfe похоже знает знает способ как заставить использовать весь диск.
хотя скорее просто вякнул и соскочил.
Простите, что отвечаю спустя несколько месяцев: не пришла нотификация (т.к. вы ответили не на мою реплику), а за тредом я не уследил.

Я нигде вроде бы не утверждал, что замена одного диска в пятом рейде (в любой его реализации) позволит сразу задействовать весь его объем; это, разумеется, не так.

Я имел ввиду, что по крайней мере для ZFS единственным способом расширить существующий raidz пул — последовательно заменять диски на более емкие. Думаю, что и для тривари аналогично; впрочем, утверждать не стану, т.к. под *nix с этими контроллерами не работал. Просто из общих соображений мне кажется, что если уж ZFS не позволяет добавлять диски в пул (по утверждению разработчиков, это технически сложно (было?) реализовать), но позволяет последовательно заменять их на более емкие, то триварь, которая поддерживает добавление дисков, такую замену уж точно умеет.

Соскакивать никуда у меня и в мыслях не было. Есть хотите продолжить дискуссию, я только за, в том числе (даже в особенности), если в чем-то не прав.
Согласен, даже шустрый zfs райдз2 начал тормозить на обычных дисках 4х1ТБайтных при 200 гб (пул был 1.7ТБ). Причем тормозить вплоть до полного зависания системы.
Вы юзаете ext файловые системы?! Что заставляет вас делать это когда есть xfs?! Рекаверить 16 терабайт ext это же несколько суток времени ждать!!!
Лет эдак 10 назад, когда XFS еще не была в ядре и небыло даже ext3 — я ее использовал и нравилось… пока не стал очень часто сталкиваться с одним багом, который разработчики называют «фича»
— если файл открыт на запись, и падает питание, файл забивается нулями.
— если нет места на разделе — только при попытке открыть файл на запись — он обнулялся.

Я уверен что многое поменялось, многое изменили в современной XFS и многое пофиксили — но «осадок остался».
Далее рекавери на ext3/4 я проходил не раз, XFS — нет.
Иннерция если кратко. Хотя приходили мысли, и не раз, потестировать XFS снова, да вот както руки не дошли. А в таких случаях как ФС — лучше составить свое окончательное мнение.
— если файл открыт на запись, и падает питание, файл забивается нулями.
— если нет места на разделе — только при попытке открыть файл на запись — он обнулялся.

эти баги уже давно давно исправили, а вот рекавери… как бы это сказать, на 20 терабайт xfs рекавери длится меньше минуты…
Не всегда, иногда идет и по часу когда что то серьезно крахнуло.
против нескольких дней на ext это ничто :)
НА ext4 вроде все тоже очень быстро, но в продакшене ещё не гонял.
нет, на экст4 все тоже самое, рекавери ооочень долгий (на больших массивах) по дурости завел один раз, после первого же вылета и рекавери вернулся на проверенный xfs
Я нашел классное решение по рекавери ext* дисков.
Открывается на винде с тупым ext драйвером, не умеющем читать даже журнал.
Копируются нужные данные, после чего винт в утиль.

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

Слил тупым драйвером всё без проблем (ну 2 директории вылетели, но они были действительно неважные).
это решение если у вас есть куда скопировать скажем 16 терабайт :) ну и с lvm непонятно как под виндой быть :)
Если массив вышел из строя, а данные очень-очень нужны, то всё равно первое решение — собирается/поднимается новый массив, объёмом больше старого, куда, собственно, и копируется.
Читаете что я пишу? :) цитата: «это решение если у вас есть куда скопировать скажем 16 т» :)
Читаю. Я к тому, что если данные нужны — то это «есть куда скопировать» либо есть, либо быстро откуда-нибудь да достаётся.
Всё остальное — это выиграть короткую передышку перед более грозным крахом — откуда не возвращаются.
Лишние 16Т быстро достаётся и разворачивается только у рокфеллера, кроме того были бы лишние, то не заводили бы столь ненадежный массив, который упал :)
А я тут намучился со сборкой элементарного JBOD (для хранения бэкапов).

Собираю массив, всё по науке, всё работает идеально.

Перезагружаюсь — массива нет, вместо него какой-то md127: из тех же дисков, но с другим UUID. При попытке смонтировать его ругается на отсутствие ФС.

Разбираем md127, собираем md0 автоматом — всё ОК… до следующей перезагрузки.

Что я только не делал! Я буквально бился с этой проблемой целый день, изнасиловал выдачу гугла по «mdadm md127».

Нашел десятки жалоб на аналогичную проблему, причем на всех дистрах: Ubuntu, Debian, Fedora, RHEL, Gentoo… Говорят, что такое случилось после обновления mdadm в ядре.

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

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

… и нашел решение!

Нужно в mdadm.conf заменить «HOMEHOST » на «HOMEHOST vasya». То есть токен заменить на фактическое имя системы. И всё, mdadm перестает чудить!

Почему? Оказывается, на этапе загрузки initramfs система неспособна ресолвнуть токен из конфига. Из-за этого она считает диски принадлежащими к другой системе. И в соответствии с новой фичей mdadm, собирает их в массив с обратной нумерацией.

Зачем это нужно и почему массив при этом собирается битый, не понятно.

Баг на Launchpad.net.
* заменить «HOMEHOST <system>» на «HOMEHOST vasya»
Для пересоздания через create вероятно нужен будет --assume-clean насколько я помню. Ну и версию суперблока надо использовать ту-же, именно так я потерял свой первый RAID )
Мы рекомендуем использовать зеркало для системы и 3 RAID6 (45HDD=3*15). Но лучше резервировать на уровне сервера, что правда сложнее и дороже, но это другая история bitblaze.ru image
Надеюсь, на картинке всё Optimus'ы SSD? :)
Почему бы и нет :-) Всего можно 6 штук под кэш поставить 2,5' Sata, если без контроллеров
Почками принимаете, или только квартирами в москве?

п.с.: с курил сдача найдётся?
Тут даже в рабство отдаваться не надо, есть клиенты у которых он находится дома (правда кэш на ссд они не используют) и у них, вроде, почки на месте, и квартиры есть :-)
Простите, но вы вообще не в тему.
Да, немного отвлеклись, просто хотелось рассказать как лучше сделать, чтобы было надежнее, именно для систем хранения
Давайте уж по честному — вам просто захотелось тупо прорекламироваться. Тупо — получилось, насчёт прорекламироваться не знаю.
>ранее также встал кулер на видеокарте этого же сервера

простите, а что это за мега-видеокарта на линуксовом сервере, да еще и с активным охлаждением? Для расчетов используете что ли?
«Данные фалы содержат что-то похожее»

исправьте опечатку с ФАЛами
сколько времени у вас заняло восстановление (ребилд) рейда на оставшиеся два диска (на каких дисках, на какой системе, каком железе)?
Около суток. P Dual Core
Sign up to leave a comment.

Articles

Change theme settings