URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 88074
[ Назад ]

Исходное сообщение
"Требуется решение по синхронизации данных"

Отправлено minidc , 05-Фев-10 12:35 
Имеется сервер 1, на нем поднят дисковый программный райд на 8Тб, на этот сервер несколько служб ссыпают файлы отчетов по NFS протоколу. Постоянно. И хранить их нужно тоже постоянно (по крайней мере в обозримом будущем).

Структура для системы хранения такая: в каталоге 256 подкаталогов, в кажом еще по 256 подкаталогов, в них лежат файлы. Таких структур у меня 5. Общее количество файлов в каждой структуре в районе миллиона и прибавляется по 150000 каждый месяц.

Теперь момент номер два. Эти файлы только создаются, потом читаются. Т.е. они не могут быть изменены. Файл создается, потом иногда требуется.

Я решил организовать такую схему: поднимается второй сервер с таким же объемом места. На него периодами (я думал делать раз в час) делается rsync всего хозяйства с первого сервера. В случает отказа или обслуживания первого сервера, все переключается на второй сервер и работает с ним. Сервера соединены между собой гигабитным линком. Потеря данных в течении часа не критична.

Первоначальная синхронизация заняла трое суток.

И дальнейшая синхронизация длится около суток. МНе надо как - то ускорит это процесс. А вот как - я не знаю. Т.е. реально у меня файлы только добавляются. Но, ПО котороый работает с хранилищами не может писать сразу в 2 места.

Сразу скажу, пробовал связку drbd+OCFS2, но, по неизвестной мне причине происходили постоянные рассинхронизации.

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

Как вообще специалисты решают такие задачи?


Содержание

Сообщения в этом обсуждении
"Требуется решение по синхронизации данных"
Отправлено AlanMakoev , 05-Фев-10 13:06 
GlusterFS в режиме репликации?
Я в продакшене не юзал, только поигрался - вроде синхронизирует нормально. Правда, большие объёмы не пробовал.
Если решите попробовать - учтите один "нюанс" - писать надо в каталог, который смонтирован на Gluster-клиенте (в том числе и на мастере надо смонтировать через Gluster-клиента его собственный каталог, который реально лежит у него на диске).

"Требуется решение по синхронизации данных"
Отправлено minidc , 05-Фев-10 17:41 
>GlusterFS в режиме репликации?
>Я в продакшене не юзал, только поигрался - вроде синхронизирует нормально. Правда,
>большие объёмы не пробовал.
>Если решите попробовать - учтите один "нюанс" - писать надо в каталог,
>который смонтирован на Gluster-клиенте (в том числе и на мастере надо
>смонтировать через Gluster-клиента его собственный каталог, который реально лежит у него
>на диске).

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


"Требуется решение по синхронизации данных"
Отправлено QuAzI , 05-Фев-10 14:38 
Если дальнейшая синхронизация длится около суток, то вы скорее всего что-то неправильно делаете. Думается мне, вы проверяете для каждого файла контрольную сумму, что при условии что файл никогда не меняется, лишнее, достаточно по умолчанию - дату и размер.
Отключить сжатие передаваемых данных, раз они в локалке. Вообще было бы здорово увидеть настройку сервера и параметры запуска синхронизации.

"Требуется решение по синхронизации данных"
Отправлено minidc , 05-Фев-10 17:40 
>Если дальнейшая синхронизация длится около суток, то вы скорее всего что-то неправильно
>делаете. Думается мне, вы проверяете для каждого файла контрольную сумму, что
>при условии что файл никогда не меняется, лишнее, достаточно по умолчанию
>- дату и размер.
>Отключить сжатие передаваемых данных, раз они в локалке. Вообще было бы здорово
>увидеть настройку сервера и параметры запуска синхронизации.

Сжатия данных нет.
Данные синхронизируются по NFS примонтированной папке.

rsync -r -l -x  --ignore-existing --delete /home/storage1/www/vhosts/  /1/www/vhosts/


"Требуется решение по синхронизации данных"
Отправлено bob253 , 06-Фев-10 12:17 
>Имеется сервер 1, на нем поднят дисковый программный райд на 8Тб, на
>этот сервер несколько служб ссыпают файлы отчетов по NFS протоколу.

Отлично, известная штука

>Постоянно.
>И хранить их нужно тоже постоянно (по крайней мере в обозримом
>будущем).
>

т.е. это "любительство" или это все-таки нормальный продакшн ? Насколько большие потери если это все навернется безвозвратно ?


>Структура для системы хранения такая: в каталоге 256 подкаталогов, в кажом еще
>по 256 подкаталогов, в них лежат файлы. Таких структур у меня
>5. Общее количество файлов в каждой структуре в районе миллиона и
>прибавляется по 150000 каждый месяц.

ладно, может быть

>
>Теперь момент номер два. Эти файлы только создаются, потом читаются. Т.е. они
>не могут быть изменены. Файл создается, потом иногда требуется.
>

т.е. это WORM ? Write Once Read Many ?

>[оверквотинг удален]
>у меня файлы только добавляются. Но, ПО котороый работает с хранилищами
>не может писать сразу в 2 места.
>
>
>Ищу решение, как можно не в реальном (не обязательно а реальном) времение,
>но достаточно быстро иметь максимально синхронные копии большого количестсва мелких файлов
>с системой каталогов которую я описал выше с одного сервера на
>другой.
>
>Как вообще специалисты решают такие задачи?

На железе

EMC Celerra - c Retension Policy. Протоколы - CIFS, NFS, FTP, iSCSI. Для NX-серии - до 60 дисков.
EMC Centerra - а эта вообще на WORM заточена

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


"Требуется решение по синхронизации данных"
Отправлено Читатель , 07-Фев-10 15:01 
>>Постоянно.
>>И хранить их нужно тоже постоянно (по крайней мере в обозримом
>>будущем).
>>
>
>т.е. это "любительство" или это все-таки нормальный продакшн ? Насколько большие потери
>если это все навернется безвозвратно ?

Оценить потери в деньгах я не могу, я сисадмин, данными не владею, думаю что будут, но не фатальные.
Это не любительство, это надо не дома а в конторе, но требуется решение для бедных. Реально денег нет.

>т.е. это WORM ? Write Once Read Many ?
>

Да.

>
>На железе
>
>EMC Celerra - c Retension Policy. Протоколы - CIFS, NFS, FTP, iSCSI.
>Для NX-серии - до 60 дисков.
>EMC Centerra - а эта вообще на WORM заточена

Дорого.

>
>Все остальное - голимое любительство, несовместимое с понятием Production в которое включены
>постоянные поступления на затраты на оборудование, специалистов и обучение этих самых
>специалистов с одной стороны, а со второй - обязательство неуничтожения данных
>(непрерывность бизнеса).

Допускаю, но нужно  таком случае "надежное любительское решение". Нету денег. Потому и райд софтовый.


"Требуется решение по синхронизации данных"
Отправлено iasb , 07-Фев-10 17:55 
>Допускаю, но нужно  таком случае "надежное любительское решение". Нету денег. Потому
>и райд софтовый.

посмотри HP LeftHand. Virtual SAN. На ОФ сайте есть вмварные образы.


"Требуется решение по синхронизации данных"
Отправлено ШлМимо , 24-Фев-10 22:40 
я не знаю как это в продакшене, но вообще есть
http://ru.wikipedia.org/wiki/Inotify
обрати внимание на IN_CLOSE_WRITE и ставь в очередь на копирование сразу по его получению. имхо дёшего и сердито, надеюсь идея поможет :)

"Требуется решение по синхронизации данных"
Отправлено minidc , 27-Фев-10 17:44 
>я не знаю как это в продакшене, но вообще есть
>http://ru.wikipedia.org/wiki/Inotify
>обрати внимание на IN_CLOSE_WRITE и ставь в очередь на копирование сразу по
>его получению. имхо дёшего и сердито, надеюсь идея поможет :)

Пробовал, но там структура каталогов такая - что замучаюсь с этим


поставил glusterfs вполне доволен.