Plone powered или CMS на службе российских физиков

а чем ZODB не устроил?

Firefox can't find the server at www.oka.ihelp.ru

Я бы порекомендовал: http://www.sugarcrm.com/crm/

Пока её размер десятки мегабайт - можно потерпеть бекап всей базы, а вот когда будет сотни мегабайт-гигабайты, то incremental backup однозначно лучше. Загрузка базы в память после рестарта зопы уже на десятках мегабайт длится несколько секунд, на гигах сервис будет недоступен несколько минут. Да, и как вы себе представляете работу с файлом в пределе размером в пару десятков гигов??? Извиняюсь, ни вздохнуть, ни пёрнуть. Или может я чего не знаю и ZODB умеет себя сегментировать на несколько файлов? Когда народ начнёт активно пихать в базу доки/статьи/картинки с результатами, да с десятком-другим промежуточных версий, головная боль быстро появится. Иметь разных _документов_ на пару гигабайт это нормальное явление. Чем бегать, искать человека с нужной докой, надо один раз выложить и всё, проблема решена.

http://www.oka.ihep.ru (http://www.oka.ihep.su)

Всё это интересно, но интереснее гораздо будет DAQ для эксперимента, я себя назначил начальником IT-department'а этого эксперимента ;))), поскольку кластером заведую я, порталом заведую я, програмной частью тестирования модулей электроники заведую тоже я, по этой же причине я послал все существующие ДАКи в одно место и решил писать свою, распределённую систему сбора данных с хранением данных на узлах кластера. Основная идея в том, что аппаратный RAID покупать не нужно, покупаем диски, засовываем их в ноды и организуем "разбиение хранения" данных програмно, естественно с дублированием данных на разных нодах. Экономия на хранении измеряется _разами_. Естественно надо организовать и backup на внешние носители, на эксперименте-предшественнике это делалось на DLT, что использовать сейчас пока не решено (за сеанс предполагается набирать около пары терабайт). Организация хранения заключается в динамическом распихивании данных во время сбора по разным нодам для последующей обработки на всех нодах только локально хранимых данных на каждой из нод, чтобы при обработке с одной стороны не нагружалась сеть (хотя ноды кластера связаны двумя гигабитными сетками - это делалось когда хранение предполагалось делать на RAID'е, чтобы развязать потоки от front-end машин к event builder'ам и потоки от event builder'ов к RAID), а с другой стороны все ноды обрабатывали данные. Есть две интересные задачи: правильное "размазывание" данных по нодам в online/offline и запуск заданий при обработке с учётом того, что надо обработать все данные и каждый файл с данными только один раз (более сложный случай, когда надо обрабатывать заданные куски данных выбранные по некоторому критерию), причём это должен иметь возможность делать каждый пользователь кластера. Ну это в кратце, на самом деле всё несколько сложнее, как всегда ;).

Посмотри GPFS -- как мне кажется для твоей задачи самое оно.

>Или может я чего не знаю и ZODB умеет себя сегментировать на несколько файлов?

Да, конечно. У zodb есть разные бекэнды. BerkleyStorage, DirectoryStorage...

А русская версия сайта?

Неплохая вещь кстати, только это всё-таки crm, а не cms

Один из достойных рабочих столов под KDE. Практично и без выпячиваний глупых и бесполезных иконных красот в пол экрана.

> Я бы порекомендовал: http://www.sugarcrm.com/crm/

спасибо за линк, но я люблю sugar-free (это камень в огород PHP, слишком много в нём дыр находят ;))

> >Или может я чего не знаю и ZODB умеет себя сегментировать на несколько файлов?

> Да, конечно. У zodb есть разные бекэнды. BerkleyStorage, DirectoryStorage...

только с ними свои гланды:

http://www.zope.org/Members/runyaga/ZopeFAQs/WhatWhyHowZODB
http://www.zope.org/Members/distagon/How-tos/test

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

> Экономия на хранении измеряется _разами_.

Сколько стоит 10 ТБ? + LTO2 магнитофон (не деться пока от него)

> А русская версия сайта?

а французская/китайская/...? многоплановый вопрос :-|, если мы говорим о просветительской точке зрения сайта, то бишь о залётных посетителях, желающих поглазеть "чем там эти учёные занимаются", то вопрос имеет смысл, бабло на эксперимент идёт российское и показать российским налогоплательщикам "куда бабло ушло в натуре" дело полезное. Только это отдельная задача и заниматься ею надо тогда, когда решены все более нужные задачи или есть бабло нанять человека, который это сделает.

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

Да и как я уже убедился найти толкового чела в инете понимающего по-аглицки, а не по-русски значительно проще.

В Plone тоже багов много. Например: http://article.gmane.org/gmane.comp.web.zope.plone.user/24981 позволяет любому локальному пользователю получить права администратора. Найдет полтора года назад, неуверен что закрыт до сих пор. Вообще Plone/Zope сам использую, если забыть о безопастности то это замечательная система.

> Сколько стоит 10 ТБ? + LTO2 магнитофон (не деться пока от него)

Я говорил только о рейдах vs. встроенные диски, бекап нужен в любом случае, поэтому это отдельная песня. Или вы предлагаете заниматься обработкой читая с лент? Ну тогда нам надо покупать робот, крутить десятки лент вручную, это мы уже проходили на объёмах существенно меньших ожидающихся (разница больше порядка). А ленточные библиотеки стоят очень дорого (до сотни и больше килобаксов). На ВЦ у нас такая штука стоит, но она им самим нужна. Плюс потери во времени на ожидание загрузки в очереди и само чтение лент.

Давайте прикинем: ноды для кластера уже есть (без них не будет обработки а посему эксперимента вообще, в пропозале оценочно требовалось полсотни писюков, отсылаю туда для обоснования: http://www.oka.ihep.ru/Members/zopeadmin/oka-papers/pred.ps), пустой рейд обходится грубо в $2500, диски в него 8x$100(250GB)=$800, это около 2TB в RAID5, плюс файл-сервер $600 (это обычная писюка с гигом рамы и SCSI-интерфейсом, мы не банк, нам пять девяток не нужны), то есть в сумме $3900, в итоге 10TB обойдётся в $19500, с учётом двух рейдов на один файл-сервер это минус $1200, получаем $18300. И это только на само хранилище. Сравниваем с "голыми" 10TB на встроенных дисках: 2(дублирование)x40x$100=$8000. Имеем $18300/$8000=2.2875-кратную разницу в стоимости.

Спасибо за предложение, я тут про люстру (GFS, PVFS, etc) читал на всякий пожарный, проблема с кластерными ФС та, что нам не нужна по большому счёту предлагаемая ими функциональность и того, что нужно тоже нет.

Во-первых нужна надёжность при аварийном/штатном выключении нод, что происходит с ФС когда одна из нод с её дисками исчезает? Даже если она выживает, то часть файлов недоступны, распределённый рейд будет в люстре через несколько лет и за деньги. Есть такой проект Distributed Data RAID (DDRAID), но он скорее мёртв, чем жив. Если я восстанавливаю данные с лент на одну из нод, можно ли объяснить самой ФС, что это те данные, которые пропали и путь к ним такой же? а что происходит когда поднимается выключенная нода с оригиналом данных?

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

В _любом_случае_ придётся наворачивать логику хранения или поверх кластерной ФС или напрямую на дисках и я думаю, что второй вариант получится проще, надёжнее и быстрее.

> Один из достойных рабочих столов под KDE. Практично и без выпячиваний глупых и бесполезных иконных красот в пол экрана.

ЛОЛ.

ну вы блин даёте, за день месячную посещаемость у меня набрали (awstat'ом смотрю), можно порадовать начальника эксперимента небывалой заинтересованностью посетителей ЛОРа российской наукой :)))

> > Один из достойных рабочих столов под KDE. Практично и без выпячиваний глупых и бесполезных иконных красот в пол экрана.

> ЛОЛ.

точно, самого стола и не видно, может у меня там грудастая фотомодель глазки строит и от работы отвлекает, шучу :)))

LOL это когда рабочий стол занимает 90% времени :p Хотя какого времени, чего 90%? Автор не уточнил...

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

За Федору (RHEL?) респект.

> За Федору (RHEL?) респект.

SLC ?

А можно в двух словах зачем этот plone вообще нужен?:) А то нам, российским физикам, интересно, а ссылок вы не привели...

>А можно в двух словах зачем этот plone вообще нужен?:) А то нам, российским физикам, интересно, а ссылок вы не привели...

Российским физикам прикрыли доступ к гуглу?

SLC ?

SLC4 (RHEL4-derived)

Про люстру точно не скажу, так как работаем в основном с GPFS.

> что происходит с ФС когда одна из нод с её дисками исчезает?

В GPFS при создании FS можно указать требуемое количество реплик для данных и метаданных.

> что происходит с ФС когда одна из нод с её дисками исчезает?

Идет довольно сложная внутренняя процедура синхронизации, но для пользователя все OK. Некоторые подробности описаны, например здесь:

http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=/com.i... http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/topic/com.ibm.cluster....

> я не зря упомянул про локальность обработки хранимых данных, иначе получится, что с вероятностью скажем 90% задание обрабатывает данные хранимые на другой ноде, сеть просто просядет от такого насилия, а обработка данных будет заниматься вводом-выводом, а не обработкой.

Верно, только вероятность с GPFS будет 100% -- при записи выполняется striping. Другой вопрос, поверх какой сети это все работает.

Если вы сами пишете правила раскладки данных, то согласен,распределенная FS не нужна. Другое дело что реализовать надежное, эффективное хранение данных довольно сложно, и не получится ли в итоге дороже решения с внешним storage?

А можно в двух словах зачем этот plone вообще нужен?:) А то нам, российским физикам, интересно, а ссылок вы не привели...

статья в википедии о CMS: http://en.wikipedia.org/wiki/Content_management_system

Если в двух словах, то набор средств для автоматизации управления контентом веб-сайтов, если по-простому, то добавление информации в удобном для автора виде и её динамическое представление в удобном для посетителей виде. Создание руками статических html-страниц это технология прошлого века, в которой разделение на model и view нет вообще откуда и проблемы. Мне нужно было обеспечить наполнение сайта без моей помощи его пользователями, Plone эту задачу решает полностью.

Сейчас CMS'ы пытаются заглотить и другие области, одна из интересных мне это groupware, автоматизация совместной работы, что особенно актуально для удалённых географически участников. Если сбегать в соседний офис не особо обременительно, то слетать в другой город или даже страну это целое дело, а емеля решает только узкую задачу обмена инфы между участниками.

сайт разработчиков Plone: http://plone.org/
русскоязычный сайт: http://plone.org.ru/

2filin

спасибо за разъяснение.

> Если вы сами пишете правила раскладки данных, то согласен,распределенная FS не нужна. Другое дело что реализовать надежное, эффективное хранение данных довольно сложно, и не получится ли в итоге дороже решения с внешним storage?

Не стоит задача реализовать всю функциональность файловой системы для сырых данных, есть один пользователь, который один раз кладёт данные (возможно потом дополнительно размазывает по нодам), а потом все только читают их во время обработки:

A. Нода упала -> пометка в каталоге о недоступности хранимых на ней данных -> проверка доступности данных на других нодах -> создание реплики на нодах не хранящих этих данных -> запрос на восстановление отсутствующих данных с лент

B. Нода поднялась -> пометка в каталоге о доступности хранимых на ней данных

C. Потребовалось место -> находим данные с максимальным кол-вом копий (>1) -> удаляем из каталога -> трём одну из копий

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

Объём обработанных данных меньше на порядки исходного и его можно уместить в обычный рейд. Если реконструкция будет достаточно шустра, то и DST (реконструированные и отобранные данные примерно в 10 раз меньшего объёма) можно не писать.

>Я говорил только о рейдах vs. встроенные диски, бекап нужен в любом случае, поэтому это отдельная песня. Или вы предлагаете заниматься обработкой читая с лент?

Боже упаси. Но восстанавливать данные с лент мне уже приходилось. Так что ленты вам в любом случае заводить придётся если хотите чтобы было что восстанавливать в случае чего.

> Сравниваем с "голыми" 10TB на встроенных дисках: 2(дублирование)x40x$100=$8000. Имеем $18300/$8000=2.2875-кратную разницу в стоимости.

А вы своё время, потраченное на настройку не учитываете? Плюс сдаётся мне, что обслуживание такой распределённой железяки вместо компактной коробки с RAID-5 будет более чем в два раза по времени накладно.

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

> > Я говорил только о рейдах vs. встроенные диски, бекап нужен в любом случае, поэтому это отдельная песня. Или вы предлагаете заниматься обработкой читая с лент?

> Боже упаси. Но восстанавливать данные с лент мне уже приходилось. Так что ленты вам в любом случае заводить придётся если хотите чтобы было что восстанавливать в случае чего.

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

> > Сравниваем с "голыми" 10TB на встроенных дисках: 2(дублирование)x40x$100=$8000. Имеем $18300/$8000=2.2875-кратную разницу в стоимости.

> А вы своё время, потраченное на настройку не учитываете?

Евгений, я сам писал приложение с каталогом ФС в БД (опять же не полнофункциональным), я знаю чего это стоит и для меня это не проблема

> Плюс сдаётся мне, что обслуживание такой распределённой железяки вместо компактной коробки с RAID-5 будет более чем в два раза по времени накладно.

чьего времени? как и при каких условиях вы измеряете? повторюсь ещё раз, от распределённой ФС в данном случае остаются рожки да ножки: один пользователь один раз записывает по строго заданным правилам, много пользователей много раз читают.

> А чудеса при перекачки больших объёмов данных разные случаются.

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

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

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

>> Плюс сдаётся мне, что обслуживание такой распределённой железяки вместо компактной коробки с RAID-5 будет более чем в два раза по времени накладно.

>чьего времени? как и при каких условиях вы измеряете? повторюсь ещё раз, от распределённой ФС в данном случае остаются рожки да ножки: один пользователь один раз записывает по строго заданным правилам, много пользователей много раз читают.

Вашего. Потому что обслуживание одной качественной железяки+UPS (для действительно качественной денег не хватает, но более-менее приемлимое железо подобрать можно) для неё много проще чем кучи полутерминалов в соответствующем исполнении. Основная цель всё-таки это физический эксперимент.

У нас в институте есть три детекторные группы, которые испытывают необходимость в больших объёмах данных. Из них на текущий момент работает только наша. Для хранения данных у нас используется 3 Тб RAID5 в исполнении Axus Brownie - за два года работы к конструктиву нареканий нет. Очень рекомендую отказаться от экспериментальных вещей в сторону простых методов.

С другой стороны за два года объёмы дисков сильно увеличились и те же три терабайта сейчас можно набрать за пять дисков. Но вот надёжностью не понятно.

>> А чудеса при перекачки больших объёмов данных разные случаются.

>спасибо за заботу :), чексуммы никто не отменял, к тому же сейчас любая уважающая себя железка делает это сама, и диски и сетевые карты

Закон Паркинсона: всё что может сломаться - ломается

Следствие: всё что не может сломаться - тоже ломается

Всякое бывает: нам как-то раз казалось бы уважаемая фирма подсунула битую регистровую память, был случай, когда проблемы с памятью проявлялась после недели тестирования. Сейчас у нас чудеса со SCSI контроллером - портится ровно один бит для неких последовательностей данных в случае их быстрой передачи. Чем меньше железа - тем лучше.

ПРЕВЕД ИХЕПУ, КАРДАНЕВУ ОСОБЫЙ ПРЕВЕД!!!

> Вашего. Потому что обслуживание одной качественной железяки+UPS (для действительно качественной денег не хватает, но более-менее приемлимое железо подобрать можно) для неё много проще чем кучи полутерминалов в соответствующем исполнении. Основная цель всё-таки это физический эксперимент.

Для меня основная цель это набрать как можно больше уникального интеллектуального опыта в области IT и CS, мне эта задача как коту сметана, будет надо пойду по трупам :)

> У нас в институте есть три детекторные группы, которые испытывают необходимость в больших объёмах данных. Из них на текущий момент работает только наша. Для хранения данных у нас используется 3 Тб RAID5 в исполнении Axus Brownie - за два года работы к конструктиву нареканий нет. Очень рекомендую отказаться от экспериментальных вещей в сторону простых методов.

Да, безусловно усилий на sw development ваш вариант требует меньше, но: он существенно дороже (уже посчитали насколько), он намного хуже по нагрузке на сеть. Когда нод около десятка можно жить с гигабитом без проблем, когда нод несколько десятков и больше главная проблема - сеть, fibre channel или myrinet нам никто не подарит.

> С другой стороны за два года объёмы дисков сильно увеличились и те же три терабайта сейчас можно набрать за пять дисков. Но вот надёжностью не понятно.

> Закон Паркинсона: всё что может сломаться - ломается
> Следствие: всё что не может сломаться - тоже ломается
> Всякое бывает: нам как-то раз казалось бы уважаемая фирма подсунула битую регистровую память, был случай, когда проблемы с памятью проявлялась после недели тестирования. Сейчас у нас чудеса со SCSI контроллером - портится ровно один бит для неких последовательностей данных в случае их быстрой передачи. Чем меньше железа - тем лучше.

вы полностью подтверждаете мои слова - поломка железа дело практически не котролируемое, а посему чем короче цепочка источник_данных -> потребитель_данных, тем лучше, мой вариант можно сказать идеален по сравнению с вашим :), поскольку:

* мой вариант: данные зачитываются напрямую в кеш ФС с локального диска

* ваш вариант: в кеш контроллера рейда -> в скази интерфейс рейда -> в скази интерфейс файл-сервера -> в кеш файловой системы файл-сервера -> в гигабитный интерфейс файл-сервера (-> где-то тут свитч который мы опустим) -> в гигабитный интерфейс ноды -> в кеш клиента файловой системы на ноде

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

В моём варианте цепочка, обеспечивающая передачу _потока_данных_ (не управляющая, которая на порядки менее "тяжёлая"!), предельно короткая и практически все проблемы у меня в руках поскольку почти все места со SPoF'ами разруливаются софтом.

> ПРЕВЕД ИХЕПУ, КАРДАНЕВУ ОСОБЫЙ ПРЕВЕД!!!

взаимно, полный превед, он давно в Москве бабло рубит админом

>> Вашего. Потому что обслуживание одной качественной железяки+UPS (для действительно качественной денег не хватает, но более-менее приемлимое железо подобрать можно) для неё много проще чем кучи полутерминалов в соответствующем исполнении. Основная цель всё-таки это физический эксперимент.

>Для меня основная цель это набрать как можно больше уникального интеллектуального опыта в области IT и CS, мне эта задача как коту сметана, будет надо пойду по трупам :)

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

>Да, безусловно усилий на sw development ваш вариант требует меньше, но: он существенно дороже (уже посчитали насколько), он намного хуже по нагрузке на сеть. Когда нод около десятка можно жить с гигабитом без проблем, когда нод несколько десятков и больше главная проблема - сеть, fibre channel или myrinet нам никто не подарит.

Если считать время, затраченное на настройку, обеспечении работы и простои, то существенно дешевле. У нас азота в сутки тратится на 1000$ не зависимо от того можно писать данные или нельзя. С сетью проблема будет в любом случае. На текущий момент проблем не замечено - до счётных машин 1Гб и основное время тратится на обработку, а не на чтение данных.

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

Дикий вы какой-то, наверное вы ни разу не видели какие деньги буржуи "выбрасывают" на обучение персонала. Экспериментов можно поставить сколько угодно если есть квалифицированный персонал (ваши же слова: такого персонала днём с огнём не сыскать). А пока его нет, "учиться, учиться и ещё раз учиться", как завещал дедушка Ленин, ибо если нет квалифицированного и обученного персонала, то "результата" в _вашем_понимании_ не получить.

> Если считать время, затраченное на настройку, обеспечении работы и простои, то существенно дешевле. У нас азота в сутки тратится на 1000$ не зависимо от того можно писать данные или нельзя.

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

> С сетью проблема будет в любом случае. На текущий момент проблем не замечено - до счётных машин 1Гб и основное время тратится на обработку, а не на чтение данных.

Вы себе противоречите, говорите что проблема будет в любом случае и тут же говорите что проблем не замечено ;))).

Извините, мне наскучило объясняться, за сим раскланиваюсь.

Может быть запостил бы новость о сайте на http://plone.org.ru/?