Есть в наличии:Куча компьютеров и старых винтов.
Требуется:
Сделать 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 реагирует на такие вещи если сконфигурировать простой линейный массив. При смерти одного из дисков весь массив становится недоступен?
>[оверквотинг удален]
> 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
> наступит логический конец всей этой странной затеиЧем же затея странна? неужели утилизация старого железа с пользой сейчас не в моде? :) Реализация - да, выглядит возможно немножко по-дебильному, но я пытался использовать максимально простые и низкоуровневые инструменты для реализации странной затеи. В идеале я вижу это так: Человек собирает мусор в "сервер", накатывает на него образ системы и просто подключает винты на NAS. (кстати мне только что пришло в голову, что было бы неплохо использовать ФС, которые умеют расширяться без размонтирования) :) В случае если мусорный винт умер - менять нечем - _ключевой момент_ не делает ничего. Вот это важно. На информацию в таком случае просто забивают. На счёт замены и введения в работу нового - вопросительная ситуация. расширять-то файловую систему можно, но придётся по ходу действия видимо полечить её, чтобы она больше не надеялась увидеть данные с потерянных экстентов.
HA с резервированием не нужно, это сжирает ёмкость, а ёмкость - это единственное ради чего всё затевается. Скорость так же должна быть максимальной однако даунтайм вполне допустим.
> lvm отдаст то, что сможет
Т.е. блокировки всего LV не случится, если один из используемых в нём PV умрёт, остальные данные останутся доступны, я верно понимаю?
> перейдёт в ro, в лучшем случаее
В EXT4 совсем не упираюсь. Но такое поведение неприемлемо в данном случае.
Вообще мне кажется это странно себя так вести. ну допустим я использую винт который сам не переназначает сектора в случае их выхода из строя. Система не смогла извлечь информацию из своего нода - ок, это плохо, но зачем устраивать такую трагедю и переводить всё в ro. Я не отрицаю что я плохо разбираюсь в таких вещах, но логики тут вообще не вижу. Есть ли системы которые более толерантны к таким вещам? С распределёнными ФС связываться не готов да и эксплуатировать это будет некому. :(> fs тут не при чём -- если вам нужно HA -- то
> делать нужно на уровне блочного устройствабазируясь на ваших ответах прихожу к выводу, что причём. HA не нужно.
> линейный массив? raid0? -- перейёт в режим degraded, будут отдовать то, что
> сможет.Да, Linear mode. Это хорошо.
> если нужно HA SAN на простом железе -- то для вас есть
> ceph, как в виде блочного устройства так и ввиде FSВозможно я слишком громко выразился про SAN. По факту просто проект утилизации большого объёма ненужного железа, для задач хранения не критичной к потерям информации. Ceph мне почему-то кажется оверпауэром для этой странной затеи. Я не готов о нём думать пока не пойму что изначальную идею реализовать с помощью этих инструментов действительно невозможно.
>>[оверквотинг удален]
>> И вот вопрос заключается в следующем. Что будет с такой схемой если
>> например один винт просто умрёт, что на самом деле очень вероятно.
> наступит логический конец всей этой странной затеину в общем да, но можно и dm-таржет сделать r5 скажем, или все это безобразие поверх md5-10 пустить. 5 тяжеловато будет, наверно. или можно btrfs попробовать с его raid-м.
>>>[оверквотинг удален]
>>> И вот вопрос заключается в следующем. Что будет с такой схемой если
>>> например один винт просто умрёт, что на самом деле очень вероятно.
>> наступит логический конец всей этой странной затеи
> ну в общем да, но можно и dm-таржет сделать r5 скажем, или
> все это безобразие поверх md5-10 пустить. 5 тяжеловато будет, наверно. или
> можно btrfs попробовать с его raid-м.Резервирование винтов под отказ с помощью RAID5/10 не рассматривается. Винты все разной ёмкости, сроить из них рэйда будет адским занятием и повысит стоимость эксплуатации всей системы до того уровня, когда действительно проще пойти в магазин и купить новый съёмный диск на 3ТБ.
Интересует именно построение системы, которая будет терять винты/данные и работать дальше.
> Интересует именно построение системы, которая будет терять винты/данные и работать дальше.карго-культ
>> Интересует именно построение системы, которая будет терять винты/данные и работать дальше.
> карго-культНе понимаю о чём идёт речь. :-)
>[оверквотинг удален]
>>>> например один винт просто умрёт, что на самом деле очень вероятно.
>>> наступит логический конец всей этой странной затеи
>> ну в общем да, но можно и dm-таржет сделать r5 скажем, или
>> все это безобразие поверх md5-10 пустить. 5 тяжеловато будет, наверно. или
>> можно btrfs попробовать с его raid-м.
> Резервирование винтов под отказ с помощью RAID5/10 не рассматривается. Винты все разной
> ёмкости, сроить из них рэйда будет адским занятием и повысит стоимость
> эксплуатации всей системы до того уровня, когда действительно проще пойти в
> магазин и купить новый съёмный диск на 3ТБ.
> Интересует именно построение системы, которая будет терять винты/данные и работать дальше.да элементарно! каждый винт форматится в любую фс, и все собирается через unionfs или overlayfs в единую шару
я так винты и утилизирую
>[оверквотинг удален]
>>> все это безобразие поверх md5-10 пустить. 5 тяжеловато будет, наверно. или
>>> можно btrfs попробовать с его raid-м.
>> Резервирование винтов под отказ с помощью RAID5/10 не рассматривается. Винты все разной
>> ёмкости, сроить из них рэйда будет адским занятием и повысит стоимость
>> эксплуатации всей системы до того уровня, когда действительно проще пойти в
>> магазин и купить новый съёмный диск на 3ТБ.
>> Интересует именно построение системы, которая будет терять винты/данные и работать дальше.
> да элементарно! каждый винт форматится в любую фс, и все собирается через
> unionfs или overlayfs в единую шару
> я так винты и утилизируюupd. можно часть винтов одинаковой емкости собирать в raid5
например 500гб в один том 1000 в другой том итд
и все это через unionfs в одну точку
> upd. можно часть винтов одинаковой емкости собирать в raid5
> например 500гб в один том 1000 в другой том итд
> и все это через unionfs в одну точкуRAID5/1/10 - точно нет. Ёмкость и скорость нужно максимизировать, процесс замены может происходит долго либо не произойти вообще.
А за UnionFS спасибо, очень интересная концепция, погуглю и наличие многих ФС никак не противоречит моим целям, наоборот представляется весьма неплохой фичей страхующей от внезапных глобальных ошибок на одной единственной ФС. А насколько прозрачно для пользователя событие потери одной из входящих в неё ФС?
>> upd. можно часть винтов одинаковой емкости собирать в raid5
>> например 500гб в один том 1000 в другой том итд
>> и все это через unionfs в одну точку
> RAID5/1/10 - точно нет. Ёмкость и скорость нужно максимизировать, процесс замены может
> происходит долго либо не произойти вообще.
> А за UnionFS спасибо, очень интересная концепция, погуглю и наличие многих ФС
> никак не противоречит моим целям, наоборот представляется весьма неплохой фичей страхующей
> от внезапных глобальных ошибок на одной единственной ФС. А насколько прозрачно
> для пользователя событие потери одной из входящих в неё ФС?файлы пропадут те что бы ли на битом винте, и все
>> upd. можно часть винтов одинаковой емкости собирать в raid5
>> например 500гб в один том 1000 в другой том итд
>> и все это через unionfs в одну точку
> RAID5/1/10 - точно нет. Ёмкость и скорость нужно максимизировать, процесс замены может
> происходит долго либо не произойти вообще.
> А за UnionFS спасибо, очень интересная концепция, погуглю и наличие многих ФС
> никак не противоречит моим целям, наоборот представляется весьма неплохой фичей страхующей
> от внезапных глобальных ошибок на одной единственной ФС. А насколько прозрачно
> для пользователя событие потери одной из входящих в неё ФС?aufs еще есть, это доработанная unionfs
> aufs еще есть, это доработанная unionfsВы знаете, мне понравилась идея с UnionFS. А что будет происходить при записи новых файлов? Как она определяет на какую ФС ей писать если допустим каталог существует в 3х из 5 подключенных ФС? Извиняюсь за возможно глупый вопрос, просто у меня нет опыта работы с ней.
>> aufs еще есть, это доработанная unionfs
> Вы знаете, мне понравилась идея с UnionFS. А что будет происходить при
> записи новых файлов? Как она определяет на какую ФС ей писать
> если допустим каталог существует в 3х из 5 подключенных ФС? Извиняюсь
> за возможно глупый вопрос, просто у меня нет опыта работы с
> ней.по свободному месту определяет, где больше места туда и пишет
если файл реально большой то на остатки он не раскидается конечно(
>> aufs еще есть, это доработанная unionfs
> Вы знаете, мне понравилась идея с UnionFS. А что будет происходить при
> записи новых файлов? Как она определяет на какую ФС ей писать
> если допустим каталог существует в 3х из 5 подключенных ФС? Извиняюсь
> за возможно глупый вопрос, просто у меня нет опыта работы с
> ней.лучше конечно overlayfs и aufs мучать, там с записью получше дело обстоит
> Интересует именно построение системы, которая будет терять винты/данные и работать дальше.С такой постановкой вопроса - ваш исходный вопрос не имеет смысла. Делайте.
А лучше отнесите все это ваше хозяйство на свалку.
И место освободиться, и электроэнергию тратить не надо и голову себе не забивать...
>> Интересует именно построение системы, которая будет терять винты/данные и работать дальше.
> С такой постановкой вопроса - ваш исходный вопрос не имеет смысла.Почему же? Выходит из строя винтов меньше чем работает, дата не критична к потерям и может быть восстановлена. Значит работоспособность системы всё же имеет значение. Я как раз пришел посовещаться по вопросу как делать. :-)
>>> Интересует именно построение системы, которая будет терять винты/данные и работать дальше.
>> С такой постановкой вопроса - ваш исходный вопрос не имеет смысла.
> Почему же? Выходит из строя винтов меньше чем работает, дата не критична
> к потерям и может быть восстановлена. Значит работоспособность системы всё же
> имеет значение. Я как раз пришел посовещаться по вопросу как делать.
> :-)Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте dfs от винды.
> Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте
> dfs от винды.Это вполне вариант, но меня печалит реализация AoE в Виндах, iSCSI не хочу. :( И опять же мне не мешает самба, задачам не мешает самба и я не вижу, чем DFS будет лучше допустим той же UnionFS. Так же планируется возможная эксплуатация Аманды так, что Win-решения не очень в жилу на самом деле.
>> Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте
>> dfs от винды.
> Это вполне вариант, но меня печалит реализация AoE в Виндах, iSCSI не
> хочу. :( И опять же мне не мешает самба, задачам не
> мешает самба и я не вижу, чем DFS будет лучше допустим
> той же UnionFS. Так же планируется возможная эксплуатация Аманды так, что
> Win-решения не очень в жилу на самом деле, хотя, да, можно, но не в приоритете.
>>> Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте
>>> dfs от винды.
>> Это вполне вариант, но меня печалит реализация AoE в Виндах, iSCSI не
>> хочу. :( И опять же мне не мешает самба, задачам не
>> мешает самба и я не вижу, чем DFS будет лучше допустим
>> той же UnionFS. Так же планируется возможная эксплуатация Аманды так, что
>> Win-решения не очень в жилу на самом деле, хотя, да, можно, но не в приоритете.Ко всему она ещё и денег стоит ;)
>>>> Поскольку вы в конечном счете станете раздавать по самбе все это- ставьте
>>>> dfs от винды.
>>> Это вполне вариант, но меня печалит реализация AoE в Виндах, iSCSI не
>>> хочу. :( И опять же мне не мешает самба, задачам не
>>> мешает самба и я не вижу, чем DFS будет лучше допустим
>>> той же UnionFS. Так же планируется возможная эксплуатация Аманды так, что
>>> Win-решения не очень в жилу на самом деле, хотя, да, можно, но не в приоритете.
> Ко всему она ещё и денег стоит ;)Ко всему прочему, только ради смб-протокола ставить винду - это лютый оверкилл. Да и в никсах больше решений для поддержки и обслуживания подобного решения.
>[оверквотинг удален]
> Будет ли потеряна только та часть информации которая хранится на физических экстентах
> этого диска? Как отреагирует на это LVM, сделает недоступным весь LV
> или просто перестанет возвращать ФС запрашиваемую информацию с отсутствующих Physical
> Extents?
> Как отреагирует EXT4 на непредоставление ей данных от LVM при обращении к
> определённым файлам? Полностью умрёт или будет просто возвращать ошибку при обращении
> к данным которые были размещены на убитом диске?
> Если всё плохо, порекомендуйте пожалуйста ФС которая способна пережить подобные вещи.
> Ещё интересует как MDADM реагирует на такие вещи если сконфигурировать простой линейный
> массив. При смерти одного из дисков весь массив становится недоступен?Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не пробовал, так что промолчу. в них можно создать распределенное хранилище и отказ ноды почти никак не скажется на файлах (аля сетевой raid 5 если по простому)
> Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не
> пробовал, так что промолчу. в них можно создать распределенное хранилище и
> отказ ноды почти никак не скажется на файлах (аля сетевой raid
> 5 если по простому)бывшие владельцы cloudmouse с вами не согласны! :D
>> Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не
>> пробовал, так что промолчу. в них можно создать распределенное хранилище и
>> отказ ноды почти никак не скажется на файлах (аля сетевой raid
>> 5 если по простому)
> бывшие владельцы cloudmouse с вами не согласны! :D"Не ищите альтернатив, мы то, точно знаем, кому можно доверять в сфере облачных услуг.
" (с) CloudMouse
https://hosting.kitchen/cloudmouse/vazhno-ot-cloudmouse.html
> "Не ищите альтернатив, мы то, точно знаем, кому можно доверять в сфере
> облачных услуг.
> " (с) CloudMouse
> https://hosting.kitchen/cloudmouse/vazhno-ot-cloudmouse.htmlреферальная ссылка на flops на многих ресурсах обсуждалась )) некоторые даже предлагали варианты о пирамиде "облачного сервиса"
>> Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не
>> пробовал, так что промолчу. в них можно создать распределенное хранилище и
>> отказ ноды почти никак не скажется на файлах (аля сетевой raid
>> 5 если по простому)
> бывшие владельцы cloudmouse с вами не согласны! :Dу них, как я понимаю, были проблемы в архитектуре своего облака. Так что ваш коммент можно считать бесполезным.
>>> Лучшее используйте для хранения файлов ceph или как вариант GFS. другое не
>>> пробовал, так что промолчу. в них можно создать распределенное хранилище и
>>> отказ ноды почти никак не скажется на файлах (аля сетевой raid
>>> 5 если по простому)
>> бывшие владельцы cloudmouse с вами не согласны! :D
> у них, как я понимаю, были проблемы в архитектуре своего облака.логично, но насколько я знаю, точкой отказа стал именно Ceph
> логично, но насколько я знаю, точкой отказа стал именно Cephповторюсь еще раз, у них была проблема в архитектуре...
"если подключить дисковую полку только к одному серверу не о какой HA говорить не стоит." (автор не известен)
вы так критичны к инструменту (в данном случае ceph) сами то пробовали его хоть на стенде запускать?
по моему мнению, система хранения файлов на ceph более стабильна чем на сетевом LVM+ext4.
и дает возможность дополнительно не загружать сеть если требуется доступ к диску на локальной ноде, а отключение одной из нод, для ceph практичести не вызывает таймаутов к получению данных
> "если подключить дисковую полку только к одному серверу не о какой HA
> говорить не стоит." (автор не известен)Автор прячется :)
Ибо "если у вас только одна дисковая полка - не о какой HA говорить не стоит!" Автор - Я.
> логично, но насколько я знаю, точкой отказа стал именно Cephhttp://habrahabr.ru/post/250097/
из тикетов "Уважаемые пользователи, в результате аппаратного сбоя были утеряны все данные виртуальных машин, включая их бекапы. И как следствие, мы вынуждены были удалить все виртуальные машины в облаке....
С уважением,
команда разработчиков CloudMouse"ключевая фраза " в результате аппаратного сбоя".
>> логично, но насколько я знаю, точкой отказа стал именно Ceph
> http://habrahabr.ru/post/250097/
> из тикетов "Уважаемые пользователи, в результате аппаратного сбоя были утеряны все
> данные виртуальных машин, включая их бекапы. И как следствие, мы вынуждены
> были удалить все виртуальные машины в облаке....
> С уважением,
> команда разработчиков CloudMouse"
> ключевая фраза " в результате аппаратного сбоя".Они кинули на бабло и данные дох.ра народа.... Что еще они могли написать? что они используют неправильные инструменты для неправильной архитектуры неправильными людьми?
Между тем, именно так и нужно понимать их фразу " в результате аппаратного сбоя".
> Они кинули на бабло и данные дох.ра народа.... Что еще они могли
> написать? что они используют неправильные инструменты для неправильной архитектуры неправильными людьми?
> Между тем, именно так и нужно понимать их фразу " в результате
> аппаратного сбоя".но их кидаловом не стоит опускать нормальные инструменты
>> ключевая фраза " в результате аппаратного сбоя".
> Они кинули на бабло и данные дох.ра народа.... Что еще они могли
> написать? что они используют неправильные инструменты для неправильной архитектуры неправильными
> людьми?
> Между тем, именно так и нужно понимать их фразу " в результате
> аппаратного сбоя".Они словили багу в ceph, собранном из апстрима. Была ли это в самом деле "аппаратная проблема", или это был программный баг, или сочетание первого и второго, приведший к тому, что произощло - уже неважно. Но надо понимать, что, к сожалению, на сегодня текущая версия ceph в продакшн не пригодна. Они рискнули и они проиграли. Ну, бывает. "Слабоумие и отвага", чо.
PS. flops.ru использует версию почти двухлетней давности, на которой полтора года вылизывали код и отлавливали (многочисленные)баги. Да, у них нет многих новых фич ceph, но зато у них отлаженный код и он работает.
Просто надо понимать, что не все то, что называется stable и выложено в интернет - пригодно для серьезной работы с данными.
> ключевая фраза " в результате аппаратного сбоя".а что по твоему они должны были написать? :facepalm:
Ибо я получал пару их писем, и явно было видно, что коммуникация с общественностью у них очень страдает. Так что ...
По теме. Если кому-то интересно решение AoE+LVM+Ext4 - оно работает. При потере диска теряется только часть данных. Остальные данные доступны. Если есть деньги на RAID - это будет стабильная и простая система для консолидации ресурсов SAN.У Ext4 есть опция монтирования, корректирующая поведение при ошибках: errors=continue. Это её значение обеспечивает дальнейшую работу даже при потере диска. Однако я счёл подобный уровень автомоушна излишним и опасным. Потеря диска - событие на которое надо обратить внимание в любом случае т.к. клиенты как минимум начинают получать отказы при обращении к утраченной области. Админ должен быть в курсе что область утрачена. В результате умолчальное поведение errors=remount-ro считаю оптимальным.
От реализации в продакшне данной системы отказался - изменились приоритеты и цели.
> От реализации в продакшне данной системы отказался - изменились приоритеты и цели.это потому-что ты sooo slooow
>> От реализации в продакшне данной системы отказался - изменились приоритеты и цели.
> это потому-что ты sooo slooowНу с другой стороны если бы мне оплачивали время на экспирименты интересные мне, а не компании я бы .... УХ! :)