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

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

"Создание хранилища способного пережить потерю диска"	+/–
Сообщение от Слоупок (ok) on 16-Июн-15, 09:22
Есть в наличии: Куча компьютеров и старых винтов. Требуется: Сделать SAN. Изначально идея такова: 1 Собрать несколько "серверов" набитых винтами, установить лёгкий Linux и экспортировать винты по гигабитной сети используя AoE. 2 Собрать NAS. На нём будет работать AoE-инициатор, который подцепит все накопители и LVM в который будут подключаться подцепленные из локальной сети винты и будут выглядеть в нём как Physical Volumes. Создаётся одна большая Volume Group и в ней один большой Logical Volume включающий в себя все Physical Volumes. Это даёт возможность безболезненно добавлять новые винты в дальнейшем просто расширяя LV. 2.1 В этом LV создаётся одна большая EXT4. 2.2 Доступ к большой EXT4 предоставляется с помощью SAMBA. И вот вопрос заключается в следующем. Что будет с такой схемой если например один винт просто умрёт, что на самом деле очень вероятно. Будет ли потеряна только та часть информации которая хранится на физических экстентах этого диска? Как отреагирует на это LVM, сделает недоступным весь LV или просто перестанет возвращать ФС запрашиваемую информацию с отсутствующих Physical Extents? Как отреагирует EXT4 на непредоставление ей данных от LVM при обращении к определённым файлам? Полностью умрёт или будет просто возвращать ошибку при обращении к данным которые были размещены на убитом диске? Если всё плохо, порекомендуйте пожалуйста ФС которая способна пережить подобные вещи. Ещё интересует как MDADM реагирует на такие вещи если сконфигурировать простой линейный массив. При смерти одного из дисков весь массив становится недоступен?
Ответить | Правка | Cообщить модератору

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

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

1. "Создание хранилища способного пережить потерю диска"	–1 +/–
Сообщение от pavel_simple (ok) on 16-Июн-15, 10:44
>[оверквотинг удален] > 2 Собрать NAS. На нём будет работать AoE-инициатор, который подцепит все накопители > и LVM в который будут подключаться подцепленные из локальной сети винты > и будут выглядеть в нём как Physical Volumes. Создаётся одна большая > Volume Group и в ней один большой Logical Volume включающий в > себя все Physical Volumes. Это даёт возможность безболезненно добавлять новые винты > в дальнейшем просто расширяя LV. > 2.1 В этом LV создаётся одна большая EXT4. > 2.2 Доступ к большой EXT4 предоставляется с помощью SAMBA. > И вот вопрос заключается в следующем. Что будет с такой схемой если > например один винт просто умрёт, что на самом деле очень вероятно. наступит логический конец всей этой странной затеи > Будет ли потеряна только та часть информации которая хранится на физических экстентах > этого диска? Как отреагирует на это LVM, сделает недоступным весь LV > или просто перестанет возвращать ФС запрашиваемую информацию с отсутствующих Physical > Extents? lvm отдаст то, что сможет > Как отреагирует EXT4 на непредоставление ей данных от LVM при обращении к > определённым файлам? Полностью умрёт или будет просто возвращать ошибку при обращении > к данным которые были размещены на убитом диске? перейдёт в ro, в лучшем случаее > Если всё плохо, порекомендуйте пожалуйста ФС которая способна пережить подобные вещи. fs тут не при чём -- если вам нужно HA -- то делать нужно на уровне блочного устройства > Ещё интересует как MDADM реагирует на такие вещи если сконфигурировать простой линейный > массив. При смерти одного из дисков весь массив становится недоступен? линейный массив? raid0? -- перейёт в режим degraded, будут отдовать то, что сможет. если нужно HA SAN на простом железе -- то для вас есть ceph, как в виде блочного устройства так и ввиде FS
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 11:25
	> наступит логический конец всей этой странной затеи Чем же затея странна? неужели утилизация старого железа с пользой сейчас не в моде? :) Реализация - да, выглядит возможно немножко по-дебильному, но я пытался использовать максимально простые и низкоуровневые инструменты для реализации странной затеи. В идеале я вижу это так: Человек собирает мусор в "сервер", накатывает на него образ системы и просто подключает винты на NAS. (кстати мне только что пришло в голову, что было бы неплохо использовать ФС, которые умеют расширяться без размонтирования) :) В случае если мусорный винт умер - менять нечем - _ключевой момент_ не делает ничего. Вот это важно. На информацию в таком случае просто забивают. На счёт замены и введения в работу нового - вопросительная ситуация. расширять-то файловую систему можно, но придётся по ходу действия видимо полечить её, чтобы она больше не надеялась увидеть данные с потерянных экстентов. HA с резервированием не нужно, это сжирает ёмкость, а ёмкость - это единственное ради чего всё затевается. Скорость так же должна быть максимальной однако даунтайм вполне допустим. > lvm отдаст то, что сможет Т.е. блокировки всего LV не случится, если один из используемых в нём PV умрёт, остальные данные останутся доступны, я верно понимаю? > перейдёт в ro, в лучшем случаее В EXT4 совсем не упираюсь. Но такое поведение неприемлемо в данном случае. Вообще мне кажется это странно себя так вести. ну допустим я использую винт который сам не переназначает сектора в случае их выхода из строя. Система не смогла извлечь информацию из своего нода - ок, это плохо, но зачем устраивать такую трагедю и переводить всё в ro. Я не отрицаю что я плохо разбираюсь в таких вещах, но логики тут вообще не вижу. Есть ли системы которые более толерантны к таким вещам? С распределёнными ФС связываться не готов да и эксплуатировать это будет некому. :( > fs тут не при чём -- если вам нужно HA -- то > делать нужно на уровне блочного устройства базируясь на ваших ответах прихожу к выводу, что причём. HA не нужно. > линейный массив? raid0? -- перейёт в режим degraded, будут отдовать то, что > сможет. Да, Linear mode. Это хорошо. > если нужно HA SAN на простом железе -- то для вас есть > ceph, как в виде блочного устройства так и ввиде FS Возможно я слишком громко выразился про SAN. По факту просто проект утилизации большого объёма ненужного железа, для задач хранения не критичной к потерям информации. Ceph мне почему-то кажется оверпауэром для этой странной затеи. Я не готов о нём думать пока не пойму что изначальную идею реализовать с помощью этих инструментов действительно невозможно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Аноним (??) on 16-Июн-15, 11:27
	>>[оверквотинг удален] >> И вот вопрос заключается в следующем. Что будет с такой схемой если >> например один винт просто умрёт, что на самом деле очень вероятно. > наступит логический конец всей этой странной затеи ну в общем да, но можно и dm-таржет сделать r5 скажем, или все это безобразие поверх md5-10 пустить. 5 тяжеловато будет, наверно. или можно btrfs попробовать с его raid-м.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 11:33
	>>>[оверквотинг удален] >>> И вот вопрос заключается в следующем. Что будет с такой схемой если >>> например один винт просто умрёт, что на самом деле очень вероятно. >> наступит логический конец всей этой странной затеи > ну в общем да, но можно и dm-таржет сделать r5 скажем, или > все это безобразие поверх md5-10 пустить. 5 тяжеловато будет, наверно. или > можно btrfs попробовать с его raid-м. Резервирование винтов под отказ с помощью RAID5/10 не рассматривается. Винты все разной ёмкости, сроить из них рэйда будет адским занятием и повысит стоимость эксплуатации всей системы до того уровня, когда действительно проще пойти в магазин и купить новый съёмный диск на 3ТБ. Интересует именно построение системы, которая будет терять винты/данные и работать дальше.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Создание хранилища способного пережить потерю диска"	+1 +/–
	Сообщение от дима (??) on 16-Июн-15, 12:11
	> Интересует именно построение системы, которая будет терять винты/данные и работать дальше. карго-культ
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	11. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 13:33
	>> Интересует именно построение системы, которая будет терять винты/данные и работать дальше. > карго-культ Не понимаю о чём идёт речь. :-)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	6. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Анонимфывфыв on 16-Июн-15, 12:29
	>[оверквотинг удален] >>>> например один винт просто умрёт, что на самом деле очень вероятно. >>> наступит логический конец всей этой странной затеи >> ну в общем да, но можно и dm-таржет сделать r5 скажем, или >> все это безобразие поверх md5-10 пустить. 5 тяжеловато будет, наверно. или >> можно btrfs попробовать с его raid-м. > Резервирование винтов под отказ с помощью RAID5/10 не рассматривается. Винты все разной > ёмкости, сроить из них рэйда будет адским занятием и повысит стоимость > эксплуатации всей системы до того уровня, когда действительно проще пойти в > магазин и купить новый съёмный диск на 3ТБ. > Интересует именно построение системы, которая будет терять винты/данные и работать дальше. да элементарно! каждый винт форматится в любую фс, и все собирается через unionfs или overlayfs в единую шару я так винты и утилизирую
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Анонимфывфыв on 16-Июн-15, 12:31
	>[оверквотинг удален] >>> все это безобразие поверх md5-10 пустить. 5 тяжеловато будет, наверно. или >>> можно btrfs попробовать с его raid-м. >> Резервирование винтов под отказ с помощью RAID5/10 не рассматривается. Винты все разной >> ёмкости, сроить из них рэйда будет адским занятием и повысит стоимость >> эксплуатации всей системы до того уровня, когда действительно проще пойти в >> магазин и купить новый съёмный диск на 3ТБ. >> Интересует именно построение системы, которая будет терять винты/данные и работать дальше. > да элементарно! каждый винт форматится в любую фс, и все собирается через > unionfs или overlayfs в единую шару > я так винты и утилизирую upd. можно часть винтов одинаковой емкости собирать в raid5 например 500гб в один том 1000 в другой том итд и все это через unionfs в одну точку
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 13:11
	> upd. можно часть винтов одинаковой емкости собирать в raid5 > например 500гб в один том 1000 в другой том итд > и все это через unionfs в одну точку RAID5/1/10 - точно нет. Ёмкость и скорость нужно максимизировать, процесс замены может происходит долго либо не произойти вообще. А за UnionFS спасибо, очень интересная концепция, погуглю и наличие многих ФС никак не противоречит моим целям, наоборот представляется весьма неплохой фичей страхующей от внезапных глобальных ошибок на одной единственной ФС. А насколько прозрачно для пользователя событие потери одной из входящих в неё ФС?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Анонимфывфыв on 16-Июн-15, 13:39
	>> upd. можно часть винтов одинаковой емкости собирать в raid5 >> например 500гб в один том 1000 в другой том итд >> и все это через unionfs в одну точку > RAID5/1/10 - точно нет. Ёмкость и скорость нужно максимизировать, процесс замены может > происходит долго либо не произойти вообще. > А за UnionFS спасибо, очень интересная концепция, погуглю и наличие многих ФС > никак не противоречит моим целям, наоборот представляется весьма неплохой фичей страхующей > от внезапных глобальных ошибок на одной единственной ФС. А насколько прозрачно > для пользователя событие потери одной из входящих в неё ФС? файлы пропадут те что бы ли на битом винте, и все
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Анонимфывфыв on 16-Июн-15, 13:41
	>> upd. можно часть винтов одинаковой емкости собирать в raid5 >> например 500гб в один том 1000 в другой том итд >> и все это через unionfs в одну точку > RAID5/1/10 - точно нет. Ёмкость и скорость нужно максимизировать, процесс замены может > происходит долго либо не произойти вообще. > А за UnionFS спасибо, очень интересная концепция, погуглю и наличие многих ФС > никак не противоречит моим целям, наоборот представляется весьма неплохой фичей страхующей > от внезапных глобальных ошибок на одной единственной ФС. А насколько прозрачно > для пользователя событие потери одной из входящих в неё ФС? aufs еще есть, это доработанная unionfs
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	17. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 14:03
	> aufs еще есть, это доработанная unionfs Вы знаете, мне понравилась идея с UnionFS. А что будет происходить при записи новых файлов? Как она определяет на какую ФС ей писать если допустим каталог существует в 3х из 5 подключенных ФС? Извиняюсь за возможно глупый вопрос, просто у меня нет опыта работы с ней.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	19. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Анонимфывфыв on 16-Июн-15, 17:30
	>> aufs еще есть, это доработанная unionfs > Вы знаете, мне понравилась идея с UnionFS. А что будет происходить при > записи новых файлов? Как она определяет на какую ФС ей писать > если допустим каталог существует в 3х из 5 подключенных ФС? Извиняюсь > за возможно глупый вопрос, просто у меня нет опыта работы с > ней. по свободному месту определяет, где больше места туда и пишет если файл реально большой то на остатки он не раскидается конечно(
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	20. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Анонимфывфыв on 16-Июн-15, 18:24
	>> aufs еще есть, это доработанная unionfs > Вы знаете, мне понравилась идея с UnionFS. А что будет происходить при > записи новых файлов? Как она определяет на какую ФС ей писать > если допустим каталог существует в 3х из 5 подключенных ФС? Извиняюсь > за возможно глупый вопрос, просто у меня нет опыта работы с > ней. лучше конечно overlayfs и aufs мучать, там с записью получше дело обстоит
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	8. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Square (ok) on 16-Июн-15, 12:58
	> Интересует именно построение системы, которая будет терять винты/данные и работать дальше. С такой постановкой вопроса - ваш исходный вопрос не имеет смысла. Делайте. А лучше отнесите все это ваше хозяйство на свалку. И место освободиться, и электроэнергию тратить не надо и голову себе не забивать...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	10. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 13:25
	>> Интересует именно построение системы, которая будет терять винты/данные и работать дальше. > С такой постановкой вопроса - ваш исходный вопрос не имеет смысла. Почему же? Выходит из строя винтов меньше чем работает, дата не критична к потерям и может быть восстановлена. Значит работоспособность системы всё же имеет значение. Я как раз пришел посовещаться по вопросу как делать. :-)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	12. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Square (ok) on 16-Июн-15, 13:35
	>>> Интересует именно построение системы, которая будет терять винты/данные и работать дальше. >> С такой постановкой вопроса - ваш исходный вопрос не имеет смысла. > Почему же? Выходит из строя винтов меньше чем работает, дата не критична > к потерям и может быть восстановлена. Значит работоспособность системы всё же > имеет значение. Я как раз пришел посовещаться по вопросу как делать. > :-) Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте dfs от винды.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 13:53
	> Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте > dfs от винды. Это вполне вариант, но меня печалит реализация AoE в Виндах, iSCSI не хочу. :( И опять же мне не мешает самба, задачам не мешает самба и я не вижу, чем DFS будет лучше допустим той же UnionFS. Так же планируется возможная эксплуатация Аманды так, что Win-решения не очень в жилу на самом деле.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	16. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 13:55
	>> Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте >> dfs от винды. > Это вполне вариант, но меня печалит реализация AoE в Виндах, iSCSI не > хочу. :( И опять же мне не мешает самба, задачам не > мешает самба и я не вижу, чем DFS будет лучше допустим > той же UnionFS. Так же планируется возможная эксплуатация Аманды так, что > Win-решения не очень в жилу на самом деле, хотя, да, можно, но не в приоритете.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	18. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Слоупок (ok) on 16-Июн-15, 14:04
	>>> Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте >>> dfs от винды. >> Это вполне вариант, но меня печалит реализация AoE в Виндах, iSCSI не >> хочу. :( И опять же мне не мешает самба, задачам не >> мешает самба и я не вижу, чем DFS будет лучше допустим >> той же UnionFS. Так же планируется возможная эксплуатация Аманды так, что >> Win-решения не очень в жилу на самом деле, хотя, да, можно, но не в приоритете. Ко всему она ещё и денег стоит ;)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	21. "Создание хранилища способного пережить потерю диска"	+2 +/–
	Сообщение от Аноним (??) on 16-Июн-15, 21:01
	>>>> Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте >>>> dfs от винды. >>> Это вполне вариант, но меня печалит реализация AoE в Виндах, iSCSI не >>> хочу. :( И опять же мне не мешает самба, задачам не >>> мешает самба и я не вижу, чем DFS будет лучше допустим >>> той же UnionFS. Так же планируется возможная эксплуатация Аманды так, что >>> Win-решения не очень в жилу на самом деле, хотя, да, можно, но не в приоритете. >  Ко всему она ещё и денег стоит ;) Ко всему прочему, только ради смб-протокола ставить винду - это лютый оверкилл. Да и в никсах больше решений для поддержки и обслуживания подобного решения.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

23. "Создание хранилища способного пережить потерю диска"	–1 +/–
Сообщение от сис.админ_23rus (ok) on 17-Июн-15, 15:31
>[оверквотинг удален] > Будет ли потеряна только та часть информации которая хранится на физических экстентах > этого диска? Как отреагирует на это LVM, сделает недоступным весь LV > или просто перестанет возвращать ФС запрашиваемую информацию с отсутствующих Physical > Extents? > Как отреагирует EXT4 на непредоставление ей данных от LVM при обращении к > определённым файлам? Полностью умрёт или будет просто возвращать ошибку при обращении > к данным которые были размещены на убитом диске? > Если всё плохо, порекомендуйте пожалуйста ФС которая способна пережить подобные вещи. > Ещё интересует как MDADM реагирует на такие вещи если сконфигурировать простой линейный > массив. При смерти одного из дисков весь массив становится недоступен? Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не пробовал, так что промолчу. в них можно создать распределенное хранилище и отказ ноды почти никак не скажется на файлах (аля сетевой raid 5 если по простому)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Создание хранилища способного пережить потерю диска"	–1 +/–
	Сообщение от ALex_hha (ok) on 18-Июн-15, 10:36
	> Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не > пробовал, так что промолчу. в них можно создать распределенное хранилище и > отказ ноды почти никак не скажется на файлах (аля сетевой raid > 5 если по простому) бывшие владельцы cloudmouse с вами не согласны! :D
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Square (ok) on 18-Июн-15, 12:45
	>> Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не >> пробовал, так что промолчу. в них можно создать распределенное хранилище и >> отказ ноды почти никак не скажется на файлах (аля сетевой raid >> 5 если по простому) > бывшие владельцы cloudmouse с вами не согласны! :D "Не ищите альтернатив, мы то, точно знаем, кому можно доверять в сфере облачных услуг. " (с) CloudMouse https://hosting.kitchen/cloudmouse/vazhno-ot-cloudmouse.html
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	27. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от сис.админ_23rus (ok) on 18-Июн-15, 13:00
	> "Не ищите альтернатив, мы то, точно знаем, кому можно доверять в сфере > облачных услуг. > " (с) CloudMouse > https://hosting.kitchen/cloudmouse/vazhno-ot-cloudmouse.html реферальная ссылка на flops на многих ресурсах обсуждалась )) некоторые даже предлагали варианты о пирамиде "облачного сервиса"
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	26. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от сис.админ_23rus (ok) on 18-Июн-15, 12:57
	>> Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не >> пробовал, так что промолчу. в них можно создать распределенное хранилище и >> отказ ноды почти никак не скажется на файлах (аля сетевой raid >> 5 если по простому) > бывшие владельцы cloudmouse с вами не согласны! :D у них, как я понимаю, были проблемы в архитектуре своего облака. Так что ваш коммент можно считать бесполезным.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	28. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от ALex_hha (ok) on 18-Июн-15, 13:02
	>>> Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не >>> пробовал, так что промолчу. в них можно создать распределенное хранилище и >>> отказ ноды почти никак не скажется на файлах (аля сетевой raid >>> 5 если по простому) >> бывшие владельцы cloudmouse с вами не согласны! :D > у них, как я понимаю, были проблемы в архитектуре своего облака. логично, но насколько я знаю, точкой отказа стал именно Ceph
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	29. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от сис.админ_23rus (ok) on 18-Июн-15, 13:25
	> логично, но насколько я знаю, точкой отказа стал именно Ceph повторюсь еще раз, у них была проблема в архитектуре... "если подключить дисковую полку только к одному серверу не о какой HA говорить не стоит." (автор не известен) вы так критичны к инструменту (в данном случае ceph) сами то пробовали его хоть на стенде запускать? по моему мнению, система хранения файлов на ceph более стабильна чем на сетевом LVM+ext4. и дает возможность дополнительно не загружать сеть если требуется доступ к диску на локальной ноде, а отключение одной из нод, для ceph практичести не вызывает таймаутов к получению данных
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	34. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Аноним (??) on 18-Июн-15, 17:57
	> "если подключить дисковую полку только к одному серверу не о какой HA > говорить не стоит." (автор не известен) Автор прячется :) Ибо "если у вас только одна дисковая полка - не о какой HA говорить не стоит!" Автор - Я.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	30. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от сис.админ_23rus (ok) on 18-Июн-15, 13:35
	> логично, но насколько я знаю, точкой отказа стал именно Ceph http://habrahabr.ru/post/250097/ из тикетов  "Уважаемые пользователи, в результате аппаратного сбоя были утеряны все данные виртуальных машин, включая их бекапы. И как следствие, мы вынуждены были удалить все виртуальные машины в облаке.... С уважением, команда разработчиков CloudMouse" ключевая фраза " в результате аппаратного сбоя".
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	31. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Square (ok) on 18-Июн-15, 13:45
	>> логично, но насколько я знаю, точкой отказа стал именно Ceph > http://habrahabr.ru/post/250097/ > из тикетов  "Уважаемые пользователи, в результате аппаратного сбоя были утеряны все > данные виртуальных машин, включая их бекапы. И как следствие, мы вынуждены > были удалить все виртуальные машины в облаке.... > С уважением, > команда разработчиков CloudMouse" > ключевая фраза " в результате аппаратного сбоя". Они кинули на бабло и данные дох.ра народа.... Что еще они могли написать? что они используют неправильные инструменты для неправильной архитектуры неправильными людьми? Между тем, именно так и нужно понимать их фразу " в результате аппаратного сбоя".
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	32. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от сис.админ_23rus (ok) on 18-Июн-15, 14:43
	> Они кинули на бабло и данные дох.ра народа.... Что еще они могли > написать? что они используют неправильные инструменты для неправильной архитектуры неправильными людьми? > Между тем, именно так и нужно понимать их фразу " в результате > аппаратного сбоя". но их кидаловом не стоит опускать нормальные инструменты
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	38. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от kia_ on 09-Июл-15, 01:00
	>> ключевая фраза " в результате аппаратного сбоя". > Они кинули на бабло и данные дох.ра народа.... Что еще они могли > написать? что они используют неправильные инструменты для неправильной архитектуры неправильными > людьми? > Между тем, именно так и нужно понимать их фразу " в результате > аппаратного сбоя". Они словили багу в ceph, собранном из апстрима. Была ли это в самом деле "аппаратная проблема", или это был программный баг, или сочетание первого и второго, приведший к тому, что произощло - уже неважно. Но надо понимать, что, к сожалению, на сегодня текущая версия ceph в продакшн не пригодна. Они рискнули и они проиграли. Ну, бывает. "Слабоумие и отвага", чо. PS. flops.ru использует версию почти двухлетней давности, на которой полтора года вылизывали код и отлавливали (многочисленные)баги. Да, у них нет многих новых фич ceph, но зато у них отлаженный код и он работает. Просто надо понимать, что не все то, что называется stable и выложено в интернет - пригодно для серьезной работы с данными.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	33. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от ALex_hha (ok) on 18-Июн-15, 16:42
	> ключевая фраза " в результате аппаратного сбоя". а что по твоему они должны были написать? :facepalm: Ибо я получал пару их писем, и явно было видно, что коммуникация с общественностью у них очень страдает. Так что ...
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

35. "Создание хранилища способного пережить потерю диска"	+/–
Сообщение от Слоупок (ok) on 26-Июн-15, 14:27
По теме. Если кому-то интересно решение AoE+LVM+Ext4 - оно работает. При потере диска теряется только часть данных. Остальные данные доступны. Если есть деньги на RAID - это будет стабильная и простая система для консолидации ресурсов SAN. У Ext4 есть опция монтирования, корректирующая поведение при ошибках: errors=continue. Это её значение обеспечивает дальнейшую работу даже при потере диска. Однако я счёл подобный уровень автомоушна излишним и опасным. Потеря диска - событие на которое надо обратить внимание в любом случае т.к. клиенты как минимум начинают получать отказы при обращении к утраченной области. Админ должен быть в курсе что область утрачена. В результате умолчальное поведение errors=remount-ro считаю оптимальным. От реализации в продакшне данной системы отказался - изменились приоритеты и цели.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	36. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от pavel_simple (ok) on 26-Июн-15, 15:07
	> От реализации в продакшне данной системы отказался - изменились приоритеты и цели. это потому-что ты sooo slooow
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	37. "Создание хранилища способного пережить потерю диска"	+/–
	Сообщение от Аноним (??) on 26-Июн-15, 18:12
	>> От реализации в продакшне данной системы отказался - изменились приоритеты и цели. > это потому-что ты sooo slooow Ну с другой стороны если бы мне оплачивали время на экспирименты интересные мне, а не компании я бы .... УХ! :)
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

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

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