Как объеденить 20 Пбайт в один раздел?

Это проприетарное программное обеспечение.

Блин, рад за ИЯФ.

если кто-чего вдруг заметит

Стр. 3, «с точки зрелища пользователя»

«мониторирующие программы» - лучше уж «программы мониторинга»

Стр.4, «Файловая система — это простейшая база данных с сильно резанным функционалом» - наверное, «урезанным».

Я не Ъ. :-(

Спасибо пофиксил, кроме мониторирующих программ — это вроде устойчивое словосочетание.

Не буду оригинален - union поверх смонтировнных по NFS сторадж-серверов?

это вроде устойчивое словосочетание

Сомневаюсь. Мне и глаза, и уши режет такая русская языка. Либо уж «Мониторящие программы». Вот и фуррифокс слово «мониторирующих» не знает.

Видимо это наш локальный слэнг.

Слишком много этих стораджей. Думаю не взлетит.

Lustre бы порекомендовал, но кластер с ней мы пока так и не ввели в эксплуатацию - надо маньячить с /etc/passwd на системном узле, корне для бездисковой загрузки и сервере метаданных. Да ещё и система охлаждения нынче навернулась - все вырубили нафиг..

вопрос от нуба:

zfs?

Разбил лицо феспалмом. Это как вы при имеющихся технологиях собираетесь достичь записи в 10^6 мегабайт в секунду? если максимум 500 в секунду на винтах.

В голову пришел LVM, но насчет таких объемов - хз.

Новомодный Brtfs может заменить LVM и вроде как большие объемы тянуть.

Разбил лицо феспалмом. Это как вы при имеющихся технологиях собираетесь достичь записи в 10^6 мегабайт в секунду? если максимум 500 в секунду на винтах.

Фейспалмовцы такие фейспалмовцы.

man raid0

Понадобится каких-нибудь 20000 винтов. И емкость винтов должна будет получится каких нибудь 20птX20000=430Пт. Фейспалм.жпг

430000Пт. поправка.

математика и логика это не твое

ОК сейчас пересчитал, получилось 430 Пт (это быстрые подсчеты в уме, числа округляю). Ну что ж, в добрый путь, если деньги есть, можно все что угодно купить.

пересчитай так чтобы получилось 20пт и тогда я пойму что ты исправился.

Трололо. Берем винт на терабайт(у меня прямо сейчас такой) и пробуем его заполнить за 100 секунд. Не получится, поскольку он больше 100Мбс не пишет. Докупаем таких же винтов, расчеты показывают, что даже если он будет писать на 500, их нужно будет не менее 21 (т.е 21 тб), делаем рейд. Теперь переносим размеры на 20 пт, получается не менее 420 пт. если точно, что 430 пт.. Где тут ошибка в логике и математике?

Вобщем, просто возьми винт на терабайт и попробуй заполнить его за 100 секунд. Когда осознаешь, что это невозможно, поймешь.

Тут люди какой то хадуп упоминают, наверно вот это имеют в виду: http://ru.wikipedia.org/wiki/Hadoop#HDFS

Где тут ошибка в логике и математике?

Тут ещё и в коде ошибка, похоже. Зачем умножать? Умные люди давно сказали - взять всё и поделить. Пусть сторадж каждый на 24 SAS-диска по 3Тб (это медленный основной сторадж, быстрый на SSD), в нулевом рейде, получаем скорость не менее 2,4Гбайт/с, с пиком вдвое выше. Для SSD соответственно 12Гбайт/с на один пятиюнитовый сторадж. Сеть столько уже не потянет.

Ну давай делить, мой зеленый друг. 1024 гигабайта\100с=10,24 Гбайт/c. На HDD, про которые мы говорили, это достижимо только при очень большом количестве винтов.

Нужна скорость записи 10000 Мбайт/с (10Гбайт/с)

Предположим что на 1 условный диск (storage) можно писать со скоростью 500Мб/с (fiber 8Gbit)

Т.о. нужно писать параллельно на 20 дисков, что вполне реально.

20000Тбайт / 20 «дисков» = 1000Тбайт на storage

Можешь поиграть со скоростью и кол-вом дисков, не меняя общего объема хранилища и придешь к вполне приемлемым результатам и реальности проекта.

Максимальный поток, который ты можешь подвести к одному стораджу - 10Г[бит]/с. От этой печки и надо плясать. В принципе, достаточно дюжины дисков в страйпе, чтобы забить канал целиком (1,2Гбайт/с = 9,6Гбит/с). Дальнейшее увеличение скорости можно достичь только распределением потока между несколькими стораджами. При этом объём одного стораджа получается равным 36Тбайт на двух юнитовый сервер.

Да, но задача решает.

У меня другой вопрос, зачем аналоговый сигнал писать сразу в цифру. Нет ли аналоговых альтернатив, с которых потом можно будет считать в цифру и обработать.

Проблемы с передачей сигнала. В частности нужно мнооого кабелей. Поэтому сейчас по возможности оцифровывающую электронику стремятся разместить сразу в детекторе и выводить через оптоволокно.

Разбил лицо феспалмом.

Ну формально 1 Тб/сек это не поток — это пропускная способность кабелей. Она в 10 раз выше максимальной загрузке, чтобы коллизий не было.

Тут из зала подсказывают что такие масштабы нужно доверять специализированным системам, типа на готовые решения смотреть надо.

Школу уже закончил?

ТЗ на железо уже есть и там по характеристикам всё проходит даже для уже доступного железа. Что будет когда и если будет финансирование предсказать не возможно. Если я правильно понимаю самая дорогая часть — это охлаждение.

Кстати в двойку можно скорость увеличить если перед записью на диск данные сжимать.

Посмотри там ещё в плюсе обсуждение, может что интересное прочтёшь. Там я тебя скастовал, если не ошибся.

А вот это пока не проверишь на месте сказать не возможно. Есть весьма печальные примеры когда для написания систем сбора данных опирались на закрытые компоненты. Как правило кончалось тем, что всё переписывалось с нуля на открытых решениях, так как поправить закрытый компонент не представлялось возможным ни за какие деньги.

zfs

К одному компьютер такой объём не подключишь, а если подключишь, то его нагнут 100500 запросов от клиентов. Поэтому просто fs мало — нужна сетевая fs

Ну и мелочи вида, что всё будет под GNU/Linux

радует, что на науку хоть какие-то деньги дают. поначалу вопрос вообще удивил. первая мысль «а на какие шиши?»

google+ что-то молчит как партизан. Куда смотреть?

Не дают по большому счёту. Когда проходил конкурс несмотря на самые высокие экспертные оценки проекта стау сделали такие правила, чтобы прошёл Курчатник и Минатом.

А эти деньги по большому счёту мелочь.

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

У нас на нем крутится ~6 Пбайт данных с обработкой мап-редусом.

тот же анон.

Ну есть ещё Lustre.

В любом случае спасибо за наводку — похоже на вариант решения.

У тебя в оповещениях нет сообщения что тебя упомянули в обсуждении?

Не вижу.

Зофрендил. Наверно там от нефрендов уведомления не показываются.

Вот, готовое решение емкостью до 30 ПБ на ленточных накопителях без HDD. Ничего бредового я в нем не вижу, не понимаю, почему меня сегодня так активно игнорят.

http://www-03.ibm.com/systems/ru/storage/tape/ts3500/index.html

Временный диск в оперативе на терабайт, потом кеш на рейде в несколько терабайт а потом эта ленточная библиотека и ничего придумывать не надо, были б деньги.

Ленточное хранилище естественно будет, но не на 20 Пб, а на 200 Пб. Минусы ленточного хранилища в том, что оно очень медленное, особенно в случае многопользовательской работы.

Подписался на тему, давно того с чего можно было бы узнать что-то новое для меня на лоре не было. Судя по всему Lustre действительно тут будет лучше всего.

если очень кратко и для ламеров

в чем суть эксперемента, что такие объемы данных?

Суть: физика c-кварка и tau-лептона (включает поиск экзотических состояний, редких распадов, изучение нарушения CP-симметрии и прочее). Особенности: высокая светимость 10^35 см^{-2}с^{-1} — потому и называется ctau-фабрикой.

Максимальная загрузка физическими события в пике J/psi мезона порядка 300 кГц (3% от полного времени набора). Средний размер события порядка 30 кБ. Вне пиков J/psi и psi(2S) загрузка на порядок меньше при условии подавления событий ee рассеяния. Физическая программа рассчитана на 10 лет работы фабрики частиц.

Объёма 250 Пбайт по оценкам должно для сохранения сырых данных хватить. В оперативном же доступе для анализа нужно постоянно иметь около 5 Пбайт (за всё время эксперимента включая моделирование).