Компания Red Hat опубликовала (http://www.redhat.com/promo/storage/press-release.html) пресс-релиз с информацией о достижении окончательного соглашения о покупке за 136 млн долларов компании Gluster (http://www.gluster.org), разрабатывающей распределенную файловую систему GlusterFS. В компании надеются, что это событие позволит клиентам Red Hat перейти на новую парадигму управления данными, предусматривающую хранение и обработку информации в облаке, вместо использования централизованных хранилищ, таких как SAN.
"За прошедшее десятилетие мы стали свидетелями резкого сдвига в строну цифровых форматов передачи данных, что, в сочетании с большим распространением широкополосного доступа в интернет, вызвало массовый спрос на новые классы хранилищ данных." - говорит Брайян Стивенс (Brian Stevens), технический директор и вице-президент Worldwide Engineering, Red Hat. "Многие компании сегодня до сих пор используют традиционные базы данных и хранилища SAN для хранения неструктурированных дан...URL: http://www.redhat.com/promo/storage/press-release.html
Новость: http://www.opennet.me/opennews/art.shtml?num=31941
использую уже года четыре. нареканий почти ноль.
Да, Red Hat правильной дорогой идут. Нужные покупки. Не уверен, как сформирована цена в сотню миллионов долларов. И я тоже использую его два месяца ) проблем пока тоже не было.
Все работает как часы.
Тоже начинаю использовать данную ФС. И появился один вопрос, на который пока не могу найти ответа. Создал replicated volume на двух нода. Если одна нода умирает (например по питанию) на другой ноде gfs volume "подвисает" на время равное network.ping-timeout. Как обойти данную багу/фичу, чтобы не было таких "подвисаний"?
GPFS куда стабильнее
>GPFS куда стабильнееКонкретные претензии к стабильности GlusterFS есть? Или, как обычно, "не читал, но осуждаю"?
я его не точ то читал - я его готовил
и на вкус он полное Гособенно если нфс )
>я его не точ то читал - я его готовил
>и на вкус он полное ГЕсли я щас бездоказательно заявлю, что готовил GPFS и он на вкус полное Г - вы не обидитесь?
>>я его не точ то читал - я его готовил
>>и на вкус он полное Г
> Если я щас бездоказательно заявлю, что готовил GPFS и он на вкус
> полное Г - вы не обидитесь?на обиженных воду возят ))
а вот на счёт готовки GPFS - она куда вкуснее
если вы мне не верите что гластер - Г - то приготовьте по выше указанному мною рецепту посмотрим как она вам на вкус
> если вы мне не верите что гластер - Г - то приготовьте
> по выше указанному мною рецепту посмотрим как она вам на вкусНе вижу рецепта выше, только высеры про то что плохо работает.
дык отвечать то ниже надо было а не прыгать выше головы
>я его готовил и на вкус он полное ГКак я понимаю, конкретных претензий мы не услышим?
>>я его готовил и на вкус он полное Г
> Как я понимаю, конкретных претензий мы не услышим?притензии ?
ок постройте кластер из 8 нод и взаимо реплицируйте - добавьте на одной ноде файлики и её отрубите - посмотрим как на других нодах будут копии
>ок постройте кластер из 8 нод и взаимо реплицируйте - добавьте на одной ноде файлики и её отрубите - посмотрим как на других нодах будут копииSo, what's the problem?
>>ок постройте кластер из 8 нод и взаимо реплицируйте - добавьте на одной ноде файлики и её отрубите - посмотрим как на других нодах будут копии
> So, what's the problem?эт вы у меня спрашиваете ? протестируйте если не готовили
может покажите где в продакшене это Г юзают ?
>эт вы у меня спрашиваете ? протестируйте если не готовилиУНВР.
>может покажите где в продакшене это Г юзают ?
У нас например. Все довольны.
>>эт вы у меня спрашиваете ? протестируйте если не готовили
> УНВР.
>>может покажите где в продакшене это Г юзают ?
> У нас например. Все довольны.конфиги в студию
>конфиги в студиюХехе. Может, еще и приватные ключи от серверов, где данные лежат? :)
>>конфиги в студию
> Хехе. Может, еще и приватные ключи от серверов, где данные лежат? :)а кто вам говорит чтобы вы палили адреса - трудно заменить ? или у вас конфиг дороже ключей ?
хотите я вам нарисую ваш конфиг ?
>а кто вам говорит чтобы вы палили адреса - трудно заменить ? или у вас конфиг дороже ключей ?Правила безопасности запрещают раскрывать подобные данные. И я не враг своему здоровью.
>хотите я вам нарисую ваш конфиг ?
Ну нарисуйте. Приду на работу - гляну отличия, обсудим с админами стораджей.
И чего? Для больших CDN такое поведение более чем нормально. Врубится нода - пройдет репликация.
> И чего? Для больших CDN такое поведение более чем нормально. Врубится нода
> - пройдет репликация.отлично и вы это называете репликацией ?
я же сказал залейте файлы а потом отрубите - не сказал же во время залива отрубите
Дык асинхронный режим. Так и должно быть
эта ФС совсем из другой весовой (нишевой) категории
> эта ФС совсем из другой весовой (нишевой) категориив смысле из другой ? - что они обе не распределённые кластерные ?
или одна за бабло а другая опенсоурс ?
пс: хотя вы правы куда ей до категории GPFS
> или одна за бабло а другая опенсоурс ?
> пс: хотя вы правы куда ей до категории GPFSЭто главное. Наколеночное опенсорсное поделие дилетантов просто не может сравниваться с полноценным проприетарным продуктом, сделанным уважаемой компанией, ага.
Знаем мы эту гнилую логику.
Ни когда опен соурс не был авторитетнее проприетарщины
Надеюсь, ее наконец-то перенесут из фузи в ядро. Еще сам Линус говорил, что хороших скоростей из фузи не выжать.
такую вешь нельзя заносить в ядро. Хочешь скорости - используй libglusterfs
>такую вешь нельзя заносить в ядро.Почему?
>Хочешь скорости - используй libglusterfs
В смысле, напрямую в приложениях? Та еще веселуха...
>такую вешь нельзя заносить в ядро. Хочешь скорости - используй libglusterfsДрайвер в ядро, в user-friendy (всмысле прикладной) код в юзерспесе. И чего нельзя - когда вполне можно (нужно?) ?
Может я и не прав, но вроде бы держать данные неструктурированными - не самая лучшая идея? Откуда берётся 80% неструктурированных данных?
> Откуда берётся 80% неструктурированных данных?Из бестолковых пользователей :(
Файлопомойки. На корпоративных файлопомойках может быть структура, но каждый юзер норовит что-нибудь спрятать или копирует туда что-то "на время", а в результате - та же файлопомойка.
>Может я и не прав, но вроде бы держать данные неструктурированными - не самая лучшая
>идея? Откуда берётся 80% неструктурированных данных?Вы не правы. Данные всегда (!) структурированы (даже если лежат блобом), поэтому конктеризируйте что именно не ясно?
Ну, IMHO, правильная позиция по поводу необходимости в лёгкой масштабируемости... Однако, я не хочу, конечно, троллить или ещё что, но помнится, пробовал этот GlusterFS для реализации одного кластера. Хоть уже несколько мутно помню, но, если меня не подводит память, скорость работы упёрлась в CPU, а не в скорость raid-ов. OCFS2 over DRBD работает ощутимо быстрее, а CPU по сути вообще не жрёт. Да и вообще, не помню ниодной FUSE-реализации чего-либо, чтобы это работало нормально:
- sshfs - глючит
- ntfs - тормозит
- curlftpfs - отлетает
- glusterfs - тормозит
etc
А что вы от фузи хотели? Вот ежели загонят в ядро, да прямыми руками - летать будет.
> А что вы от фузи хотели? Вот ежели загонят в ядро, да
> прямыми руками - летать будет.Я то от FUSE ничего не хотел, но вот то, какие надежды Red Hat возлагает на GlusterFS немного удивляет. :)
Что ещё более удивительно, они FUSE-овость считают плюсом. Это, конечно, имеет свои плюсы, но не для продакшена, IMHO.
>- sshfs - глючитЛПП
>>- sshfs - глючит
> ЛППЯ, конечно, не знаю как сейчас, но я припоминаю как раньше он то зависал, то отлетал через неделю, если пытаться держать постоянный mount и гонять там неплохой трафик (в моём случае, бекапы сбрасывать). Я дико извиняюсь, если таких проблем давно уже нет.
мде.. оно на фре и так собиралось через 1 место, сейчас конторка причиняющая добро доведет "до ума" еще больше. грусть.
> мде.. оно на фре и так собиралось через 1 место, сейчас конторка
> причиняющая добро доведет "до ума" еще больше. грусть.Ну да, ну да, нормальные программисты только в Apple.
>> мде.. оно на фре и так собиралось через 1 место, сейчас конторка
>> причиняющая добро доведет "до ума" еще больше. грусть.
> Ну да, ну да, нормальные программисты только в Apple.интересный вывод. можно узнать из чего он сделан?
Отлично! Лучшая новость за этот месяц с вероятностью 99%.
Используем GlusterFS в продакшне, замечательно масштабируется, никаких особых нареканий. Если RH допилит известные косячки - будет конфетка.
А скажите пожалуйста, на каком канале висят ноды GlusterFS у Вас? FC? IB? или Ethernet?
> А скажите пожалуйста, на каком канале висят ноды GlusterFS у Вас? FC?
> IB? или Ethernet?1Gbe, 10Gbe
И как оно на нем?
Просто у меня есть не совсем удачный опыт использования GlusterFS - при работе с мелкими файлами скорость проседала аж до 1-2 Мбайт/с . Мы использовали по 2а канала 1Gbit ethernet на ноду. Очень долго тьюнили, но не помогло в итоге. Решили, что это беда ethernet и что на fc/ib это должно решиться.
> Просто у меня есть не совсем удачный опыт использования GlusterFS - при
> работе с мелкими файлами скорость проседала аж до 1-2 Мбайт/с .Не поможет тут IB, да и что-либо еще - тоже вряд ли. GlusterFS просто не заточен под мелкие файлы с высокой частотой обращений, его применение - именно "толстый" контент (метр и выше).
Хотя - если правильно его готовить - у нас на нем работает и несколько PHP-хостов, просто надо аккуратно писать приложения, и пользоваться хоть каким-то SHM-акселератором, дабы снизить число чтений самих файлов (от stat это все равно не избавляет).
По конкретике - файлы от 2 до 16 мб. Упираемся в сеть и диск, но не в синхронизацию/CPU.
попробуйте последнюю версию 3.2.3, после апдейта на нее скорость возросла, например чтение с 10мб/с до 60мб/с
Хотя у нас критичные баги, которые не дают в полную меру пользоваться.
Вот этот я запостил (3487), а вот этот вызывает настороженность - 3534