Всем привет! У меня возник очень интересный вопрос: есть свой сервак, ось Debian, но с одним хардом. Нужно поставить еще два харда и объединить их в одну файловую систему или каталог... Мне нужно увеличить место на серваке но чтобы это выглядело как один хард. Места не хватает, а раскидать файлы и скрипты сайта по разным хардам просто нельзя, сам сайт требует одного катклока. Очень нужна помощь!
LinuxForum.Fans
Объединение нескольких хардов в одну файловую систему (каталог)
Автор: djamen
30 сообщений
7824 просмотров
LVM
Да то что нужно, посмотрим. Спс.
Скажите на Debian это можно сделать без переустановки оси, повреждений данных? Работоспособность останется прежней?
Всё будет хорошо, если вы прочтёте изначально документацию
Например:
http://www.ibm.com/developerworks/linux/library/l-lvm/?dwzone=linux
Всё будет хорошо, если вы прочтёте изначально документацию
Например:
http://www.ibm.com/developerworks/linux/library/l-lvm/?dwzone=linux
На данный момент добрался вот до эго:Управление логическими томами
Создание томов, управление томами, мгновенные резервные копии и другие возможности LVM2
http://www.ibm.com/developerworks/ru/library/l-lvm2/
Надеюсь это то что нужно.
LVM
Там есть только одна маленькая проблема - если умирает один из физических дисков, объединенных в LVM, то приятного мало будет. Конечно, регулярные бэкапы - наше всё, но...
Я бы на такое объединение не велся. Оно нужно только для одной цели - иметь возможность записать файл больший, чем размер одного диска. А такие файлы у нас есть?
Если уж и надо объединять в один LVM-том, то под этим томом должно быть RAID-зеркало.
По мне - гораздо практичнее монтировать дополнительные диски в /mnt или куда удобнее и на этих смонтированных дисках и размещать свои данные. Тогда выход из строя одного диска не повлияет на работоспособность оставшейся системы.
Что-то никто про aufs не сказал.
aufs - файловая система, реализующая каскадно-объединённое монтирование для файловых систем Linux. Помимо унаследованного от UnionFS функционала здесь реализованы RW-ветки и балансировка записи, что идеально подходит для решения поставленной задачи.
Но aufs2 не включена в mainline-ядро.
Установка:
text
aptitude install aufs-toolsДопустим, есть два смонтированных раздела:
старый /media/old
и новый /media/new
чтобы эти два раздела были видимы как один, необходимо выполнить:
text
mount -t aufs none /media/storage -o br:/media/old=rw:/media/new=rw,create=mfs,sumВ /etc/fstab такая запись должна иметь вид:
text
none /media/storage aufs br:/media/torrents=rw:/media/new_storage=rw,create=mfs,sum 0 0раскидать файлы и скрипты сайта по разным хардам просто нельзя, сам сайт требует одного каталога.
Не совсем понятно - сайт требует размещения десятков гигабайт данных в одном "плоском" каталоге? Кучей? Без возможности иметь там подкаталоги? В топку такой сайт.
Или введение там подкаталогов допустимо? Тогда что мешает смонтировать дополнительный диск (и не один) прямо в нужное место и увеличить этим емкость данных подкаталогов для размещения данных? Или смонтировать его в стандартный /mnt и сделать на него из нужного места обычные симлинки?
Не совсем понятно - сайт требует размещения десятков гигабайт данных в одном "плоском" каталоге? Кучей? Без возможности иметь там подкаталоги? В топку такой сайт.
ну почему-же? очень удобно, если файлы большие. В этом огромном каталоге хранятся файлы переименованные (что-бы не было конфликтов), а пользователь естественно видит виртуальную систему каталогов. Плюс в гибкости и лёгкости изменения виртуальной ФС, причём даже динамически. Можно сделать например виртуальную папку "популярные файлы". С каталогом это получается не очень хорошо. Например проблемы возникнут при изготовлении бекапов.
ну почему-же? очень удобно, если файлы большие.
Такие большие файлы на сайте - по моему - это фильмы. Вряд ли будет хорошим тоном валить их все в одну кучу. Так как фильмо-сайты помимо самого фильма дают еще и дополнительную по нему информацию, например, обложку диска и еще что-нибудь. То есть - естественно раскидывать такие "фильмы" по своим уникально поименованным каталогам. А что мешает вместо такого "физического" каталога с фильмом иметь линк на каталог с этим фильмом на ином диске?
Плюс в гибкости и лёгкости изменения виртуальной ФС, причём даже динамически. Можно сделать например виртуальную папку "популярные файлы". С каталогом это получается не очень хорошо. Например проблемы возникнут при изготовлении бекапов.
По моему - тоже не менее гибко и нет проблем настраивать те же "популярные файлы"....
Я дома в медиаплейере так и делаю (на одном диске, второй не подключить) - есть общая куча, а рядом организован каталог (в библиотечном понимании), где эти фильмы линками сгруппированы по артистам, по жанрам, по авторам... А что мешает слинковывать в свой каталог файлы (директории) находящиеся на разных дисках?
Чем и хорош юникс - одну задачу можно решить тысячью способов.
И все равно - пребываю в убеждении, что большая файловая система хороша для хранения таких же больших файлов. Её стоит делать, если имеешь диски по 500 гигабайт, а файлы данных по терабайту. Вот тогда, действительно, надо диски склеивать. А если этого нет, то зачем городить лишнюю сущность, когда старые добрые линки (и mount в нужное место) решат нашу задачу?
Да и проблем с бакапами каталоговых структур я не вижу никаких.
Такие большие файлы на сайте - по моему - это фильмы. Вряд ли будет хорошим тоном валить их все в одну кучу. Так как фильмо-сайты помимо самого фильма дают еще и дополнительную по нему информацию, например, обложку диска и еще что-нибудь. То есть - естественно раскидывать такие "фильмы" по своим уникально поименованным каталогам. А что мешает вместо такого "физического" каталога с фильмом иметь линк на каталог с этим фильмом на ином диске?
эх... Вы таки меня не поняли. Я как раз и предлагаю хранить весь "мусор" (описания, обложки, и прочее, вплоть до имени файла) в базе данных. Тогда с этой инфой будет очень удобно работать. Например, если у вас описание к файлу лежит в подкаталоге рядом с фильмом, то для того, что-бы выполнить запрос "покажи мне фильмы с 1990го, по 2003й, жанра 'ужасы', и отсортируй по времени доступа (в конце те, что я недавно смотрел", вам придётся
1. написать небольшой скриптик
2. распарсить все описания
Ну а мне достаточно будет одного запроса к БД. Естественно, СУБД можно и нужно обернуть в красивую обёртку, что-бы тыкать мышкой. Сами фильмы (файлы) могут при этом лежать в одном каталоге на диске. И дробить этот каталог нет никакого смысла. Именно так, видимо, и организован сайт ТС'а.
Да и проблем с бакапами каталоговых структур я не вижу никаких.
когда у вас одна структура, проблем действительно нет. Но если вы делаете несколько динамических структур, к пример вы можете захотеть сделать подборку мультфильмов, но при этом, основная база у вас подобрана по года, то у вас начинаются проблемы. ФС конечно позволяет хранить файл в двух местах. Но об этом ещё и нужно рассказать программе бекапа. Как она отличит виртуальную подборку мультиков (которую бекапить не нужно), от ссылки на второй диск, которую бекапить нужно?
Про базу данных изначально у ТС речи не было. Безусловно держать информацию в ней гораздо удобнее, чем в файловой системе. Здесь спорить не буду. Однако - не переубедил. Так как и СУБД прекрасно позволяет держать "фильмы" в разных местах. Ведь в неё же будем записывать ссылки на эти "фильмы". А ссылка может показывать куда угодно, хоть на внешний сервер. Что мешает?
Так что применение СУБД не есть аргумент в пользу большой файловой системы. Более того, это аргумент в пользу "распределенной" ФС, что где бы ни держали наши файлы - все равно к ним есть доступ через единую точку доступа, через СУБД.
И с архивированием не вижу проблем. Просто надо бэкапить оригинальные файлы отдельно, а систему ссылок на них (свои виртуальные каталоги) отдельно. Разве сложно отличить линк (сделанный по ln -s) на объект от оригинала?
text
$ll | grep -v '^l'
$ll | grep '^l'По первой строке кладем файлы в архив, а по второй - формируем скрипт, который нам все линки восстановит. В чем проблема?
Про базу данных изначально у ТС речи не было. Безусловно держать информацию в ней гораздо удобнее, чем в файловой системе. Здесь спорить не буду. Однако - не переубедил. Так как и СУБД прекрасно позволяет держать "фильмы" в разных местах. Ведь в неё же будем записывать ссылки на эти "фильмы". А ссылка может показывать куда угодно, хоть на внешний сервер. Что мешает?
Так что применение СУБД не есть аргумент в пользу большой файловой системы. Более того, это аргумент в пользу "распределенной" ФС, что где бы ни держали наши файлы - все равно к ним есть доступ через единую точку доступа, через СУБД.
С этим я конечно не могу не согласится. Однако, возможно создатель движка и не преследовал цель в распределённой ФС, и всё свалил в один каталог. Конечно, ничего не стОит ему ввести ещё одно поле в таблице, которое указывает на этот самый каталог, если их больше одного. Очевидно, что модифицировать код таким образом ТС почему--то не может.
сам сайт требует одного катклока.
Ну а про СУБД я конечно сам догадался, используя skill telepat :P
Просто IRL приходилось с таким сталкиваться.
И с архивированием не вижу проблем. Просто надо бэкапить оригинальные файлы отдельно, а систему ссылок на них (свои виртуальные каталоги) отдельно. Разве сложно отличить линк (сделанный по ln -s) на объект от оригинала?
симлинк конечно не сложно. Но иногда хардлинки куда как удобнее. А вот они неразличимы принципиально. Единственное, что можно придумать - это смотреть inode, и не бекапить уже забекапленное. Конечно, в самописном скрипте можно и это сделать, но... Это, согласитесь - проблема (решаемая конечно).
И да, грипать как раз не надо. Уже давно придумали опции -H, -L, и -P (для find, для других утилит иногда по другому названо).
И да, грипать как раз не надо. Уже давно придумали опции -H, -L, и -P (для find, для других утилит иногда по другому названо).
Да это то известно. У нас полный консенсус выходит :-). Давай завязывать мозги топикстартеру умными мыслями полоскать. :rolleyes:
Да это то известно.
ну.. ИМХО не всем оно известно.
Давай завязывать мозги топикстартеру умными мыслями полоскать.
ОК. посмотрим, что ответят.
[quote=djamen]раскидать файлы и скрипты сайта по разным хардам просто нельзя, сам сайт требует одного каталога.
Не совсем понятно - сайт требует размещения десятков гигабайт данных в одном "плоском" каталоге? Кучей? Без возможности иметь там подкаталоги? В топку такой сайт.
Или введение там подкаталогов допустимо? Тогда что мешает смонтировать дополнительный диск (и не один) прямо в нужное место и увеличить этим емкость данных подкаталогов для размещения данных? Или смонтировать его в стандартный /mnt и сделать на него из нужного места обычные симлинки?[/quote]
Смотрите что бы было понятно. На сайте очень много музыки- по жанрам(категориям). Сам музыкальный компонент проигрывает музыкальные файлы из папки которая должна лежать в корне сайта...
Есть много видео файлов загруженные самим и пользователями, этот компонент тоже работает из корня сайта. И выносить аудио и видео файлы, за корень сайта не получается. Если смогу переадресовать загрузку файлов на другие харды, то проблем не будет. Но не просто это все...
И выносить аудио и видео файлы, за корень сайта не получается. Если смогу переадресовать загрузку файлов на другие харды, то проблем не будет. Но не просто это все...
а в чём проблема? ИМХО вам проще поправить движок, чем мучится с такой кривой архитектурой.
Да если существует такая возможность как смонтировать свободные харды в указанное место(у меня 3 папки), то помогите грамотно подойти к этому делу. Было бы проще нарастить объем нужных папок!
Войдите или зарегистрируйтесь, чтобы ответить.
