посоветуйте тулзу (распределённую ФС?)
кучу мелких файловкуча - это сколько? на каждом узле надо точную реплику что-ли?
а то может тебе rsync сойдет
если серьезно, то glusterfs есть, посмотри её
раз требований к скорости нет то — NFS
кластерные файловые системы типа glusterfs.
настроить так чтоб на каждом узле была полная копия остальных узлов.
появляться будет сразу. никаких рсинков по крону.
обычный диск, но только информация едентична на всех серверах.
настроить так чтоб на каждом узле была полная копия остальных узлов.
появляться будет сразу. никаких рсинков по крону.
обычный диск, но только информация едентична на всех серверах.
Опыта с кластерными ФС не имею, поэтому для подобной задачи прикрутил бы либо unison либо owncloud.
~100 000 шт по 0.2-2мб
да, точную реплику.
спасибо, ща глану
да, точную реплику.
спасибо, ща глану
скорость чтения важна. записи - по боку.
так что nfs это не про то.
так что nfs это не про то.
если данные потом не меняются а на время репликации покласть то лучше не использовать распределённые фс — только получишь лишний оверхэд на ревалидации кэшей, управлении лизами и прочее.
из гита можно построить довольно эффективную систему такого деплоя, только нужно объяснить ему не перепроверять статус существующих файлов а только вываливать новые.
из гита можно построить довольно эффективную систему такого деплоя, только нужно объяснить ему не перепроверять статус существующих файлов а только вываливать новые.
репозитории - это интересное решение. но это подразумевает
1) наличие мастера и необходимость что-то делать в случае его выбега, что ломает систему кластеризации
2) надо будет писать демона, который будет долбать обновления (что в принципе ерунда)
3) и обёртку для этого демона с системой мониторинга, чтобы видеть, что обновление дошло до всех и ни один из них не сдох
1) наличие мастера и необходимость что-то делать в случае его выбега, что ломает систему кластеризации
2) надо будет писать демона, который будет долбать обновления (что в принципе ерунда)
3) и обёртку для этого демона с системой мониторинга, чтобы видеть, что обновление дошло до всех и ни один из них не сдох
В случае с гитом у тебя будет полная копия на каждой машине. Обновление заключается в совершении коммита на любой машине и git push на все остальные (можно веером или деревом) а там в post-update хуке checkout свежего бахала. Только надо всё заранее продумать, а то можно получить интересные грабли в случае silent data corruption. Кажется недавно кде-шники получили интересный опыт на своём гитовом кластере.
1) наличие мастера и необходимость что-то делать в случае его выбега, что ломает систему кластеризациибез мастера есть ещё tahoe lafs
В случае с гитом у тебя будет полная копия на каждой машине.уж реально лучше glusterfs
а простое облако не устраивает чем-то?
и плюсуюсь к гиту, он няшка
и плюсуюсь к гиту, он няшка
Только надо всё заранее продумать, а то можно получить интересные грабли в случае silent data corruption. Кажется недавно кде-шники получили интересный опыт на своём гитовом кластере.Мне одному кажется, что они сломали свой микроскоп забиванием гвоздей?
Мне одному кажется, что они сломали свой микроскоп забиванием гвоздей?Неа, проблема что гит по дефолту не всегда перепроверяет консиснетность данных. В результате можно упустить
silent data corruption. И на самом деле мало кто заранее думает о такого рода проблемах.
http://www.opennet.ru/opennews/art.shtml?num=36491
Неа, проблема что гит по дефолту не всегда перепроверяет консиснетность данных.Не в дефолте дело. Они обновления выкачивали не с помощью push/pull, а с помощью mirror, которая как раз тупо копирует. Т.е. идея изначально была обречена на провал.
Да не, я просто не очень понимаю смысла в распространении файлов по кластеру гитом, если схему распространения все равно приходится руками скриптовать. Зачем гит то? Типа хочется бекап всей хистори на каждом боксе?
Glusterfs не устраивает по причине того, что он хранит файло в своей какой-то структуре, и эмулирует диск и при обращении к диску он там внутри себя какими-то алгоритмами шелестит. Лишнее замедление работы какими-то костылями ненужными нам ну совсем не нужно.
зато удобно если у тебя синхронизация на время навернулось, всегда знаешь какая из версий файлов на двух серверах тебе нужна.
upd: плюс если какой-то контент-манагер решил пошутить и матерное слово куда-нибудь вписать, всегда будешь знать, кому ата-та сделать.
upd: плюс если какой-то контент-манагер решил пошутить и матерное слово куда-нибудь вписать, всегда будешь знать, кому ата-та сделать.
Glusterfs не устраивает по причине того, что он хранит файло в своей какой-то структуре, и эмулирует диск и при обращении к диску он там внутри себя какими-то алгоритмами шелестит. Лишнее замедление работы какими-то костылями ненужными нам ну совсем не нужно.всё хуже. клиент гластера работает через фьюз. эта "технология" не имеет ничего общего с надёжностью и высокой производительностью. и это не голословные утверждения мы фьюз используем и уже всю перепатчили но результат всё равно далёк от идеала. гластер после наших патчей ускорился в несколько раз. об этом поведали те самые чуваки из редхата пилящие гластер.
у нас на гластере хранится несколько терабайт видео-контента и отдаётся гигабитами.
отдаётся гигабитами.А если он создается гигабайтами, как себя гластер чувствует?
несколько террабайтпрям из земли берете?
прям из земли берете?"А ещё он называл тебя земляным
Ну пишется на эту же файловую систему 200-300 мегабит на каждый сервер в кластере. Запись в 40 потоков на сервер. В кластере 12 серверов. Каждый фрагмент данных хранится на 2 серверах.
уж реально лучше glusterfsТред не читал, но с gluster есть проблемы. Скорость записи на куче мелких файлов практически нулевая. Забил на неё, когда поднял и протестил на куче php-сайтов. Когда 2Гб из 80 скопировалось за 3 часа, я решил расстаться с этой ФС. Даже на самом сайте гластера пишут, что она больше приспособлена для больших файлов.
Вообще, есть ещё всякие ceph, и прочие, но конкретно гластер от них отличается тем, что в нём нет точки отказа в виде отдельного сервера с метаданными. Но, все-равно, для мелких файлов они все не сильно годятся. Если нужна некоторая отказоустойчивость, то я щас пытаюсь у себя организовать примерно такую схему: на ноды с веб-серверами маунтится но NFS через autofs ФС с основного сервера, который через DRBD реплицируется на второй в master-slave режиме. В случае отказа основного DRBD-слейв становится мастером, и autofs перемонтирует NFS на него. Пока что уперся в многочисленные баги autofs...
Не хотите Bittorrent Sync заценить?
нашёл ещё две проги: drbd и "SUSE Linux Enterprise High Availability Extension". первую забраковал, вторую пока что пытаюсь поставить.
за наводку спасибо, интересная прога.
за наводку спасибо, интересная прога.
Заценили, с большим количеством мелких файлов он справляется довольно паршиво - в 100 раз скорость падает по сравнению с большими файлами. Однако решили остановиться именно на нём. Большое спасибо за наводку. Очень порадовало то, что он кроссплатформенный, простой в настройке и с одного нода можно сразу состояние всех мониторить.
Оставить комментарий
kill-still
Надо хранить на многих машинах в кластере кучу мелких файлов.Необходимо придумать механизм, как их синхронизировать.
Чтобы был удобный механизм как записав файл на одном сервере чтобы он появился на остальных.
И чтобы она была POSIX-совместимой - эти файлы потом надо будет читать через обычные обращения операционки.