Представлен (http://www.lessfs.com/wordpress/?p=909) первый стабильный релиз проекта BTIER 1.0.0 (http://www.lessfs.com), предназначенного для формирования многоуровневых блочных устройств, состоящих из нескольких разнотипных устройств небольшого размера. Код системы отмечен как стабильный и прошедший тестирование в промышленном использовании, в том числе в достаточно сложных конфигурациях, в которых используются сетевые разделы DRDB и работают приложения Oracle. BTIER оформлен в виде модуля для ядра Linux, который может быть собран для ядер, начиная с выпуска 2.6.32. Изначально проект развивался под именем TIER, но был переименован (http://www.lessfs.com/wordpress/?p=850) в BTIER для того чтобы упростить выборку связанной с проектом информации через поисковые системы. Исходные тексты BTIER распространяется под лицензией GPL.
За счёт оптимального разнесения блоков по дискам и использования техники активного кэширования данных в ОЗУ раздел на базе BTIER позволяет заметно поднять производительность сводного раздела. Например, при тестировании BTIER-раздела, созданного на базе SSD-накопителя STEC Zeus и 5 SAS НЖМД, и экспортируемого через iSCSI (SCST), была продемонстрирована (http://www.lessfs.com/wordpress/?p=850) способность выполнения заметно большего числа операций в секунду, по сравнению с системой кэширования на SSD-накопителях BCache (https://www.opennet.ru/opennews/art.shtml?num=35849).<center><a href="http://www.lessfs.com/wordpress/wp-content/docimages/btier_m... src="https://www.opennet.ru/opennews/pics_base/0_1369637152.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="BTIER" border=0></a><a href="http://www.lessfs.com/wordpress/wp-content/docimages/bcache_... src="https://www.opennet.ru/opennews/pics_base/0_1369637182.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="BCACHE" border=0></a></center>
Использование BTIER позволяет достигнуть более высокой производительности по сравнению с другими методами ускорения доступа к данным, использующими SSD-накопители, благодаря применению техники кэширования в оперативной памяти, ранее реализованной в RAM-диске EPRD (https://www.opennet.ru/opennews/art.shtml?num=33541). При распределении данных по дискам TIER учитывает статистику доступа к уже размещённым данным, например, принимает во внимание то, когда данные использовались последний раз и как часто они запрашиваются. При наличии разных типов накопителей в пуле, отличающихся скоростными характеристиками, наиболее востребованные данные будут вытеснены на более быстрые накопители, такие как SSD или SAS, а редко используемые данные будут размещены на медленных дисках.
В итоге, BTIER позволяет значительно сэкономить, используя SSD только для действительно востребованных данных, при том, что общая ёмкость всего быстрого хранилища в BTIER составляет сумму из всех подключенных устройств хранения. Например, близкий аналог flashcache (https://www.opennet.ru/opennews/art.shtml?num=26440) может поддерживать отдельный кэш из SSD-накопителей поверх традиционных дисков, дублируя данные, в то время как BTIER максимально эффективно использует доступное пространство. Кроме производительности, от других систем виртуального слияния хранилищ BTIER отличается поддержкой автоматической миграции данных между накопителями и обеспечением "умной" балансировки размещения блоков данных на накопителях в зависимости от характера нагрузки.URL: http://www.lessfs.com/wordpress/?p=909
Новость: https://www.opennet.ru/opennews/art.shtml?num=37023
Вот это, я понимаю! Не то что всякие там фюжндрайвы и турбобусты (или как там в винде называется кеширование дллок).
Да еще и под GPLv3!
> Да еще и под GPLv3!Путаешь с lessfs.
btier-1.0.0.tar.gz лежит COPYING =GPLv2, в "документации" лицензия не поминается, в исходнике модуля, в _одном файле из _7_:
* Partly based up-on sbd and the loop driver.
* Redistributable under the terms of the GNU GPL.
Пардон, зашел сюда http://www.lessfs.com/wordpress/, увидел GPLv3 и обрадовался... Спасибо.Да все-равно круто же.
Даже круче — значит можно ожидать в ваниле, то биш "изкаропки".
Не удивлюсь что именно поэтому и гпл2.
очередной троль - который не потрудился посмотреть исходники. GPL v2 таки более популярна и она использована.
> очередной троль - который не потрудился посмотреть исходники.Спасибо, что прочитали мой ник. А Вы тире не к месту употребили ;)
Так у него как? Если ворд не подчёркивает, значит правильно.
хреновый из тебя наблюдатель ;-)
С чего ты взял что я за хренами наблюдаю? :D
> С чего ты взял что я за хренами наблюдаю? :DСудит всех по себе, видимо.
> очередной трольТы настолько лузер, что даже слово "тролль" не можешь правильно написать. Позор!
наконец то, что нужно!!! годнота!!!
Дык линукс же и так кеширует весь обмен с фс в ОЗУ, то есть, хошь ускориться добей оперативы; сервера нагруженные, так ведь там и железо соответстующее, в крайнем случае есть своп, который как раз и можно держать на ссд или сас, если данные в оперативу совсем не лезут, в чем профит?
> Дык линукс же и так кеширует весь обмен с фс в ОЗУ,
> то есть, хошь ускориться добей оперативы;Ну, как бы тех, кто пишет и использует БД интересует момент окончания _записи на ...[ммм, как это есть по-русски]... non-volatile носитель.
> в крайнем случае есть своп, который как раз и можно держать на ссд
:*)))
> кто пишет и использует БД интересует момент окончания _записи наГм. Поправочка "ФС и БД".
я бы сказал - на persistent storage. особенно в плане комита транзакций. Поэтому в linux был в свое время (может и даже сейчас) смешной баг у dm_multipath - когда один из каналов более быстрый и более новые транзакции комитились раньше старых, что приводило к неработоспособности барьеров внутри FS.
Дык у всех мультипасов такой "баг". Они как бэ нагрузку и не предназначены балансировать.
Пихание разнотипных носителей по такой схеме сродни забиванию гвоздей буратинами.
Тоже было (на личном опыте своими глазами видел) и в соляре, а в винде (2000) вообще отвалившийся девайс только минут через 20 "обнаруживался" пропавшим. И все транзакции за это время как в /dev/null ушли.
> Дык у всех мультипасов такой "баг". Они как бэ нагрузку и не
> предназначены балансировать.
> Пихание разнотипных носителей по такой схеме сродни забиванию гвоздей буратинами.
> Тоже было (на личном опыте своими глазами видел) и в соляре, а
> в винде (2000) вообще отвалившийся девайс только минут через 20 "обнаруживался"
> пропавшим. И все транзакции за это время как в /dev/null ушли.Правильные multi path реализуют правильные барьеры :) да да - есть командочка такая в bio уровне.
не правильные - убивают FS в хлам. Вывод делать вам :)
Мультипас не реализуют барьеры. Вообще. :D
> Правильные multi path реализуют правильные барьерыЭто где такие? Ну, кроме вашего воображения.
> если данные в оперативу совсем не лезутто нужно не городить свопы а разгрузить телегу
1. Объединение разнотипных, разноскоростных, разноразмерных (и тд) устройств в одно логическое.
2. Никакой кэшЪ не поможет от синк. Если процессу нужно точно знать, что данные на диске, то будет иовэйт по-любому. К примеру в оракле (по-мимо транзакций и тд) каждые 3 секунды чекпоинт, скидывает "грязные" блоки на диск.Зыж
Вопрос по сабжу — как с загрузкой с таких разделов? И когда будет в ванниле?
> Если процессу нужно точно знать, что данные на диске, то будет иовэйт по-любому.Процессу можно сказать, что данные есть, "- а где и как - тя нипёт!".
Можно.
Но никто (в зравом уме) этого им не говорит.
Особенно на рсубд в режиме 24*7*365.
> Процессу можно сказать, что данные есть, "- а где и как - тя нипёт!".Можно. Только когда у тебя при крахе потом навороченный двигун БД не сможет отреплеить свой журнал и транзакционность факапнется - будешь писать жалобы в спортлото и копить деньги на оптовую закупку вазелина.
в смысле как? initrd
еще бы совместно с EPRD заюзать, будет просто супер!
Зачем? Задачи разные. Никто не мешает сделать EPRD поверх.
> еще бы совместно с EPRD заюзать, будет просто супер!А разве EPRD не блочное устройство?
Или BTIER блочные устройства не поддерживает?
Так никто и не мешает их юзать параллельно. Можешь не сомневаться. ERPD был убран из TIER автором уже вроцессе развития, что бы не дублировать код проекта. Автор, кстати, у них один и тот же.
DRBD
> DRBDСемнадцать!
Асфальт
не согласен
Неожиданный ход.
Макароны
Distributed Replicated Block Deviceдля тех кто не понял, это было на "сетевые разделы DRDB"
Аналог технологии FAST (Fully Automated Storage Tiering).
Хорошо.
НоtSwap и Hot Spare надо, в виде утилиты хотя бы.
Hot Spare не спасёт ввиду отсутствия избыточности. Если хоть один из носителей вылетит, то менять его будет уже поздно - данные потеряны. А вот Ноt Swap таки поможет, если за S.M.A.R.T.ом следить и вовремя диски менять.
Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD, а то определить какие данные потерялись при вылете SSD будет проблематично, хотя вероятнее всего самые нужные ;)
> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
> а то определить какие данные потерялись при вылете SSD будет проблематично,
> хотя вероятнее всего самые нужные ;)можно замутить RAID 1 из BTIER дисков =-o
>> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
>> а то определить какие данные потерялись при вылете SSD будет проблематично,
>> хотя вероятнее всего самые нужные ;)
> можно замутить RAID 1 из BTIER дисков =-oЗачем? Диск переходит в RO режим. Просто выводишь RO диск из массива, ставишь новый и продолжаешь работать.
Данные не теряются. Если не может записать на SSD, пишет на другой диск.
ssd перешел в ro,как его заменить? это raid5 из 5-ти hdd+ssd, а tier 1 = raid5 из 5 hdd + tier 2 из ssd. В самом деле, сценарий восстановления тут интересен - останов всей конструкции на замену и раздельное зеркалирование ssd, а затем сбор всей конструкции заново - весьма слабый и непромышленный вариант.
> Данные не теряются. Если не может записать на SSD, пишет на другой диск.А куда они денутся? BTIER - по сути, это RAID0 в режиме FIFO,
где верх кучи это самый быстрый диск.
> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
> а то определить какие данные потерялись при вылете SSD будет проблематично,
> хотя вероятнее всего самые нужные ;)Интересная штука, используя N x RAID1 из SSD мы поднимаем отказоустойчивость от вероятного "протирания до дырки" грубо в N раз, а применяя на них N x RAID0 мы увеличиваем ресурс в N раз, тем самым снижая эту вероятность.
>> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
>> а то определить какие данные потерялись при вылете SSD будет проблематично,
>> хотя вероятнее всего самые нужные ;)
> Интересная штука, используя N x RAID1 из SSD мы поднимаем отказоустойчивость от
> вероятного "протирания до дырки" грубо в N раз, а применяя на
> них N x RAID0 мы увеличиваем ресурс в N раз, тем
> самым снижая эту вероятность.если исключить вроде как не подтверждённую проблему "SSD зеркалу иногда имеет особенность умирать целиком", то таки в случае зеркало будет некоторое время для замены ;) ...
В зеркале износ одинаковый для всех компонент, общий ресурс равен наибольшему из устройств, следовательно оно практически не защищает от износа. В страйпе общий ресурс равен наименьшему из компонент умноженному на их количество.
Насчет времени для замены, лучше чтобы его никогда не случилось.
> В зеркале износ одинаковый для всех компонент, общий ресурс равен наибольшему из
> устройств, следовательно оно практически не защищает от износа. В страйпе общий
> ресурс равен наименьшему из компонент умноженному на их количество.
> Насчет времени для замены, лучше чтобы его никогда не случилось.И к чему это? на серверах всегда выходили из строя диски, и весь смысл зеркалирования, и его "развитий" в том что бы в случае выхода из строя ( который в дата центрах является плановым событием ) в сохранении данных...
> ресурс равен наименьшему из компонент умноженному на их количество.это неверно если вам не наплевать на данные, как бы ресурс человека не равен наименьшему ресурсу клетки помноженному на их количество...
Если не говорить об отказах электроники, а только об износе механическом (HDD) и электронном (SSD), то картина следующая. Чем больше у нас в массиве HDD тем выше вероятность отказа. В случае механики она еще и менее предсказуема. А в случае с SSD наоборот, чем бОльший объем тем бОльший ресурс. Разницу видно?
Ну и RAID10 никто не отменял.> ресурс человека
Потеря одной клетки не влечет за собой гибель организма.
Если организм не одноклеточный ;)
> А в случае с SSD наоборот, чем бОльший объем тем бОльший ресурс.Что вы понимаете под ресурсом?
если ресурс это возможность отдать информацию в том виде ( без ошибок ) в котором она была передана то это не так... и хоть миллиард устройств, в случае отказа не важно что останется на других, если нет копии данных которые лежали на этом устройстве ( и не важно механика там, магнитная лента, ссд или печатная продукция на складе )...
>> А в случае с SSD наоборот, чем бОльший объем тем бОльший ресурс.
> Что вы понимаете под ресурсом?
> если ресурс это возможность отдать информацию в том виде ( без ошибок
> ) в котором она была передана то это не так... и
> хоть миллиард устройств, в случае отказа не важно что останется на
> других, если нет копии данных которые лежали на этом устройстве (
> и не важно механика там, магнитная лента, ссд или печатная продукция
> на складе )...Для начала подумайте, с чего бы это ресурс в SSD измеряют в циклах записи а то и просто в петабайтах. И почему в одинаковой модельной линейке SSD вдвое меньший объем заявляется со вдвое меньшим ресурсом. Если этого не поймете, то и разговаривать дальше нет смысла.
> Для начала подумайте, с чего бы это ресурс в SSD измеряют в
> циклах записи а то и просто в петабайтах. И почему в
> одинаковой модельной линейке SSD вдвое меньший объем заявляется со вдвое меньшим
> ресурсом. Если этого не поймете, то и разговаривать дальше нет смысла.физически у вас отказ перезаписи ячейки, на практике развал фс ( ячейка оказалось была со служебной информацией ( не я верю что эти все проблемы разобраны и решены, но что-то мне подсказывает обратное), микрокод контроллера ссд пытался работать вплоть до финиша, либо просто не память а что то другое умерло )... так что какая разница, про маркетинг по поводу ресурса на перезапись не надо, микрокод контроллера ssd не разбирали и как он будет падать доподлинно не известно ( были прецеденты и с полным отказом ). изначальный пост был о том, что все привыкли что ssd в схеме используется как быстрый большой кэш на чтение а вся записываемая инфа гарантированно сохранялась зеркальным ( избыточным ) рейдом, а у этого продукта подход другой, т.е. с точки зрения сохранности данных он считает быстрые и медленные носители одинаково надёжными...
Не совсем понятно, что вы хотите доказать. И кому.
Я выразил свою точку зрения на отказоустойчивость RAID1 vs RAID0 в свете другой технологии хранения данных. Постулировал что зеркало на SSD не дает преимущества в долговечности. И что скорее наоборот, RAID0 проработает дольше при том же трафике на запись. А вас понесло на ячейки и ФС. Кстати, S.M.A.R.T. ведь никто не отменял. И по сравнению с HDD там намного более точные сведения об оставшемся ресурсе. В чём спорить изволите?
> Не совсем понятно, что вы хотите доказать. И кому.
> Я выразил свою точку зрения на отказоустойчивость RAID1 vs RAID0 в свете
> другой технологии хранения данных. Постулировал что зеркало на SSD не дает
> преимущества в долговечности. И что скорее наоборот, RAID0 проработает дольше при
> том же трафике на запись. А вас понесло на ячейки и
> ФС. Кстати, S.M.A.R.T. ведь никто не отменял. И по сравнению с
> HDD там намного более точные сведения об оставшемся ресурсе. В чём
> спорить изволите?в общем начали с этого, возможно по пути потерял где то ход мысли :(
>Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD, а то определить какие данные потерялись при вылете SSD будет проблематично, хотя вероятнее всего самые нужные ;)
> физически у вас отказ перезаписи ячейки, на практике развал фс ( ячейка
> оказалось была со служебной информациейВы хоть почитай не про устройство фс и в каких фс как хранят данные и как работают.
А не воображариум устраивать.
>> физически у вас отказ перезаписи ячейки, на практике развал фс ( ячейка
>> оказалось была со служебной информацией
> Вы хоть почитай не про устройство фс и в каких фс как
> хранят данные и как работают.
> А не воображариум устраивать.Он о метаданных, упырь.
В LSI есть CacheCade. И помнится на семинаре представителю LSI задавали вопрос: - "А что происходит и как обрабатывается ситуация, когда SSD умирает?"Так вот он ответил, что если SSD умирает из-за ресурса, то чтение сохраняется все равно. Т.е. нельзя записать новые данные, а старые прочитать можно. Т.о. ничего страшного не происходит.
Если умирает электроника, то конечно все плохо. Но вылет электроники крайне редок, и теоретически после починки данные возможно вытащить все равно.
> Так вот он ответил, что если SSD умирает из-за ресурса, то чтение
> сохраняется все равно. Т.е. нельзя записать новые данные, а старые прочитать
> можно. Т.о. ничего страшного не происходит.
> Если умирает электроника, то конечно все плохо. Но вылет электроники крайне редок,
> и теоретически после починки данные возможно вытащить все равно.Смотря что вылитит, если карта реаллокации блоков - то сильно врядли... Да, вылет электроники у ssd - зависит от условий эксплуатации, и увы, не редок.
Они изобрели FreeBSD-шный GEOM для Linux и добавили местечковых костылей, вот и вся новость.
Толстопуз, окстись. GEOM тут ни с одной из шести сторон.
> Они изобрели FreeBSD-шный GEOM для Linux и добавили местечковых костылей, вот и вся новость.Ликвидируем безграмотность среди школьников: "FreeBSD-шный GEOM" - это просто копипаста с линуксового device mapper.
Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.
А можно еще сказать, что возможности ZFS, имеющиеся во FreeBSD, в линуксе реализуемы только костылями в виде BTIER и Btrfs :)
> А можно еще сказать, что возможности ZFS, имеющиеся во FreeBSD, в линуксе реализуемы только костылями в виде BTIER и Btrfs :)Или наоборот: возможности ZFS и Btrfs, имеющиеся в линуксе, во FreeBSD реализуются только костылями в виде ZFS.
Даже так: возможности ZFS, Btrfs и BTIER.
> возможности ZFS..., имеющиеся в линуксеДа, несчастные бсдешники уже и забыли, что с появлением zfsonlinux количество преимуществ freebsd перед linux вернулось на исторически сложившийся уровень (0).
Пока zfsonlinux не появится в ядре, оно будет просто детской игрушкой для энтузиастов. А в ядре оно не появится никогда.ЗЫ Ох, какие у нас линуксолюбивые модераторы пошли, трут неудобные комментарии на раз. А чего бы не стереть тогда уж и тот комментарий, на который я отвечаю? Религия мешает? Как можно любить free software и не любить свободу выражения мнения?
Какая религия? Видел я твой коммент, смесь спеси, хамства и невежества.
Ау? Это ты бсд имел ввиду, говоря про энтерпрайз? Ха.
Патчинг ядра и смена форматов вообще шедевр. Ау, у zfsonlinux тотже формат и версия, что и в бсд. Какой нафиг патчинг?
Такое ощущение, что виндовые вирусы стали поражать уже и вантузятников.
> Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.В ZFS это просто банальный кэш. Ни о каком tiering'е там сегодня речи быть не может.
>> Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.
> В ZFS это просто банальный кэш. Ни о каком tiering'е там сегодня
> речи быть не может.Потому что он там в пень не уперся. Она чутка для других задач, нежели самодельное гогно.
Нет, в ZFS ничего похоже нет.
Это типа FusionDrive в Mac OS X?
В начальном посте сказано что данные кэшируются в озу. А чего произойдет если будет падение ноды по питанию ? Большие дедьки типа нетаппа гонят данные через nvram кэш, а тут через озу.
> А чего произойдет если будет падение ноды по питанию ?закупка новых бесперебойников
LOL. Ну это обойтись малой кровью. Конечно же имеется ввиду если нода вылетела в силу каких-то причин.
> LOL. Ну это обойтись малой кровью. Конечно же имеется ввиду если нода
> вылетела в силу каких-то причин.Чо, чо... только своевременные бэкапы, переодические инкрементальные бэкапы.
Такие вещи продумывают ещё до закупки оборудования. Критически важные данные
хранят на соседнем RAID61. Если работаш с БД - репликация, с файлам - сетевое зеркалирование/синхронизация.
>> А чего произойдет если будет падение ноды по питаниюне закоммитить изменения на диск
Не попахивает ли тут Venti?
> Например, близкий аналог flashcache может поддерживать отдельный кэш из SSD-накопителей поверх традиционных дисков, дублируя данные, в то время как BTIER максимально эффективно использует доступное пространство.А эта эффективность нужна?
Например, размер СХД 12ТБ, для оптимизации работы достаточно SSD скажем на 200ГБ.
Т.о. получаем "эффективность" 200/12000=1.6%
Но для надежности придется использовать 2 зазеркаленых диска SSD.
Мне кажется, что использовать SSD как кэш было бы более эффективно и надежно.
Нужна.
Во-первых, реализации аля кэш уже есть. Пользуйтесь.
Во-вторых, вот есть у меня ноут. Двд сменил на ссд. Вот сабж более чем к месту тут.
В-третьих, в случае кэша в/в всё равно дублируется. Что может быть критично. Графики выше.
Ну все. Теперь линукс точно готов для десктопа
Дааа ... теперь походу десктоп не готов для линукса :)
А можно простыми словами для чего оно нужно?
Вот есть у вас очень быстрый ссд, но он мелкий и относительно дорогой, и есть очень большой и дешёвый, но медленный жёсткий диск. Вы можете сами раскладывать то, что по-вашему, требует быстрого чтения и редко изменяется на быстрый ссд, а жёсткий диск использовать для данных, которые не так критичны к скорости загрузки. Но как определить что куда класть, да и следить за этим нужно. В общем, слишком много мороки. А эта технология позволяет залепить из ссд и жёсткого диска один раздел, а потом сама ведёт статистку использования и решает какие файлы (или блоки) на какой физический носитель пихать. За счёт этого конечный пользователь получает и высокую скорость загрузки и преимущества большого и дешёвого носителя.
