Компания Red Hat, которая приобрела (http://www.opennet.ru/opennews/art.shtml?num=31941) в 2011 году распределённую кластерную файловую систему GlusterFS, объявила (http://www.redhat.com/about/news/press-archive/2013/5/gluste...) о трансформации проекта Gluster (http://www.gluster.org/) в новое сообщество для разработки свободных проектов, связанных с системами хранения данных. Из жёстко контролируемого проекта, развиваемого в соответствии с принципом Open Core (http://www.opennet.ru/opennews/art.shtml?num=27351) (открытая базовая часть и закрытый продукт с расширенными возможностями), Gluster теперь следует рассматривать как экосистему открытого ПО с быстро растущим числом проектов и участников.
Для обеспечения работы нового сообщества открыт ресурс Gluster Community Forge (https://forge.gluster.org), предоставляющий основанную на Gitorious среду совместной разработки, где участники могут как развивать имеющиеся, так и добавлять новые проекты. Коммерческий продукт на базе технологий GlusterFS по прежнему будет поставляться под именем Red Hat Storage Server (http://www.redhat.com/products/storage-server/).
На данный момент, кроме флагманского проекта GlusterFS Core (https://forge.gluster.org/glusterfs-core), в Gluster Comunity Forge будут развиваться такие проекты, как:
- pmux (https://forge.gluster.org/pmux) - написанная на языке Ruby система MapReduce, применяющая конвейерные обработки для распределенных вычислений на кластере GlusterFS и способная обрабатывать большие объемы данных, хранящихся в файлах;- gflocator (https://forge.gluster.org/gflocator) - демон для предоставления ответов на запросы о расположению файлов на узлах GlusterFS;
- HDFS plugin (https://forge.gluster.org/hdfs-shim) - проект, позволяющий использовать GlusterFS в Hadoop вместо или в дополнение к штатной HDFS;
- Интеграция Samba и GlusterFS (https://forge.gluster.org/samba-glusterfs) - цель проекта - совместное использование томов GlusterFS клиентами SMB;
- Dispersed Volume (https://forge.gluster.org/disperse) - система с задаваемым уровнем избыточности, похожая на RAID5/6, но для распределённой GlusterFS.
URL: http://www.redhat.com/about/news/press-archive/2013/5/gluste...
Новость: http://www.opennet.ru/opennews/art.shtml?num=36865
если упоминули Ruby то сразу понятно что не нужно, потому что тормоз
> Коммерческий продукт на базе технологий GlusterFSА люди за этот тормоз деньги еще платят, да?
> если упоминули Ruby то сразу понятно что не нужно, потому что тормозТак сейчас, когда код открыт, может кто то решится выпилить руби и заменить его на что то более быстрое. Хотя раз шапка не сделала этого ранее то им проект скорее всего вообще неинтересен
> Хотя раз шапка не сделала этого ранее то им проект скорее всего вообще неинтересенВпервые вижу таких добрых бизнесменов. Купили проект, который им заведомо неинтересен. Видимо, чтобы оказать благотворительную помощь предыдущим владельцам.
>> Хотя раз шапка не сделала этого ранее то им проект скорее всего вообще неинтересен
> Впервые вижу таких добрых бизнесменов. Купили проект, который им заведомо неинтересен.
> Видимо, чтобы оказать благотворительную помощь предыдущим владельцам.С конкуренциию подавляют скупкой конкурентов или патентов.
> С конкуренциию подавляют скупкой конкурентов или патентов.Замечательная версия. У нее всего один недостаток - непонятно, с каким продуктом редхата конкурировал gluster. С Linux?
К тому же патентов там никаких не было, а СПО покупать бессмысленно - его всегда можно форкнуть.
gpfs ? или как там называется кластер от redhat с жестко зашитым ограничением в 256 узлов..
GPFS - это у IBM. (IBM General Parallel File System)
А у RedHat это GFS2.
Вот только GFS2 - ни разу не конкурент для gluster. Потому что GFS - это только шарилка, там нет избыточности.
> Вот только GFS2 - ни разу не конкурент для gluster. Потому что
> GFS - это только шарилка, там нет избыточности.В GPFS тоже нет избыточности. Но и GPFS и GFS2 можно построить на RAID-ах.
> В GPFS тоже нет избыточности. Но и GPFS и GFS2 можно построить
> на RAID-ах.А вот в Gluster есть избыточность, при чем _сетевая_. Это вам не рейд.
>> Вот только GFS2 - ни разу не конкурент для gluster. Потому что
>> GFS - это только шарилка, там нет избыточности.
> В GPFS тоже нет избыточности. Но и GPFS и GFS2 можно построить
> на RAID-ах.Вообще-то, в GPFS есть прозрачная синхронная репликация между нодами как данных, так и метаданных, причем еще и с настраиваемым по отдельности replication factor.
> В GPFS тоже нет избыточности.ну здрасте, а нейтив рейд?
>> В GPFS тоже нет избыточности.
> ну здрасте, а нейтив рейд?Я строил кластер на 5-х рейдах без всякой репликации, т.к. места много нужно было для бакапов не данных с GPFS - а с клиентов ПО для бакапа инфраструктуры. И что бы бакап делался не по "тормознутой" сети - а по SAN.
там было другое (здесь же в новостях с год назад) - патентный тролль подал в суд на редхат, в ответ ему указали на наличие в его проприетарном поделии gpl-кода, после чего судиться стало не актуально. скорее всего и приобретали проект, чтобы спровоцировать наезд, ну и забрать все деньги и женщин обидчика :)
> там было другое (здесь же в новостях с год назад) - патентный
> тролль подал в суд на редхат, в ответ ему указали на
> наличие в его проприетарном поделии gpl-кода, после чего судиться стало не
> актуально. скорее всего и приобретали проект, чтобы спровоцировать наезд, ну и
> забрать все деньги и женщин обидчика :)Годы шли, а любители запихнуть код gluster в проприетарный продукт так и не находились...
> Впервые вижу таких добрых бизнесменов. Купили проект, который им заведомо неинтересен.
> Видимо, чтобы оказать благотворительную помощь предыдущим владельцам.Шапка купила, но это еще не значит что оно им действительно нужно, в конце концов, вспомните про Oracle и посмотрите теперь на MySQL. Возможно до покупки были какие-то миражи по поводу того что на этом можно сделать profit но после покупки, стало понятно что нельзя. Отдали в сообщество, возможно у людей из сообщества появится какие-то идеи, которые сделают проект более интересным и востребованным.
Шапка и Oracle - это как небо и земля. Достаточно сравнить модели развития Linux и MySQL.
> Шапка и Oracle - это как небо и земля. Достаточно сравнить модели
> развития Linux и MySQL.да да, достаточно сравнить. MySQL закрыл разве что тестовый набор и то до того как выпустят заплатку.
А шапка сделала закрытый репозиторий под свое ядро, занимается обфускацией патчей на ядро что бы осложнить другим анализ (да да - нагадить ksplice который продался не ей, а oracle), но попутно с ksplice нагадила еще и остальным открытым проектам. Но это не мешает евангелистам redhat лизать ей все что можно.
Про ksplice можно забывать. Если до оракла оно худо-бедно умело всё, то после оракла в принципе ни на что кроме OEL его вкручивать уже не рискнет почти никто.
скажите спасибо redhat и его защите бизнеса.
Показали пример как это можно делать - вот другие и пошли тем же путем..
Так почему redhat может защищать свой бизнес - а другим в этом отказано?
Меня сильно больше напрягает бардак с тем что я не вижу что за патчи были включены в ядро, это сказывается на стабильности моего продукта. А kplice это фиолетово, или можно просто подписать с ними контракт и все будет.
hint. при подписании контракта с ksplice - они могут делать поддержку всего что хочешь и предоставить тебе самому распространять патчи для своего дистрибутива.
> если упоминули Ruby то сразу понятно что не нужно, потому что тормозА то, что она через fuse работает, никого не смущает?
> если упоминули Ruby то сразу понятно что не нужно, потому что тормозЕсли бы ты потрудился открыть документацию, то ты бы узнал, что сами вычисления производятся не ruby-кодом, а внешними mapper-ами и reducer-ами, задаваемыми пользователем и вызываемыми pmux-ом. Сам pmux занимается только раскидыванием задач по нодам и вводом-выводом, а для этого скорость исполнения кода не важна.
по RoR ruby не судят
Этот гластер - поделие, тьфу на него еще раз, мучался с ним два года. Сейчас на MooseFS переходим.
> Этот гластер - пoдeлue, тьфy на него еще раз, мuчaлcя с ним два года.Да, yжac. Пробовали Ceph, но у него к CPU больше требования.
> Сейчас на MooseFS переходим.
Спасибо за наводку, посмотрим...
то, что вы мучал'ись - не говорит о плохой реализация glusterFS (Moose тоже не совершенство)
p.s. еще и два года)
а в роли какой фс его использовать ? может нфс ? да нет стандартный нфс куда стабильнее, может шаред фс ? - да нет куда стабильнее ocfs2, дистрибьютед ? - хехехе куда лучше уж люстру, а если ещё и денег достаточно можно и gpfsтак что в полне разумный вопрос - где его использовать ?
вот и красношляпники тоже посмотрели, почесали репу на тему "где его использовать ?" и решили что подкормив сообщество очередным полунужным хламом, они может получат хоть какие-то плюшки и развитие, да и карму плюсанут неплохо.
> вот и красношляпники тоже посмотрели, почесали репу на тему "где его использовать
> ?" и решили чтоузнают об этом из следующего релиза федоры. ну, на крайний, дебиана.
> вот и красношляпники тоже посмотрели, почесали репу на тему "где его использовать
> ?" и решили что подкормив сообщество очередным полунужным хламом, они может
> получат хоть какие-то плюшки и развитие, да и карму плюсанут неплохо.Аналогичных систем всего 2-3. Люстра, сабж и HDFS. Другие или не активно развиваются или проприетарь или еще чего.
И да, конкуренция идет на пользу потребителям и сообществу.
Xen VS KVM
Lustre VS Gluster
Tomcat VS JBoss (шутка смешного юмора ;) )
> Аналогичных систем всего 2-3. Люстра, сабж и HDFS. Другие или не активно развиваются или проприетарь или еще чего.POHMELFS :)
>> Аналогичных систем всего 2-3. Люстра, сабж и HDFS. Другие или не активно развиваются или проприетарь или еще чего.
> POHMELFS :)это которая позволяет писать в 1 файл только одному клиенту? которая принципиально O_APPEND не обрабатывает правильно? как там у нее с flock для поддержки samba и MPI ?
ceph. Которая кстати в ядро уже включена.
>> вот и красношляпники тоже посмотрели, почесали репу на тему "где его использовать
>> ?" и решили что подкормив сообщество очередным полунужным хламом, они может
>> получат хоть какие-то плюшки и развитие, да и карму плюсанут неплохо.
> Аналогичных систем всего 2-3. Люстра, сабж и HDFS. Другие или не активно
> развиваются или проприетарь или еще чего.это не конкурент люстре :-) совсем совсем другие требования..
Lustre VS Glusterнебо и земля не стоит сравнивать
> Lustre VS Gluster
> небо и земля не стоит сравниватьИ по общей сложности поддержки - тоже.
> вот и красношляпники тоже посмотрели, почесали репу на тему "где его использовать
> ?" и решили что подкормив сообщество очередным полунужным хламом, они может
> получат хоть какие-то плюшки и развитие, да и карму плюсанут неплохо.Аналогичная история произошла лет 20 назад - тогда редхат никак не мог придумать, что делать с ненужным пoделием одного финского студента, и решил слить его сообществу. До сих пор плюшки гребут.
> Аналогичная история произошла лет 20 назад - тогда редхат никак не мог
> придумать, что делать с ненужным пoделием одного финского студента, и решил
> слить его сообществу. До сих пор плюшки гребут.Про 20 лет почти угадал.
"""Компания начала свою работу в 1993 году, [...] В 2003 году Red Hat сменила политику выпуска дистрибутивов, отказавшись от выпуска коробочных версий Red Hat Linux (последняя коробочная версия Red Hat Linux 9) и превратив внутренний процесс разработки Red Hat Linux в открытый проект Fedora [...]
>> Аналогичная история произошла лет 20 назад - тогда редхат никак не мог
>> придумать, что делать с ненужным пoделием одного финского студента, и решил
>> слить его сообществу. До сих пор плюшки гребут.
> Про 20 лет почти угадал.
> """Компания начала свою работу в 1993 году, [...] В 2003 году Red
> Hat сменила политику выпуска дистрибутивов, отказавшись от выпуска коробочных версий Red
> Hat Linux (последняя коробочная версия Red Hat Linux 9) и превратив
> внутренний процесс разработки Red Hat Linux в открытый проект Fedora [...]вот вот :-) в 2003 году - redhat закрыла итоговый результат и стала продавать его. А сообществу выпихнула недоделки.
Т.е. до 2003 года они ничего не продавали и жили на средства спонсоров?
если посмотреть на капитализацию и доходы RedHat - она резко пошла в гору - когда они закрыли бинарные пакеты и вообще все связаное с RHEL - "подарив" сообществу Fedora.
И что именно всё? Вам название centos жмёт? Ибо от RHEL он названием и копирайтом отличается.
> И что именно всё? Вам название centos жмёт? Ибо от RHEL он
> названием и копирайтом отличается.О да, а закрытые для постороннего репозитории RHEL тоже не существуют? Или обновления centOS выходят прямо вот сразу? Вы никогда не сталкивались что в CenOS поломаны зависимости и поставить пакет из CentOS в систему с RHEL не возможно? ну и последнее - как не купив поддержки в redhat посмотреть какие патчи были наложены на ядро? или вас устраивает большая мешанина в которой разобраться не реально?
> ну и последнее - как не купив
> поддержки в redhat посмотреть какие патчи были наложены на ядро? или
> вас устраивает большая мешанина в которой разобраться не реально?Знатное пригорание седалища у ораклышей. Оно того стоило, определенно :)
если вы не заметили у Oracle - свое ядро, а ядро redhat они все равно без ограничений раскладывают на патчи и выкладывают для сообщества.Кому это подгадило - так это дебиан, CentOS (отгрызло тот кусок платного сапорта который они могли дать и чем пробывали зарабатывать на хлеб), SL, Lustre и тп которые так или иначе использовали ядро redhat в своих проектах, видимо это того стоило?
Даже lwn.net считает что redhat поступил не коректно -http://lwn.net/Articles/430098/
Ну да - подгадить всем кто это использует - это же так в традициях redHat, а вы не стесняйтесь - несите дальше деньги шапке.. может еще еще лизнуть при случае..
> если вы не заметили у Oracle - свое ядро, а ядро redhat
> они все равно без ограничений раскладывают на патчи и выкладывают для
> сообщества.Тогда почему именно у ораклят так пригорает анус?
> Тогда почему именно у ораклят так пригорает анус?Наверное, все дело в том, что именно оракл пытается свое чудо-инновационное тырпрайз-ядро строить на основе редхатовского. А у всяким дебианам нужны разве что критические багфиксы и исправления безопасности.
Вот ораклыши и кричать "ай бида-бида, дебиан-то ущемляют, жпл нарушают, гады-разбойники, перевешать их всех во главе с Торвальдсом!"
>> Тогда почему именно у ораклят так пригорает анус?
> Наверное, все дело в том, что именно оракл пытается свое чудо-инновационное тырпрайз-ядро
> строить на основе редхатовского. А у всяким дебианам нужны разве что
> критические багфиксы и исправления безопасности.наверно не в курсе - но ядро у них свое полностью. Стоило бы учить матчасть, ребетенок :-)
>> если вы не заметили у Oracle - свое ядро, а ядро redhat
>> они все равно без ограничений раскладывают на патчи и выкладывают для
>> сообщества.
> Тогда почему именно у ораклят так пригорает анус?видимо потому что по себе судишь ?:)
>> ну и последнее - как не купив
>> поддержки в redhat посмотреть какие патчи были наложены на ядро? или
>> вас устраивает большая мешанина в которой разобраться не реально?
> Знатное пригорание седалища у ораклышей. Оно того стоило, определенно :)к слову - это была такая защита их бизнеса (в чем они сознавались - Red Hat reported its fiscal 2011 revenues this week which hit $909 million. Going forward, Red Hat has already taken steps to protect its business by changing the way it packages the Red Hat Enterprise Linux 6 kernel).
только видимо свобода и соблюдение требований GPL для них пустой звук - каждый патч состоит из описания (это требование lkml) и самого изменения - так почему-то redhat считает возможным проводить обфускацию исходников и вырезания описаний - которые являются частью изменений.
Ну да - для защиты своего бизнеса все средства хороши - даже нарушения лицензий.
> только видимо свобода и соблюдение требований GPL для них пустой звук -
> каждый патч состоит из описания (это требование lkml) и самого измененияТак-так. GPL и LKML - это уже синонимы?
> - так почему-то redhat считает возможным проводить обфускацию исходников и вырезания
> описаний - которые являются частью изменений.Респект им и уважуха. Пусть эффективные менеджеры оракла попыхтят :)
> Ну да - для защиты своего бизнеса все средства хороши - даже нарушения лицензий.
Если в их действиях действительно есть нарушение GPL - подай на них в суд и отсуди стопицот тыщ мильенов, делов-то. А то демагогию разводить каждый горазд, а как до дела дойдет - шумно сдувается.
>> только видимо свобода и соблюдение требований GPL для них пустой звук -
>> каждый патч состоит из описания (это требование lkml) и самого изменения
> Так-так. GPL и LKML - это уже синонимы?красиво передернул. возьми пирожек - LKML был приведен как пример каким был исходный патч.
Но ведь вырезать из оригинала куски и не показывать GPL разрешает? ведь так?>> - так почему-то redhat считает возможным проводить обфускацию исходников и вырезания
>> описаний - которые являются частью изменений.
> Респект им и уважуха. Пусть эффективные менеджеры оракла попыхтят :)респерт за то что создали проблемы открытым проектам? Да - я понимаю вас, с промытыми мозгами.
Главное что у корпорации добра добавилось денег - а проблемы открытым проектам - это же фигня?
Кто за такое их осудит?
>> Ну да - для защиты своего бизнеса все средства хороши - даже нарушения лицензий.
> Если в их действиях действительно есть нарушение GPL - подай на них
> в суд и отсуди стопицот тыщ мильенов, делов-то. А то демагогию
> разводить каждый горазд, а как до дела дойдет - шумно сдувается.У меня денег сильно меньше - что бы выиграть. Но высказывать мне свое мнение о их позиции - видимо можно?
> в CenOS поломаны зависимости и поставить пакет из CentOS в систему
> с RHEL не возможно? ну и последнее - как не купивПоставить пакет из CentOS в систему с RHEL... это прекрасно. То, что они бинарно совместимы по API ядра, библиотек и софта (+ бинарно идентичны на 99%) - не обещает совместимости на уровне зависимостей пакетов. А вообще - лучше сначала думать, потом делать. А то так можно докатиться до того, что обвинить все линухи в том, что на них Win32 EXE нативно не запускаются.
>> в CenOS поломаны зависимости и поставить пакет из CentOS в систему
>> с RHEL не возможно? ну и последнее - как не купив
> Поставить пакет из CentOS в систему с RHEL... это прекрасно. То, что
> они бинарно совместимы по API ядра, библиотек и софта (+ бинарно
> идентичны на 99%) - не обещает совместимости на уровне зависимостей пакетов.пошли отмазки :-) то есть нельзя вот прям так взять пакет который создан был для RHEL и без пересборки поставить в CentOS? То есть CentOS выходит не юзабельный и не разу не замена для RHEL как тут предлагали?
> А вообще - лучше сначала думать, потом делать. А то так
> можно докатиться до того, что обвинить все линухи в том, что
> на них Win32 EXE нативно не запускаются.hint. у wine был модуль который грузился как доп. бинарный формат и позволял запускать MZ бинарники.
hint2. win4lin (если не путаю) делал тоже самое путем патчей на ядро (времен 2.4).
> пошли отмазки :-) то есть нельзя вот прям так взять пакет который
> создан был для RHEL"Пакет, который создан был для RHEL", и "пакет из RHEL" - разница есть?
Всё, что "создано для RHEL", у меня на центу вставало без проблем. ЧЯДНТ?
Тем более, что ты пел об обратном процессе - перетащить пакет из CentOS в RHEL - ЗАЧЕМ????
>> пошли отмазки :-) то есть нельзя вот прям так взять пакет который
>> создан был для RHEL
> "Пакет, который создан был для RHEL", и "пакет из RHEL" - разница
> есть?
> Всё, что "создано для RHEL", у меня на центу вставало без проблем.
> ЧЯДНТ?
> Тем более, что ты пел об обратном процессе - перетащить пакет из
> CentOS в RHEL - ЗАЧЕМ????Я "пел" о том что CentOS нефига не совместим с RedHat - в первую очередь по тому что RedHat (весь такой открытый) закрывает процесс сборки пакетов и всячески усложняет клонирование.
И "пел" о закрытых для некупивших сапорт - репозиториях с бинарными пакетами - которых в виде src.rpm не выкладывают на сайте - да нет никакой гарантии что то что выложено - совпадает с тем что они реально собирают.
"пел" о том что redhat "защищая" свой бизнес - создает постоянно проблемы другим открытым продуктам.
"пел" о качестве сборки CentOS - когда пакеты имеют кривые зависимости. и пакет пересобранный из src.rpm на CentOS (но созданный на RHEL) - отказывается ставиться на CentOS из-за того что зависимости не могут быть разрешены, и это не решается без правки spec файла.
hint. когда кончаются аргументы - не стоит пытаться унизить собеседника своим хамством.
> Я "пел" о том что CentOS нефига не совместим с RedHatС какого бы перепугу он не был совместим? Весь софт под редхат, модули ядра и прочее - отлично встает. А попытки совместить RHEL+CentOS в одном флаконе - это твои ЛПП.
> "пел" о качестве сборки CentOS - когда пакеты имеют кривые зависимости. и
> пакет пересобранный из src.rpm на CentOS (но созданный на RHEL)Пример пакета в студию.
> hint. у wine был модуль который грузился как доп. бинарный формат и позволял запускать MZ бинарники.Это штатная функция ядра, вайн там сбоку.
> hint2. win4lin (если не путаю) делал тоже самое путем патчей на ядро (времен 2.4).
Совсем путаете.
а я и не говорю что это не штатная функция ядра - я говорю что в составе wine был модуль для MZ бинарей - что бы прозрачно запускать - который использовал эту функцию.win4lin - могу путать :-) давно было .осталось ощущение безшовного запуска винды в линухе - но сам не использовал.
> а я и не говорю что это не штатная функция ядра -
> я говорю что в составе wine был модуль для MZ бинарей
> - что бы прозрачно запускать - который использовал эту функцию.Да не было никакого специального модуля. Просто настройками ядра задавалось, что при попытке выполнить файл filename, начинающийся с MZ, следовало выполнять wine filename.
> вот вот :-) в 2003 году - redhat закрыла итоговый результатВаганыч, залогинься.
>> вот вот :-) в 2003 году - redhat закрыла итоговый результат
> Ваганыч, залогинься.Подлизывай дальше шапке. А она пусть продолжает дальше гадить другим открытым проектам в которых находит себе конкурентов ('We are the top commercial contributor to most of the components of the Linux kernel and we think we have a lot of value and we want to make sure that, that value is recognized,' Red Hat CEO Jim Whitehurst said. 'In terms of competition, I don't think we necessarily saw anything different from before but I'd say better to close the barn door before the horses leave than afterwards.'" )
да да, close barn door для CentOS / SL / Debian - это же так благородно..
ну и за одно..
http://raphaelhertzog.com/2011/02/17/people-behind-debian-ma.../
ну как - удалось лизнуть шапке? дали бесплатную лицензию на RHEL?
> да да, close barn door для CentOS / SL / Debian - это же так благородно..Напомни-ка, что там с barn door применительно к MySQL?
>> да да, close barn door для CentOS / SL / Debian - это же так благородно..
> Напомни-ка, что там с barn door применительно к MySQL?это такой способ съезжать с темы? но вот продолжим обсуждение поведения redhat - а то оказывается они ведут себя не лучше чем клятый Оракл - но ему то можно, он корпорация зла, а вот redhat.. они же корпорация добра - как они могут то?
> ну как - удалось лизнуть шапке? дали бесплатную лицензию на RHEL?Я их люблю не за бесплатные лицензии, а токмо за то, что они твой сpаный оракл щемят во всех позах. За одно это им надо дать орден беззаветного человеколюбия.
>> ну как - удалось лизнуть шапке? дали бесплатную лицензию на RHEL?
> Я их люблю не за бесплатные лицензии, а токмо за то, что
> они твой сpаный оракл щемят во всех позах. За одно это
> им надо дать орден беззаветного человеколюбия.смешной ты :-) оракл не мой, но лично он мне проблем не доставлял - в отличии от redhat.
> вот вот :-) в 2003 году - redhat закрыла итоговый результат и
> стала продавать его. А сообществу выпихнула недоделки.Так ты продукт redhat для "сообщества"? Да, дествительно, как-то "незавершённо" выглядишь :(
плюсануть карму за NNN бабла... сам придумал, или подсказал кто?
так оно уровня люстры. +/- где то рядом.конечно с ocfs2 не сравнимо - для этого у них gfs2.
> так оно уровня люстры. +/- где то рядом.уровня люстры? хм.. вы скажите - оно как с RDMA? как оно на скоростях 4Gb/s по сети?
К слову, поддержка RDMA у glusterfs есть.
> К слову, поддержка RDMA у glusterfs есть.в fuse ? ;-)
>> К слову, поддержка RDMA у glusterfs есть.
> в fuse ? ;-)man ibverbs
ibverbs в userland? хотя да - что-то пробывали, и даже новый тип сокетов для этого придумали..
> ibverbs в userland? хотя да - что-то пробывали, и даже новый тип
> сокетов для этого придумали..В общем-то, ibverbs - это всего лишь API, причем в линуксе раскручивающееся напрямую в uapi ядра, никакими сокетами там не пахнет, особенно в RDMA, где семантика обмена данными (put/get) от принятой в сокетах (send/recieve) отличается кардинально.
Про сокеты ты, наверное, с SDP спутал.
да нет.. не спутал..config RDS
tristate "The RDS Protocol (EXPERIMENTAL)"
depends on INET && EXPERIMENTAL
---help---
The RDS (Reliable Datagram Sockets) protocol provides reliable,
sequenced delivery of datagrams over Infiniband, iWARP,
or TCP.
tcp сделали недавно. до этого был только IB & iWarp.кстати сделан был ненавистным тут ораклом.
а семантика в RDMA - по моей памяти не то что бы сильно отличается. разве что разница в 2х этапном get/put (сначала iov и (или) служебные данные - потом уйдут сами данные) - что позволяет очень легко обернуть в сокетовый уровень. Даже когда-то делал такую обвертку наколенке..
>> К слову, поддержка RDMA у glusterfs есть.
> в fuse ? ;-)К тому же, fuse - это интерфейс для взаимодействия с VFS (к слову, не единственный, есть также поддержка протокола NFS). Передачей же данных между нодами занимаются другие части кода.
>>> К слову, поддержка RDMA у glusterfs есть.
>> в fuse ? ;-)
> К тому же, fuse - это интерфейс для взаимодействия с VFS (к
> слову, не единственный, есть также поддержка протокола NFS). Передачей же данных
> между нодами занимаются другие части кода.к слову fuse не только отвечает за vfs (aka md операции) но интерфейс взаимодействия с MM и передача данных. Которая со слов прозвучавших на Storage Summit - реализована из рук вон плохо, и минимальными телодвижениями можно получить 2-3x прирост скорости.
> к слову fuse не только отвечает за vfs (aka md операции) но
> интерфейс взаимодействия с MM и передача данных. Которая со слов прозвучавших
> на Storage Summit - реализована из рук вон плохо, и минимальными
> телодвижениями можно получить 2-3x прирост скорости.GlusterFS упирается в round-trip, FUSE там не помеха. Тащить в пространство ядра сложный код FS, да еще вдоль и поперек завязанный на сеть - затея геморройная.
но люстра и IBM это же сделали ?:)причем в обоих случаях красиво вынеся сетевой обмен в отдельный уровень.
> а в роли какой фс его использовать ? может нфс ? да
> нет стандартный нфс куда стабильнее, может шаред фс ? - да
> нет куда стабильнее ocfs2, дистрибьютед ? - хехехе куда лучше уж
> люстру, а если ещё и денег достаточно можно и gpfsВы хотя бы примерно представляете себе структуру кластера для люстры? А для gpfs?
>> а в роли какой фс его использовать ? может нфс ? да
>> нет стандартный нфс куда стабильнее, может шаред фс ? - да
>> нет куда стабильнее ocfs2, дистрибьютед ? - хехехе куда лучше уж
>> люстру, а если ещё и денег достаточно можно и gpfs
> Вы хотя бы примерно представляете себе структуру кластера для люстры? А для
> gpfs?вам пруфлинки нужны ? (http://paranoidchaos.livejournal.com/2111.html)
да прекрасно обе фс в кластере поднимал.ps: жаль я весь процесс с люстрой не описал
> а в роли какой фс его использовать ? может нфс ? да
> нет стандартный нфс куда стабильнее, может шаред фс ? - да
> нет куда стабильнее ocfs2, дистрибьютед ? - хехехе куда лучше уж
> люстру, а если ещё и денег достаточно можно и gpfs
> так что в полне разумный вопрос - где его использовать ?gpfs тоже не без греха. Пару лет назад ее пытались использовать в одном хостинге под хранилище виртуальных дисков, так его и так и сяк подкручивали, но в оно продакшене недолго продержалось из-за постоянных проблем с стабильностью под данным видом нагрузки.
>> а в роли какой фс его использовать ? может нфс ? да
>> нет стандартный нфс куда стабильнее, может шаред фс ? - да
>> нет куда стабильнее ocfs2, дистрибьютед ? - хехехе куда лучше уж
>> люстру, а если ещё и денег достаточно можно и gpfs
>> так что в полне разумный вопрос - где его использовать ?
> gpfs тоже не без греха. Пару лет назад ее пытались использовать в
> одном хостинге под хранилище виртуальных дисков, так его и так и
> сяк подкручивали, но в оно продакшене недолго продержалось из-за постоянных проблем
> с стабильностью под данным видом нагрузки.Начиная с версии 3.3 она уже гораздо получше будет. 3.3,3.4,3.5 развиваются и фиксятся в параллель, просто у каждой версии свой EOL. Вот например Скалакси её юзают, правда немного переделали под себя (на habrahabr их статьи), хотя по-моему это всё уже реализовали в 3.4 & 3.5.
Вообще-то, я именно о скалакси и рассказывал (если мне не изменяет память, там использовался gpfs 3.3) :)
GPFS в продакшене продержался очень недолго и почти сразу же был произведен переход на SRP+MDRAID+DM/LVM.
На хабре об этом упоминалось в статье http://habrahabr.ru/company/oversun/blog/116137/
> Вообще-то, я именно о скалакси и рассказывал (если мне не изменяет память,
> там использовался gpfs 3.3) :)
> GPFS в продакшене продержался очень недолго и почти сразу же был произведен
> переход на SRP+MDRAID+DM/LVM.
> На хабре об этом упоминалось в статье http://habrahabr.ru/company/oversun/blog/116137/Да, и чем потом сказка кончилась - http://habrahabr.ru/post/146971/ с Xen -> Hyper-V.
А лучше вот так http://habrahabr.ru/search/?q=%5Bscalaxy%5D&target...
А идея и реализация действительно были хороши.
> Да, и чем потом сказка кончилась - http://habrahabr.ru/post/146971/ с Xen -> Hyper-V.Эмм... скалакси до сих пор на Xen. На Hyper-V совершенно другой проект компании Оверсан-Меркурий, от которой Скалакси отделился.
Вы даже свой единственный источник habrahabr умудряетесь по диагонали читать, ошибаясь во втором утверждении подряд.
>> Да, и чем потом сказка кончилась - http://habrahabr.ru/post/146971/ с Xen -> Hyper-V.
> Эмм... скалакси до сих пор на Xen. На Hyper-V совершенно другой проект
> компании Оверсан-Меркурий, от которой Скалакси отделился.
> Вы даже свой единственный источник habrahabr умудряетесь по диагонали читать, ошибаясь
> во втором утверждении подряд.Я сильно и не вчитывался что у них там сейчас, да и с хостингом никоим образом не связан. Но GPFS разрабатывался не для VM-хостинга - а для HPC & Backup. Хотя если GPFS строить на нормальном SAN/Infiniband-сторедже (коего нет у Скалакси из-за стоимости) с правильной разбивкой, а лучше несколько или за кластером SAN Volume Controller - то это будет совсем другой разговор и производительность.
> на нормальном SAN/Infiniband-сторедженормальный - это какой? где в тамошнем узкие места?
> с правильной разбивкой
А чем в скалакси она неправильна?
Не подумай, что я придираюсь, просто если резюмировать твои заявления, то получается: "с профилем нагрузки я не знаком, но GPFS не для таких задач, ситуацию я не знаю, но, вообще, у них железо плохое и руки кривые, и все равно GPFS весь в белом". Остановись для начала на чем-нибудь одном.
>> а в роли какой фс его использовать ? может нфс ? да
>> нет стандартный нфс куда стабильнее, может шаред фс ? - да
>> нет куда стабильнее ocfs2, дистрибьютед ? - хехехе куда лучше уж
>> люстру, а если ещё и денег достаточно можно и gpfs
>> так что в полне разумный вопрос - где его использовать ?
> gpfs тоже не без греха. Пару лет назад ее пытались использовать в
> одном хостинге под хранилище виртуальных дисков, так его и так и
> сяк подкручивали, но в оно продакшене недолго продержалось из-за постоянных проблем
> с стабильностью под данным видом нагрузки.в моих тестах gpfs была намного стабилнее люстры
Используем Gluster в роли подложки для кластеризованного бэкенда.
И как?
> И как?Работает. Тормозновато с кучей мелких файлов, но репликация не подводила ни разу. Центральный вебхост на GlusterFS крутится вполне себе нормально. Основное требование - минимизация stat, это самая тормозная операция в GlusterFS.
Еще юзаем для бэкапов, тоже вполне себе неплохо - автоматическая переливка данных по сети и автоматический шардинг.
lustre не умеет реплицировать данные. Эт эдакий raid0 по сети.
единственный достойный конкурент glusterfs это ceph. Файловая система cephfs ещё не готова к промышленной эксплуатации (сервер метаданных только один), но кластер блочных устройств rbd вполне юзабелен и уже используется, например для виртуальных машин в proxmox, ganeti и opennebula. При этом ceph укладывает gluster на лопатки как по скорости так и по надежности.
> lustre не умеет реплицировать данные. Эт эдакий raid0 по сети.
> единственный достойный конкурент glusterfs это ceph. Файловая система cephfs ещё не готова
> к промышленной эксплуатации (сервер метаданных только один), но кластер блочных устройств
> rbd вполне юзабелен и уже используется, например для виртуальных машин в
> proxmox, ganeti и opennebula. При этом ceph укладывает gluster на лопатки
> как по скорости так и по надежности.Кстати, в РФ RBD-кластер в промышленной эксплуатации использует проект Flops
>Кстати, в РФ RBD-кластер в промышленной эксплуатации использует проект FlopsЭто объясняет жалобы пользователей на форуме http://forum.flops.ru в стиле
"Молодцы парни, отличный у Вас "облачный хостинг". Регулярные падения раз-два раза в сутки."
Ребалансировка rbd кластера приводит к залипаниям ввода/вывода у виртуалок kvm. Ещё у osd серверов ceph есть проблемы с утечкой памяти. В общем не скучно наверное быть админом в flops.ru.
> lustre не умеет реплицировать данные. Эт эдакий raid0 по сети.не умеет. да и не надо было. Хотя если почитаете материалы последнего LUG - то проект network raid реанимировали.
вы лучше скажите - как cephfs и gluster на скоростях гигабайты в секунду по ib?
как у них проблемы с recovery - правда ли что cephfs - надеется только на репликацию - и требует в 2 раза больше дисков и электричества для хранения того же объема данных (hint - 12P дискового массива жрут очень дофига, что бы удваивать)
> как у них проблемы с recovery - правда ли что cephfs -
> надеется только на репликацию - и требует в 2 раза большеА какие способы гарантированного recovery кроме репликации вам известны?
>> как у них проблемы с recovery - правда ли что cephfs -
>> надеется только на репликацию - и требует в 2 раза больше
> А какие способы гарантированного recovery кроме репликации вам известны?гарантированного? а можно описать в каких случаях это вообще надо :-)
а то Cray об этом не в курсе и не использует recovery вообще :)
А так.. хотя бы журналирование данных и метаопераций.
> гарантированного? а можно описать в каких случаях это вообще надо :-)"Если мы что-то не поддерживаем, значит, вам это не нужно"
>> гарантированного? а можно описать в каких случаях это вообще надо :-)
> "Если мы что-то не поддерживаем, значит, вам это не нужно"к слову вариант для тех кому нужно - поддерживается :-)
>>> гарантированного? а можно описать в каких случаях это вообще надо :-)
>> "Если мы что-то не поддерживаем, значит, вам это не нужно"
> к слову вариант для тех кому нужно - поддерживается :-)Тогда зачем так старательно доказывать, что оно не нужно? Может, лучше сначала погуглить и выяснить, в каких именно аспектах требуется ваша яростная защита?
>>>> гарантированного? а можно описать в каких случаях это вообще надо :-)
>>> "Если мы что-то не поддерживаем, значит, вам это не нужно"
>> к слову вариант для тех кому нужно - поддерживается :-)
> Тогда зачем так старательно доказывать, что оно не нужно? Может, лучше сначала
> погуглить и выяснить, в каких именно аспектах требуется ваша яростная защита?старательно? я лишь сослался на опыт Cray ;-) вполне себе.. а как у вас запекло...
>>>> гарантированного? а можно описать в каких случаях это вообще надо :-)
>>> "Если мы что-то не поддерживаем, значит, вам это не нужно"
>> к слову вариант для тех кому нужно - поддерживается :-)
> Тогда зачем так старательно доказывать, что оно не нужно? Может, лучше сначала
> погуглить и выяснить, в каких именно аспектах требуется ваша яростная защита?кстати raid5/6 вполне могут обеспечить надежность без полной репликации данных - на этом был (и есть) основан люстровый network raid.
> кстати raid5/6 вполне могут обеспечить надежность без полной репликации данных - на
> этом был (и есть) основан люстровый network raid.Простите, как быть с вашим RAIDx, если потеряется вся нода целиком? Две ноды? В случае Gluster всё проще - там можно реплицироваться на любое число нод. At expense of performance.
>> кстати raid5/6 вполне могут обеспечить надежность без полной репликации данных - на
>> этом был (и есть) основан люстровый network raid.
> Простите, как быть с вашим RAIDx, если потеряется вся нода целиком? Две
> ноды? В случае Gluster всё проще - там можно реплицироваться на
> любое число нод. At expense of performance.нода целиком? это как? разу все диски рейд возьмут и умрут? для мисье секрет что raid5/6 может востанавливаться на воткнутый hot spare винт?
может не стоит покупать винчестеры по 20 баксов - а стоит посмотреть на серьезные вещи?
hint. наши железянщики рассказывают что не все марки одинаково хороши для рейдов + ext4 причем разница в скорости может достигать в разы - при одних и тех же параметрах md.
> нода целиком?Это очень просто. Например, сгорел контроллер или baseboard. Я даже больше скажу, ноды могут сразу целыми стойками из строя выходить даже при резервировании питания по независимым линиям: например, на одно из линий падает напряжение (трансформатор на подстанции взял и накрылся) во время пиковой нагрузки, и через второй PDU на другой линии в стойке ток поднялся выше расчетного значения, в итоге, второй PDU в стойке тоже отключился. И привет, стойка обесточена.
Подобных сценариев можно массу на ходу придумать. Именно поэтому равноправные узлы кластера в некоторых местах принято разносить по разным стойкам. Или, например, использовать несколько датацентров, строя архитектуру таким образом, чтобы выход из строя одного датацентра не прервал работу сервиса.
А ты: "диски, диски..."
> это как? разу все диски рейд возьмут и умрут?
Например, произошел сбой драйвера контроллера или сам контроллер сдох.
> Например, произошел сбой драйвера контроллера или сам контроллер сдох.Достаточно сдохнуть батарейке в рейд контроллере. Сразу-же отключается кэш на запись и весь массив становится неработоспособен.
>> Например, произошел сбой драйвера контроллера или сам контроллер сдох.
> Достаточно сдохнуть батарейке в рейд контроллере. Сразу-же отключается кэш на запись и
> весь массив становится неработоспособен.Ну... уж не всё так страшно :) Современные контроллеры прекрасно работают без батарейки, в режиме кеширования write-through
>> нода целиком?
> Это очень просто. Например, сгорел контроллер или baseboard. Я даже больше скажу,
> ноды могут сразу целыми стойками из строя выходить даже при резервировании
> питания по независимым линиям: например, на одно из линий падает напряжение
> (трансформатор на подстанции взял и накрылся) во время пиковой нагрузки, и
> через второй PDU на другой линии в стойке ток поднялся выше
> расчетного значения, в итоге, второй PDU в стойке тоже отключился.
> И привет, стойка обесточена.Если случится такое - то выход из строя ноды будет самое легкое что произойдет. Худшее - очередной атлантис сдохнет на орбите или биологический/ядерный эксперемент накроется :-)
Это будет веселее.
> Подобных сценариев можно массу на ходу придумать. Именно поэтому равноправные узлы кластера
> в некоторых местах принято разносить по разным стойкам. Или, например, использовать
> несколько датацентров, строя архитектуру таким образом, чтобы выход из строя одного
> датацентра не прервал работу сервиса.:-) у вас слишком простой сценарий.
> А ты: "диски, диски..."
>> это как? разу все диски рейд возьмут и умрут?откройте для себя disk backplane с JBOD контролером.
hint. так и вижу как фирма расчитывающая спецэфекты для черного рыцаря (ну или любую другую что они делали) - ходит через океан на другой DC за файлами с кадрами.
>Если случится такое - то выход из строя ноды будет самое легкое что произойдет.Если ноды зарезервированы, то это будет единственное, что произойдет.
>:-) у вас слишком простой сценарий.
На сложность претензий не было, скорее, наоборот, это первое, что в голову пришло :)
>откройте для себя disk backplane с JBOD контролером.
В общем-то, тупой HBA вместо RAID-контроллера от сбоя драйвера этого HBA не защищает. И уж тем более, не предотвращает простой, если диски подключены через единственный контроллер.
А резервировать каждый компонент сервера, и все равно с отсутствием гарантии, что нода не может стать недоступна, не факт, что дешевле, чем поставить 2 менее дорогих ноды с меньшим уровнем внутреннего резервирования.>hint. так и вижу как фирма расчитывающая спецэфекты для черного рыцаря (ну или любую другую что они делали) - ходит через океан на другой DC за файлами с кадрами.
Эта фирма не ходит, а многие другие ходят, чтобы не допустить глобального простоя сервиса в случае катастрофы. Я о том тебе и говорю, что задачи и требования разные бывают и считать, что всем в качестве средства резервирования подойдут исключительно RAID-массивы, а большего никому не требуется - наивно. Тот же гугл, например, почему-то, одни рейд-массивы не устраивают.
> нода целиком? это как?Это элементарно: умерла мать/память/RAID-контроллер / порвали оптику/патчкорд до FCoE-коммутатора / etc. Т.е. выпала вся нода целиком.
> мисье секрет что raid5/6 может востанавливаться на воткнутый hot spare винт?
Постановка задачи однозначная: выпала НОДА, а не "все винты умерли", и нечего додумывать. Не важно, что там случилось. Пожар в DC был, может быть, и умерло всё, а не только винты. Или питалово отключили просто (тогда данные целы, но толку от них чуть менее, чем 0). Главное - нода потеряна.
Итак, что будем делать? И как поможет RAID1/5/6/100500 в данном случае?
>> нода целиком? это как?
> Это элементарно: умерла мать/память/RAID-контроллер / порвали оптику/патчкорд до FCoE-коммутатора
> / etc. Т.е. выпала вся нода целиком.и что? JBOD SAS и active-passive резервирование на соседную материнку. какое-то время проживет - при этом в течении часа сдохшее поменяют.
>> мисье секрет что raid5/6 может востанавливаться на воткнутый hot spare винт?
> Постановка задачи однозначная: выпала НОДА, а не "все винты умерли", и нечего
> додумывать. Не важно, что там случилось. Пожар в DC был, может
> быть, и умерло всё, а не только винты. Или питалово отключили
> просто (тогда данные целы, но толку от них чуть менее, чем
> 0). Главное - нода потеряна.
> Итак, что будем делать? И как поможет RAID1/5/6/100500 в данном случае?у вас слишком маленькие объемы данных что бы защищать это реплицированием - и слишком маленькие скорости - что бы работало в разнесенных географически DC. когда у вас начнут требовать скорости 2.5Gb/s на запись per node и 4GB/s на чтение и объемы данных per node - от 20P тогда поговорим о реплицировании и разнесении по разным датацентрам.
hint. если что-то с питанием - страдает все - а не только 1 нода :-) пожар ровно так же. Но все это сильно искуственные условия.
> и что? JBOD SAS и active-passive резервирование на соседную материнку. какое-то время
> проживет - при этом в течении часа сдохшее поменяют."В течение часа" для телекома, например - это ни хрена не допустимый простой.
Остальное - вода. Кто-то делает, кто-то ищет отговорки вида "вот когда начнут".
>> и что? JBOD SAS и active-passive резервирование на соседную материнку. какое-то время
>> проживет - при этом в течении часа сдохшее поменяют.
> "В течение часа" для телекома, например - это ни хрена не допустимый
> простой.
> Остальное - вода. Кто-то делает, кто-то ищет отговорки вида "вот когда начнут".:-) смешной ты. так что там на счет JBOD SAS и disk backplane к 2 разным материнкам, с резервированием по блокам питания и сетевым? с дополнительными блоками защиты на входе в каждую стойку и в целом всей комнаты? Телеком всегда на таком экономил.
ну и отдельной электростанцией :-)
hint. японский кластер из top100 (не помню уже его теперешнюю позицию) - потреблял около 6-10Мегаватт*ч. Да да - я посмотрю как будет резервироваться такая мощность :-) и в какую копеечку этот резерв обойдется вам.
hint2. репликация может (и частично должна) делаться другими средствами - а не FS. в частности HSM - хорошо "реплицирует" FS на ленточки.
>>> и что? JBOD SAS и active-passive резервирование на соседную материнку. какое-то время
>>> проживет - при этом в течении часа сдохшее поменяют.
>> "В течение часа" для телекома, например - это ни хрена не допустимый
>> простой.
>> Остальное - вода. Кто-то делает, кто-то ищет отговорки вида "вот когда начнут".
> :-) смешной ты. так что там на счет JBOD SAS и disk
> backplane к 2 разным материнкам, с резервированием по блокам питания и
> сетевым? с дополнительными блоками защиты на входе в каждую стойку и
> в целом всей комнаты?А что там насчет стоимости полного резевирования каждого компонента в сравнении с стоимостью второй обычной ноды?
> ну и отдельной электростанцией :-)
Отдельной подстанцией. С распределением нагрузки в энергосети между разными электростанциями энергетики сами справляются.
> hint2. репликация может (и частично должна) делаться другими средствами - а не
> FS. в частности HSM - хорошо "реплицирует" FS на ленточки.А что там с доступностью и актуальностью данных, хранящихся на лентах? У меня такое чувство, что ты путаешь цели бэкапов и high availability.
> А что там насчет стоимости полного резевирования каждого компонента в сравнении с стоимостью второй обычной ноды?Не каждого. active-passive я не зря указал.
> Отдельной подстанцией. С распределением нагрузки в энергосети между разными электростанциями энергетики сами справляются.не хватит :-)
> А что там с доступностью и актуальностью данных, хранящихся на лентах? У меня такое чувство, что ты путаешь цели бэкапов и high availability.
HSM - вполне может справиться в real time с заливанием на ленты. главное сделать правильно.
для FS это выглядит как обычный файл при доступе к которому возникает задержка (если так настроено).ps. вариантов может быть чуть более чем дофига - и без гемороя с репликацией и контролем целостности в этом случае
pps. о parity declustering я в курсе.
>> А что там насчет стоимости полного резевирования каждого компонента в сравнении с стоимостью второй обычной ноды?
> Не каждого. active-passive я не зря указал.active-standby или active-active - не важно. Стоимость железа, поддерживающего такую конфигурацию, выше, порой, намного. А отсутствие SPOF на нижних уровнях архитектуры опять же не гарантируется. Проще, дешевле и надежнее при построении масштабного сервиса сразу предусматривать отказоустойчивую архитектуру, а не молиться на фичастые полки и RAID.
>> Отдельной подстанцией. С распределением нагрузки в энергосети между разными электростанциями энергетики сами справляются.
> не хватит :-)Вот прям всякому, кому необходима отказоустойчивость, и не хватит? :)
>> А что там с доступностью и актуальностью данных, хранящихся на лентах? У меня такое чувство, что ты путаешь цели бэкапов и high availability.
> HSM - вполне может справиться в real time с заливанием на ленты.А с production-нагрузкой он справится? Еще раз, не путай бэкапы и отказоустойчивость всей системы. Они нацелены на решение разных проблем.
> главное сделать правильно.
> для FS это выглядит как обычный файл при доступе к которому возникает
> задержка (если так настроено).Да пусть этот архив как угодно выглядит, хоть gopher-ресурсом прикидывается. Если при выходе из стоя одной ноды ты лезешь в библиотеку за резервной копией, а сервис при этом лежит - это уже не система для широкой промышленной эксплуатации. В лучшем случае, это нишевое решение для работы специальных условиях, а в худшем - локалхост школьника Пети (это еще умный школьник, если он бэкапы делает).
> ps. вариантов может быть чуть более чем дофига - и без гемороя
> с репликацией и контролем целостности в этом случаеЛюбое распределенное хранилище построено на компромиссе между условиями CAP-теоремы. Либо оно не распределенное и является одним большим SPOF.
> :-) смешной ты. так что там на счет JBOD SAS и disk
> backplane к 2 разным материнкамА как насчет отказа backplane?
Или таки как насчет пожара в ДЦ? Развертываемся из бэкапа с ленточек несколько суток?
Я предпочту онлайновую репликацию. Неважно, hot или hot standby.
>> :-) смешной ты. так что там на счет JBOD SAS и disk
>> backplane к 2 разным материнкам
> А как насчет отказа backplane?лежит рядом готовый к замене. Замена отработана и тп. Для выработавщих ресурс проводится предварительная замена.
> Или таки как насчет пожара в ДЦ? Развертываемся из бэкапа с ленточек
> несколько суток?
> Я предпочту онлайновую репликацию. Неважно, hot или hot standby.если сгорит ДЦ у NASA - то потери от данных - будут самым малым что может быть.
Тоже самое можно сказать про Лос-Аламос (ака sandia.gov), или Ок Ридж.опять же HSM - прозрачно перекинет данные с FS на ленту.
>лежит рядом готовый к замене. Замена отработана и тп. Для выработавщих ресурс проводится предварительная замена.Поздравляю с даунтаймом. А даунтайма быть не должно.
>опять же HSM - прозрачно перекинет данные с FS на ленту.
Ага, а когда сдохнет production-сервер, все будет лежать, а ты будешь восстанавливать данные с ленты. Нафига такое счастье?
У меня складывается такое впечатление, что ты нам тут растолковываешь, как сделать так, чтобы данные не потерялись, а мы тебе толкуем о том, что даже простой сервиса - это уже ЧП, а потеря данных - за гранью добра и зла.
еще раз почитайте что такое HSM.в момент _обращения_ данные прийдут с ленты. прозрачно для приложения.
> еще раз почитайте что такое HSM.
> в момент _обращения_ данные прийдут с ленты. прозрачно для приложения.Т.е. придется еще держать кластер из ленточных накопителей + связанную с ними дисковую полку + робота для загрузки? Выйдет в десятки раз дороже. Спасибо, у нас задача - не попилить на инфраструктуре, а решить проблему отказоустойчивости с минимальными затратами и максимальным эффектом.
Еще раз: латентностные характеристики ленточного хранилища позволят ему выдержать production-нагрузку?
Хорошая компания! :)
с хорошей практикой покупки проектов открытых|закрытых с дальнейшей открытой разработкой :)
> Хорошая компания! :)
> с хорошей практикой покупки проектов открытых|закрытых с дальнейшей открытой разработкой
> :)Жалко ksplice проморгали. Сейчас он в какое-то УГ превратился под эгидой одной известной шараги.
>> Хорошая компания! :)
>> с хорошей практикой покупки проектов открытых|закрытых с дальнейшей открытой разработкой
>> :)
> Жалко ksplice проморгали. Сейчас он в какое-то УГ превратился под эгидой одной
> известной шараги.Это вы так о redhat отзываетесь? да.. эти делали что могли что бы усложнить работу ksplice team раз уж не смогли его купить. В результате - с чего бы им любить остальных? может спросим с redhat - чего это они так не любят открытость и кооперацию.. ?
> Это вы так о redhat отзываетесь? да.. эти делали что могли чтоДля тупых: ksplice сейчас под эгидой oracle.
> бы усложнить работу ksplice team раз уж не смогли его купить.
> В результате - с чего бы им любить остальных? может спросим
> с redhat - чего это они так не любят открытость и
> кооперацию.. ?То, что получилось в результате покупки ксплайса ораклом, вы называете открытостью и кооперацией? До покупки хотя бы часть исходников была открыта. После покупки - где оно?
>> Это вы так о redhat отзываетесь? да.. эти делали что могли что
> Для тупых: ksplice сейчас под эгидой oracle.для очень тупых - как только redhat не смогло купить ksplice - так сразу начало гадить всем, закрывать все что можно и "защищать" свой бизнес.
>> бы усложнить работу ksplice team раз уж не смогли его купить.
>> В результате - с чего бы им любить остальных? может спросим
>> с redhat - чего это они так не любят открытость и
>> кооперацию.. ?
> То, что получилось в результате покупки ксплайса ораклом, вы называете открытостью и
> кооперацией? До покупки хотя бы часть исходников была открыта. После покупки
> - где оно?Ответ на позицию redhat. почему редхату можно защищать свой бизнес а другим нет?
Многовато постов твоих, "я бежала за вами три дня чтобы сказать как вы мне безразличны". Босс за ставил вляпаться в Оракл, и теперь жар снизу обязывает клаву до крови сбивать обcирая Redhat в каждой теме? "У оракла свое ядро" "федора тестовый полигон"... Оракл запрещает публиковать бенчмарки своей БД (вообще лютый пипец, типа Ходжы Насреддина "запрещаю думать про обезьяну"), это тоже шапка виновата?
переход на личности? а по теме что сказать то хотел.
глупое вы Страшило, отправляйтесь к Гудвину))