Pull to refresh

Comments 30

Насколько я слышал последнее обсуждение этих систем, все они рано или поздно показывали дырявость абстракции в самый неудачный момент. Подробностей, к сожалению, не помню.
Мне кажется для торентопомойки это абсолютно не критично.
Ну а мне всё же кажется, что лучше пересилить себя и сделать чистенький LVM)) А ещё лучше — RAID через mdadm, тогда даже избыточность для сохранности данных легко вставить. Всё же приведённые решения — откровенные костыли, и не важно, для чего они используются ;)
У LVM есть минусы: при отвале одного из дисков сносит всю файловую систему целиком, что может быть болезненным даже при не очень критичных данных. Одно дело восстанавливать информацию с одного погибшего диска и другое — с четырёх. У RAID тоже есть минусы: во-первых, он создаёт иллюзию надёжности и про резервное копирование в итоге часто забывают (к тому же тратится место), во-вторых, его не очень удобно расширять. Я, например, не знаю, как перенести массив с дисков по 1,5 ТБ на 2 ТБ, заменяя диски по очереди, а не сразу.
У LVM да, есть минусы. А RAID не создаёт иллюзию, он действительно надежен. Чем вам например 10 RAID не угодил, или скажем RAID6. Программный RAID — это просто простой способ делать ваши бекапы. Ну а расширение… Да, нужны диски одинакового объёма или же сразу полная замена массива. Не считаю это минусом, поскольку реально это не вредит ничему.
RAID любого уровня может спасти только от одной угрозы — физического выхода из строя носителя из строя. А с информацией, между тем, может случиться много чего занятного: выход из строя файловой системы, ошибка ПО или пользователя, приводящая к повреждению данных, диверсия, наконец. Причём в сумме это может оказаться гораздо более вероятным, чем подыхание диска. Таким образом фраза «программный RAID — это просто простой способ делать ваши бекапы» ­— не более чем миф. Если у меня будет два жёстких диска и нужно будет сделать из них максимально надёжную систему, я не стану делать из них RAID1, а поставлю один диск и буду время от времени подключать второй, чтобы скинуть на него бэкапы. А до рейда дело дойдёт, когда 1) появится больше носителей и 2) потребуется кроме надёжности обеспечить ещё и высокую доступность.
Я не страдаю паранойей, поэтому считаю что правильно организованное хранилище на рейдах не требует в основном бекапа))) Если у вас конечно не информация, представляющая гостайну. ФС восстанавливается на раз при любых ошибках (кроме откровенных диверсий, ага), привет ext3/4, ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно, а потерять пару текущих файлов из-за ошибки ПО, с ним работающего — это не страшно и от этого бекапы не спасут. РЕально конечно надо делать бекапы важных данных, а рейд скорее использовать для отказоустойчивости системы, но фанатизм в бекапах при использовании рейда проявлять явно не стоит. То есть если рассматривать организацию отказоустойчивого хранилища, то я бы начал ровно наоборот: сначала рейд, а потом если получится отдельное место для бекапа. Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад раз в 24 часа снимающимися, это чтобы защититься от случайного удаления файла пользователем вместо инкрементальных бекапов. Хотя это уменьшит скорость записи сильно, но обычно для сетевых хранилищ некритично.
> Я не страдаю паранойей, поэтому считаю что правильно организованное
> хранилище на рейдах не требует в основном бекапа

Зеркальный рэйд спасает от гибели диска, но не спасает от случайного или намеренного удаления кем-то важных данных, ведь это удаление сразу будет отзеркалено на другие диски. Именно для этого и нужен регулярный бэкап.
Это правда, я для этого использую LVM со снапшотами на трое суток назад))) Просто началось всё с иллюзии надёжности RAID. Он не создаёт иллюзию, он действительно надёжен, особенно в рамках приведённой задачи. Если вам нужны бекапы в целях защиты от шаловливых ручек — то тут уже ничего не попишешь. Часто на это забивают, зачастую кстати обоснованно. Зачем например бекап серверов без пользовательских данных — непонятно. А вот рейд на них может спасти от более реальных опасностей, как то выход диска из строя например.
> Я не страдаю паранойей
А стоило бы.
> ФС восстанавливается на раз при любых ошибках
Сама ФС, скорее всего, восстановится (хотя сталкивался и с убитой напрочь ext3), только базе, которая в этот момент меняла структуру таблиц, от этого лучше не станет, если не включать журналирование данных.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
Чёрт, рано отправилось.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
Ни разу не сталкивались с DELETE FROM xxx без WHERE, случайно попавшим в продакшн, поскольку программер забыл проверить дописываемую фичу? Или с утечкой пароля, из-за которой кто-то нехороший поправил ненравящиеся ему данные? Поздравляю.
> но фанатизм в бекапах при использовании рейда проявлять явно не стоит
А нафига нужны два экземпляра неправильных данных?
> Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад
Вот это уже ближе к истине.
> Зачем например бекап серверов без пользовательских данных — непонятно.
А зачем нужны сервера без пользовательских данных?
Я тоже не страдал, теперь я в категории людей кто «уже делает бэкапы», после того как контроллер перестал видеть оба винта в массиве. К счастью все решилось, но несколько неприятных часов я пережил. :-D
Если вы про h3, то спасибо, поправил.
UFO just landed and posted this here
Узнать можно, хоть и не напрямую. Исходные точки монтирования вполне доступны для чтения и записи.
Для справки: в Gentoo тоже есть sys-fs/aufs2 :)
По поводу Дебиана: aufs-tools есть и в тестинге и в анстейбле. Модуль ядра также есть в 2.6.32-5, которая в тестинге по умолчанию. А вот в 2.6.34 из экспериментальной ветки уже нет.
По задаче: ещё есть btrfs, которая позволяет подключить второй том к уже существующей ФС и даже распределить данные из первого поровну по обоим. Правда, он ещё сыроват и порою падает с кернель упсами.
как они работают с нфс? я давненько пробовал mhddfs экспортить но работало оно с ошибками, т.е. файлы прерывались в рандомные моменты. mhddfs в свою очередь еще и делает неплохую нагрузку на систему.
mhddfs не удалось завести с nfs. aufs лично я в такой связке не пробовал.
Подтверждаю, mhddfs не работает с nfs. Пришлось прописать в установленной самбе
UFO just landed and posted this here
в Ubuntu (так как LiveCD Ubuntu построен с применением этой ФС);

В каком месте она там? Вроде бы squashfs всегда использовался.
Сначала монтируется RO squashfs, а поверх неё —RW aufs.
На самом деле очень большая проблема получить хранилище устойчивое к вылету одного диска с возможностью простой замены/добавления дисков. Самый простой вариант как мне кажется — это отказаться от RAID в пользу объединения через LVM и rsync критичных данных на отдельный хдд.
Я примерно к такому же схеме пришёл. Но некритичные данные терять тоже не очень хотелось бы.
Или разбивать диски на меньшие разделы, ставить их в RAID а потом на него еще LVM. Я сам этого не делаю, так как не нужно, но встречал много руководств, когда учился админинстрировать mdadm.
что только не придумают, вместо того чтобы пользоваться одним целым разделом на весь диск.
Стоит вспомнить, что ZFS лишена описанных в статье сложностей в работе по-умолчанию.
Only those users with full accounts are able to leave comments. Log in, please.