Я както не очень доверяю файловым системам объемом в 60 мегов, при таком объеме исходников наверняка работает хреново. Былобы 1-2 мега ну 6 максимум, но 60?
Кросплатформенная DFS размером 2мега? Это будет выдающееся достижение мире IT. Что-то типа карманного атомного реактора. :-) Все мечтают, но никто не видел.
MIT ее использует. Продвинутая сетевая файловая система, распределенно хранящая данные с резервированием на нескольких (многих) серверах, с локальным кэшированием на клиентах и прочими наворотами.
> Глупый порос, но все-же, что есть OpenAFS? Его кто-нибудь реально использует?
OpenAFS - сетевая файловая система, которая, говорят, предоставляет много вкусного: распределенное дерево каталогов, расширенные файловые атрибуты и acl'ы, собственную систему бэкапа, интегрированную с Kerberos авторизацию и прочая и прочая. Подробнее - http://openafs.org/pages/doc/AdminGuide/auagd006.htm
Я дошел до состояния "работающий сервер, три клиента". После того, как два экселя, работая с одной таблицей, начали ее лихо курочить, не обращая внимания друг на друга, все работы с openafs были свернуты. Таким образом, всякие мегафичи типа распределенных томов, бэкапа и проч. даже смотреть не стал.
Короче, на момент 1.3.86 (этим летом) система была неюзабельна для корпоративной сети. Разве что есть сети, где люди никогда не открывают мс-офисом сетевые файлы одновременно. Сам Альтман проблему byte-range locking ставил на сто шестнадцатое место: https://lists.openafs.org/pipermail/openafs-info/2005-July/018545.html
Виндовая клиентская действительно страшновата для пользователя, но в принципе жить можно.
В общем, если есть лишнее время, openafs можно покрутить и сейчас, но в боевые условия я бы ее пока не кидал. Возни сравнительно немало, а результат - кот в мешке.
Many applications on Windows (e.g. Microsoft Office) require the use of byte range locks applied to a file either to protect against simultaneous file access or as a signaling mechanism. OpenAFS does not currently support byte range locks. It is strongly recommended that files not be edited within AFS if they might be accessed by multiple users or multiple processes on a single machine.
>> После того, как два экселя, работая с одной таблицей, начали ее лихо >> курочить, не обращая внимания друг на друга, все работы с openafs были >> свернуты
Забей и выкинь. Ну не у всех получается использовать то, что давно работает во всех Национальных Лабораториях (US) и в Церне. Да и задачи надо выбирать соответственно, один сервер и три клиента это идет вопреки всему, ради чего AFS создавалась.
Свои проблемы конечно есть, но не на таком уровне, извини :)
1) Громадной отказоустойчивой файлопомойки со 100% защищённостю от взлома, быстрым доступом(быстрее FTP) и балансировкой нагрузки. Предполагается что количество операций чтения на порядок-два превышают количество операций записи.(Суммарный обьём всех открытых файлов может составлять СОТНИ ТЕРАБАЙТ).
2) При количестве одновременных коннектов ~50 000. В состоянии на все пятьдесят тысяч одновременно отдавать mp3 в реальном времени (по этому параметру имеет только ДВЕ альтернативы: IBM dfs && Lustre )
3) Абсолютно неломаема при пользовании kerberos 5. за 25 лет своего существования не отдала налево ни одного байта. Было только несколько удачных атак типа DOS.
OpenAFS - распределенная файловая система. Допускает оффлайновую работу клиента, что очень приятно. Отказоустойчива, с хорошей аутентификацией (krb-based), быстрая. Разумеется, у нее есть свои глюки, но к использованию она вполне пригодна. Ответ на второй вопрос: да. Ее используют :)
> Да и задачи надо выбирать соответственно, один сервер и три клиента это идет вопреки всему, ради чего AFS создавалась. Свои проблемы конечно есть, но не на таком уровне, извини :)
Т.е. когда бы я раскинул OpenAFS на несколько удаленных офисов с несколькими тысячами клиентов, начали бы лочиться открытые на запись файлы?
Опять же, в национальных лабораториях работает IBM AFS или OpenAFS?
но опен вариант отстает и капитально --- достаточно посмотреть на размер тома.
основное ее вреимущество это кеширование на диск на стороне клиента --- это приводит к огромной разгрузке сети. удаленный диск просто доступен для работы, локальный кеширует. архитектура винды с ее реестром и прочей лабудой не позволяет(затрудняет) таким образом использовать программки установленные централизованно.
с файлопомоек в основнов стали тащить фильмы (!в ДВД!). никакого кеширования при индивидуальном использовании клиентского компа увы нет для разумного размера кеша (в моем конкретном случае). 1,5 терабайта инфа на файло помойке и 80-100 гиг у пользователя (из которых свободно гиг 10)
Насчет Kerberos5 не очень понял - AFS же всю жизнь была нежно привязана к Kerberos4 (или kerberos524)? Или что-то поменялось за последнее время? А в Церне и прочих национальных лабораториях ее используют (ИМХО) в качестве кластерной файловой системы (ROMIO там и прочие прелести) когда NFS нехватает (виндовые клиенты), а pvfs1/2 ставить как-то стремно. К проблемам любителей byte-range lockinga все это имеет весьма отдаленное отношение.
>>>После того, как два экселя, работая с одной таблицей, начали ее лихо курочить, не обращая внимания друг на друга, все работы с openafs были свернуты.
Лихо. Новости про базы данных до вашего оффиса видимо еще не докатились? Ну, подождите еще лет тридцать.
>Насчет Kerberos5 не очень понял - AFS же всю жизнь была нежно привязана к Kerberos4 (или kerberos524)?
ветка 1.2.13 досихпор содержит встроенный kerberos4 но рекомендуют его не пользовать а переходить на К5 так как сильно повышается взломоустойчивость
>Или что-то поменялось за последнее время?
да. ещё можно пользовать heimdal и вендузный KDC
>А в Церне и прочих национальных лабораториях ее используют (ИМХО) в качестве кластерной файловой системы (ROMIO там и прочие прелести) когда NFS нехватает (виндовые клиенты),
на нфс и самбу там весьма давно забили по причине очень низкой масштабируемости
>а pvfs1/2 ставить как-то стремно.
а эта весчь совсем с другой песни. насколько я знаю у неё серьёзные ограничения по числу клиентов
>Допускает оффлайновую работу клиента, что очень приятно.
если вы имеете ввиду тоже что поддерживает кода то вы ошибаетесь. В настоящем оффлайне afs в состоянии обеспечить только ro-доступ к ПРОКЕШИРОВАНЫМ файлам. по крайней мере для версии 1.2.13
>> После того, как два экселя, работая с одной таблицей, начали ее лихо курочить, не обращая внимания друг на друга, все работы с openafs были свернуты.
> Лихо. Новости про базы данных до вашего оффиса видимо еще не докатились? Ну, подождите еще лет тридцать.
> а может перед разворачиванием работ следовало немного документации почитать???
Без наезда: ты видимо больше по научной части. Если бы я начальству докладал о новых вреднениях с такой скоростью, с какой читаю английскую документацию, меня бы давно уволили к хвостам собачьим. :) То есть я, конечно, добросовестно, аж в метро, читал распечатки "Administration Guide", но ближе к телу больше налегал на хавты по инсталляции. Соответственно, в том, что под мою задачу OpenAFS не подходит, убедился раньше, чем прочитал об этом в мануале. Собственно и посты мои только для того, чтобы те, кто ищет новые решения для офисного файл-сервера (на текущий момент), не теряли времени. Лично мне подобная информация в свое время очень бы помогла.
А зачем шлюз afs-samba, если в таком случае достаточно самбы?
OpenAFS делает все, что нужно, но ей действительно не хватает byte-range lock для использования за пределами узкой ниши распределенного ftp ресурса с авторизацией и аклами. И хранения имен файлов в юникоде с конвертацией для клитента.
Ну кому нужна шара, которая теряет и мусорит файлы при использовании файлов с нее большинством виндовых прог?
Ну и клиент для винды надо переписывать, чтоб был не хуже клиента самбы.
Смотрел. Насколько я понял из lib/afs.c, самбовская поддержка afs завязана на наличии kerberos4. Очень не хочется. Опять же инфраструктура получается какая-то опухшая и корявая. "Дешевле" просто завязаться на чистой самбе и не париться.
В общем, как Альтман писал, что cifs и локи будут готовы только в 2006 году, так, судя по всему, и будет. Тогда и попробуем еще раз систему пощупать.