Comments 14
а он данные дублирует? что будет, если один из узлов пропадет?
Да, можно сконфигурировать так, что для каждого файла будет N копий, но не больше чем M. При этом, если нод упадёт, то новая копия будет создана. К тому-же, dCache умеет мигрировать данные на ленту и брать их обрато, если понадобится. Система изначально создавалась как фротэнд для ленточного хранилища.
У кого-нибудь есть это чудо в продакшене или хотя бы тестировании? Интересно в сравнении, например, с glusterfs.
Совсем экзотика )) Можно в GRID к ученым подключиться, например. В остальном выглядит не очень удобно. Как большая библиотека, где надо в бахиллах шепотом разговаривать, а под землей миллиарды книг ))
Подозреваю, что файлы сюда надо складывать медленно и сравнительно нечасто, постгрес умрет без надлежащего вакуума очень быстро.
>> В связи с натурой экспериментальных данных dCache не предусматривает изменение хранимых файлов.
Удалить и записать заново?
В сети не нашел ни бенчей, ни сравнений.
Подозреваю, что файлы сюда надо складывать медленно и сравнительно нечасто, постгрес умрет без надлежащего вакуума очень быстро.
>> В связи с натурой экспериментальных данных dCache не предусматривает изменение хранимых файлов.
Удалить и записать заново?
В сети не нашел ни бенчей, ни сравнений.
Порядка 50% всех данных хранится в dCache.А остальные где?
А можно в двух словах: зачем нужен dCache?
Я помню, на заре своего существования основная задача, которю он решал была миграция файлов из места постоянного хранения в кэш ближайший к потребителю. А чем он занимается сейчас?
P.S. Очепятка в «долее сложные конфигурации».
Я помню, на заре своего существования основная задача, которю он решал была миграция файлов из места постоянного хранения в кэш ближайший к потребителю. А чем он занимается сейчас?
P.S. Очепятка в «долее сложные конфигурации».
Основная задача dCache — это построение распределённого хранилища на основе обычного железа. Причём, все сервера видны клиентам как одна большая файловая система, размер которой можно увеличивать по мере надобности. При добавлении нового узла мы увеличиваем как дисковое пространство, так и сетевой канал, так-как клиенты пишут/читают прямо с серверов.
P.P.S: спасибо, исправил.
P.P.S: спасибо, исправил.
glusterFS то же самое. И Java не нужна. И всё прозрачно (FUSE, очень мало кода — если что, можно просто посмотреть как что работает). + Какая-никакая поддержка от RH, какие-то тесты, комьюнити.
И тоже работает на любом железе. И в продакшене работает. И файлы изменять там можно. И 26 файлов в секунду — это не так уж много. Даже если 7 дней в неделю.
Так почему нам нужен dCache? :)
И тоже работает на любом железе. И в продакшене работает. И файлы изменять там можно. И 26 файлов в секунду — это не так уж много. Даже если 7 дней в неделю.
Так почему нам нужен dCache? :)
25 файлов — это конкретный случай и не единичный.
GlusterFS тоже можно использовать. Всё зависит от того что вам надо. Изначально, dCache создавался для предоставления прозрачного доступа к данным на ленте, что по сей день активно используется. dCache поддерживает WebDAV и FTP, которые на glusterFS запустить легко, а вот использовать распределённую природу glusteraFS сложно.
Ну а Java есть свои преимущества. Да и код не так страшен, если C читать множите.
GlusterFS тоже можно использовать. Всё зависит от того что вам надо. Изначально, dCache создавался для предоставления прозрачного доступа к данным на ленте, что по сей день активно используется. dCache поддерживает WebDAV и FTP, которые на glusterFS запустить легко, а вот использовать распределённую природу glusteraFS сложно.
Ну а Java есть свои преимущества. Да и код не так страшен, если C читать множите.
Безусловно, инструмент нужно подбирать под задачи. Вот их и пытаюсь понять.
Каюсь, с лентами не сталкивался, но если у «ленты» есть точка монитрования — точно также ее можно использовать в гластере, создав distributed хранилище. Никакой сложности использования распределенной природы глустера НЕТ, сказки это всё.
Про преимущества Java — интересно, это какие? :) Проприетарная природа? Любовь к памяти?
Да и не в яве как таковой вопрос, хотя от сравнения с C меня и коробит. Вопрос в том, что вы тянете минимум 2 сеьезных зависимости — JVM и БД (пусть даже любимый постгрес). И это только для организации хранилища. Любая зависимость — это ПЛОХО, использование её должно быть обосновано, давать какие-то плюшки, которых не получить без неё. Вот я плюшек-то и не вижу, только зависимости.
Это не наезд, мне интересна эта тема, но я не вижу ответов в статье, уж простите.
Каюсь, с лентами не сталкивался, но если у «ленты» есть точка монитрования — точно также ее можно использовать в гластере, создав distributed хранилище. Никакой сложности использования распределенной природы глустера НЕТ, сказки это всё.
Про преимущества Java — интересно, это какие? :) Проприетарная природа? Любовь к памяти?
Да и не в яве как таковой вопрос, хотя от сравнения с C меня и коробит. Вопрос в том, что вы тянете минимум 2 сеьезных зависимости — JVM и БД (пусть даже любимый постгрес). И это только для организации хранилища. Любая зависимость — это ПЛОХО, использование её должно быть обосновано, давать какие-то плюшки, которых не получить без неё. Вот я плюшек-то и не вижу, только зависимости.
Это не наезд, мне интересна эта тема, но я не вижу ответов в статье, уж простите.
в сравнении с hdfs что скажете?
так понял что в dcache упор на заливку и распределенное хранение любых файлов +доступ по множеству протоколов, ну первое hdfs вроде бы выполняет, вот с протоколами у нее туго.
так понял что в dcache упор на заливку и распределенное хранение любых файлов +доступ по множеству протоколов, ну первое hdfs вроде бы выполняет, вот с протоколами у нее туго.
Sign up to leave a comment.
dCache — xранилище, где живёт ХИГГС