Структура файлового хранилища

[Xenon]

В общем, ситуация такая.
Необходимо орагнизовать распределенное хранилище аудио файлов. Файлы заливаются пользователями. Нужно сделать что-нибудь такое, чтобы новый сервер легко бы добавлялся в текущую схему. Еще хотелось бы организовать каким-то образом резервное копирование.
Вообще пока выбор стоит между какой-нибудь кластерной файловой системой и использованием WebDav - то есть тот сервер, через который пользователи заливают файлы их же и посылает на какой-либо файловый сервер.
Бэкап, наверное, реализую перекрестный с rsync. То есть если у нас два сервера A и B, то на A его данные + бэкап B, а на B его данные + бэкап A
Я только не знаю что эффективней и удобнее. Может кто-нибудь сталкивался с подобного рода задачами? Хелп

[kawey]

Что-то так захотелось ответить, хотя я не особо в теме.

1. Если выбрать распределенную по сети файловую систему, то это будет типа RAID по сетке. Главное задать избыточность достаточную, но не громоздкую.
2. первый пункт - это безопасность данных и системы как сервиса. Что касается резервного копирования - один простенький выделенный сервер для цельного бэкапа. Для параноиков можно даже 2: один rsync-кает по ночам, другой по выходным.

Вы не уточнили имеет ли место распределение территориальное или только для ускорения дисковых операций...



[сетевое оборудование] - [демон] - [хранилище фалов]

0.999x0.999x0.98=0,978 - это 7-8 дней простоя в год


самым ненадежным будет последний. Отказ дисковой подсистемы.

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

вынося [демон] на отдельный комп, Вы прибавляете еще одну [дисковую подсистему], пускай и не так нагруженную.

распределяя [хранилище фалов] Вы выигрываете только в одном месте.

[сетевое оборудование] 0.999
|
[демон] на отельном компе 0.989
|
[ [хранилище фалов]x[хранилище фалов]x[хранилище фалов] ] 0.99

итого 0.978


Неожиданно, но получилась одна цифра. 3 параллельных блока хранения файлов - мало. надо чтобы была хотябы 0.998
тогда будет 0.986 - а это 5 дней.

Цыфры с тремя девятками - это конечно я погорячился, а расчет для параллельных блоков на глаз, формулы не помню.
потом надо учесть - в каждом хранилище свой [демон]. в общем к вопросу нужно подходить серьездно. т.к. должно быть 0.999 у всей системы.
иначе прийдется городить мега систему разервного копирования...

[kawey]

Вспомнил как делают RAID параноики

если это один комп.

берем 2, а то и 3 платы RAID5 с аппаратным XOR разных партий или разных производителей.

к каждой плате по 5 или более дисков (объем один, произодители или партии разные)

каждая плата дает нам виртуальный диск

меджу этими дискам делается SOFTWARE RAID (RAID1 - если платы 2 и RAID5 - если 3).

на это уже ложится файловая система с контролем четности и забыл как называется (когда программе сообщается, что данные с кэша сброшены на диск)

и все это ради несчастной БД на гиг или чуть больше.

[Ленивая Бестолочь]

думаю может стоит воспользоваться drbd для raid 1 по сетке.
у меня он прекрасно работает.
на xgu.ru хорошо все описано (только правда там есть вещи, которые к drbd7 относятся - это несколько устарело)

[KiWi]

http://www.lustre.org/

[Xenon]

Сначала у меня была мысль об NFS, но она достаточно странно себя ведет, когда теряется связь с одним из серверов.
Если я буду использовать кластерную fs - тот же Lustre, то что будет при падении сервера?
Просто мне понравилась идея с кросс-бэкапами и WebDav тем, что при падении сервера А мы начинаем просто работать с сервером B, чиним сервер A и достаточно простым скриптом выкачиваем все с сервера В.
Мне интересно как с такими ситуациями борятся в кластерных fs. Там создается один большой бэкап, который хранится на отдельном сервере? И если этот сервер падает, то полный пэ?

[Xenon]

Ленивая Бестолоч...
Я так понимаю если я буду использовать DRDB, то у меня проучится примерно так:
Будет кластер непосредственно основных серверов и класер вторичных серверов, которые работают под управлением DRDB? Получится один большой бэкап и одно большой файловое хранилище. В DRDB, я так понял, при падении primary мы переключаемся в secondary и тут неудобно, что у меня primary и secondary это два больших вместе взятых кластера. А если разбивать на более мелкие связки primary -> secondary, то тогда по-моему будет не очень удобно.
И каким образом с фронтэндов помещать информацию на эти серверы?

[strah]

Мне интересно как с такими ситуациями борятся в кластерных fs. Там создается один большой бэкап, который хранится на отдельном сервере? И если этот сервер падает, то полный пэ? smile.gif

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

[Ленивая Бестолочь]

ну собственно про drbd проще рассказать - что оно умеет :-)

схема primary -> secondary:
на двух хостах делается раздел, экспортируется по drbd.
один хост выбирается в качестве primary (drbdadm primary all), другой - secondary (drbdadm secondary all)
работать нужно (можно) только с primary. на нем можно создать ФС (любую - ext2-4, reiserfs, ....), подмонтировать его и все изменения
будут реплицироваться на secondary хост.
в случае выхода из строя primary хоста переводим secondary в состояние primary.

схема primary <-> primary:
на двух хостах делается раздел, экспортируется по drbd.
в конфиге вставляем опцию allow-two-primaries
на обоих хостах делаем drbdadm primary all и разворачиваем на них кластерную ФС (ocfs2, lustre, забыл третью)

если необходимо более двух хостов - это описано вот тут: http://www.drbd.org/users-guide/s-three-nodes.html

у меня везде используется по два хоста в связке, на них размещены domU xen.

[Xenon]

Ленивая Бестолоч...
Ну, про primary - primary и primary - secondary я прочитал, к тому же то же самое в MySQL, поэтому все понятно.
Тем не менее, вопрос остается.
Логично, что в таком проекте логично разбить фронтэнды и файловые серверы на две разные группы. Каждый файловый сервер я могу, в принципе реализовать в виде парных primary - secondary (кстати у secondary при сбое primary сам меняется статус?), но вопрос в том как от фронтэндов доставлять контент на файловые серверы? У меня пока в голове витает WebDav, но это не самое классное решение, которое, как мне кажется, тут можно придумать. Монтировать по NFS primary серверы как-то ... не очень. Объединять фронтэнды с primary файловыми серверами? Непонятно как, кому по сколько, ведь количество файловых серверов будет расти, нужень дешевый способ подключения.
С WebDav все сводится к установке nginx и установке моего rsync скрипта + добавлением IP серверов в моей админ панеле.

[Ленивая Бестолочь]

кстати у secondary при сбое primary сам меняется статус

в конфиге drbd описываются политики на этот счет - нужно смотреть man drbd.conf "/after-sb-"
встречал, когда это делают heartbeat-ом.

вопрос в том как от фронтэндов доставлять контент на файловые серверы

может быть iscsi, aoe?

[Xenon]

Ленивая Бестолоч...
Ага, сейчас про них почитаю.
А может сделать так:
Сделать кластер primary серверов и каждый из primary связан по drmb со своим личным secondary. Когда primary улетает secondary становится primary и вступает в кластер.
Это вообще можно реализовать?
Просто хочется, чтобы внешне все выглядело как одно большое файловое хранилище и я мог заливать, неважно каким образом, файл и он бы заливался на какой-то сервер и автоматически был бэкпился. И чтобы при отказе одного из серверов автоматически включался бэк. Это было бы идеально. Вот и думаю можно ли как-то через кластер и drmb это организовать или же кластерные FS сами как-то это умеют.

[TuLiss]

А чем плохо кстати решение iscsi + gfs ?

[Xenon]

А чем плохо кстати решение iscsi + gfs ?

ISCSI для доставки а GFS для хранения?
Ну, положим, доставлять буду посредством iSCSI, но я просто не знаю как серверы объединенные в кластер посредством GFS ведут себя при сбое. Нужно, чтобы делался сам бэкап и при падении одного из серверов включался резервный.
Я пока изучаю Lustre - там что-то подобное есть - автовосстановление. Но пока еще в полной мере не разобрался с этим вопросом.
Если расскажешь как это реализуется в GFS будут очень признателен