форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
Сообщение от opennews (??) on 19-Мрт-10, 23:42
Линус Торвальдс утвердил (http://lwn.net/Articles/379554/rss) включение в состав Linux-ядра 2.6.34 кода файловой системы Ceph (http://ceph.newdream.net/), способной поддерживать работу хранилища объемом в несколько петабайт (1 Пб = 1024 Тб), распределенного по тысячам машин. В запросе (http://groups.google.ru/group/kernelarchive/msg/329b77b1d40e...) на интеграцию Ceph в состав ядра сообщается, что последние несколько месяцев стабильность работы Ceph была существенно улучшена и компания Red Hat собирается включить поддержку работающей на уровне пользователя реализации Ceph в дистрибутив Fedora 13. Встроенные в Ceph механизмы репликации данных (данные разбиваются на блоки и несколько раз дублируются на разных машинах) обеспечивают чрезвычайно высокую живучесть системы. При добавлении или удалении новых узлов, массив данных автоматически ребалансируется с учетом изменения конфигурации. В Ceph имеется поддержка снапшотов, причем снапшот может быть создан не только для ФC, но и для ... URL: http://lwn.net/Articles/379554/rss Новость: http://www.opennet.dev/opennews/art.shtml?num=25879
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

5. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
Сообщение от psix on 20-Мрт-10, 01:21
А чем оно отличается от ZFS или RAID-Z что лучше использовать для построения распределенных отказоустойчивых хранилищ ?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от pavlinux (ok) on 20-Мрт-10, 01:23
	Люстру.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–2 +/–
	Сообщение от минона on 20-Мрт-10, 02:10
	думаешь ceph не справиться? зы: там кстати по 2-ой ссылке и другая новость есть http://ceph.newdream.net/ >RBD: rados block driver >Christian Brunner sent an initial implementation of ‘rbd’, a librados-based block driver for qemu/KVM, to the ceph-devel list last week. A few minor nits aside, it looks pretty good and works well. The basic idea is to stripe a VM block device over (by default) 4MB objects stored in the Ceph distributed object store. This gives you shared block storage to facilitate VM migration between hosts and fancy things like that. и т.д. что тоже весьма интересно
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от _umka_ (??) on 20-Мрт-10, 10:48
	у ceph не было рековери как класс (во всяком случае еще год назад) - а значит данные которые были на клиенте в момент обрыва линка и не сохраненные на persistent storage - с большой веросятностью будут в /dev/null
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–1 +/–
	Сообщение от минона on 20-Мрт-10, 13:47
	Ceph's main goals are to be POSIX-compatible, and completely distributed without a single point of failure. The data is seamlessly replicated making it fault tolerant
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–1 +/–
	Сообщение от минона on 20-Мрт-10, 14:01
	Strong reliability and fast recovery — All data in Ceph is replicated across multiple OSDs. If any OSD fails, data is automatically re-replicated to other devices. However, unlike typical RAID systems, the replicas for data on each disk are spread out among a large number of other disks, and when a disk fails, the replacement replicas are also distributed across many disks. This allows recovery to proceed in parallel (with dozens of disks copying to dozens of other disks), removing the need for explicit “spare” disks (which are effectively wasted until they are needed) and preventing a single disk from becoming a “RAID rebuild” bottleneck.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–1 +/–
	Сообщение от _umka_ (??) on 20-Мрт-10, 15:16
	и ? не надо путать 2 режима - востановление после сбоя и умирания одного из osd девайсов, и востановление состояния после аварийного reboot. Приведу простейший пример - raid обычном серваке.  рейд может рассыпаться - и его можно востановить вызвав recovery - но при этом вы должны остановить все программы которые работают с raid и теряете то что наработали программы в кэшах. и возможно вам прийдется запустить ext3/ext4 с abort journal что бы они чего не натворили. И вам нужен запуск fsck для проверки непротиворечивости метаданных на FS. - обычный аварийный reboot - тогда файловая система с журналированием выполняет journal replay для обеспечения непротиворечивости мета-данных на FS. Вот если мой склероз не изменяет - ceph работал именно как raid, а не как журналируемая FS. а у люстры recovery это несколько другая вещь - апаратную целостность данных она не контролирует (для это есть апаратные возможности рейдов или DDN storages). Lustre recovery ближе к journal replay у журналируемых FS - когда по информации с клиентов востанавливается журнал не записаных на диск операций - и выполняется повторное выполнение их для обеспечения EOS (executed once semantic). понятна разница ?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	21. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от VBart on 20-Мрт-10, 16:17
	Вы хотя бы читали то что вам процитировали? Ceph это вам не raid и не journal fs, а гораздо надежнее. Вы можете в любой момент выбросить любой из osd (даже парочку) или добавить новых, и система автоматически на лету реконфигурируется не приостанавливая обслуживания ни на секунду.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от _umka_ (??) on 21-Мрт-10, 09:43
	читал и смотрел ceph достаточно внимательно. перечитайте раздел ceph recovery - вся их защита построена на репликации данных по кластеру. что позволяет при выходе одного из osd из строя выполнять rebuild (аналогично как работает raid-5 + горячий резерв). Это и не большее - скрывается за их описанием. >> For example, suppose osd1 crashes and is marked down, and osd2 takes over as primary for pgA. If osd1 recovers, it will request the latest map on boot, and a monitor will mark it as up. When osd2 receives the resulting map update, it will realize it is no longer primary for pgA and send the pgA version number to osd1. osd1 will retrieve recent pgA log entries from osd2, tell osd2 its contents are current, and then begin processing requests while any updated objects are recovered in the background. >> если допустить что оба osd на которых находится реплика окажутся в down (тривиальный network flap) - будут проблемы. Так как обмена "логом изменения" с клиента на osd - не предусмотрена дизайном.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	34. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от VBart on 21-Мрт-10, 20:08
	"одного из osd из строя выполнять rebuild (аналогично как работает raid-5 + горячий резерв)" Во-первых ни одного, а даже большего количества, все зависит от количества реплик в системе. Во-вторых так называемый вами "rebuild" будет и так выполняется постоянно в фоне в зависимости от нагрузки, количество реплик для самых востребованных данных будет увеличиваться. И выкидывание\добавление нод в систему максимально просто и эффективно. "Так как обмена "логом изменения" с клиента на osd - не предусмотрена дизайном." Какой лог изменений? Нахрен он нужен? Вы видимо не понимаете для построения каких систем эта ФС будет просто сказочна. Вот у меня есть 1000 серверов набитых дешевыми жесткими дисками, дешевыми комплектующими. Нужно объединить их в единое пространства для хранения огромного количества файлов: графических, видео. При этом ежеминутно, 24x7, десятки тысяч пользователей запрашивают разные файлы, и тысячи пользователей загружают новые. Если один из серверов дохнет, я его просто выкидываю и втыкаю на его место новый. Ни о каком восстановлении данных, хранившихся конкретно на этом сервере, и речи идти не может. Некогда этим заниматься, система должна продолжать функционировать, как ни в чем не бывало, и сохранять свою целостность, ни один из файлов при этом не должен потеряться.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	36. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от _umka_ (??) on 21-Мрт-10, 22:06
	>"одного из osd из строя выполнять rebuild (аналогично как работает raid-5 + горячий резерв)" >Во-первых ни одного, а даже большего количества, все зависит от количества реплик в системе. Резвирование репликацией не лучший вариант. Всегда возможна ситуация когда выходят из строя или не доступны все реплики (сразу или по очереди - при этом последная полная реплика умирает до момента полного востановления первой). Это не считая того что 2 стораджа по 10P (сторадж стоящий в Ornl.gov) стоят очень дорого что бы так легко раскидываться местом. >"Так как обмена "логом изменения" с клиента на osd - не предусмотрена дизайном." >Какой лог изменений? Нахрен он нужен? Разберитесь в архитектуре FS, а покачто спрячьте свои пальцы - а то ведь отломают. для локальных FS - это называется журналом. в Ceph в приведенном фрагменте это называет "recent pgA log entries". остальной бред скипнут. Когда разберетесь как работает этот тип FS - приходите - поговорим.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	39. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от pavel_simple (ok) on 21-Мрт-10, 23:25
	>>"одного из osd из строя выполнять rebuild (аналогично как работает raid-5 + горячий резерв)" >>Во-первых ни одного, а даже большего количества, все зависит от количества реплик в системе. > >Резвирование репликацией не лучший вариант. дружок? ты откуда опять выплыл? слез со стакана и давай всех уму разуму? -- ну-ну
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	40. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от Andrey (??) on 21-Мрт-10, 23:34
	А он вас не оскорблял...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	42. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–1 +/–
	Сообщение от минона on 22-Мрт-10, 00:00
	видимо вы из тех, кто едет молча в трамвае, пока хамы пристают к остальным.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	44. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от VBart on 22-Мрт-10, 01:06
	>Резвирование репликацией не лучший вариант. Всегда возможна ситуация когда выходят из строя или не доступны все реплики (сразу или по очереди - при этом последная полная реплика умирает до момента полного востановления первой). Это не считая того что 2 стораджа по 10P (сторадж стоящий в Ornl.gov) стоят очень дорого что бы так легко раскидываться местом. Вы это гуглу расскажите. 5 стораджей по 10P на дешевых компонентах будут стоить на порядок дешевле, чем 2 по 10P на северных. А надежность будут обеспечивать при этом не меньшую. Картинка вот очень наглядная: http://blog.backblaze.com/wp-content/uploads/2009/08/cost-of... вот из этой статьи: http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-h.../ Резервирование репликацией это один из самых лучших, если не лучший вариант. Так резервируют самолетные системы, так резервируют системы атомных станций, именно дублированием. Нет ничего надежнее, чем дублирование. Ни одна, даже самая умная система журналирования, не спасет вас от аппаратного отказа оборудования и полной физической потери данных на узле. >Разберитесь в архитектуре FS, а покачто спрячьте свои пальцы - а то ведь отломают. для локальных FS - это называется журналом. в Ceph в приведенном фрагменте это называет "recent pgA log entries". Вопросы были риторические. Вы утверждаете, словно это проблема: >если допустить что оба osd на которых находится реплика окажутся в down (тривиальный network flap) - будут проблемы. Так как обмена "логом изменения" с клиента на osd - не предусмотрена дизайном. а я вам говорю, что для тех задач, на которые проектируются такие системы, это не является ключевой проблемой, поэтому и дизайном не предусмотрено. Если пойти по ссылкам из топика, то можно наткнуться на такой комментарий: http://lwn.net/Articles/379689/ - вот человек, понимает фишку Ceph
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	46. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от _umka_ (??) on 22-Мрт-10, 09:08
	>Вы это гуглу расскажите. 5 стораджей по 10P на дешевых компонентах будут стоить на порядок дешевле, чем 2 по 10P на северных. А надежность будут обеспечивать при этом не меньшую. Вы считаете только стоимость комплектующих. А теперь посчитайте сумарную стоимость владения этим решением: 1. вам потребуется в 2-3 раза больше электричества на ваш ДС (а следовательно более дорогие провода при разводке, больше счета за электричество). 2. 5 стоек выделяют более чем в 2-3 раза больше тепла - сразу возрастает количество систем охлаждения, вопросы с проведением воздуховдов и тп. 3. Это в ~2 раза больше площадь - за нее платить надо, ее охлаждать и тп. Учитывая что кластер в ornl (10P страдж + вычислительные ноды + все охлаждение) потребляет около 6МВатт - то потребуется построить еще одну электростанцию - ибо 2МВатт надо будет откуда-то взять. Как вам такие расходы ? PS. не задумывались почему гугл хочет открыть дочернее предприятие по продаже электричества? PPS. потребляемая мощность взята не из ornl - а из японского кластера ti-tech который меньше того что стоит в ornl - поэтому оценка скорее всего занижена. > Резервирование репликацией это один из самых лучших, если не лучший вариант. Так резервируют самолетные системы, так резервируют системы атомных станций, именно дублированием. Нет ничего надежнее, чем дублирование. Ни одна, даже самая умная система журналирования, не спасет вас от аппаратного отказа оборудования и полной физической потери данных на узле. спасет. Причем методика примерно аналогичная тому как востанавливают базы данных после сбоя. Сначала рейд выполняет свой rebuild - потом база данных накатывает собственный лог изменений, что бы дотянуть базу до актуального состояния.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	52. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от VBart on 22-Мрт-10, 20:39
	>[оверквотинг удален] >охлаждение) потребляет около 6МВатт - то потребуется построить еще одну электростанцию >- ибо 2МВатт надо будет откуда-то взять. > >Как вам такие расходы ? > >PS. не задумывались почему гугл хочет открыть дочернее предприятие по продаже электричества? > >PPS. потребляемая мощность взята не из ornl - а из японского кластера >ti-tech который меньше того что стоит в ornl - поэтому оценка >скорее всего занижена. Не переживайте, мы все посчитали. Вы считаете исходя из энергопотребления, которое производит стандартное серверное оборудование с малоемкими (320-750Гб), зато очень горячими и вращающимися на 15К оборотов, жесткими дисками. Которые подключены в серверные многопроцессорные материнские платы с прожорливыми серверными модификациями процессоров. При этом запиханы в корпуса с 3-10 мощнейшими высокооборотистыми вентиляторами для охлаждения всей этой печки и с парой мощных блоков питания для резерва. И вполне понятно, в системе в которой репликация не превышает единицы, предъявляются высокие требования к надежности и высокие требования к быстродействию каждого узла. В системе же, где мы можем получать данные параллельно со множества серверов, требования к быстродействию и надежности каждого отдельного узла - существенно меньше. И мы свободно можем собирать их на основе холодных объемных жестких дисков (1,5 - 2Тб) работающих на 5400 и потребляющих на порядок меньше энергии в расчете на гигабайт пространства. И все это под управлением microatx материнских плат с процессорами аля Intel Atom на борту. >PS. не задумывались почему гугл хочет открыть дочернее предприятие по продаже электричества? А не задумывались почему во всех отчетах гугл хвастается своей энергоэффективностью приводя количество энергии расходуемое на один запрос пользователя. И демонстрируя цифры гораздо более привлекательные, чем у стандартных серверных решений. При этом везде хвастаясь заботой о природе, продолжая увеличивать это показатели, дальше собирая свои дешевые, на простых комплектующих, маломощные сервера. >спасет. Причем методика примерно аналогичная тому как востанавливают базы данных после сбоя. > >Сначала рейд выполняет свой rebuild - потом база данных накатывает собственный лог >изменений, что бы дотянуть базу до актуального состояния. Каждая методика имеет ограниченную область эффективности. То что эффективно для базы данных с большим количеством мелких записей, будет абсолютно неработоспособно на файловой системе с меньшим количеством, но зато больших по объему файлов. Также надо учитывать частоту и объем обновлений. В отличии от того же лога изменений, который может пригодиться только в случае нештатной ситуации, а остальное время только в пустую расходует ресурсы, репликация увеличивает быстродействие за счет параллельного чтения данных сразу с нескольких устройств.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	45. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от VBart on 22-Мрт-10, 01:23
	>оба osd на которых находится реплика окажутся в down Для тех систем, для которых предназначена Ceph 1) Реплик для большей части данных должно быть >1 2) Даже если предположить, что для некоторого куска данных у нас всего одна реплика, то вероятность того, что "реплика" и "оригинал" окажутся именно на этих двух, вышедших из строя одновременно(!), серверов из 1000 - ничтожно мала, и скорее всего при этом совпадение будет только для очень малого фрагмента данных.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	47. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от _umka_ (??) on 22-Мрт-10, 09:11
	>>оба osd на которых находится реплика окажутся в down > >Для тех систем, для которых предназначена Ceph >1) Реплик для большей части данных должно быть >1 >2) Даже если предположить, что для некоторого куска данных у нас всего >одна реплика, то вероятность того, что "реплика" и "оригинал" окажутся именно >на этих двух, вышедших из строя одновременно(!), серверов из 1000 - >ничтожно мала, и скорее всего при этом совпадение будет только для >очень малого фрагмента данных. Сбои на свичах и фонящие кабеля у IB - я уже видел за время своей работы, и многие вещи вероятность которых ничтожна мала. PS. на кластерах размером 10-20к нод - в день умирает 1-2 ноды и это статистика собраная Cray.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	49. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от _umka_ (??) on 22-Мрт-10, 09:20
	>>оба osd на которых находится реплика окажутся в down > >Для тех систем, для которых предназначена Ceph >1) Реплик для большей части данных должно быть >1 >2) Даже если предположить, что для некоторого куска данных у нас всего >одна реплика, то вероятность того, что "реплика" и "оригинал" окажутся именно >на этих двух, вышедших из строя одновременно(!), серверов из 1000 - >ничтожно мала, и скорее всего при этом совпадение будет только для >очень малого фрагмента данных. PS. 1к нод это очень мало - имеет смысл разговаривать о 10-50к нод - тогда и статистика будет совсем другой. вместо одного выхода из строя в неделю - к тому что ноды постоянно выходят из строя - и кластер постоянно находится в состоянии востановления своих частей.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	22. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–1 +/–
	Сообщение от минона on 20-Мрт-10, 16:29
	>а у люстры recovery это несколько другая вещь - апаратную целостность данных она не контролирует это я то путаю? :D странный вы какой-то. вот несколько пунктов для усваивания: 1. OSDs usually store data on raw block devices, using a custom storage format called EBOFS 2. Internally, Btrfs bears some resemblance to Ebofs, the userland object file system developed for use in Ceph 3. The storage daemons rely on btrfs for storing data (and take advantage of btrfs' internal transactions to keep the local data set in a consistent state). This makes the storage cluster simple to deploy, while providing scalability not currently available from block-based Linux cluster file systems. 4. Ceph может работать поверх блочных устройств, внутри одного файла или через размещение данных в существующих ФС (например, XFS). т.е. поверх чего бы ceph не работал, он сохраняет данные в EBOFS. вот теперь можете рассказывать как 2-а режима... бороздят просторы большого театра :D
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	23. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–1 +/–
	Сообщение от минона on 20-Мрт-10, 16:47
	зы: на фоне вышесказанного lustre (которую уже надо переименовать в что-то типа sustre) выглядит набором костылей - A Lustre file system has three major functional units: 1. A single metadata target (MDT) per filesystem that stores metadata, such as filenames, directories, permissions, and file layout, on the metadata server (MDS) 2. One or more object storage servers (OSSes) that store file data on one or more object storage targets (OSTs). Depending on the server’s hardware, an OSS typically serves between two and eight targets, each target a local disk filesystem up to 8 terabytes (TBs) in size. The capacity of a Lustre file system is the sum of the capacities provided by the targets 3. Client(s) that access and use the data. Lustre presents all clients with standard POSIX semantics and concurrent read and write access to the files in the filesystem. и MDTs and OSTs currently use a modified version of ext3 to store data. In the future, Sun's ZFS/DMU will also be used to store data.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	29. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–1 +/–
	Сообщение от _umka_ (??) on 21-Мрт-10, 09:48
	>>а у люстры recovery это несколько другая вещь - апаратную целостность данных она не контролирует > >это я то путаю? путаешь. иди читай книжки по ceph архитектуре. > :D странный вы какой-то. вот несколько пунктов для >усваивания: >1. OSDs usually store data on raw block devices, using a custom >storage format called EBOFS и что ? как формат внутри одного osd связан с логикой обмена клиентов с эти самым OSD? >2. Internally, Btrfs bears some resemblance to Ebofs, the userland object file >system developed for use in Ceph да да. опять же - рассказываем что внутри osd - не обращая на взаимодействие клиентов кластера с этим самым osd. >3. The storage daemons rely on btrfs for storing data (and take >advantage of btrfs' internal transactions to keep the local data set >in a consistent state). This makes the storage cluster simple to >deploy, while providing scalability not currently available from block-based Linux cluster >file systems. да да. и как FS внутри OSD связано с механзмом обмена клиентов и OSD ? >4. Ceph может работать поверх блочных устройств, внутри одного файла или через >размещение данных в существующих ФС (например, XFS). >т.е. поверх чего бы ceph не работал, он сохраняет данные в EBOFS. это вобще хит сезона - как тип FS связан с recovery ? :-) > >вот теперь можете рассказывать как 2-а режима... бороздят просторы большого театра :D > покажи пожалуста хоть в одном из этих пунктов "распределенные транзакции" ? когда найдешь - тогда расскажешь.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	35. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от минона on 21-Мрт-10, 21:35
	>да да. опять же - рассказываем что внутри osd - не обращая на взаимодействие клиентов кластера с этим самым osd. ты орал про клиента? вот и получи. ну и раз ты такой большой спец, то и о RADOS должен был читать:       RADOS is a Reliable, Autonomic Distributed Object Store that provides excellent performance and reliability while scaling to many thousands of storage devices. RADOS facilitates an evolving, balanced distribution of data and workload across a dynamic and heterogeneous storage cluster while providing applications with the illusion of a single logical object store with well-defined safety semantics and strong consistency guarantees. >это вобще хит сезона - как тип FS связан с recovery ? :-) для идиотов - конечно. вот люстру можно на любую локальную fs поставить? нет? или ты, читающий всё и лучше всех, не видишь связи RADOS с EBOFS? ну и о чём тогда с тобой можно говорить. зы: т.е. о 2-х типах восстановления уже молчим? прогресс!!!:D
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	37. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от _umka_ (??) on 21-Мрт-10, 22:11
	>>да да. опять же - рассказываем что внутри osd - не обращая на взаимодействие клиентов кластера с этим самым osd. > >ты орал про клиента? вот и получи. ну и раз ты такой >большой спец, то и о RADOS должен был читать:   >    RADOS is a Reliable, Autonomic Distributed Object >Store that provides excellent performance and reliability while scaling to many >thousands of storage devices. RADOS facilitates an evolving, balanced distribution of >data and workload across a dynamic and heterogeneous storage cluster while >providing applications with the illusion of a single logical object store >with well-defined safety semantics and strong consistency guarantees. И что? Кроме лозунгов процитировать алгоритм работы можешь ? Или слабо? >>это вобще хит сезона - как тип FS связан с recovery ? :-) > >для идиотов - конечно. вот люстру можно на любую локальную fs поставить? >нет? От идиота слышу. Ты малыш научись сначала азбуке.. потом прочитай про архитектуру (как это работает внутри) А люстру да - можно поставить на любую создаем файл на этой fs - монтируем через loopback и вперед. >или ты, читающий всё и лучше всех, не видишь связи RADOS с >EBOFS? >ну и о чём тогда с тобой можно говорить. Научись сначала не оскорблять других. после этого поговорим. >зы: >т.е. о 2-х типах восстановления уже молчим? прогресс!!!:D С тобой смешно разговаривать. я процитировал тебе кусок из документации на Ceph - ты тихо слил и промолчал. PS. Когда научишся разбираться в предмете - приходи по говорим, а пока ничего кроме соплей от тебя не видно. Знаний тоже. Ну еще и хамство которым ты пытаешся прикрыть свои сопли и незнание предмета.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	41. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от минона on 21-Мрт-10, 23:57
	>И что? Кроме лозунгов процитировать алгоритм работы можешь ? Или слабо? процитировать? Да там в самой диссертации 239 страниц! походу ты хвастался, что читал. значит терминами владеть должен. а значит должен знать в частности о CRUSH (Controlled Replication Under Scalable Hashing), a pseudo- random data distribution algorithm that efficiently and robustly distributes object replicas across a heterogeneous, structured storage cluster), о том зачем ей RADOS, которому зачем то нужен EBOFS. >От идиота слышу. Ты малыш научись сначала азбуке.. потом прочитай про архитектуру (как это работает внутри) думаешь хамство исправит пробелы в твоем образовании? не надейся. малыш. :D >А люстру да - можно поставить на любую создаем файл на этой fs - монтируем через loopback и вперед. вот именно. >Научись сначала не оскорблять других. после этого поговорим. угу. тогда пробегись по ветке, встреть первое хамское высказывание и извинись. >С тобой смешно разговаривать. я процитировал тебе кусок из документации на Ceph - ты тихо слил и промолчал. Я процитировал архитектуру люстры. ты тихо слил. малыш. >PS. Когда научишся разбираться в предмете - приходи по говорим, а пока ничего кроме соплей от тебя не видно. Знаний тоже. Ну еще и хамство которым ты пытаешся прикрыть свои сопли и незнание предмета. видимо в люстре совсем плохи дела, если такие неучи на каждом углу орут что что-то туда пишут. печально.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	48. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от _umka_ (??) on 22-Мрт-10, 09:18
	>>И что? Кроме лозунгов процитировать алгоритм работы можешь ? Или слабо? > >процитировать? Да там в самой диссертации 239 страниц! Выдели кусок который подтверждает твой тезис и процитируй. >походу ты хвастался, что читал. значит терминами владеть должен. а значит должен >знать в частности о CRUSH (Controlled Replication Under Scalable Hashing), a >pseudo- >random data distribution algorithm that efficiently and robustly distributes object replicas across >a heterogeneous, structured storage cluster), о том зачем ей RADOS, которому >зачем то нужен EBOFS. и что? вопрос репликации весьма слабо корелируют с вопросами crash recovery. Поэтому они даже в описании архитектуры вынесены в разные разделы. >>От идиота слышу. Ты малыш научись сначала азбуке.. потом прочитай про архитектуру (как это работает внутри) > >думаешь хамство исправит пробелы в твоем образовании? не надейся. малыш. :D Нет перенимаю твой стиль, малыш :-P >>Научись сначала не оскорблять других. после этого поговорим. > >угу. тогда пробегись по ветке, встреть первое хамское высказывание и извинись. если для тебя слова "незнаешь предмерт" это хамаство ;-) ну так оно есть по правде. >>С тобой смешно разговаривать. я процитировал тебе кусок из документации на Ceph - ты тихо слил и промолчал. > >Я процитировал архитектуру люстры. ты тихо слил. малыш. это не архитектура :-) тем более могу сказать что ты цитировал устаревшие сведения. скорее всего от 1.6 - а есть таки 2.0. Спасибо за утренний смех :-)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	50. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от минона on 22-Мрт-10, 11:08
	вот как удачно всё складывается, учитывая ваш полный провал в доказательстве своих слов "у ceph не было рековери как класс", полный фэйл в "2 режима востановления", не знание терминологии, скатывание на оскорбления и под конец истерический смех. а я уж думал развить свою мысль, просмотрел истории изменений (типа commit ce464a5a0af670fba24ba37e9d44fa5e7112165a Author: Sage Weil <sage@newdream.net> Date:   Fri Feb 12 14:45:02 2010 -0800   osd: fix recovery requeue race и прочие osd: recovery fixes, journaling fixes) но до recovery osd (отсутствовавшего как класс :D) так и не дошло. а жаль. имеется в виду жаль, что в люстре сейчас именно такого класса "разработчики". помнится именно такие и слили сан (вашими же словами) как класс.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от pavlinux (ok) on 20-Мрт-10, 14:39
	>думаешь ceph не справиться? Думается, если работа идёт в юзерспейсе, то выигрышь будет только у распределённых приложений, и то, с точки зрения переноса вычислений на юзеров. Так что, нужно считать суммарные ресурсы (GHz + RAM + MSS time ...+ Х.З.)/юзеров  + сервера > >зы: >там кстати по 2-ой ссылке и другая новость есть http://ceph.newdream.net/ >>RBD: rados block driver >>Christian Brunner sent an initial implementation of ‘rbd’, a librados-based block driver for qemu/KVM, to the ceph-devel list last week. A few minor nits aside, it looks pretty good and works well. The basic idea is to stripe a VM block device over (by default) 4MB objects stored in the Ceph distributed object store. This gives you shared block storage to facilitate VM migration between hosts and fancy things like that. > >и т.д. что тоже весьма интересно Я бы сказал, это даже более интересно...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		–1 +/–
	Сообщение от минона on 20-Мрт-10, 15:00
	это до 34 ведра. в 33-е Торвальдс его не взял но мне нравиться ещё и это: >Internally, Btrfs bears some resemblance to Ebofs, the userland object file system developed for use in Ceph. However, Btrfs includes some critical features Ebofs does not (namely, copy-on-write semantics for file data), and is well maintained and tested. To avoid reinventing the wheel, Ceph will use btrfs on individual storage nodes (OSDs) to store object data, and we will focus on adding any additional functionality needed to btrfs where it will hopefully benefit non-Ceph users as well. http://ceph.newdream.net/wiki/Btrfs вполне возможно, что к промышленному применению они обе будут готовы почти одновременно. >Я бы сказал, это даже более интересно... безусловно практическое применение носит определяющий характер
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от anonymous (??) on 20-Мрт-10, 20:21
	У btrfs до сих пор нет банального fsck, если что то пойдет не так то только полное переформатирование, или недельные копания в исходниках и написание своих инструментов для лечения сбойных блоков и порушеной структуры. И тормозит она нещадно, причем мало что меняется за последние пол года. Нехорошие ощущения того что Oracle задумал недоброе.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от минона on 20-Мрт-10, 21:38
	как бы объяснить... это сейчас не гламурно. даже zfs поддалась этой пагубной привычке - http://opennet.ru/openforum/vsluhforumID3/60649.html или тут - http://hub.opensolaris.org/bin/view/Community+Group+zfs/faq#... зы: вот про астрал и секретные космические орбитальные отряды у вас не плохо получается. может не стоит менять профиль. а то если что случится, а у нас ни одного специалиста по пришельцам не останется. а про тормоза в бтре лучше у павлинуха спроси. мой лимит на разяснения кончился.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	32. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от alexxy on 21-Мрт-10, 11:33
	>У btrfs до сих пор нет банального fsck, если что то пойдет >не так то только полное переформатирование, или недельные копания в исходниках >и написание своих инструментов для лечения сбойных блоков и порушеной структуры. >И тормозит она нещадно, причем мало что меняется за последние пол >года. Нехорошие ощущения того что Oracle задумал недоброе. Уверен что нет? xeon ~ # qfile -v  btrfsck sys-fs/btrfs-progs-0.19 (/sbin/btrfsck) так что не прав ты. =)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	43. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от минона on 22-Мрт-10, 00:13
	он действительно пока не полностью реализован (последний коммит от 21 сентября - This patch adds semantic checks for links to snapshot/subvolume and root back/forward references.) но с другой стороны там даже дефрагментация есть :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
Сообщение от psix on 20-Мрт-10, 01:40
а RAID-Z ?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	30. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от alexxy on 21-Мрт-10, 11:28
	А он утебя сетевой? Имхо нет. так что идет лесом. еще давай вспомним по вероятность вытаскивания данных с него в случае краха zfs (она примерно ноль :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	38. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от Anon Y Mous on 21-Мрт-10, 23:12
	>А он утебя сетевой? Имхо нет. так что идет лесом. еще давай >вспомним по вероятность вытаскивания данных с него в случае краха zfs >(она примерно ноль :) А мужики то не знают. И вполне себе вытаскивают. Примеры сам найдешь или привести?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	51. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от аноним on 22-Мрт-10, 15:53
	приведите, если под рукой
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	53. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от Anon Y Mous on 23-Мрт-10, 01:43
	Погуглите по ключевым словам zfs pool recover rewind и их вариациям в домене opensolaris.org
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
Сообщение от aZ (ok) on 21-Мрт-10, 02:47
Очередная сотая фс в линуксе стабильность которой оставляет желать лучшего.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	31. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от alexxy on 21-Мрт-10, 11:29
	>Очередная сотая фс в линуксе стабильность которой оставляет желать лучшего. И что ты этим хочешь сказать? Назови мне фс под ругие операционные системы обладающие такими же свойствами.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	33. "В состав Linuх-ядра 2.6.34 будет включена распределенная фай..."		+/–
	Сообщение от aZ (ok) on 21-Мрт-10, 11:51
	Всё что хотел - я уже сказал.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема